Page 1 of 2   next page »

Since Web 2.0 kicked off scarcely a day goes by without a headline targeting mashups and their enablers, AJAX and Web Services, as the next hot Web technologies. Mashups are Web sites that integrate a variety of services (e.g., news feeds, weather reports, maps, and traffic conditions) in new and interesting ways. Just take a look at Zillow.com, which provides instant home valuations plotted as thumbtacks on a map (Figure 1), or HousingMaps.com, which marks listings from craigslist.org as captions on a map, and you'll get a clear picture of the power behind converging data sources.

Google Maps is often identified as the disruptive force that spawned the mashups movement. The popular mapping service is now the home of more than 600 mashups according to ProgrammableWeb.com. Why the hype? Google Maps provides a simple JavaScript API that makes geo-spatial data, a historically cost-prohibitive service, easily accessible to a broad audience with a variety of technical skills. Web 2.0-savvy developers are highly attracted to this simplified and accessible approach to SOA development because it no longer confines their Web site functionally to a user interface, but opens the site up to syndicate functionality and data. Thus a site's success is no longer based on traffic alone, but on the number of subscribers. The proliferation of these services is mind-boggling. ProgrammableWeb.com, a mashup-tracking site, has more than 300 registered services available to mix-and-match, and more than 1,100 registered mashups. Roughly 2.8 new sites are registered every day.

Despite the momentum behind mashups, corporate IT departments only consume a handful of the services used by the mashup crowd. Instead, businesses have constructed their own ecosystem of services in parallel to the Web 2.0 movement. The problem with corporate adoption of mashups is two-fold. First, the concept of mashups is often considered a social phenomenon or a grassroots effort tangential to enterprise software. Second, there's no clear path to integrate business services with those available on the Web. This second issue is due, in part, to the impedance mismatch between business services and mashup services. Mashup APIs are generally written in JavaScript, while services deployed to the enterprise are developed using Java or .NET technologies. Thus, both perception and technology define the barriers to corporations adopting an enterprise mashup strategy that incorporates external services such as Google Maps.

Despite these initial hurdles, the services and collaborative development style that mashups provide have created a buzz among enterprise software vendors. IBM recently announced a R&D effort to create an enterprise "mashup maker" - a tool that lets developers blend corporate services with external services, and rapidly assemble applications. More recently, Oracle announced the Oracle WebCenter Suite, which uses JSR-168/286 and WSRP 1.0/2.0 to mix-and-match corporate services using a combination of AJAX and Java portlets. The "mashup maker" and "mashups as a portal" are both interesting concepts and quite possibly the future of rapid business application development. In a later installment we will take a closer look at JSR-168/286 and WSRP 1.0/2.0 and how these standards can be used to create enterprise mashups that mix corporate services. Meanwhile, the aim of this article is to give application developers, specifically enterprise Java developers, the tools to build meaningful enterprise mashups that take advantage of the popular mashup services.

Today's Toolkit
Business services developed with Java technologies generally fall into one of four categories: Enterprise JavaBeans, Spring, POJOs, or Web Services. The problem is that mashup APIs are generally implemented with JavaScript. There are a few services such as Flickr that offer parallel APIs written in Java, .NET, and a number of other technologies. For sites that don't offer a Java API, developers are left to their own devices to bridge the integration gap between JavaScript and Java. Existing Web Services provide the most direct path to integration, and processing XML over XMLHttpRequests, though tedious, is a relatively established method of binding AJAX-enabled interfaces to Web Services. There are a number of JavaScript packages, such as the vcXMLRPC Library, that help simplify the handling of XML-RPC requests. However, integrating Java-centric applications built with Spring or Enterprise JavaBeans makes for a more interesting problem. The first solution that comes to mind is to expose an existing EJB or Spring application as a Web Service, a simple task given that both EJB 3.0 and Spring 2.0 support remote method invocations via a Web Service end-point (JSR 181). Despite the simplicity of creating such a Web Service, we are still presented with the cumbersome task of processing XML with JavaScript.

