Federated Portals Guide

Other Topics and Best Practices

This chapter focuses on best practices for developing portlets in a producer. By following the practices described in this chapter, you will help to ensure that remote portlets created in consumers function properly. We recommend that you review Federated Portal Architecture before reading this chapter.

This chapter the following sections:

Decouple Rendering from Interaction

As explained in Life Cycle of a Remote Portlet, the rendering and interaction phases of a remote portlet’s life cycle are decoupled. As a result, you cannot expect a portlet to receive the same HTTP response or request for the render phase as it receives for an interaction.

A portlet that is being rendered must not expect to receive form data in the request object. This is because the request may have been submitted some time ago and is being rendered now, and you may not have the same data.

If you want to maintain data between requests, you need to store that data locally, typically in the session. For instance, if you are processing and order ID, you can store that ID locally.

If you are using page flows, data is automatically passed forward. However, if you are using backing files with a remote portlet, you need to make sure that data is stored in the session, because you won’t get back the same request object.

To avoid problems, keep the following points in mind:

Avoid Interportlet Dependencies

Rather than create explicit depdendencies between portlets, use events to communicate between portlets. For example, suppose that on a portal page, there is a portlet for collecting orders and a portlet for displaying the status of all orders. When an order is taken, data is stored in the database, and the data is then displayed in the order status portlet, as shown in Figure 14-1.

In this scenario, a strong dependency is created between the collect order and the order status portlets. The Collect Order portlet needs to somehow communicate some information (the order ID) to the Order Status portlet. Storing the ID in the session or other common state between the portlets creates a strong dependency between the Collect Order and Order Status portlets. Depending on the implementation of the portlets, if one of them is changed or replaced, the changes will necessarily affect the other portlet.

To avoid this dependency, use events to communicate between portlets. In this example, if an event is used to communicate order information to the order status portlet, the order status portlet does not have to care about where the order came from. The order status portlet just handles an event, retrieving, for example, an order ID from the event’s payload.

For more information on how event handling occurs in WebLogic federated portals, see Interportlet Communication with Events.

Avoid Portal Layout Dependencies

Some portals are built with inherent portal layout dependencies. For example, a login portlet might be designed to function differently if it is on a human resources page versus a finance page. In other words, when an interaction takes place, the portlet tries to find out what page it is on before taking action. This practice closely couples the portlet to the Portal Framework elements, such as pages, books, or desktops on the consumer.

This scenario does not work in a federated portal, because the producer does not know what page layouts exist on the consumer. Avoid this scenario when possible. If it is required, deploy those portlets locally on the consumer, or use shared components where possible and create alternative layouts that are offered through separate portlets.

Avoid Coupling by URL

If you embed URLs in your portlets, such as in links, you may find that your portlets work as expected when they are running locally. However, when you move those portals to a federated environment, the links no longer work. For example, in the following code fragment, a developer is invoking the action of a page flow portlet on the same portal using string manipulation. In a federated portal, this sort of construction will not work. Typically, this sort of programming arises because of reverse engineering, where a developer looks at and copies how links are created.

String url = ”http://mydomain.com/portal/portal.portal?”;
url = url + ”myportlet_actionOverride=login”;
url = url + ”...”;

Likewise, the following resource URL will not work in a federated portal because it includes an explicitly specified link to a document. Because the document doesn’t exist on the consumer, the consumer doesn’t know what to do with it:

<img src=”images/logo.jpg”/>
<a href=”/docServlet?docId=9999”>Download</a>

Common URL problems found in federated portals include the following. These problems stem from the fact that remote portlets do not follow the same URL structure as portlets in a local environment.

It is important that you let the WebLogic Portal Framework create URLs for you using the proper set of JSP tag libraries and utility classes. Use the following tags and classes:

All of these tags go through the WebLogic Portal URL rewriters and will work properly in a federated environment.

It is important to realize that there are inherent differences between remote portlets and local portlets. Developers must not expect that all correctly functioning local portlets will function properly as remote portlets, although in many cases they do.

Avoid Accessing Request Parameters in Rendering Code

When you deploy a local portlet, the portlet can access the request parameters from the portal’s request and the request attributes set by other portlets on the same page. If you implement a portlet to depend on such request parameters and attributes, the portlet will not function correctly in a WSRP environment. In a WSRP environment, remote portlets are running on remote systems; the HTTP request received by a remote portlet on a producer is not the same as the one that is received by the consumer portal.

