Using WSRP with WebLogic Portal

Local Proxy Support

Local proxy support allows co-located Producer and Consumer web applications to short-circuit network I/O and "SOAP over HTTP" overhead.

Note: If you run both the Consumer and Producer on the same server, a deadlock situation can potentially occur. This is because the Producer allocates a new thread for each portlet. When running the in local proxy mode, extra threads are not allocated. For this reason, using local proxy mode, as described in this section, is recommended whenever you are running both the Producer and Consumer in the same server.

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 web applications. Among the most significant are that it:

Avoids potential deadlock situations when the Producer and Consumer are running on the same server.
Avoids local network I/O.
Avoids serialization and deserialization of SOAP.
Invokes remote portlets using the same execute thread.
Writes portlet markup directly to the response without intermediate buffers.
Enables large file uploads without causing OutOfMemoryErrors.

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:

Deploy the Producer and Consumer web applications on the same server. These applications could be in the same enterprise application or across different enterprise applications.

Enable local proxy support by setting <enable-local-proxy> to "true" in WEB-INF/wsrp-producer-registry.xml in the Consumer web application, as shown in Listing 7-1:

Listing 7-1 Setting <enable-local-proxy> to "true"

<wsrp-producer-registry
   xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-registry/8.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-
      registry/8.0 wsrp-producer-registry.xsd">

   <!-- Upload limit (in bytes) -->
   <upload-read-limit>1048576</upload-read-limit>

   <!-- Timeout (in milli seconds) -->
   <connection-timeout-secs>120000</connection-timeout-secs>

   <!-- Enable local proxy -->
   <enable-local-proxy>true</enable-local-proxy>

...
</wsrp-producer-registry>

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:

When portlets are deployed in self-contained web applications on the same server. The local proxy support provides isolated portlet deployment. In this mode, each portlet web application can be deployed as a WSRP producer. Portlets can therefore be loaded by separate class loaders and have their own servlet context and session. Portlet web applications can de deployed/undeployed without affecting the portal web application.
When you don't need advanced monitoring software between the Producer and Consumer

On the other hand, you shouldn't use local proxy support when interoperating with non-BEA Producers and Consumers.

Maintaining Session State

When a producer and consumer are deployed on the same server, it is possible that session state can be lost when a user interacts with portlets that are deployed in different web applications. This issue arises because, in terms of HTTP, the user is interacting with two separate web applications that set cookies with the same session ID (JSESSIONID) and path. For example, as shown in Figure 7-1, Cookie 1 and Cookie 2 have the same session name and path, and the browser simply replaces Cookie 1 with Cookie 2. As a result, the session state maintained by Cookie 1 for Web App 1 is lost.

Figure 7-1 Cookies are Overwritten

Cookies are Overwritten

To avoid this situation, manually change the cookie name in one of the web applications. To do this, edit the <session-descriptor> element of the application's weblogic.xml file as follows:

<session-descriptor>
    <timeout-secs>300</timeout-secs>
    <cookie-name>JMYCOOKIE</cookie-name>
</session-descriptor>

where JMYCOOKIE is a name you choose.