In my previous article, "Enterprise Mashup Services: Real-World SOA or Web 2.0 Novelties?" (JDJ Vol. 11, Issue 12), I discussed how a Java-to-AJAX library such as Direct Web Remoting (DWR) can bridge the gap between mashup services implemented with JavaScript and business services written in Java, allowing developers to blend corporate services with external services such as Google Maps. The problem with this approach is that it relies on AJAX as an integration point, which entails a fragile development platform as well as the need to maintain browser-specific code due to idiosyncrasies in browser support for JavaScript - the primary technology behind AJAX. In addition, JavaScript lacks a standardized approach for componentizing code, making applications written in it difficult to consolidate and reuse. The solution to these shortcomings is to pair AJAX with a component framework. JavaServer Faces (JSF) provides this foundation and eliminates the complexities of JavaScript - besides providing rich integration with the Java EE platform.

A mashup component is a custom JSF component that encapsulates the code that operates on a mashup API. Once created, the mashup component eliminates the need to work with JavaScript. Thus the code is both simplified and easily reused, making the API accessible to both JavaScript experts and less-experienced developers. The intent of this article is to build on the concepts introduced in the previous article and present the tools to create enterprise-ready components that encapsulate mashup services.

Rich Components Versus Mashup Components
On the surface, JSF components that abstract mashup APIs appear no different than those that encapsulate AJAX functionality. In fact, the concepts that define both components are the same; it's the philosophy behind the component definitions that differs. AJAX-enriched components abstract the complexities of JavaScript and provide interactive visual effects. JSF components that encapsulate mashup services are created with the same intent; however, mashup components package both visual effects and interactions with services. So mashup components represent Service Oriented Architectures (SOAs) at a micro level within a larger composite application. The example used in this article is a component that blends Google Maps with the Yahoo! Geocoding API. The crux of this solution is the tying of JavaScript events to event handlers implemented with Java code. This marriage lets mashup services work in conjunction with those implemented on the Java EE platform, which in the example are isolated to services provided by the JSF-managed bean facility.

Shale Remoting
The Shale Framework, which can be found on the Apache Web site (http://shale.apache.org/), provides a rich Web development framework that extends JSF. Instead of going into the numerous features that Shale provides, I'll focus on a single aspect, Shale Remoting, which maps a server-side resource such as a static JavaScript file or a method associated with a managed bean to a URL. For example, Shale maps the URL faces/remote/hellobean/welcomeUser to helloBean.welcomeUser(), which calls the welcomeUser method associated with the helloBean managed bean. The URL faces/static/com/thepeninsulasedge/scripts/maps.js identifies a script file located in a Java archive (JAR) under the package structure /com/thepeninsulasedge/scripts/.

In short, Shale Remoting provides a simple mechanism to implement AJAX functionality in custom JSF components that would otherwise require the implementation of a custom PhaseListener or ViewHandler to handle XMLHttpRequests and serve static resources. In this article, Shale is used to map JavaScript event listeners to methods defined in managed beans. More specifically, it's used to tie Glisteners - JavaScript functions that respond to events triggered by Google Map's GMap2 object - to methods implemented in Java. Note that DWR could be used to accomplish this task; however, Shale provides tighter integration with the JSF managed bean facility as well as the ability to serve resource files from archives.

Using Shale Remoting
In the example that follows we construct a simple managed bean (HelloBean) that defines a method (welcomeUser) that's invoked by a JavaScript function in Figure 1.

The function is called when a user enters his or her name into a text field, and a response for each event is displayed in a div below the text field. Listing 1 shows the complete JSP page. The HelloBean managed bean defines three methods: welcomeUser, getParam, and writeResponse.

The latter two methods are simply utility functions. The getParam method extracts a value from the request string via the RequestParameterMap for a given parameter. The writeResponse method writes a response to the FacesContext, which is rendered to the client and processed by an XMLHttpRequest handler (more on this later).

The welcomeUser method is invoked with the URL faces/dynamic/hellobean/welcomeUser. This method extracts the value associated with the username parameter from the request, manipulates the extracted value, and then writes a response to the client using the writeResponse method. A parameter can be passed to the welcomeUser method by using the URL faces/dynamic/hellobean/welcomeUser?username=Ric, which calls the method and provides a name/value pair as a parameter. Accessing the URL via a browser provides a simple way to test this, and should display a response similar to that shown in Figure 2.

Once mapped to a URL, the welcomeUser method is easily tied to an event listener that uses the JavaScript XMLHttpRequest object to post to the URL mapped to the method innovation. The code to perform this operation is in Listing 2 and is contained in a file, scripts.js. (Listings 2-11 can be downloaded from the online version of this article at http://java.sys-con.com).

For simplicity's sake, the Prototype framework (http://prototype.conio.net/) is used to manipulate XMLHttpRequest objects - the AJAX.Request function handles each request. The function requires a URL, which is used to call the welcomeUser method defined in the HelloBean managed bean. The AJAX.Request function also accepts a JavaScript object as an argument, which defines the request method (for example, POST or GET) as well as the parameters to append to the request string. The final argument passed to the AJAX.Request function identifies a handler used to process the response initiated asynchronously by the request. In the example, the response is handled by the displayResponse function, which writes the text of the response to a div identified by the ID response. The $(...) notation is shorthand for the document.getElementById() JavaScript function and is a feature of the Prototype framework.

The welcomeUser function is fired on the onkeyup event of the text field. With each keystroke the user enters in the text field, the welcomeUser function is called, which invokes the method defined in the managed bean. In essence, the managed bean contains the logic to respond to each JavaScript onkeyup event.

JavaServer Faces Components Now that we have identified a mechanism to link Java code to JavaScript, let's quickly review the key facets of a JSF component before putting the pieces together to build our first mashup component. There are essentially three elements to a JSF component: behavior, presentation, and tag definition. (Figure 3 shows the class definitions for each element of the component used in this article.)