Portals

The Java Specification Request for the Portlet Specification (a.k.a. JSR 168), articulated by the Java Community Process in October 2003, aims to provide a standard for portlets that the portal arena has lacked. Portlets that are written to the JSR 168 spec will be deployable to any JSR 168-compliant portal.

The spec in essence defines a contract between a portlet and the portlet container that powers it. Areas covered by the APIs defined in the specification include topics such as aggregation, personalization, presentation, and security. As these concepts are core to the portal realm, they needed to be addressed by a spec in order to enable interoperability between portlets and portals.

A portal is a Web application that typically provides end users with personalization, single sign-on, and content aggregation from different sources. It is the responsibility of a portlet container to run portlets, providing them with a runtime environment and managing their life cycles. The container also persists portlet user preferences, enabling a customized end-user experience. IBM WebSphere Portal Server acts as a portlet container; it has an infrastructure that supports JSR 168. To the avail of developers entrusted with the task of developing portlets, you will also see tooling support via the tandem offerings of IBM WebSphere Studio Application Developer and the WebSphere Portal Toolkit version 5.0.2.

JSR 168 Lays Down the Law

Why pay attention to the specification? JSR 168 backs up its bark with some bite. Major players in the industry, including IBM, Sun Microsystems, Vignette, BEA, Plumtree, and Oracle took an active role in establishing the specification; all of these companies either already support or plan to support the spec with their respective products. Recognizing the popularity of the portal concept, the Apache Software Foundation is currently incubating a reference implementation of the Java Portlet Specification in a project called Jakarta Pluto.

Fundamentally, portlet architecture bears a lot of similarity to Java servlet architecture. However, portal developers face unique challenges such as user interface rendering restrictions and the challenge of displaying on the same page multiple portlets that may have to communicate with one another.

The standard API of JSR 168 has some significant differences from the IBM Portlet API introduced in WebSphere Portal version 4.1. These differences include the concepts of initialization parameters, portlet preferences (both user-independent and user-dependent), session state, and navigational state. You can learn more about the differences by reading "Best practices for developing portlets using JSR 168 and WebSphere Portal V5.0.2" and "Comparing the JSR 168 Java Portlet Specification with the IBM Portlet API" (see the Resources section).

One fundamental paradigm shift to note: portlets in JSR 168 do not extend servlets and their major interfaces. However, under the covers, JSR 168 still taps into much of the functionality offered through the servlet specification. Because the overall concepts of JSR 168 parallel many of those of the IBM Portlet API, developers familiar with the IBM Portlet API should experience a smooth migration.

WebSphere's Compliance

IBM took a major role in the defining of JSR 168, and WebSphere Portal v5.0.2 proudly supports the required specifications. In addition, it addresses some "optional" parts of the JSR, including expiration-based caching.

Because the JSR spec is in its first incarnation, it doesn't offer the feature-rich API customers might want to see in their portal. Accordingly, IBM offers nonstandard extensions. For instance, the only interportlet communication provided by JSR 168 is sharing of data through sessions. On the other hand, IBM WebSphere Portal offers technologies such as click-to-action (cooperative portlets) in the WebSphere-specific toolbox. As a developer, you should keep in mind when using the extensions that the portability of your portlet is compromised by leveraging such technologies. This of course becomes an evaluation process. Does the functionality offered by nonstandard extensions provide a value-add for which you are willing to sacrifice portlet portability?

The Tools to Get Things Done

The JSR 168 Technology Preview is an extension to the WebSphere Portal Toolkit that is installed when you install Portal Toolkit v5.0.2. The extension provides a wizard as well as example code to get you jump-started with JSR 168-compliant portlet programming (see Figure 1). In its current incarnation, you can develop specification-compliant portlets within WebSphere Studio. These portlets can then be debugged remotely using WebSphere Portal Attach (a remote debug configuration).

Support for JSR 168 in WebSphere Portal Server

IBM enables its JSR 168 customers with a fixpack for WebSphere Portal v5.0.2. WebSphere Portal v5.0.2 incorporates a portlet runtime environment based on Apache Pluto (which, if you recall, is the reference implementation by the Apache Software Foundation supporting JSR 168).

Customers might ask themselves, "Does the portlet specification mean that the portal I run it in is a non-issue?" The short answer is: no way. IBM WebSphere Portal v5.0.2 is a J2EE application that runs on IBM WebSphere Application Server version 5. Portlets running in WebSphere Portal reap the performance benefits of the portal server's symbiotic relationship with WebSphere Application Server (WAS). The reputation of WAS precedes itself as a high-performance and extremely scalable transaction engine for powering even the most complex, dynamic e-business applications.

Also, as stated earlier, the portlet specification is still rather young and not that rich in its offerings. Enterprise organizations will typically want to leverage the extended offerings of WebSphere Portal.

Conclusion

Much of the popularity of portlets has stemmed from their major value-add of being reusable components. These components provide access to Web-based content, applications, and other content. Unfortunately, in the past, portlet reusability carried the caveat of "for use in a particular container of a particular portal server."

In a world of proprietary portlet APIs, JSR 168, the Java Portlet Specification, promises interoperability between portlets and portals. By following the specification, customers will no longer be bound to proprietary vendor APIs; they can build portlets as pluggable modules. The concept of portlet portability that JSR 168 brings to the table will most likely add to third-party vendors' motivation to develop portlets, as they can reach multiple vendors without having to code for each of their portal environments, thus further catalyzing the portal phenomenon.

Also on the Horizon

Another key specification approaching final status is WSRP (Web Services for Remote Portals), which aims to affect the portal arena significantly. We will introduce you to this specification in an upcoming article in WebSphere Journal. To whet your appetite just a bit, the WSRP specification, shepherded by the Organization for the Advancement of Structured Information Standards (OASIS), describes the use of Web services standards to integrate remote content and applications into portals.

Acknowledgment

The authors would like to thank Scott Karabin of IBM Software Services for WebSphere for his review of this article.

Resources

JSR 168 Portlet Specification: http://jcp.org/en/jsr/detail?id=168

IBM WebSphere Portal for Multiplatforms Version 5.0.2 Information Center: http://publib.boulder.ibm.com/pvc/wp/502/index.html

Best practices: Developing portlets using JSR 168 and WebSphere Portal V5.0.2: www-106.ibm.com/developerworks/websphere/library/techarticles/0403_hepper/0403_hepper.html

Comparing the JSR 168 Java Portlet Specification with the IBM Portlet API: www-106.ibm.com/developerworks/websphere/library/techarticles/0312_hepper/hepper.html

JSR 168 Portlet Specification for WebSphere Portal Technology Preview: www-106.ibm.com/developerworks/websphere/downloads/jsr168.html

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...