Using WSRP with WebLogic Portal

Best Practices for Implementing WSRP

This section describes programming and tuning practices that you should follow to ensure the best performance of your WSRP-compliant portlets, Producers, and Consumers. It contains the following guidelines:

Portlet Programming Guidelines

Please follow these guidelines when programming WSRP-compliant portlets:

Requests and Sessions

Don't rely on request attributes across portlets.
If your portlets share a session, host them on the same Producer.

Security

To secure messages, implement SSL on any port through which the Producer will be offered.
Specify true for all secure attributes in the <service-config> element of the Producer project's WEB-INF/wsrp-producer-config.xml file (for more information, please refer to Establishing WSRP Security).

Note: If you make any changes to wsrp-producer-config.xml, you will need to redeploy or bounce the server before the changes become active.

To manage user identity, rely on single-sign-on (SSO), which is set up by default in WebLogic Portal and then have users login to the Consumer portal. WebLogic Portal will manage SSO automatically. Information sharing between the Consumer and the Producer is facilitated by using an external Profile service that can run with the user identity as the key.
To secure resources on the producer, see Setting Security Constraints on Resources.

URLs

When creating URLs in a portlet, do not use direct links; instead use WebLogic Portal tags and APIs to create URLs.

Look and Feel

Let portlets use standard style attributes and specify those attributes on the Portal skins.

Backing Files

You can use backing files on the Consumer side (remote-portlet) to take some action based on session / request objects or property sets.

Caching WSRP Portlets

Producer - Use <wl:cache> or p13nCache wherever possible.
Consumer (remote-portlet) - Use 'RenderCacheable' attribute if you want to cache the remote portlet's rendered HTML. However, this is a session scoped cache and is not configurable.

Exception Handling

Producer; to prevent stack traces from appearing, errors should be handled on the Producer side and a suitable business message provided.
Consumer (remote-portlet); in WebLogic Workshop, with your remote portlet open, do the following (in this order):

Click the Document Structure tab of the remote portlet.
Click remote Content.
Click Property Editor.
Type in the Error URI

Page Flow

If 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.

Development on a WebLogic Server Domain

For detailed information on using WSRP with a WebLogic Server domain, see Using WSRP in a Basic WebLogic Server Domain.

Performance Tuning Recommendations

To ensure optimal performance of your Producers and Consumers, we recommend the following performance tuning guidelines:

Producer Tuning

Enable attachment support by adding <markup transport="attachment"/> to WEB-INF/wsrp-producer-config.xml, as shown in Listing 5-1.

Listing 5-1 Enabling Attachment Support

<?xml version="1.0" encoding="UTF-8"?>
wsrp-producer-config
    xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-config/8.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-config/8.0 
wsrp-producer-cnfig.xsd">

    <service-config>
        <registration required="false" secure="true"/>
        <service-description secure="true"/>
        <markup secure="true" rewrite-urls="true" transport="attachment"/>
        <portlet-management required="false" secure="true"/>
    </service-config>

Let the Producer create correct URLs by using Consumer-supplied URL templates. This is the default practice.

Consumer Tuning

By default, WebLogic Portal logs SOAP messages on the consumer. Because of the potentially large volume of messages, it is a good practice in a production environment to disable this logging. To disable the logging of SOAP messages on the consumer, edit the WEB-INF/web.xml file as shown in Listing 5-2.

Listing 5-2 Disabling SOAP Message Logging

<servlet>
    <servlet-name>com.bea.wsrp.logging.MessageMonitor</servlet-name>
    <servlet-class>com.bea.wsrp.logging.MessageMonitor</servlet-class>
    <init-param>
      <param-name>enableSoapMessageLogging</param-name>
      <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>

Additional tips for tuning the consumer include:

Accept the default behavior to enable caching for remote portlets.
Enable forked rendering for remote portlets.
Set connection timeout. See Setting a Timeout Value on Remote Portlets for detailed information on setting timeouts.

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.

Note: Currently, WebLogic Portal only supports a shared registration model, where staging and production environments share the same producer registration handle. For more information on shared registration and propagating WSRP producers, see the Production Operation User's Guide.

Tip: 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

Upgrading Simple Producers from Service Pack 3

When upgrading a simple producer from WebLogic Portal Service Pack 3 to a later service pack version, WSRP producer web application libraries are not automatically updated. If you upgrade from SP3 to a later service pack version, you must perform the following steps to ensure that your simple producer continues to function properly as a WSRP producer.

Note: A simple producer is a non-portal web application. For more information on simple producers, see Producers.

Perform the normal procedures for upgrading a WebLogic Portal application from SP3 to a later service pack version.

Copy the the following files into the WEB-INF/lib directory of your web application:

BEAHOME/weblogic81/portal/lib/netuix/web/netui-adapter.jar
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter.jar
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-html.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-naming.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-nested.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-tiles.tld
BEAHOME/weblogic81/portal/lib/wsrp/wsrp-producer.jar
BEAHOME/weblogic81/portal/lib/wsrp/adapters/wsrp-jpf-adapter.jar
BEAHOME/weblogic81/portal/lib/wsrp/adapters/wsrp-struts-adapter.jar

Redeploy the WSRP producer web application.

Other Guidelines

Configuring Session Cookies

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 weblogic.xml Deployment Descriptor Elements at:

http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webapp/weblogic_xml.html#1038173

for details on how to set the domain name and path.

Using Local Proxy Mode to Avoid Deadlocks

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. For detailed information, see Local Proxy Support.