Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Introducing the Portlet Specification, Part 1

Get your feet wet with the specification's underlying terms and concepts

By Stefan Hepper and Stephan Hesmer, JavaWorld.com, 08/01/03

With the emergence of an increasing number of enterprise portals, various vendors have created different APIs for portal components, called portlets. This variety of incompatible interfaces generates problems for application providers, portal customers, and portal server vendors. To overcome these problems, JSR (Java Specification Request) 168, the Portlet Specification, was started to provide interoperability between portlets and portals.

JSR 168 defines portlets as Java-based Web components, managed by a portlet container, that process requests and generate dynamic content. Portals use portlets as pluggable user interface components that provide a presentation layer to information systems.

JSR 168's goals are the following:

• Define the runtime environment, or the portlet container, for portlets
• Define the API between portlet container and portlets
• Provide mechanisms to store transient and persistent data for portlets
• Provide a mechanism that allows portlets to include servlets and JSP (JavaServer Pages)
• Define a packaging of portlets to allow easy deployment
• Allow binary portlet portability among JSR 168 portals
• Run JSR 168 portlets as remote portlets using the Web Services for Remote Portlets (WSRP) protocol

The IT industry has broadly accepted JSR 168. All major companies in the portal space are part of the JSR 168 expert group: Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle, SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO, and Vignette. The list of official supporters is even longer.

Currently, JSR 168 is in public review and the final version is planned for September 2003.

In this article, we first define portals and portlets, then explain the concepts JSR 168 introduces, including the API's basic objects. Next, we dive into the JSR's more advanced functions, such as user information, localization, and caching. We then cover the extension points that allow portal vendors to extend the currently defined functionality in the portlet specification. The article concludes with the description of portlet application packaging and deployment.

Read the whole series on the Portlet Specification:

• Part 1: Get your feet wet with the specification's underlying terms and concepts
• Part 2: The Portlet API's reference implementation reveals its secrets

Basic definitions

In this section, we explain the basic definitions used in the portlet specification, including a portal's basic architecture, the portlet container, and a portal page.

Portal

A portal is a Web-based application that provides personalization, single sign-on, and content aggregation from different sources, and hosts the presentation layer of information systems. Aggregation is the process of integrating content from different sources within a Webpage. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different sets of portlets creating content for different users.

Figure 1 depicts a 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 portlet container provides the runtime environment for the portlets and calls the portlets via the Portlet API. The portlet container is called from the portal via the Portlet Invoker API; the container retrieves information about the portal using the Portlet Provider SPI (Service Provider Interface).