The portlet specification defines a standard infrastructure for Web portals in J2EE. While this infrastructure helps reduce proprietary code in HTML applications, it poses a challenge in Rich-Internet Applications (RIA) that have a hard time managing the state of their user interface appropriately. An efficient solution rests with RIA approaches that are based on the half-object + protocol design pattern, a pattern that maintains the state of the user interface (UI) on the server side, a crucial enabler for rich-client portlets.

Portlets as defined by the Java Specification Request (JSR) 168 are an emerging standard in developing Web portals. They allow aggregating content, server-side Java applications, and SOAP-based Web Services in a coherent browser front-end that can be configured flexibly.

The Portlet Switching Issue
Unfortunately, this new standard has a shortcoming: it's incompatible with most rich- client technologies. The problem is that portlets must maintain the state of their UI when the user switches back and forth between them. Typical rich-client technologies can't cater to this need, because an active page's UI will be discarded whenever a new browser page is loaded. So the state of a portlet's UI is lost when the user switches to another portlet, and can't be restored when the user returns.

Tackling this issue requires that the UI's state be saved when a portlet is switched. Doing this is difficult and expensive for technologies that execute their entire presentation layer on the client. Since there's no generally available option to save the browser state on a client, the state has to be saved back to the server and restored from there. Doing this is both ineffective and complex (see Figure 1).

Server-Side Proxy Solution
A solution to this problem is to choose a server-side UI model from the outset. Some Java-based RIA products follow this approach. These products offer a server-side proxy library that applies the half-object + protocol design pattern to the client-side UI widgets, as described in the article Server-Side Swing for Rich Internet Applications.

This server-side proxy approach fits well into the portlet infrastructure for the following reasons:

• Architecture: The architecture is the same as for HTML applications. The split between client and server is located in the presentation layer (see Figure 2). There is no application-specific code on the client that has to be saved and restored when portlets are switched.
• Programming model: The programming model is server-side, as with HTML applications. This means that the APIs for data exchange between portlets are easily accessible, so rich-client portlets can share business logic as well as data with HTML portlets.
• Runtime model: At runtime the UI is rendered by a presentation engine that's independent of an individual application, exactly like a browser. In a portlet context, this engine executes as an applet in the browser (in other contexts, it can also execute in a standalone JRE). It will typically be cached by the browser and doesn't have to be loaded from the server when a portlet is started or re-activated.
• Built-in synchronization: The core of the half-object + protocol design pattern is the transparent and optimized synchronization of state between the peer objects across two address spaces. This means that the logic to synchronize the client-side UI widgets and their server-side peer objects comes with the base library. And it's typically optimized for minimal network traffic, transferring only the visible parts of a UI to the client, compressing data, etc. As a consequence, saving and restoring the client-side representation of the UI - as required when portlets are switched - is a task that can be executed efficiently and without a lot of additional and complex code.

Given this proxy approach, the portlet switching issue can be resolved easily and in a way that performs efficiently. The base library already takes care of synchronizing the client-side UI with the corresponding server-side model at runtime. When a portlet is left, the UI can be discarded because the server-side session maintains its state. When the same portlet is re-activated, all that's required is to re-start the applet, re-connect to the session, and retrieve and display the visible parts of the UI (see Figure 3).

Some of the products mentioned can execute this scenario. Typically, it's done with pause and resume methods, where the former does some cleanup that lets the UI be scrapped, and the latter restores the UI from the server.

Note that pause and resume are attractive for other scenarios as well, for example in situations where users want to switch their working place, or recover from a client crash. For this reason, pause and resume are ideally externalized in an API.

Moreover, the portlet integration can be wrapped in a configuration option, so that any application can be deployed as a servlet, EJB, or portlet without changing the application code.

Summing up: portlets are an attractive standard for developing Web portals. Delivering rich-client applications as portlets is a major challenge, except for approaches that rely on the half-object + protocol design pattern. Applied properly, this pattern enables portlet integration of Rich-Internet Applications (RIA) merely as a matter of the deployment configuration.

References

• AltioLive: www.altio.com
• AppProjector: www.asperon.com
• Canoo UltraLightClient: www.canoo.com/ulc
• Classic Blend: www.appliedreasoning.com/products_what_is_Classic_Blend.htm
• Droplets: www.droplets.com
• NexaWeb: www.nexaWeb.com
• RSWT: http://rswt.sourceforge.net
• Thinlets: www.thinlet.com
• Gerard Meszaros: Pattern: Half-Object + Protocol; in Pattern Languages of Program Design; James O. Coplien and Douglas C. Schmidt, eds. Addison-Wesley, © 1995, ISBN 0-201-60734-4).
• Bernhard Wagner: Server-Side Swing for Rich Internet Applications: http://javadesktop.org/articles/canoo/index.html