Shelly has worked in software development for 18 years and is a freelance software consultant. She can be contacted at [email protected].
Business users like web portals because portal views let them work with corporate data and business processes through a single, consistent UI. Software development teams like them because portals provide a comprehensive UI framework and the architectural opportunity to integrate applications in real-time at the front-end, rather than via potentially costly and unreliable offline batch processes at the back-end. Consequently, portals are increasingly considered an essential part of an enterprise SOA strategy. .NET developers, however, have had limited options when it comes to portals, since most high-end portals—BEA's WebLogic Portal Server and IBM's WebSphere Portal Server come to mind—are based on Java EE. In this article, I present techniques and examine tools for developing .NET applications for IBM's WebSphere Portal Server.
JSR 168
The major portlet specification is JSR 168 (jcp.org/ en/jsr/detail?id=168), which ensures that portlets developed in Java can run on multiple portal servers. Many commercial and open-source organizations have adopted this standard, which defines the programming model for portlets and the contract between the portlets and the portlet container.
The portlet lifecycle (Figure 1) consists of two main phases:
- The processAction phase lets the portlet respond to events and has two parameters: ActionRequest and ActionResponse. ActionRequest provides access to information such as the request, the window's state, the portlet session, and portlet preferences data. The ActionResponse object is used to change mode or state during the request.
- The render phase is used by portlets to generate content as HTML fragments. It also has two parameters: RenderRequest and RenderResponse. The RenderRequest object provides access to similar information as the ActionRequest object. The RenderResponse object is used to return content, or delegate content to a JSP or servlet.
The portlets are defined as a standard portlet descriptor file, portlet.xml; see Listing One. Within JSR 168 is consistent support for persistent and transient data management. Portlets can access two different types of persistent data:
- Initialization Parameters. Read-only data defined in the portlet deployment descriptor file. Examples include the names of the files that make up the portlet.
- Portlet Preferences. User-dependent data, usually acquired from the portlet in Edit mode, can also be used via the PortletPreferences node of portlet.xml (Listing Two). Portlets can read/write preferences in the processAction phase but can only read in the render phase.
$?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">
<portlet>
<description>This is a test portlet</description>
<portlet-name>A test portlet</portlet-name>
<display-name>A Test Portlet</display-name>
<portlet-class>GhDynamicPortlet</portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>Test Portlet</title>
<short-title>Test</short-title>
<keywords>Test</keywords>
</portlet-info>
</portlet>
</portlet-app>
<portlet-preferences>
<preference>
<name>userData</name>
<value></value>
</preference>
</portlet-preferences>
Transient data comes from two sources:
- Session data, which is handled just like any web application. To prevent two portlets from using the same Session variable, the name of the portlet is automatically prefixed by the portlet container to each Session variable defined in the portlet.
- Modes and Window State, where all portlets support View (default), Edit, and Help modes. If the Edit mode is implemented, users can change the portlet configuration. This type of configuration information can be persisted anywhere you choose—in Session or in a datastore. Help mode displays help about using the portlet. A number of custom modes can also be implemented (see JSR 168).
