Introducing the Portlet Specification, Part 2

The Portlet API's reference implementation reveals its secrets

By Stefan Hepper and Stephan Hesmer, JavaWorld.com, 09/05/03

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

Enterprise portal vendors use pluggable user-interface components, known as portlets, to provide a presentation layer to information systems. Unfortunately, in the past each vendor defined its own portlet API, producing incompatibilities across the industry. To standardize the process, the Java community launched Java Specification Request (JSR) 168: the Portlet Specification.

Part 1 of this two-part series examined JSR 168 in detail. This final article focuses on the Portlet API's reference implementation (RI), also known as Pluto. The RI provides a working example portlet from which you can launch your own development efforts.

Read the whole series on the Portlet Specification:

This article's first section describes the RI's architecture, including the portlet container's plug-in concept and how to reuse the container in other projects. The second section explains how to install and use the RI, as well as how to quickly deploy portlets. The article concludes with a series of progressively more complex portlet examples.

Note: You can download this article's source code from Resources.

Pluto's architecture

Let's begin by examining Pluto's architecture and underlying concepts. First, we briefly explain the portal that runs the RI, and see where to find a portlet container inside a portal architecture. Next, we investigate Pluto's architecture in detail. Last, we look at how it solves one challenging item of the portlet container: portlet deployment.

The portal

Pluto normally serves to show how the Portlet API works and offers developers a working example platform from which they can test their portlets. However, it's cumbersome to execute and test the portlet container without a driver, in this case, the portal. Pluto's simple portal component is built only on the portlet container's and the JSR 168's requirements. (In contrast, the more sophisticated, open source Apache Jetspeed project concentrates on the portal itself rather than the portlet container, and considers requirements from other groups.)

Figure 1 depicts the portal's basic architecture. The portal Web application processes the client request, retrieves the portlets on the user's current page, and then calls the portlet container to retrieve each portlet's content. The portal accesses the portlet container with the Portlet Container Invoker API, representing the portlet container's main interface supporting request-based methods to call portlets from a portal's viewpoint. The container's user must implement the portlet container's Container Provider SPI (Service Provider Interface) callback interface to get portal-related information. Finally, the portlet container calls all portlets via the Portlet API.

Figure 1. The simple portal included with Pluto. Click on thumbnail to view full-size image.

The portlet container

The portlet container, the portlets' runtime environment and a core component of each portal, requires knowledge about the portal itself and must reuse common code from it. Consequently, the portlet container remains completely separated from every other portal component. That said, you can embed the standalone portlet container in any portal by complying with the portlet container's requirements, such as implementing all SPIs.