Avoid Moving Producers

When you add producers and create remote portlets, the producer registry (WEB-INF/wsrp-producer-registry.xml) and the portal framework database tables contain specific information about the producer, such as its WSDL address and the addresses of ports described in the WSDL. If you propagate or move the producer from one environment to another, this data becomes invalid. In this case, consumers whose proxy portlets reference the producer’s portlets will no longer be able to find them.

You can update the database entries for a producer programmatically. The following class provides methods to get and update producer information:

com.bea.wsrp.consumer.management.producer.ProducerManager

Refer to the Javadoc for information on this class.

WebLogic Server Producers

In some cases, you may want to expose portlets with WSRP from a producer environment that does not include any WebLogic Portal components. For example, you may be running a Struts Web application in a Basic WebLogic Server Domain, or a Java Page Flow application in a Basic WebLogic Workshop Domain. In either case, WebLogic Portal is not part of the server configuration. For detailed information on using a non-portal server domain to host remote portlets, see Configuring a WebLogic Server Producer.

If you are using a Portal Web application as your producer, all the portal artifacts are available in the web application; however, for any WSRP producer that is not a Portal Web application, you cannot use portal features such as property sets. If you need to access portal features in your producer, use a Portal Web application.

Security for Remote Portlets

To secure messages, implement SSL on any port through which the producer will be offered. For detailed information on configuring single sign-on security for federated portals, see:

Error Handling

This section gives an overview of error handling techniques for federated portals.

On the Producer

To prevent stack traces from appearing, handle errors on the producer side and provide a suitable business message.

On the Consumer

In Workshop for WebLogic, with a remote portlet open, do the following:

Interceptors

You can use interceptors to handle errors returned from a producer. For instance, if a specific producer is not registered, you can trap the registration error and handle it as you wish. For detailed information on using interceptors, see The Interceptor Framework.

Portlet Programming Guidelines and Best Practices

This section discusses guidelines and best practices for developing remote portlets.

Designing for Performance

To ensure optimal performance of your producers and consumers, we recommend the following performance tuning guidelines on the producer and the consumer.

Performance Guidelines for Producers

Performance Guidelines for Consumers

Using Local Proxy Mode

Local proxy support allows co-located producer and consumer web applications to short-circuit network I/O and “SOAP over HTTP” overhead. When you enable this feature, the consumer tries to determine if the producer is deployed on the same server and, if it discovers that the producer is so deployed, it uses a local proxy to send requests to the producer. If the producer is not deployed on the same server, the consumer uses the default remote proxy. Remote producers can still be invoked as usual even when the local proxy support is enabled.

This section describes how to implement local proxy support. It includes information on the following subjects:

Why Use Local Proxy Mode?

Local proxy mode provides a number of advantages over the default remote proxy when you are working with co-located consumers and producers. Among the most significant advantages of local proxy mode are:

Additionally, by enabling local proxies, customers can take advantage of the decoupling benefits of WSRP without incurring its performance overhead.

Deployment Configuration

To take advantage of local proxy support, do the following:

You can also enable local proxy support by setting a system property com.bea.wsrp.proxy.LocalProxy.enabled = true. If this system property is set to true, it will override the <enable-local-proxy> setting in WEB-INF/wsrp-producer-registry.xml.

Local proxy support is disabled by default in web application templates.

When to Use and Not Use

As powerful a tool as local proxy support is, you should only use it when it will benefit your application. The most common reasons for using local proxy support are:

On the other hand, you should not use local proxy support when interoperating with non-BEA producers and consumers.

Monitoring and Logging

You can monitor activity between producers and consumers by using the message monitor servlet installed with Workshop for WebLogic. You can also create custom logs to display specific information about WSRP sessions.

This section contains information on these subjects:

Using the Monitor Servlet

To monitor the response and request headers, as well as the action SOAP messages that are passed between producers and consumers, do the following:

Where:

For example:

http://localhost:7001/wsrpMonitorTest/monitor 

The monitor appears in the browser, as shown in Figure 14-2.

Click Enable to start monitoring. Click Refresh to see the latest transactions. Click Clear to remove all messages from the browser window.

Each time the remote portlet communicates with the producer, a request and response message headers appear on the monitor screen, as shown in Figure 14-3.

