Fundamentally, a service-oriented architecture facilitates the creation of dynamic data services within the enterprise and enables the enterprise developer to create composite applications that leverage any number of these services. Web 2.0 promises a rich Web experience where users can collaborate in effective and, hopefully, rewarding ways. If we combine these two phenomena we can begin to realize significant new efficiencies in the way members of an enterprise community interact amongst themselves and with corporate data that is constantly changing around them. Collaborative enterprise mashups and other next-generation Web applications are on the horizon, but speculation in the development community is that there are fundamental gaps between the technologies needed to realize the apparent benefits. We will examine the state of Java presentation technologies in an effort to understand where the standards must go to facilitate the marriage of SOA and Web 2.0 concepts.
Standards form the foundation for SOA, but are nonexistent in the Web 2.0 world. A plethora of approaches are emerging to support Web 2.0 capabilities, most of which rely heavily on JavaScript implementations that leverage Ajax techniques. In the Java EE specification, JavaServer Faces provides the presentation layer, but its current revision pre-dates the popular emergence of Ajax techniques and Web 2.0 concepts. The extensible component architecture in JSF has proven to be well-suited to incorporation of Ajax techniques at the component level, but the problem with component-level Ajax techniques is that they exist within little silos of interactivity that circumvent the JSF lifecycle. What is needed is a more holistic approach to incorporating Ajax interactions within the JSF lifecycle. In particular, there are two areas that need to be addressed.
1. Improved User Interaction Model: The current user interaction model in JSF is form based, which is too crude to deliver rich Web 2.0 features. There is significant difference in the granularity of an Ajax interaction at the component level and the form-based submission model that JSF currently relies on. The types of interactions that should be possible include:
- A pure client-local JavaScript interaction with no server communication and no need to execute the JSF lifecycle. An example of this might be navigation through a calendar in a data-picker component. This model can be supported today with a component-level JavaScript implementation.
- A component-level Ajax interaction with no need to execute the JSF lifecycle. An example of this might be to populate a list based on current user input in a text field. The key here is that user interaction with the component affects only that component's presentation. Again this model can be supported today with a component-level JavaScript implementation.
- A component-level submit that causes the JSF lifecycle to execute. The results of the lifecycle execution will be new presentation that might impact multiple components in the page. An example of this is the completion of picking a date in a date-picker component with the result causing different scheduling information to be displayed. This form of interaction is not currently supported in JSF.
2. Incremental Presentation Update: In order for the 3rd interaction model to be achieved in an Ajaxian way (no page refresh), JSF requires an incremental update mechanism where only necessary changes to the presentation are applied to the page from one render pass to the next. This concept is illustrated below. It requires an Ajax bridge capable of assembling presentation changes server-side and reassembling those changes in the client-side DOM.
JSF Push Mode
An Ajaxified JSF implementation and most other Ajax approaches inherit a common characteristic from the legacy Web application model, that being a client-initiated interaction model. This means that presentation to the client only changes in reaction to a user interacting with the presentation. With Ajax techniques, this interaction is finer-grained than with legacy applications, but it remains client-initiated. Now, when you examine the dynamic nature of the SOA data model that backs the application and account for collaborative interaction with this dynamic data by multiple simultaneous users, it becomes clear that a mechanism to push dynamic presentation changes to the client is essential. It is the only way to achieve the true dynamic nature that the Web 2.0 model demands. Ajax push techniques, also referred to as Comet, have been proven in industry, and it is necessary for the JSF specification to incorporate a presentation push model. The incremental update feature described above already provides the Ajax-based update mechanism required to implement the JSF push model. Additionally, it is necessary to augment the JSF lifecycle to allow a forced render when application logic detects some state change that will affect client presentation. The basic JSF push model is illustrated below.
While the JSF push model is relatively straightforward to achieve, industry experience has shown that exposing a low-level forced rendering mechanism in the JSF API will be insufficient for developers to leverage effectively. Around the basic push mechanism it is necessary for the JSF specification to introduce rendering APIs that give the developer a clean and efficient mechanism for requesting forced rendering. Specifically the API should provide:
1. Triggered Rendering: The application developer should be able to define trigger points in the business logic that will cause a render request.
2. Group Rendering: A trigger point can affect a single client, multiple clients or all clients connected to an application. It is necessary to provide group management facilities for trigger rendering.
3. Scheduled Rendering: There are a number of convenient scheduling mechanisms that should be supported, including on-demand, delay and interval rendering. The scheduled rendering architecture should be extensible to support other custom scheduling requirements.
It is important that the triggered rendering mechanism be transparently efficient. With potentially a large number of triggers affecting a large number of clients in different ways, the onus cannot be placed on the developer to manage the rendering process. The triggered rendering implementation must coalesce render requests efficiently and handle necessary synchronization, all in a thread-efficient manner.
Multi-view Support
The existing session and request scopes defined for JSF are insufficient to support Ajax-enabled JSF applications where a user can have multiple active views onto the same application. Session scope can be used to maintain state that is common to all views, but is insufficient to handle state that is different in each view. Request scope is also insufficient as multiple simultaneous requests can be active. A new scope is required to manage the conversational aspects of Ajax-enabled JSF applications. The JBoss Seam initiative has introduced a conversation scope that essentially provides the additional scope required in JSF. Beyond facilitating multi-view support, a conversation scope provides additional advantages, such as the ability to effectively support bookmarking and back-button features in an application by clearly delineating a series of user interactions within a conversation.
Long-lived HTTP Requests
Referring back to the push model diagram above, you will notice that the mechanism requires an outstanding HTTP request be available to asynchronously satisfy a triggered render request coming from the application. Depending on the frequency of these pushed updates, outstanding HTTP requests could be potentially long-lived. The existing Servlet model does not scale well under long-lived requests as each request occupies it's own thread until satisfied. The Servlet model must be modified to handle long-lived requests in a thread efficient manner in order to support the push model. Again, there are several industry initiatives related to asynchronous Servlets and HTTP servers that the Java EE specification can draw on to define a solution.
Conclusions
There is little doubt that the SOA and Web 2.0 worlds are about to collide and that a new generation of collaborative enterprise applications are on the horizon. There is also little doubt that the existing Java EE standards do not fully address the requirements that Web 2.0 brings and that the JSR process must begin to take these requirements into account in the immediate term. There has, however, been significant progress in industry to address the emerging requirements and commercially viable solutions that extend existing Java EE infrastructure are available today. With the upcoming work on JSR 172 to produce the JSF 2.0 specification, it is essential that Ajax features are incorporated and that industry participants contribute relevant technologies to ensure that a standards-based solution can be made available in a timely fashion.
About the Author
Stephen Maryka is the CTO and co-founder of ICEsoft Technologies Inc. Before that he served as Principal Technologist at Wind River and was the vice president for technology and co-founder of AudeSi.
References
Wikipedia entries for "Ajax" and "Web 2.0"
When the worlds of SOA and Web 2.0 collide.
Edge Perspective with John Hagel: SOA Versus Web 2.0.
JBoss Seam: The Next Generation Web Framework.
