JSR 168 has changed the playing field for portal development, letting vendors (and especially ISVs) develop portlets that various portals can consume. Likewise, WSRP has provided a standard so portals can consume portlets that reside remotely from the consuming portal. But questions remain. How real is the interoperability between portlets across different portal vendors? How does WSRP relate to other development patterns such as Struts and JSF? When should you use WSRP as opposed to JSR 168? As a developer developing for a portal customer, how do you know where to start?

This article will discuss two approaches to deploying portlets: the use of Java Specification Request (JSR) 168, which addresses the characteristics and specifications for a Java portlet, and the specification for Web Services for Remote Portlets (WSRP) from OASIS, one of the industry organizations defining Web standards.

Both of these standards seek to defi ne portlets that are independent of the portal that they may be tasked to run in, allowing for the portability and interchangeability of these portal objects. The specifi cations are for both the developers of the portlet itself as well as the developers of the portals in which they run. In both cases, the standards defi ne the areas of presentation, aggregation, security, and portlet lifecycle.

The Role of Portlets
Portlets are small objects (in our case, Java objects) that provide specifi c services running in a portal system. Web portals are a kind of content management system, letting registered users access password-protected information from a number of different sources. The information owners who, in most cases, aren't the portal owners update the information in the portal, relieving the portal owners of that onerous task. And the user controls all this through a set of "preferences screens" so there's no need to learn complex programming to design the portal.

New sources of information are appearing daily with an unbelievable range of content, enough to satisfy even the most selective users. The ability to include diverse content into a single viewable portal is dependent on both the portal developers and the content developers complying with a stringent set of portal and portlet standards. The most relevant standards from OASIS and the Java Community Process are critical to the portability and usability of these portlets and will be the basis of the discussion here.

Portlet Type Selection
As an application developer you should examine the different types of portlets that are available in portal systems and decide which type is best suited to the task at hand. For example, Java page flow portlets are particularly useful if you're interfacing with Java Controls, leveraging a Struts-based infrastructure, and delivering rich navigation elements. A JSP portlet would be a good choice if you're converting an existing JSP page into a portlet. If you're concerned with portability across multiple portlet containers then you may want to use JSR 168-compliant Java portlets.

Below is a matrix to help you decide which implementation to use when building portlets:

Image 1

Java Portlet Environment
A portlet is a Java technology-based Web component, managed by a portlet container that processes requests and generates dynamic content. Portals use portlets as pluggable user interface components for a presentation layer for information systems. A portlet container provides portlets with the required runtime environment, managing their lifecycle and the persistent storage of portlet preferences.

While portlets are different than servlets, they share many concepts. Each is based on Java technology-based Web components, runs in a specialized container to manage their operations and lifecycles, and generates dynamic content for the user. Portlets differ from servlets in only generating markup fragments, not complete documents. They aren't bound to a URL and have more defined request handling, action requests, and render requests than servlets.

Portlets also have extra functionality that's not inherent to servlets. Portlets can access and store the persistent configuration and customization data specified by the user, have access to the user's profile information, and show hyperlinks on the display ultimately rendered.

A portlet container is, in general, an extension of the servlet container. The Portlet API v1.0 is based on the Java 2 Platform, Enterprise Edition 1.3. Portlet containers and portlets meet the requirements for executing in a J2EE environment as described in the J2EE specification.

The Portlet container must use the same classloader that the servlet container uses for the Web application resources to load the portlets and related resources in the portlet application. The portlet container is responsible for informing portlets of user roles, but the portlet container doesn't deal with user authentication.

Making Portlets Remote
Web Services for Remote Portlets (WSRP) lets you decouple your portlet applications from portals. This decoupling can offer significant benefits for managing large portal deployments. Instead of bundling all your portlets with the portal in a single application, you can choose to deploy your portlets in individual portlet applications and let the portal consume those portlets using WSRP. For most large portal development projects, this decoupling eases team development, upgrades, and administration.

The best way to understand WSRP is to compare it to HTTP. The most typical HTTP application is viewing and interacting with a remote UI (for example, Web applications) via Web browsers. Using HTTP, browsers can talk to remote HTTP servers to get markup (for example, HTML), and post data (for example, by submitting a form). WSRP is a similar protocol between two applications, one application (the Consumer) acting as a client of another application (the Producer) for getting UI markup and submitting user actions. The Producer hosts the UI and Consumers use the WSRP protocol to aggregate the UI and interact with it.

Unlike browsers, Consumers are more sophisticated because they can aggregate several UI components into a single page, and they offer features like personalization, customization, and security. Consumers also deal with markup fragments, not complete documents. Consumers get these markup fragments from different Producers and combine them into a single page by applying Consumer-specific page layouts, styles, and so on.