Java-to-AJAX libraries such as Direct Web Remoting (DWR) and JSON-RPC-Java offer a simple alternative by marshaling Java objects to JavaScript and letting JavaScript communicate directly with server-side Java objects (Figure 2). So developers can interact with Java objects as if they were client-side JavaScript objects, negating the need to work with XML. For instance, by using a Java-to-AJAX library we can expose operations performed by a session bean to an AJAX-enabled Web interface and then combine the outcomes of those operations with a mashup service. An added benefit of the servlet architecture used by DWR and JSON-RPC-Java is that both libraries can take advantage of the authentication and session management provided by Java EE 5. Despite the similarities shared by both DWR and JSON-RPC-Java, DWR has a few advantages, two of which are the ability to handle recursive object structures and its integration with a large number of other libraries and frameworks such as Spring, Struts, JSF, Rife, WebWorks, and Hibernate. Thus, the amalgamation of DWR, enterprise Java services, and JavaScript mashup APIs blends the flexibility and creativity behind Web 2.0 with the reliability, scalability, and security of the Java EE architecture without needing to manipulate XML documents.

Building an Enterprise Mashup
The example application referenced in this article uses the Java Persistence API (JPA), Google Maps, and DWR to create a simple customer address book application (Figure 3). The application plots customers by address on a map using Google Map's JavaScript API. Users can update an entry by selecting a marker on a map and editing associated values in a form. Changes are committed by clicking the update, remove, and create. All records are stored in an Oracle database and persisted using the JPA.

The application provides a simple end-to-end example that demonstrates one method of blending external mashup services with Java-centric business services. Note that this article does not provide an in-depth look at DWR, JPA, or Google Maps. Instead, the intention is to prove the simplicity of integration between these technologies and enable you, the reader, to build your own enterprise mashups that leverage popular JavaScript APIs like Google Maps. Please refer to the references included in this article for more information on DWR, JPA, and Google Maps.

Setting up the DWR servlet is simple and can easily be added to an existing application. To install the servlet, first put the DWR jar in the lib directory under the WEB-INF directory, and add the following lines to the web.xml descriptor:

<servlet>
   <display-name>DWR Servlet</display-name>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>uk.ltd.getahead.dwr.DWRServlet
   </servlet-class>
   <init-param>
     <param-name>debug</param-name>
     <param-value>true</param-value>
     </init-param>
  </servlet>
  <servlet-mapping>
     <servlet-name>dwr-invoker</servlet-name>
     <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

Next, DWR must be made aware of the Java objects that should be remotable as JavaScript interfaces. The Customers object is the single JPA entity used in the application and maps to a Customers table (Listing 1). A session façade named JavaServiceFacade is used to encapsulate operations on the Customers entity object (Listing 2). Both the JavaServiceFacade and Customers classes must be registered with DWR to interact with each object via JavaScript. To do so, simply create a dwr.xml file in the WEB-INF directory as follows:

<dwr>
   <allow>
   <create creator="new" javascript="JavaServiceFacade">
   <param name="class" value="com...JavaServiceFacade"/>
     <include method="queryCustomersFindAll"/>
     <include method="queryCustomersFindById"/>
     <include method="mergeCustomers"/>
     <include method="persistCustomers"/>
     <include method="removeCustomers"/>
   </create>
   <convert converter="bean" match="com...Customers"/>
    </allow>
</dwr>

The dwr.xml descriptor defines a subset of methods on the JavaServiceFacade object to expose and declares a JavaBean converter to marshal the Customers entity as a return value or method parameter. In this example, two query methods as well as the merge, persist, and remove operations contained in the JavaServiceFacade are exposed. Once the dwr.xml file is created, three JavaScript files must be imported in the JSP or HTML pages contained in the application. This enables the use of the JavaScript representation or remote interfaces of the JavaServiceFacade and Customers Java objects. The imports are as follows:

<script type='text/javascript'
src='../dwr/interface/JavaServiceFacade.js'></script>
<script type='text/javascript' src='../dwr/engine.js'></script>
<script type='text/javascript' src='../dwr/util.js'></script>

