Native Portlet Integration

A portal provides a common point of access for several applications. It aggregates content across multiple applications and allows end-users to configure their view, including both the portal’s look and feel as well as the content / functionality made available by the portlets. Through heterogeneous application implementations, a portal needs to introduce a degree of uniformity to provide a consistent user experience. This leads to performance, scalability, reliability, security, and presentation considerations.

This topic focuses on addressing each of these areas of integration, particularly in portlet
life-cycle management, personalization, security, inter-portlet communication, and remote portlets. The guidance in this topic is based on JSR286 and WSRP standards. Although actual portal products may include vendor-specific extensions, they should be avoided to prevent vendor lock-in.

Portlet Life Cycle

Portlets are managed within a portlet container. Associated with each portlet is a deployment descriptor, which provides the portlet container with the information necessary to run the portlet. The portlet container instantiates a single object to serve requests targeted to the portlet for each portlet definition in the deployment descriptor file (portlet.xml, XML schema available at http://download.oracle.com/otndocs/jcp/portlet-2.0-fr-oth-JSpec/).

As described in the JSR 286 specification, each portlet deployment descriptor contains the portlet name (portlet-name), portlet class (portlet-class), and initial parameters (init-param) for the portlet. Also contained within the deployment descriptor is the length of time the portlet container should cache the contents created by the portlet (expiration-cache). The content types supported by the portlet and modes supported for that content type are defined by the supports element (supports). The portlet information element (portlet-info) defines information like the portlet’s default title. Finally, default portlet preferences are defined by the portlet preferences element (portlet-preferences). The deployment descriptor file may also include vendor-specific extensions. Sample Portlet Descriptor shows an example of a portlet deployment descriptor (from the Sun Microsystems white paper “Introduction to JSR168”).

Sample Portlet Descriptor; Figure presents a sample portlet descriptor as described in the text immediately preceding the figure.
Sample Portlet Descriptor

Four basic functions serve as a “contract” between the portlet and the portlet container and are invoked through different phases of the portlet life-cycle:

  1. Init(). The init function is called when the portlet is instantiated by the portlet container. This function basically prepares the portlet to serve requests.

  2. ProcessAction(). The process action function is called when the user makes changes to the portlet, such as via the doView() or doEdit() method. This function processes user changes.

  3. Render(). The render function is called when the portlet is drawn by the desktop.

  4. Destroy(). The destroy() function is called when the container destroys the portlet, when the portlet is no longer needed.

As part of the “contract,” each portlet implements these functions used by the portlet container to manage the portlet. A portlet may also publish information to log files through the portlet container—for example, for debugging purposes or error reporting. The portlet container makes available a PortalContext interface through which portlets can access logging functions.

Portlet Personalization

A consistent interface across portlets requires that each portlet implement particular functions to present content to users and for users to customize / personalize the portlet. A GenericPortlet class is provided which implements the render() function and delegates the call to more specific functions, depending on the portlet mode (view, edit, or help). The GenericPortlet class can be extended to implement as many of the mode-specific render functions as necessary. These functions, as described in JSR 286, include:

  1. doView(). The doView function renders the portlet contents when in view mode.

  2. doEdit(). The doEdit function allows users to edit the portlet.

  3. doHelp(). The doHelp function makes portlet help available for users.

Portlets should implement these functions to give users the ability to customize / personalize the portlet.

Portlet Security

Given the potential diversity of both portlets and users accessing the portal, it is important to manage access controls and exchange content securely while supporting a unified user experience. Security is the responsibility of the portlet, although the portal container makes functions available to support secure access to portals.

The portlet container provides information about the user accessing the portal, including the user’s role. The portlet container is not, however, responsible for authentication. In JSR 286, three basic functions support user authentication:

  1. getRemoteUser(). The getRemoteUser function returns the username used to authenticate into the portal.

  2. isUserInRole(). The isUserInRole function determines if a user is in a specified security role.

  3. getUserPrincipal(). The getUserPrincipal function determines the principal name of the current user.

Portlets should use these functions to authenticate and authorize user access to portlet content and functionality.

A second aspect of securing the portlet is protecting the content during transit to ensure content integrity and/or confidentiality is preserved. This is especially important if there may be sensitive data exchanged between the portlet and users. Security constraints are specified based on a portlet collection and user data constraints. The portlet collection describes the portlets to be protected. The user data constraints describe the transport layer security required by the portlet collection. For example, exchange of confidential messages must occur over Transport Layer Security protocol, typically as part of an HTTP/S communication. As part of the portlet deployment descriptor, developers should set a flag to indicate whether communication with the portlet should occur over secure communication.

Each project / application that wishes to integrate with the portal is responsible for ensuring adherence to the CMS ARS and the appropriate security artifacts are completed. Additionally, each portlet may have its own security assurance level as stipulated by the CMS ARS .

Inter-Portlet Communication

Portlets that are developed independently and packaged as separate portlets may coordinate with each other at run-time. For example, there may be a single portlet that allows users to specify their location and, based on user input, other portlets may display various information about that location, such as weather forecast, houses for sale, or traffic conditions. The JSR 286 specification defines two ways in which inter-portlet communication may occur:

  • Public render parameters. This allows for a portlet to set parameters that can be read by other portlets.

  • Events. This allows portlets to issue events / notifications that other portlets may or may not react to.

In the case of public render parameters, the parameters passed between portlets are built into the URL, and the user’s browser causes the event to be triggered. This has security implications; for example, the parameters are visible in clear text. Alternatively, events provide a more secure means for interacting with other portlets. Events go to all portlets, though they are contained within the CMS environment.

At development time, portlets need to define what type of data they understand as part of their deployment descriptor. At run-time, either shared parameters or eventing enable portlets to be combined in a loosely coupled manner, share data, and potentially derive new functionality based on the composite portlet.

Remote Portlets

Portlets often run locally within the same computing environment (i.e., sharing resources with the portal) as the rendering portal, but this is not always the case. Sometimes the portlet runs in a remote portlet container with respect to the portal. A remote portlet works best when there are multiple application owners and/or applications that are not subject to centralized deployment constraints. In this case, the WSRP specification defines a Web Service interface for accessing and interacting with portlets that reside in a remote portlet container. WSRP allows portals to display portlets that are running remotely within their portal, without any additional portal development. The advantage of remote portlets is that they do not compete for portal resources and provide a more scalable implementation.

The WSRP specification does not dictate specific security requirements, but portlet developers should follow Web Services Security (WS-Security) and Security Assertions Markup Language (SAML) when implementing WSRP-compliant portlets, in accordance with the Web Services chapter. WS-Security defines mechanisms for signing SOAP messages (for integrity), encrypting SOAP messages (for confidentiality), and attaching a security token to verify the sender’s identity. SAML provides a standard for exchanging authentication and authorization data between the remote portlet and the portlet container. TLS should also be used for transport level security.

The WSRP specification also describes session management. Session state is stored on the portlet producer side (i.e., the Web service that offers one or more portlets). When a session is created, the producer returns a reference to the session (i.e., session ID) to the consumer that provides a user interface to the portlet. For each subsequent invocation by the consumer, the consumer must include the session ID in the request to the producer.

Portlet Deployment

There are two basic portlet deployment options: local or remote. As described above in Remote Portlets, a local portlet runs within the same computing environment as the portal. A remote portlet runs in a remote computing environment and communicates with the portal via a Web service, based on the WSRP standard. Furthermore, a local portlet runs as a Java application within a portlet container (like a servlet running within a servlet container). A remote portlet based on WSRP, however, exposes a consistent Web service interface so that it can be accessed and viewed by a portal, but the actual implementation may vary.

Trade-offs should be considered when determining whether a local or remote portlet is more suitable. A local portlet should be used, for example, to optimize message exchange performance between the portlet and portal. A remote portlet is more suitable when the portlets are implemented in a programming language other than Java; local JSR286 portlet implementation is limited to Java, while remote WSRP portlets are agnostic to implementation technology. Furthermore, remote portlets may simplify security assessments, because a remote portlet may only require a single security assessment for multiple deployments, while a local portlet may need assessment for each deployment along with the portal.