The WSRP protocol defines a set of Web Services that WSRP Producers implement. WSRP Consumers can send messages to these Web Services to view and interact with the UI. The WSRP protocol translates the typical browser-server interaction protocol into a protocol that's suitable for applications (Consumers) to act as clients for applications (Producers) that host the UI.

It's important to understand that WSRP Web Services are synchronous and UI-oriented. Unlike business logic-oriented or data-oriented Web Services, UI-oriented Web Services offer coarsergrained application reuse and are more resilient to change.

Typically, portal systems will include both the Producer and Consumer components. The Portal Producer is a container that can host portlets. This is where application code (page flows, backing files, other portlet classes, controls, EJBs, and so on), user interfaces (JSPs and other resources), and the data used by the portlets reside. The Producer is designed so that you can convert any existing Web application into a WSRP Producer with minimal changes at deployment. Once a Web application is enabled as a Producer, it can start to offer portlets available in the Web application via WSRP interfaces.

To consume a remote portlet, the user typically starts with the location of the WSDL of the Producer, adds the Producer metadata to the Consumer, and then creates a remote portlet (also known as a proxy portlet). When such a portlet is added to a portal or a desktop, the WSRP protocol is typically used to present the portlet to portal users.

The Design of Systems Using Remote Portlets
To illustrate how a WSRP Consumer can interact with remote portlets, let's start with a simple page flow portlet.

See Figure 1

This page flow collects user input in a form, does a search based on the user input, and displays the search results. Here's a form presented by the index.jsp page:

Example 1 index.jsp

<netui:form action="search" method="post">
  <table>
    <tr valign="top">
      <td>First Name:</td>
      <td><netui:textBox dataSource="{actionForm.firstName}" /></td>
    </tr>
    <tr valign="top">
      <td>Last Name:</td>
      <td><netui:textBox dataSource="{actionForm.lastName}" /></td>
    </tr>
  </table>
<netui:button value="search" type="submit" />
</netui:form>

Let's assume that you created this page flow at /Search/SearchController.jpf in the Producer Web application, and created a .portlet file for this page flow. Here's a sample portlet file:

Example 2 Sample portlet file

<portal:root xmlns:netuix="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0"
  xmlns:portal="http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation=
  "http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0 portal-support-1_0_0.xsd">
   <netuix:portlet definitionLabel="search" title="Search">
    <netuix:titlebar>
     <netuix:maximize/>
      <netuix:minimize/>
   </netuix:titlebar>
   <netuix:content>
     <netuix:pageflowContent contentUri="/Search/SearchController.jpf"/>
    </netuix:content>
   </netuix:portlet>
</portal:root>

In the WSRP protocol, Consumers use what is called a portletHandle to refer to a portlet on a Producer. The Producer is responsible for assigning this value. When a portal Producer exposes any portlet to Consumers, it uses the portlet's definitionLabel as the portletHandle.

After creating the remote portlet, you can change its attributes like caching, definitionLabel, title, error page, and so on. You can also add a backing file to remote portlets on the Consumer side.

Displaying a Remote Portlet
The portal uses WSRP to get the markup (in this case, the HTML generated for this portlet) from the Producer. When the portal finds a remote portlet in a page, it does the following:

• Sends a getMarkup message to the Producer and gets a response from the Producer
• Collects the markup from the Producer's response
• Aggregates the markup into the portal page

Example 3 getMarkup request

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
   <urn:getMarkup xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
    <urn:registrationContext xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
    <urn:portletContext>
      <urn:portletHandle>search</urn:portletHandle>
    </urn:portletContext>
    <urn:runtimeContext>
      <urn:userAuthentication>wsrp:none</urn:userAuthentication>
      <urn:portletInstanceKey>search_1</urn:portletInstanceKey>
      <urn:namespacePrefix>search_1</urn:namespacePrefix>
      <urn:templates>
        <!-- Snip -->
      </urn:templates>
    <urn:userContext xsi:nil="true"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
    <urn:markupParams>
      <urn:secureClientCommunication>false</urn:secureClientCommunication>
      <urn:locales>en-US</urn:locales>
      <urn:mimeTypes>text/html</urn:mimeTypes>
      <urn:mimeTypes>*/*</urn:mimeTypes>
      <urn:mode>wsrp:view</urn:mode>
      <urn:windowState>wsrp:normal</urn:windowState>
      <urn:clientData>
        <urn:userAgent>
        Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
        .NET CLR 1.1.4322; FDM)
      </urn:userAgent>
      </urn:clientData>
        <urn:markupCharacterSets>UTF-8</urn:markupCharacterSets>
    </urn:markupParams>
   </urn:getMarkup>
  </soapenv:Body>