Note that only the JavaScript interface for the JavaServiceFacade is imported because it's the sole object that contains methods that are invoked explicitly. With the web.xml file configured, the dwr.xml file created, and all the necessary JavaScript files imported, the methods contained in the JavaServiceFacade are now accessible from a Web browser via JavaScript. To test the installation, open a Web browser and navigate to http://localhost:[port]/[nameofwebapp]/dwr. A screen should appear resembling that shown in Figure 4. Figure 5 shows all of the methods on the JavaServiceFacade that are accessible remotely.

The next step is to integrate the JavaScript interface for the JavaServiceFacade with the Google Maps API. To use the Google Maps API, an activation key is required. Visit www.google.com/apis/maps/signup.html to obtain a key. Keys are mapped to a unique URL so the key included in this article will only work with the source code provided. To use a key different from the one included in this example, simply add the following import statement to the top of your JSP page, replacing the key contained in the URL with the one obtained from the Google Maps registration page. The import below is required in the JSP page irrespective of the activation key used.

<script src="http://maps.google.com/maps?file=api&v=2&key=value"
type="text/javascript"></script>

With both DWR and Google Maps configured, DWR calls to the JPA façade and the Google Maps API can be integrated. A simple load function and a div tag, in this case named "map," are used to initialize the mapping UI. The load function is assigned to the onload attribute of the body tag in the HTML or JSP page. Note that if you're using Dojo you must use the frameworks dojo.addOnLoad function instead of the onload attribute. The load function used in the example application not only initializes the Google Maps API, but also calls the queryCustomersFindAll function defined in the JavaServiceFacade JavaScript interface to retrieve all the Customers objects. The JavaServiceFacade.queryCustomersFindAll function accepts a reference to another function as an argument. The argument handles the return value of the JavaServiceFacade.queryCustomersFindAll function as an asynchronous callback. In this case the callback handler is the processCustomers function, which processes the list of Customers returned by the JavaServiceFacade.queryCustomersFindAll function, plotting each Customers object on the map as a marker (Figure 6).

// Called on intial page load
function load() {
   if(GBrowserIsCompatible()){
     // Remotely call Java method
     // to extract all Customers
     JavaServiceFacade.queryCustomersFindAll(processCustomers);
     // Initalize map object
     map = new GMap2(document.getElementById("map"));
     // Add navigation controls to map
     map.addControl(new GSmallMapControl());
     map.addControl(new GMapTypeControl());
     // Initalize geocoder
     geocoder = new GClientGeocoder();
   }
}

// Plots an array of Customers on
var processCustomers =
   function(customers){
   // test if array is null
   if(customers != null &&
     typeof customers == 'object'){
     // iterator over array of customers
     for(var i=0;i < customers.length; i++){
       // plot each customer on the map
       addMarkerForCustomer( customers[i] );
       }
   } else {
     alert("Customer record is null!");
   }
   // Set map center and magnification
   map.setCenter(
     new GLatLng(37.4419, -122.1419), 9);
}

Plotting markers with Google Maps requires three simple steps. First, a geo-spatial point on the map is obtained by using the Google geocoder API. Second, a GMarker object representing the geo-spatial is created. Finally, the marker is added to the map at the given point by calling the addOverlay function on the current instance of the GMap2 object - the object that represents the map displayed in the UI. Below is the function used to plot a Customers object as a marker. In the example a geo-spatial point is generated with the address information provided by the Customers object. A helper function is used to create a new GMarker, which is then added to the map object with a call to the addOverlay function.

// Plots a customer on the map as a marker
function addMarkerForCustomer(customer){
...
   // create address string
   var address = customer.address + ...;
   // create point using geocoder
   geocoder.getLatLng(
     address,
     function(point) {
     ...
     // create marker
     var marker = createMarker(point, customer);
     // overlay marker on map
     map.addOverlay(marker);
     }
   );
...
}

Page 1 of 2   next page »