By clicking Show, you can display the content of the request or the response, as shown in Figure 14-4. Click Hide to close the message content.

Creating Custom Logs

To create custom logs, we recommend that you use the Interceptor Framework described in The Interceptor Framework.

You can also create custom logs that display particular information about a WSRP session by using Logger and Handler objects instantiated by WebLogic Server. You can use these objects to create your own message handlers and subscribe them to loggers. For example, if you want the remote portlet to listen for the messages that the producer generates, you can create a handler and subscribe it to a logger in the producer. For detailed information on using Logger and Handler objects, see the WebLogic Server topic, “ Filtering WebLogic Server Log Messages.”

Configuring Session Cookies

This section describes two techniques for preventing the loss of the consumer session when resource requests are made to a remote portlet. These techniques include:

Using Different Cookie Names

If you have a remote portlet that contains images, WebLogic Portal sends cookies and other headers from the producer to the browser when an image resource is requested. Note that when resource requests are made to a portlet in a producer, it is possible for the user’s browser to drop or lose the consumer session. This situation occurs when the producer and consumer are configured to include only the default path (“/”) in the session cookies, which causes the browser to replace the Set-Cookie header set by the consumer with the Set-Cookie header set by the producer.

To prevent this potential loss of the consumer session, open weblogic.xml, and configure your web applications to include the domain name and web application path for session cookies. This technique prevents the cookie names from overlapping. Please refer to session-descriptor in the WebLogic Server document “weblogic.xml Deployment Descriptor Elements” for details on how to set the domain name and path.

Using a System Property

In most cases, using different cookie names solves the problem of lost consumer sessions following resource requests. In some cases, however, this solution does not work. One such use case is when single sign-on is used with the producer and consumer running in the same domain. In this case, identical cookie names are required. For cases where using different cookie names does not work, set the following system property:

wlp.resource.proxy.servlet.block.response.headers=true

By enabling this system property, WebLogic Portal prevents a Set-Cookie header from being sent back to the user’s browser. This property prevents the consumer’s cookie from being overwritten by the producer’s cookie on the browser when a resource is returned. Using this technique, you can keep the cookie names the same for both the producer and consumer applications, which is required for single sign-on.

User Sessions on CWEB Applications

User sessions on CWEB applications might be lost if session cookies between producers and consumers overlap. To prevent this, open weblogic.xml, configure your web applications to include the domain name and web application path for session cookies. Please refer to session-descriptor in the WebLogic Server document “weblogic.xml Deployment Descriptor Elements for details on how to set the domain name and path.

Using Multiple Views with Remote Portlets

Whenever multiple views of a remote portlet are created, links in the portlets can be inconsistent and not work properly. Typically, multiple views occur when a remote portlet uses the popup mechanism in a page flow, or when a user floats a remote portlet using the portlet Float button.

If a WebLogic Portal producer is set up to use consumer-supplied URL templates, the producer caches those templates in a session created on the producer. However, when multiple views of a portlet are created either through the page flow popup mechanism, or through a Float button, the cached templates may not be valid for the current view.

You can correct the inconsistent links using one of these methods:

Handling User Identity Changes

If the user’s identity changes while a request generated from the portal is in progress, remote portlets can behave inconsistently. Typically, this occurs when the portal desktop includes a portlet or other mechanism for logging in and logging out a user. If the user identity changes, any user-specific data loaded by the portal can become invalid. In the case of remote portlets, such data includes their persistent state. When user identity changes, the consumer portal can send incorrect persistent state data to producers.

To avoid this problem, be sure to always use a browser redirect call immediately after a login or logout. The browser redirect ensures that data loaded by the portal is valid for the request.

Editing the WSRP WSDL Template File

You can customize the producer-generated WSDL. For example, you might want the WSDL to point to a proxy server other than the default one. To customize the default WSDL, you can edit the wsrp-wsdl-template.wsdl file. The easiest way to edit this file is to copy it to your workspace in Workshop for WebLogic. To do this, locate the file in the Merged Projects view in Workshop. Right-click the file and select Copy to Workspace. The WSDL template file uses URL templates. See Javadoc for the GenericURL class for information on configuring URL templates.

When you copy and edit the wsrp-wsdl-template.wsdl file, you must also copy several supporting files to your web application. You can copy the files using the Copy to Workspace feature. The additional files you need to copy include: