Portlets are extremely useful tools for Domino developers who need to integrate Domino applications with WebSphere. Moreover, IBM has made it easier to use portlets for Domino integration by creating a number of off-the-shelf Domino-specific portlets that can be plugged into the WebSphere Portal, providing quick integration with functions such as instant messaging, calendar, e-mail and so forth. Developers can also build their own custom Domino portlets with the help of IBM's Portlet Builder for Domino, the WebSphere Portal Toolkit or the Lotus Domino toolkit.
But before a developer begins building Domino portlets, he must answer one key question: Which portlet specification to use?
WebSphere Portal 5.0.2 provides two portlet containers, one for the new JSR 168 Portlet API, recently finalized and released in version 1.0, and another for the IBM Portlet API that WebSphere supported before JSR 168 was available. When creating a portlet, a developer has to declare which type he wishes to make -- JSR 168 or IBM.
The IBM Portlet API offers greater functionality than does the Java portlet standard. However, portlets built to the IBM spec cannot be used in any other portal -- only WebSphere. Moreover, IBM has indicated it may eventually phase out support for the IBM Portlet API and move entirely to support for JSR 168. That won't happen anytime soon, however, and it's possible to migrate IBM portlets to the Java spec if necessary.
While there are many basic similarities between the two portlet specifications, the following key capabilities of the IBM Portlet API make it more versatile than the current version of JSR 168.
- Inter-active portlets. One important difference is that an IBM portlet can share data and events with other portlets, allowing portlets to be chained together into larger processes. The Java portlet standard does not yet include this capability, although it is high on the list of things to be supported in future versions.
- Additional lifecycle listeners. The first version of JSR 168 does not support lifecycle listeners besides "action" and "render." Additional listeners are needed for portlets to be interactive, since they must "listen" to the lifecycle stages of other portlets that require a response -- such as data input -- at certain stages.
- Search. The IBM Portlet API makes use of the WebSphere Portal search engine, saving developers from having to integrate their portlets with the WebSphere, or another, search engine.
- Portlet menus. The IBM portlets can contribute content to a navigational menu, while JSR 168 portlets cannot.
- Personalization. The IBM Portlet API makes use of WebSphere's personalization engine, which contains rules on how content may be customized for users or groups of users.
- Services. The IBM Portlet API provides a portlet service interface that fetches needed services for the portlet, such as retrieving authentication credentials or, specific to Domino applications, a Domino access service for accessing Domino databases.
So how should a developer decide which standard to use today? If you plan to use only the off-the-shelf Domino portlets, there is no decision -- they all support the IBM Portlet API. If you want create new portlets to interact with, or in place of, the pre-built portlets, however, you have to make a choice.
Fortunately, in the most recent incarnation of WebSphere Portal -- 5.1 -- IBM portlets can share data with JSR 168 ones, so using the pre-built Domino portlets is no barrier to building new ones in Java. However, this is not true in WebSphere Portal 5.0.2, which contains the first release of JSR 168. Developers working with 5.0 who plan to use of-the-shelf IBM portlets should, therefore, stick with the IBM Portlet API unless there is a burning need for JSR 168 portability.
For everyone else, the choice remains.
On one hand, the IBM Portlet API makes better use of WebSphere's built-in services, saving development time.
On the other hand, IBM is charting its future course based on the JSR 168 standard, so the IBM Portlet API won't be around forever. For developers, that means that IBM portlets will most likely have to be migrated to JSR 168 at some point. Also, JSR 168 will likely get better with time, as new versions come out with added capabilities. In the meantime, IBM provides extensions to enable JSR 168 portlets to take advantage of some of the capabilities of WebSphere, according to Stefan Hepper, architect for the WebSphere Portal Server Development at IBM.
Hepper, who wrote "Portlet API Comparison White Paper: JSR 168 Java Portlet Specification compared to the IBM Portlet API," suggests that developers use JSR 168 unless they have great need of the features available only in the IBM API. That's sound advice, especially given for developers who don't relish the idea of porting a bunch of IBM portlets to the JSR 168 API.
IBM has claimed it will continue supporting its portlet specification fairly far into the future -- to WebSphere Portal 6.0 and, most likely, even beyond that. But while the tried-and-true IBM API offers much, the fact is that JSR 168 will be the WebSphere standard for portlets in the future. So it should be your standard as well.
About the authors:
Tony Higham is the chief solutions officer at FatWire Software and an expert on Lotus, WebSphere and Java technologies. He can be reached at tony.higham@FatWire.com.
Sue Hildreth is a contributing writer and editor based in Waltham, Mass. She can be reached at Sue.Hildreth@comcast.net.
Do you have comments on this tip? Let us know.
Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
