Michael Gilfix Online

Most articles around use of AJAX and JSR168 Portlets tend to focus on how AJAX techniques can be used to provide more dynamic visual display capabilities to Portlets. However, AJAX techniques (particularly the use of XMLHttpRequest calls can be used effective to provide inter-Portlet communication in a portable manner. Let me explain what I mean by portable: Full Portlet containers, such as WebSphere Portal Server provide additional APIs beyond the JSR168 Portlet standard to enable inter-Portlet communications. These contains offer a lot of function, but come at the cost of heavier weight infrastructure. Increasingly, support for JSR168 Portlets are appearing in lighter-weight containers. For example, the release of WebSphere Application Server V6.1 last year included support for JSR168 Portlets embedded in web modules (WAR files) in J2EE applications. WAS supports a bare-bones Portlet container, sticking only to the JSR168 specification, and providing no means for inter-Portlet communication. Portlets that are written for WAS 6.1 are considered forward compatible, in that they can be deployed in WebSphere Portal. The converse is typically not true, since WebSphere Portal contains many features that go beyond the JSR. Use of AJAX techniques can provide a design that is both forward compatible between lighter and heavier weight Portlet contains, and should allow for portability between different Portlet containers.

For those not familiar with Portlets, think of a Portlet as providing the graphical content for a portion, or visual unit, of a web page. The Portlet's sole responsibility is to render that unit of display for the page. Page content is assembled through a process called aggregation; each page has a notion of layout (typically expressed either as a JSP or in XML format) and a Servlet-like method on each Portlet is invoked by the container in order to render each piece of the aggregated page. The bare-bones Portlet container provided with WAS 6.1 does not provide aggregation capabilities. This must be done by a fronting JSP or Servlet. More advanced Portlet containers provide other capabilities, such as navigation between pages of content, filtering of content according to user roles, and even personalization of content.

The basic idea behind Portlet approach (as for many other similar systems, including the Drupal system used for this blog is a sort of UI componentization, allowing reuse of visual content and function, and promoting separation in the backing code. Portlets are intended to be mixed and matched to construct page content, either directly by the users or by the administrators of the page. Sometimes, Portlets are provided in groups that are intended to work together to provide more advanced visual display. This approach still allows the user to have control of layout and visual elements via the Portlet container, and still promotes reuse of content and capability in the code.

So, how to enable AJAX techniques with JSR168 Portlets? The best article I've found on the subject is from the a Sun Developer Network article. Here's a summary of the technique described in the article: each Portlet has an associated HTTP Servlet component that handles the AJAX communication. On load of the page, content is aggregated or generated using the usual Portlet techniques. The generated content typically has some visual element, such as a button, or Javascript code that calls the AJAX function which makes an XML HTTP request to the Servlet. The Servlet then typically sets some context information in the HTTP session based on the Javascript request before dispatching the request directly to the JSR168 Portlet code in order to render the dynamic content. The implementation architecture looks like this:

Reproduced from Greg Ziebold and Jai Suri's article

This technique is an excellent way to approach inter-Portlet communication in a Portable manner. It pushes the coupling of the Portlets out to the client, rather than relying on non-standardized Portlet techniques. In addition, it avoids requiring a page refresh when one Portlet updates another. An example of inter-Portlet communication might be when you have one Portlet that serves a filter for the content in another. Perhaps this was done to allow reuse of the filter UI on multiple pages. When the user updates the filter, it can result in an AJAX request that applies the new filter to the other portlet on the page, without requiring a page refresh. In addition, it also preserves portability between containers.