When speaking of Web application development today, it's difficult to ignore the overwhelming influence of the Portlet Specification (JSR-168). Even before the specification was formally finalized by the expert group, the Java world saw older CMS application implementing it and new portal software arrivals in the market. The proverbial "gold rush" to develop new applications as portlets, refactor existing applications to comply with the specification, and deploy new Web sites on portal software is not without good reason. The Java community was lacking a unifying specification in the Web tier, where all previous work could be brought together and leveraged, removing the tedious tasks developers once had to endure when creating most common Web applications.

Portals, as defined by the specification, are a new arrival in the market and much of the fanfare is due to just that. They have been touted as the "magic bullet" of Web application development and a new standard in developing scalable, flexible, and pluggable software components. Having lived through the dot-bomb era, we are not alone in knowing that the "newness factor" and the endless search for the "killer-app" can often cloud the judgment of decision makers regardless of functionality.

Although portals, as they exist today, promise to provide improved functionality by building on and consolidating previous work in this area, features and functionality should be the main determiners of whether to deploy a portal, a CMS, or develop a Web application using JSPs and servlets. However, before considering deploying a portal, you must have a solid understanding of what a portal actually is, what technologies are commonly found in them, and even appreciate how portlets interact with the portal.

Portal Overview
Reading section 2.1 of the Portlet Specification, a portal is defined as:

... a web based application that - commonly - provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different set of portlets creating content for different users.

As the specification states, portals commonly allow for personalization, SSO, and content aggregation. Figure 1 shows elements commonly found in open source and proprietary portal software.

Before we continue, it's important that you understand the items in Figure 1. It's likely that these functions alone will dictate whether you decide on implementing portal software. Frankly, these are among the most important and labor-intensive features to develop for most Web applications, so allowing a portal to perform the heavy-lifting exercises may be in your best interest.

• Content aggregation: Portals have the ability to present the user with information from different sources, displayed within portlets on a portal page (see Figure 2).
• Caching, clustering: Like most enterprise Web applications, portals tend to leverage existing caching and clustering technologies for increased performance and reliability.
• Security and SSO: The ability of a portal to integrate with an existing security schema used for authentication and/or authorization.
• JSR 168 compliance: Java portals, open source or not, all share this common bond as a unifying theme, allowing for portability across all vendor platforms.
• Content management: The ability of a portal to serve and allow administrators to manage content.
• Personalization: The capability of a portal user or administrator to personalize the portal and/or the individual portlets.

Of course, the diverse group of portal vendors presently in the market will offer differing sets of components to leverage within their portal, even addressing points where the Portlet Specification in its current state falls short, such as Inter-Portlet communication, portlet filters, extending the CSS support, and integration of existing frameworks (e.g., Struts or JSF).

In addition to the above cases of technology commonly found in portal software, the specification also defines the concept of a portal page. A screenshot of JBoss Portal using a custom layout and theme is used as an example here (see Figure 3).

The process of generating a portal page works like this (see Figure 4):

1. Portlet generates markup and dispatches it to the portlet container.
2. The portlet container sends the portlet content to the portal.
3. The portal adds decorations to these fragments, e.g., titles and window controls
4. The portal places a new decorated fragment on a page.

JSR 168 seeks to define the contract between the portal and the components running inside it. If you elect to deploy a portal, it is this specification you should adhere to, ideally. Some vendors may have their own proprietary APIs that, we believe, should be avoided for standard portlet development. These proprietary APIs result in vendor lock-in scenarios affecting the portability of the portlets created and increased maintenance and training costs in the long run. We would invite anyone comfortable developing servlets to read JSR 168, as it's very easy to read.

Portlet Overview
This section provides a brief overview of some of the items covered within the specification document. We made an effort to not describe in deep detail all the technical facts in the portlet API. Frankly, that was not the goal of this article, as countless other articles and books have covered these points in the past. This section will cover items at a high level that we see as important differentiators for those evaluating the use of portal software.

Portlet, Defined
A portlet is a Java application, packaged in a WAR file, and managed by the portlet container. They are pluggable components responsible for presenting fragments of data from information systems. Portlets can be as small as a content portlet that simply displays a fragment of HTML, or as large and complex as a CRM or e-commerce application.

The Portlet Life Cycle
The life of a portlet can be summarized by listing the specific methods that are called during a transaction:

1. init(PortletConfig): Called by the portlet container, this method initializes the portlet using a configuration object. A sample configuration is shown in Listing 1. Configuration information for an individual portlet can be accessed at any time after initialization.
2. processAction(ActionRequest, ActionResponse): This method is called if the client initiated a call request from an action URL. If the client's request is a render URL, this method is not called.
3. render(RenderRequest, RenderResponse): This method generates the content upon being called by the portlet container.
4. destroy(): Called by the portlet container when it determines the portlet should be removed from service.