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. Figure1 shows elements commonly found in open source and proprietary portal software.



Before we continue, it is important that the items in Figure1 are understood by you, the reader. It is 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. (Figure2)

• 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.

• JSR168 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, Spring MVC, JSF).

Portal pages

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 (Figure 3).



The process of generating a portal page, works like this (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. Portal places new, decorated, fragment on a page.
   

JSR-168 seeks to define the contract between the portal and the components running inside it. If one elects to deploy a portal, it is this specification one should adhere to, ideally. Some vendors may have their own proprietary APIs that, I 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. I would invite anyone comfortable developing servlets to read JSR168, as it is quite similar to the Servlet Specification (JSR-53).

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 eCommerce application.

The portlet lifecycle

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 Figure 5. 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.
   

<portlet>
  <portlet-name>ContentPortlet_1</portlet-name>
  <portlet-class>my.cms.ContentPortlet</portlet-class>
  <supported-locale>en</supported-locale>
  <resource-bundle>Resource</resource-bundle>
  <supports>
    <mime-type>text/html</mime-type>
    <portlet-mode>VIEW</portlet-mode>
  </supports>
  <portlet-info>
    <title>Ferrari</title>
  </portlet-info>
  <portlet-preferences>
    <preference>
      <name>uri</name>
      <value>/default/side.html</value>
    </preference>
  </portlet-preferences>
</portlet>

Portlet modes

Portlet mode functionality allows a portlet to display different information, depending on which mode the user is interested in (the same can be said for window states, covered later). The portlet mode names given are rather obvious to anyone reading them as to what their function should be. Using a generic example of a WeatherPortlet, we can specul ate on the definitions for each of the default modes covered in the specification:

• VIEW -- doView(): Generates a content fragment displaying weather from NOAA.

• EDIT -- doEdit(): Allows a user to modify his or her preferences, say, forcing the portlet to only show the weather in Miami, FL, USA.

• HELP -- doHelp(): Displays a help HTML fragment with instructions on how to use the portlet.

Some vendors define custom portlet modes that your portlets can implement. Support for custom portlet modes is briefly defined in the specification, and is as simple as adding a custom-portlet-mode node to the portlet descriptor and any other vendor-specific modifications to the descriptor or the portlet class.

Window States

Window states control how much space any portlet takes up on any given page. They function when the portlet container passes the user’s desired window state to the portlet. The portlet can then modify the fragment of data to display or even change the window state while processing the action request. The use of custom window states, much like custom portlet modes, is briefly mentioned in the specification and implemented by some vendors. Must like custom portlet modes, the portlet descriptor must be modified to use the custom-window-state element. Window states are briefly explained below. Note that not all portal vendors translate the specification in the same way, leaving much of the window mode behavior up to the portal implementation:

• NORMAL: This portlet has a limited space and is probably sharing a page with other portlets.

• MINIMIZED: In this state, a portlet renders no output, or very little content.

• MAXIMIZED: Normally, this state implies that the portlet will take up all viewable area on the page. Often, it is the only portlet displayed on that page.

The future of portal software

A subsequent version of the portlet specification should begin in the near future. There seems to have been a delay for several reasons that I will not address here. Planned for future releases are topics such as:

• Interportlet-communication (IPC), allowing communication between portlets on events.

• Portlet filters, which are similar to servlet filters.

• Portlet markup extensions, where portlet will be able to modify the markup outside of the markup fragment.

Aside from additions to the portlet specification, there has been a trend by the portal industry to integrate outside technologies, augmenting their products feature sets. One could expect this trend to continue and expand, given the growing popularity and success of portal software.  Some of the technologies being integrated that are worth noting are listed here:

• WSRP: The WSRP specification allows for the creation of a distributed portal infrastructure. This facilitates a WSRP-compliant portals being able to display portlets from another WSRP-compliant portal.

• JCR (JSR170): Adoption of this specification seems to be universal in the portal space. It seeks to provide a common API to content repositories; allowing for architecture-agnosticism, and featuring support for versioning, locking, transactions, and searching, among other thing.

• Framework support: Facilitates the use of existing web application frameworks to be leveraged in portlet development, such as, JSF/My Faces, Struts, and Spring MVC. Figure 5 shows Sun's JSF CarDemo application running, as a MyFaces portlet inside of JBoss Portal.

The portal option

So now we must answer the question, "Are portals the magic bullet of web application development?" To answer this question, one must look at the functional specification for the particular application being developed. Simply because you are developing a web application does not mean you need to build or implement an existing portal. However, if your application specifications call for implementing some of the following, it would be wise to heavily consider using a portal:

• Single Sign-On

• Personalization

• Caching

• Clustering

• Content Management

• User and Role Management

• Security and Permissions Management

Consider also some of the questions that we encounter from those evaluating portal software in their development projects:

My proposed web application requires some of the features commonly found in portals, should I just develop my own proprietary architecture in-house then?

What I have found in the past when development teams create systems such as these, they tend to cobble in random odds and ends to fill the requirements listed with little consideration given to how all these disjointed parts will work together, if the component will be maintained in the future, will there be someone responsible for keeping up with the particular component, or if support outside of a mailing list is even offered for that particular component. During the development of JBoss Portal, we stayed away from creating what we refer to as a "Frankenstein Project", and leveraged technologies that were proven in production environments (Figure 6) and supported in-house by the lead developers themselves. This philosophy aided us in identifying problems when they popped up, and having the knowledge on-staff to deal with them. How comfortable are you allowing your developers to pick and choose random components from the internet and glue them together? Leveraging portal software to handle the heavy-lifting and intricacies of a web application’s development allows developers to concentrate on portlet development, which is probably the integral part of the business anyway.



Do I need a CMS or a Portal?

The line between each is a blurry one. Portals tend to offer CMS capabilities, in general, on par with all the features traditional content management systems do. The main differentiator between a "pure CMS" and a portal, is adherence to the portlet specification, or allowing JSR168-compliant portlets to be deployed within the container. So you see, a portal can have CMS capabilities, but not all CMS are portals. Aside from this one dissimilarity, most CMS offer the same feature-set as portals.

I will also say that I am cautious of traditional CMS that later cobble-in support for the portlet specification. Having our own JBoss Nukes CMS, we can attest to the difficulties inherent in performing such a refactoring of the core architecture. Sure, it cost us in terms of time-to-market, but starting from scratch with a new portal architecture bought us endless flexibility and scalability. Cutting corners is not an option and I would be wary of any CMS-vendor-turned-portal-vendor for this reason.

Wouldn't retraining my staff to develop portlets nullify all economic gains compared to creating our own web application with existing competencies?

If your developers are savvy enough to tackle SSO, personalization, internationalization, caching, clustering, etc. and make it all accessible via servlets and JSPs, they are more than able to absorb all the technical knowledge found in the portlet specification in a short amount of time. After all, the portlet specification is extremely comparable to the servlet specification. The main differences between the specifications are listed here:

• Portlets are not tied to specific URLS, making use of the API to create URLs that are parsed through the portal server and eventually execute within a specific portlet.

• Many instances of portlets can co-exist on any assigned page.

• Portlets leverage Portlet Modes and Window States, allowing for different content to be rendered depending on a user's desire.

• Portlet generate content fragments.

• Portlets are written to the javax.portlet package.

There are close to a dozen major portal players in the market. Which one should I choose?

Being JBoss Portal developers, it would be seen as biased for us to evaluate the different players and furnish a result on which you should choose to go with, but there are a few items to investigate when choosing which is best for your business:

• Is the portal JSR168 compliant? (Does it pass Sun's TCK?)  For reasons of portability and future maintenance, it would not be wise to develop to a proprietary API. The portlet specification continues to advance and knowledge-sharing by the community is extremely active. For these reasons, vendor lock-in should be avoided.

• Are you considering open source or proprietary? Open source and proprietary portals share essentially the same features currently, with one exception: some of the proprietary vendors supply smooth integration with other applications and systems they offer. For instance, a proprietary portal can be bundled with an existing CRM or eCommerce tools offered by the same company. If the need and budget exists to have a portal tightly integrated to other proprietary information systems; one should consider the proprietary offerings. As a side note, I have seen a trend recently where businesses deploy open source portals and then custom-develop the portlets that aggregate data from the proprietary systems in the back-end. In many cases, the cost savings were immense, even when custom portlet development was outsourced to a third-party as opposed to having paid the licensing and consulting costs from the proprietary vendors.

• Does the portal vendor offer reliable support services for its products? As with any piece of software, reliable support is extremely important. This is especially true with portals, as there is often a diverse set of components sitting under the hood managing a myriad of operations. Although some open source portals are backed by proven and professional support services, some of them will leave your development team to the mercy of a mailing list or a message board. Proprietary or not, one should ask who/what/when will be those answering your support questions and only contract support from a trusted name.

As you can see, there are many advantages to utilizing portal software. The essential decision that will take place will require evaluating whether a portal, CMS, or custom web-application is the path to proceed on. The case for the use of portal software is not cut-and-dry, but there are numerous advantages in adopting it like leveraging existing technology to perform the heavy-lifting associated with web application development, numerous open source and proprietary vendors backing their products with support services, and a shallow learning curve for JEE developers with regards to the portlet specification and existing MVC frameworks.