Prev | Home | Next

 

WebSphere Portal WSRP services

 

+
Search Tips   |   Advanced Search

 

  1. Overview
  2. How WSRP works
  3. How WSRP is implemented in WebSphere Portal
  4. Prerequisites for WSRP in WebSphere Portal
  5. How you configure WSRP in your portal
  6. How you use WSRP with WebSphere Portal
  7. Security considerations for using WSRP with WebSphere Portal:
  8. Enable Portal Access Control for WSRP with WebSphere Portal
  9. Customizing the WSRP configuration of your portal:
  10. Known limitations
  11. Troubleshooting
  12. Abbreviations
  13. See also

 

Overview

IBM WebSphere Portal V5.1 supports the Web Services for Remote Portlets (WSRP) standard, enabling the ability to provide portlets as WSRP services and integrate WSRP services into a portal as remote portlets.

This topic assumes that you are already familiar with WebSphere Portal and with the WSRP specification. For more details about the OASIS WSRP specification, refer to the OASIS WSRP Standard Web site.

The OASIS WSRP standard simplifies the integration of remote applications and content into portals. With WSRP portal administrators can select from a rich choice of remote content and applications and integrate it into their portal with just a few mouse clicks and no programming effort. The WSRP specification defines a Web service interface for interactive presentation-oriented Web services. It allows users to perform the following tasks:

  • Producers can provide portlets as presentation-oriented WSRP services and make them available to Consumers who want to use these services.

  • Consumers can select from a rich choice of available Web services and integrate them into their portal.

  • Users can then access the services and work and interact with them just like they do with local portlets.

Using WSRP to perform these tasks has the following benefits:

  • WSRP becomes the means for content and application providers to provide their services in an easily consumable form to organizations that run portals.

  • By virtue of the common, well-defined WSRP interfaces, all Web services that implement WSRP plug in to all WSRP-compliant portals without requiring any service-specific adapters. A single, service-independent adapter on the portal side is sufficient to integrate any WSRP services.

  • Integrating content and applications into portals is made easier. Now, no custom programming effort using a variety of different interfaces and protocols is required. Portal administrators no longer have to write interface code to adapt the WSRP services for their portal.

  • Presentation-oriented services, as standardized by WSRP, allow Producer portals to deliver the requested data and their presentation to the Consumer portal. Previously, they delivered the data only, and the portal administrators had to provide the logic for how to present the data.

  • Portal administrators do not have to keep the WSRP services code locally on their storage devices.

  • The WSRP services appear and operate to portal users exactly like local portlets.

 

How WSRP works

WSRP services are provided by Producers for Consumers who integrate and use them. The following sections provide a brief overview of both the Producer and the Consumer and how they interact. For more details about the OASIS WSRP specification, refer to the OASIS WSRP Standard Web site

 

Producer

Portals that provide WSRP services are called Producers. The Producer part of the WSRP implementation provides an additional entry point into the Producer portal, enabling the portal to provide portlet applications or single portlets as WSRP services. The Producer is the "server" of the WSRP communication. A WSRP Producer provides one or more portlets as WSRP services for invocation by Consumer applications that reside at remote sites.

The Producer provides a set of interfaces as defined in the WSRP standard. The Producer can expose some or all of these interfaces to the Consumers as appropriate. The interfaces are listed here:

Service Description Self-description of the Producer and its available portlets. Mandatory.
Markup Interface for requesting and interacting with markup fragments. Mandatory
Portlet Management Grants access to the life cycle of the hosted portlets and to their persistent state. Optonal
Registration Not supported by the current implementation of WSRP in WebSphere Portal. However, the Consumer can handle Producers that support WSRP registration interfaces. Optional.

The Producer describes these WSRP interfaces in the Web Services Description Language (WSDL) document, which provides general technical information about how the Consumer connects to the Producer and the related infrastructure.

The Producer portal receives the requests from the Consumer to the WSRP service and generates the markup accordingly.

 

Consumer

A WSRP Consumer is a portal that wants to integrate WSRP services and consume them as remote portlets from portals that provide them. The Consumer is the "WSRP client." The Consumer selects the WSRP service and integrates it into the Consumer portal as a remote portlet. The Consumer portal receives the markup from the remote WSRP service and presents it to its users.

On the consumer side go and create a link to the producer instance. As a consumer you could have multiple links to multiple producers. You could take 3 portlets from producer A. Two portlets from producer B. one from producer C.

The following screen shows the information you would need to input to create that producer instance or link. The producer will need to supply the WSDL service definitions. It should be known that there is no definition for security in web services so there is no security here. Producer could use an external security product to lock down the WSDL URL though if they wanted.

 

How WSRP is implemented in WebSphere Portal

In WebSphere Portal, the WSRP implementation enables your portal to do both of the following tasks:

  • Provide portlets as WSRP services for remote invocation.
  • Integrate WSRP services as remote portlets. These portlets behave like local JSR 168 portlets, independent of their implementation on the Producer side - JSR 168, IBM V4.x portlet API, .NET, or other implementations.

 

Prerequisites for WSRP in WebSphere Portal

If you want to use WSRP with the IBM WebSphere Portal, have WebSphere Application Server V5.1.1 Cumulative Fix 1 installed.

 

How you configure WSRP in your portal

To configure WSRP in your portal, use the Web Service Configuration portlet or the XML configuration interface that is provided by WebSphere Portal. This topic assumes that you are already familiar with the XML configuration interface of WebSphere Portal.

For concept and reference information and more details about the XML configuration interface, refer to XML configuration interface.

For details about how to configure WSRP in your portal using the XML configuration interface, refer to the following information:

 

How you use WSRP with WebSphere Portal

The following sections describe how you can use WSRP with WebSphere Portal. This information explains how you perform the following tasks:

  1. Providing the local portlets in your Producer portal as WSRP services so that Consumer portals can invoke them as remote portlets.
  2. Configure your Consumer portal for integration of WSRP services in your Consumer portal as remote portlets.
  3. Consuming, that is integrating and using WSRP services in your portal as remote portlets.

To perform the administrative tasks related to WSRP and remote portlets, you can use the following:

  • The portal administration portlets:
    • For Producers: To provide your local portlets for remote invocation as WSRP services by other parties, use the Manage Portlets portlet.
    • For Consumers: To configure your portal for integration of WSRP services in your portal as remote portlets, use the Web Service Configuration portlet.
    • For Consumers: To consume, that is to integrate and use WSRP services in your portal as remote portlets, use the Manage Web Modules portlet.
  • The portal XML configuration interface.

 

Producer tasks

The tasks a Producer can perform are listed here:

  • Provide a portlet
  • Withdraw a portlet
  • Determine group IDs and handles.

To provide portlets for consumption by Consumer portals, or to withdraw portlets, you can use the Manage Portlets portlet, or the portal XML configuration interface.

The current implementation of the WSRP Producer in WebSphere Portal does not support the WSRP registration interface. However, the WSRP Consumer in WebSphere Portal can handle Producers that support WSRP registration interfaces.

 

WSRP service description

WSRP service Consumers need information about how to bind to the provided WSRP services. This information is described in the Web Service Description Language (WSDL) document of the Producer. The Consumer can use the information in the WSDL document to bind to the Producer and retrieve the Producer's service description for further details about the Producer.

The WSRP service description provides information about various aspects and properties of the Producer:

  • The relationship to the Consumer
  • The capabilities of the Producer
  • The Web services that the Producer provides
  • Whether the Producer requires registration
  • Some WSRP-specific details.

If the WSRP service Producer is an IBM WebSphere Portal, then Consumers of WSRP services can access the WSDL document of the Producer at the following URL:

    http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl

Note that the host and port and the wp_contextRoot directory must match those of the Producer WebSphere Portal installation.

If the WSRP service Producer is not a WebSphere Portal, then the owner or administrator of the Consumer portal needs to get the information by some other means, such as fax, phone, or e-Mail.

 

Providing or withdrawing a portlet

By providing a portlet for WSRP services, a Producer makes the portlet available remotely to Consumers. Consumer portals can then integrate it into their portal and use it as a remote portlet. By withdrawing a portlet, the Producer cancels the service that was provided by the portlet.

To provide or withdraw a portlet, you can use the Manage Portlets portlet. See the portlet help for more information.

To provide or withdraw the portlet using the XML configuration interface, specify the provided attribute to the portlet tag:

Attribute to the portlet tag Possible values Description
provided true|false If the provided attribute is set to true, then the portlet is provided.

The following two XML samples show you how to use the XML configuration interface to provide an IBM portlet and a JSR 168 compliant portlet.

The first XML sample shows you how to provide an IBM portlet:

Here and in the following sections and examples, IBM portlet has the following meaning:

  1. This portlet has been written according to the V4.x portlet API of IBM WebSphere Portal.
  2. V4.x of the portlet API is the API version that applies to the IBM WebSphere Portal Versions 4.x and 5.x.
  3. This portlet is not JSR 168 compliant. 
<?xml version="1.0" encoding="UTF-8" ?>
<request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="PortalConfig_1.3.xsd">
      <!-- 
          Sample for providing a portlet as a WSRP producer. 
      -->
   <portal action="locate">
      <!-- 
          uid must match uid attribute of portlet-app in portlet.xml
      -->
      <web-app action="locate" active="true" 
         uid="com.ibm.wps.portlets.reminder">
            <!-- 
                uid must match uid attribute of concrete-portlet-app in portlet.xml 
            -->
         <portlet-app action="update" 
            uid="com.ibm.wps.portlets.reminder.1">
               <!-- 
                   Name must match the content of the portlet-name subtag 
                   of concrete-portlet in portlet.xml.
                   To actually provide the portlet, the provided attribute is set to true. 
               -->
            <portlet action="update" name="Reminder" provided="true" /> 
         </portlet-app>
      </web-app>
   </portal>
</request>

The following XML sample shows you how to provide a JSR 168 portlet: 

<?xml version="1.0" encoding="UTF-8" ?>
<request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="PortalConfig_1.3.xsd">
      <!-- 
          Sample for providing a JSR-168 portlet as a WSRP producer. 
          Be aware that this sample is provided as a sample only.
    It might or might not work, depending on the configuration of your portal. 
      --> 
   <portal action="locate">
      <!-- 
          uid must match the uid of the portlet application appended with .webmod 
      --> 
      <web-app action="locate" active="true" 
         uid="stdTestsuite.war.webmod">
            <!-- 
                uid must match the optional portlet-app id attribute from the portlet.xml. 
                If this is not set, the .war file name must be supplied here. 
            --> 
         <portlet-app action="update" uid="stdTestsuite.war">
            <!--
                Name must match the portlet-name tag in the portlet.xml file. 
            --> 
            <portlet action="update" name="TestPortlet1" provided="true" /> 
         </portlet-app>
      </web-app>
   </portal>
</request>

To withdraw the portlet, set the provided attribute to false instead of true . (Both of the two previous examples show that attribute highlighted.)

 

Determining group IDs and handles

When Consumer portal administrators integrate a remote portlet into the portal, they need to specify the handle and groupid of the remote portlet. They need to get that information from the Producer portal owner or administrator.

If you are a Producer and you use an IBM WebSphere Portal as the Producer portal to provide your portlets, you can obtain this information by exporting all portlets that you provide using the XML configuration interface. To export all provided portlets, use the XML input file wp_root/doc/xml-samples/ExportAllPortlets.xml, and look for portlets that have the provided attribute set to true.

 

Consumer tasks

In order to use a remote WSRP service in your portal, create a Producer instance and specify which services from that Producer you want to consume.

The tasks that a Consumer can perform are listed here:

  • Create a Producer
  • Export a Producer using the XML configuration interface
  • Consume a WSRP service, that is integrate ir for use as a remote portlet.

To create a Producer or to consume a WSRP service as a remote portlet in your Consumer portal, you can use the Web Services Configuration portlet or the portal XML configuration interface.

 

Create a Producer

Create a Producer in your Consumer portal makes that Web service Producer known to your portal. If required, you also register with the Producer. There are different scenarios for creating a Producer, depending on whether you work online or offline:

  1. If you work online when creating the Producer, you can connect to the Producer. In this case you can use either the Web Service Configuration portlet or the XML configuration interface to create the Producer.
  2. If you work offline, that is you cannot connect to the Producer, you can only use the XML configuration interface to create the Producer.

Notes:

  1. The current implementation of the WSRP Producer in WebSphere Portal does not support the WSRP registration interface. However, the WSRP Consumer in WebSphere Portal can handle Producers that support WSRP registration interfaces.
  2. When you specify user attributes make sure to avoid any of the following:
    • Send security relevant attributes, such as passwords, over unsecured network connections
    • Pass sensitive data about your users to the Producer.

Create a Producer online

If you work online when creating the Producer, you can connect to the Producer and access the Producer's Web Services Description Language (WSDL) document. This means that you only need to specify the location of the WSDL document of the Producer, rather than having to specify the Service Description and Markup interfaces of the Producer. The URLs of the Producer WSRP interfaces are then taken from that WSDL document. The portal sends the required data to the Producer immediately. Optionally, you can define which user attributes you want to have transferred in the WSRP communication with the Producer.

In this case you can use either the Web Service Configuration portlet or the XML configuration interface to create the Producer.

There are three different scenarios, depending on the type of Producer you want to create:

  1. The Producer does not require registration. In this case you specify the following information when creating the Producer in your Consumer portal:
    • The URL for the WSDL service definitions of the Producer. This is mandatory.
    • A name. This is mandatory.
    • A description. This is optional.
    • User attributes. This is optional. The values for the selected user attributes are later passed on to the Producer when your portal users use the Producer's Web service. For example, if you select the attribute for user name, then the Producer's Web service can address your portal users by their name. By selecting specific attributes you prevent sensitive data about your users from being passed to the Producer.
    The registration handle and registration properties are not required.
  2. The Producer requires registration and is enabled for WSRP registration. In this case the Producer provides a registration port. As a Consumer, you specify the following information when creating the Producer in your portal:
    • The URL for the WSDL service definitions of the Producer. This is mandatory.
    • A name. This is mandatory.
    • A description. This is optional.
    • Registration properties. This is optional. The registration properties are passed on to the Producer during your registration. For example, they can provide information about your geographical location, such as the postal code. The Producer can then adapt the Web service to your location. If you live near the mountains, the Producer might then provide information or offers for ski vacation or hiking.
    • User attributes. This is optional. (For an explanation of user attributes, see above.)
    The registration handle is not required in this case. After the Consumer has completed the registration with the Producer, the Producer passes the registration handle to the Consumer, where it is stored in the Consumer portal database.
  3. If the Producer requires registration and is not enabled for WSRP registration, then registration consists of the following steps:

    1. The owner of the Consumer portal registers with the owner of the Producer portal by outside communication, that is by e-Mail, mail, fax, or phone. The Consumer portal owner can provide registration properties. The Consumer portal owner receives the registration handle from the Producer portal owner.
    2. The Consumer portal administrator creates the Producer and provides the following information:
      • The URL for the WSDL service definitions of the Producer. This is mandatory.
      • A name. This is mandatory.
      • A description. This is optional.
      • The registration handle that the Consumer received from the Producer by outside communication. This is mandatory.
      • User attributes. This is optional.
      The Consumer provides no registration properties during creation because the Producer personnel already received this information during the registration by outside communication.

Using the Web Service Configuration portlet to create a Producer online

If you use the Web Service Configuration portlet to create a new Producer, you perform the following tasks:

  1. Define the name for the new Producer
  2. Give a description for the Producer
  3. Specify the URL for the WSDL service definitions of the Producer
  4. Specify the registration handle for the Producer.

Optionally, you can also perform the following tasks:

  • Set registration properties for the Producer.
  • Set user attributes that you want to be passed on to the Producer.
  • Set language-specific names and descriptions of the Producer.
  • Assign access permission to users on a Web service Producer.
  • Delete a Producer from your portal.

To create a new Producer and add the information described above, use the Web Service Configuration portlet. See the portlet help for more information.

To create a Producer by using the XML configuration interface (working offline or online), refer to the following sections.

Create a Producer offline

If you work offline, that is you cannot connect to the Producer, you can only use the XML configuration interface to create the Producer. In this case specify at least the URLs to the Service Description and Markup interfaces of the Producer, because they are mandatory. If the Producer supports the two optional WSRP interfaces, specify them as well.

If the Producer requires certain registration properties with the registration by the Consumer, you have to specify these properties also.

The XML configuration interface writes all parameters that you provide into the portal database. This includes all of the following information:

  • The URL for the Producer's WSDL service definitions
  • A name
  • A description
  • The registration handle received from the Producer by outside communication
  • The registration properties
  • The user attributes.

Except for the user attributes, the portal transfers these parameters to the Producer at a later time when both of the following conditions apply:

  1. You work online, that is you can connect to the Producer.
  2. You update the portal configuration with an XML script that includes consuming a Web service as a remote portlet.

The user attributes are sent to the Producer with every markup or action request, that is when a user interacts with a remote portlet of that Producer.

To create a Producer using the XML configuration interface, refer to the following instructions.

Using the XML interface to create a Producer

The main tag to specify when you use the XML configuration interface to create a Producer is the wsrp-producer tag. The following table lists possible subtags you can specify with the wsrp-producer tag:

Possible subtag for the wsrp-producer tag Description
wsdl-url This describes the URL to the Producer's WSDL document. This is the only tag that is required for creating a producer when using an online connection. The other URLs are extracted from this WSDL file.
service-description-url The Producer's service description URL. Required for offline creation.
markup-url The Producer's markup URL. Required for offline creation.
registration-url The Producer's registration URL. Required for offline creation.
portlet-mgt-url The Producer's portlet management URL. Required for offline creation.
parameter Registration properties.
preferences User attributes.
localedata Specify NLS names and titles.
access-control Specify access control.
portlet-app Integrate portlets.

The following table lists possible attributes that you can specify with the wsrp-producer tag:

Possible attribute for the wsrp-producer tag Possible values Description
registration-required true|false Indicates whether the producer requires registration.
force true|false Forces creation of the producer.
default true|false Set this to true if this is the default producer.

 

The following attributes are just listed for the sake of completeness. Do not change them.
state (binary data) The Producer's state. Specified as Base64 encoded binary data. It is usually only used during export and update by the XML configuration interface.
cookiepolicy One of:
none
per_user
per_group
undefined 		The Producer's cookie policy. The policy and possible values are defined in the WSRP specification.
wspproducer true|false Identifies whether this is a Web services Producer on the Producer side (specified locally) or on the Consumer side (specified as a remote Producer).

The following XML sample shows how you use the XML configuration interface to create a Producer if you work offline: 

<?xml version="1.0" encoding="UTF-8" ?> 
<request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd" create-oids="true">
   <portal action="locate">
      <wsrp-producer action="update" uniquename="wps.myProducer1">
         <service-description-url>http://portal_host:port/wp_contextRoot/WSRPServiceDescriptionService
         </service-description-url>
         <markup-url>http://portal_host:port/wp_contextRoot/WSRPBaseService</markup-url> 
         <localedata locale="en">
            <title>Producer 1</title> 
         </localedata>
      </wsrp-producer>
   </portal>
</request>

Replace http://portal_host:port/wp_contextRoot with the appropriate values for your environment.

The following XML sample shows how you use the XML configuration interface to create a Producer that requires registration. Use this sample if you work online and have access to the Producer's WSDL document. 

<?xml version="1.0" encoding="UTF-8" ?>
<request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd" create-oids="true">
   <portal action="locate">
      <wsrp-producer action="update" registration-required="true" uniquename="wps.myProducer2">
         <wsdl-url>  http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl</wsdl-url>
         <parameter name="regprop1" type="string" update="set">value1</parameter>
         <parameter name="regprop2" type="string" update="set">value2</parameter>
         <preferences name="userattributes" update="set">
            <value>cn</value>
            <value>o</value>
            <value>uid</value>
         </preferences>
         <localedata locale="en">
            <title>Producer 2</title>
         </localedata>
      </wsrp-producer>
   </portal>
</request>

Replace http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl with the appropriate values for your environment.

To use this sample with WebSphere Portal, set registration-required="false" and remove the parameter tags. This step is necessary because the WebSphere Portal Producer does not support registration.

After you have created a Producer instance, you can proceed to integrating the WSRP services that are provided by that Producer into your Consumer portal.

Exporting a Producer using the XML configuration interface

The following example shows how you use the portal XML configuration interface to export a WSRP Producer. You might, for example, export the Producer from a test portal in order to update your production portal with it later. 

<?xml version="1.0" encoding="UTF-8" ?> 
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd" type="export">
   <portal action="locate">
      <wsrp-producer action="export" objectid="*" /> 
   </portal>
</request>

Consuming a WSRP service

After you have created a Producer instance as described previously, you can proceed to consuming the WSRP services that are provided by that Producer, that is, integrating them into your Consumer portal as remote portlets.

On the Consumer side, all WSRP services that you consume as remote portlets behave like JSR 168 compliant portlets, independent of their implementation on the Producer side.

To consume a WSRP service as a remote portlet, you can use the Manage Web Modules portlet.

To consume a WSRP service using the XML configuration interface, specify the groupid and handle of the remote portlet. Specify the groupid with the portlet-app subtag and the handle with the portlet subtag. Both values are required to use the remote portlet. They are defined by the owner of the Producer portal. The Producer portal owner provides the handle and group ID to you by appropriate means, such as fax, phone, or e-Mail. If you cannot access this information, use external tools such as the Apache WSRP Open Source implementation to find out which WSRP services the Producer has to offer.

Producers with an IBM WebSphere Portal Producer can obtain this information by exporting all provided portlets on their Producer portal using the XML configuration interface (see Determining group IDs and handles).

subtag Attribute for the subtag Description
portlet-app groupid As provided by the Producer
portlet handle As provided by the Producer

After successful integration, the remote portlets are available in the portal administration. They are handled in the same manner as local portlets.

Notes:

  1. You can consume a WSRP service only if you work online and can access the Producer's WSDL document.

  2. The WSRP implementation of WebSphere Portal does not yet make use of public WSRP services registries, such as UDDI, to discover and consume WSRP services. Instead, it uses the discovery mechanism of WSRP services that is defined in the WSRP standard to obtain a list and descriptions of the WSRP services that a certain Producer provides.

  3. An integrated portlet is always treated as a JSR 168 portlet.

To delete integrated remote portlets, use the portal administration portlets.

If you consume the WSRP service in an XML script that has already created the Producer in a previous step already (see Create a Producer), you only need to specify the following items in the XML script:

  1. A locate action on the Producer.
  2. The portlet-app subtag with the groupid attribute.
  3. The portlet subtag with the handle attribute.

The following XML sample shows how you use the XML configuration interface to integrate a WSRP service as a remote portlet: 

<?xml version="1.0" encoding="UTF-8" ?>
<request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd">
   <portal action="locate">
      <wsrp-producer action="locate" uniquename="wps.myProducer1">
         <portlet-app action="update" active="true" groupid="_2_00KJL5N5NE0U0FIA_LT">
            <portlet action="update" active="true" defaultlocale="en" 
               handle="_5_00KJL5N5NE0U0FIA_FN" name="WSRP Reminder">
               <localedata locale="en">
                  <title>WSRP Reminder</title>
                  <description>Simple Reminder portlet as Web service</description>
               </localedata>
               <access-control externalized="false" owner="undefined" private="false"/>
            </portlet>
         </portlet-app>
      </wsrp-producer>
   </portal>
</request>

 

Security considerations for using WSRP with WebSphere Portal:

When using WSRP with WebSphere Portal, you can configure security and provide authentication by one of the following two options:

When you configure security between your WSRP portals by one of these options, you also need to configure Portal Access Control for the Consumer portal users on the Producer portal. The following sections include the steps for how to do this.

 

Securing Web services by using LTPA token authentication

The WSRP Web service client and server of WebSphere Portal comply with the JSR 109 standard and can exploit the Web service security features of WebSphere Application Server. For more information about this refer to the section about Securing Web Services Based on Web Services Security in the WebSphere Application Server Information Center.

For more information about the JSR standards refer to the Java Community Process Web site: http://jcp.org.

For more information about the JSR 109 standard refer to the JSR 109 Web site: http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html.

The following sections describe how you configure the WSRP Consumer and Producer to use Lightweight Third-Party Authentication (LTPA) token authentication to secure Web services.

 

Why and when to perform this task

Use this task to configure LTPA token authentication. However, configure the client for LTPA token authentication only if the authentication mechanism configured in WebSphere Application Server is LTPA for both the Consumer Portal and the Producer Portal. Refer to the WebSphere Application Server Information Center on how to configure LTPA in general.

When a client authenticates to a Consumer portal using the LTPA authentication mechanism, a unique LTPA token is created for this client and used in subsequent client requests. When the Consumer portal calls a WSRP Producer, you can configure the Consumer portal to forward the LTPA token from the originating client. For the Producer portal to validate the LTPA token, the LTPA keys on both servers must be the same. By using this mechanism, the WSRP request and invocation of remote portlets on the Producer side run within the same security context as on the Consumer side.

 

Prerequisites

Using LTPA token authentication for securing Web services has the following prerequisites:

  • The WebSphere Application Server LTPA authentication is enabled on both sides, the Producer and the Consumer portal.
  • The same LTPA keys are set up on the Producer portal and all participating Consumer portals.
  • Producer portal and Consumer portal use the same cookie domain.

 

Configure your portal for LTPA token authentication

The following sections describe how you configure your WebSphere Portal for LTPA token authentication. Administrators need to perform the following steps for both the Producer and Consumer portals:

  1. Specify the LTPA authentication.
  2. Modify the security binding information.
  3. After completing these two steps for a portal, restart the portal for the changes to take effect.

To perform these tasks, refer to the following sections:

 

Configure the Consumer portal for LTPA token authentication

The following sections describe how you configure the Consumer portal for LTPA token authentication.

Specifying LTPA authentication for the Consumer portal

To specify the LTPA authentication for a Consumer portal, proceed by the following steps:

  1. Edit the file was_root/config/cells/your_host/applications/wps.ear/deployments/wps/wps.war/WEB-INF/ibm-webservicesclient-ext.xmi
  2. For the portQnameBindings of each WSRP service interface specify that you use LTPA authentication. To do this, replace the line 
        <portQnameBindings xmi:id="PortQnameBinding_1094728959716" 
     portQnameLocalNameLink="WSRPPortletManagementService"/>

    by the following lines: 

        <portQnameBindings xmi:id="PortQnameBinding_1094728959716" 
            portQnameLocalNameLink="WSRPPortletManagementService">
        <clientServiceConfig xmi:id="ClientServiceConfig_WSRP_PM_1">
            <securityRequestSenderServiceConfig 
                    xmi:id="SecurityRequestSenderServiceConfig_WSRP_PM_1">
                <loginConfig xmi:id="LoginConfig_WSRP_PM_1" authMethod="LTPA"/>
            </securityRequestSenderServiceConfig>
        </clientServiceConfig>
    </portQnameBindings>
    The example is for the Portlet Management interface.
  3. Make the same change for the other interfaces:
    • Service Description.
    • Markup.
    • You do not need to update the Registration interface as it is not supported for WebSphere Portal V5.1.

Notes:

  1. You just add the <clientServiceConfig> . However, make sure you add the closing tag for the </portQnameBindings> element.
  2. You can choose the IDs as you want to, but each ID must be unique.

Modifying the security binding information for the Consumer portal

This section describes how you add the necessary Consumer security binding information for each WSRP portType. You can do this by one of the following two ways:

  • By using the WebSphere Application Server Administration Console. For details about how to do this refer to the WebSphere Application Server Information Center.
  • By editing the file was_root/config/cells/your_host/applications/wps.ear/deployments/wps/wps.war/WEB-INF/ibm-webservicesclient-bnd.xmi

Provide the following binding information for the portType of each WSRP service interface:

  • The authentication method; this must be set to LTPA
  • The token value type URI; this must be set to http://www.ibm.com/WebSphere/appserver/tokentype/5.0.2
  • The token value type local name; this must be set to LTPA
  • The callback handler; this must be set to com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler

To provide the binding information, proceed by the following steps:

  1. Edit the file ibm-webserviceclient-bnd.xmi
  2. For the portQnamePortBindings of each WSRP service interface, replace the line 
        <portQnameBindings xmi:id="PortQnameBinding_1094728959506" 
        portQnameLocalNameLink="WSRPPortletManagementService"/>

    by the following lines: 

        <portQnameBindings xmi:id="PortQnameBinding_1094728959506" 
            portQnameLocalNameLink="WSRPPortletManagementService">
        <securityRequestSenderBindingConfig xmi:id="SecurityRequestSenderBindingConfig_WSRP_PM_1">
            <loginBinding xmi:id="LoginBinding_WSRP_PM_1" authMethod="LTPA" 
                    callbackHandler="com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler">
                <tokenValueType xmi:id="TokenValueType_WSRP_PM_1" 
                    uri="http://www.ibm.com/WebSphere/appserver/tokentype/5.0.2" localName="LTPA"/>
            </loginBinding>
        </securityRequestSenderBindingConfig>
    </portQnameBindings>
    The example is for the Portlet Management interface.
  3. Make the same change for the other interfaces:
    • Service Description.
    • Markup.
    • You do not need to update the Registration interface as it is not supported for WebSphere Portal V5.1.

Notes:

  1. You just add the <clientServiceConfig> . However, make sure you add the closing tag for the </portQnameBindings> element.
  2. You can choose the IDs as you want to, but each ID must be unique.

After you have specified LTPA authentication and modified the authentication method information for the Consumer portal, restart your portal for the changes to take effect.

 

Configure the Producer portal for LTPA token authentication

The following sections describe how you configure the Producer portal for LTPA token authentication.

Specifying LTPA authentication for the Producer portal

To specify the LTPA authentication for a Producer portal, proceed by the following steps:

  1. Edit the file was_root/config/cells/your_host/applications/wps.ear/deployments/wps/wps.war/WEB-INF/ibm-webservices-ext.xmi
  2. For the pcBinding of each WSRP service interface specify that you use LTPA authentication. To do this, replace the line 
        <pcBinding xmi:id="PcBinding_1063269561895" 
        pcNameLink="WSRPServiceDescriptionService" 
        scope="Application"/>

    by the following lines: 

        <pcBinding xmi:id="PcBinding_1063269561895" 
            pcNameLink="WSRPServiceDescriptionService" scope="Application">
        <serverServiceConfig xmi:id="ServerServiceConfig_WSRP_SD_1">
            <securityRequestReceiverServiceConfig 
                    xmi:id="SecurityRequestReceiverServiceConfig__WSRP_SD_1">
                <loginConfig xmi:id="LoginConfig__WSRP_SD_1">
                    <authMethods xmi:id="AuthMethod__WSRP_SD_1" text="LTPA"/>
                </loginConfig>
            </securityRequestReceiverServiceConfig>
        </serverServiceConfig>
    </pcBinding>
    The example is for the Service Description interface.
  3. Make the same change for the other interfaces:
    • Portlet Management.
    • Markup.
    • You do not need to update the Registration interface as it is not supported for WebSphere Portal V5.1.

Notes:

  1. You just add the <serverServiceConfig> . However, make sure you add the closing tag for the </pcBindings> element.
  2. You can choose the IDs as you want to, but each ID must be unique.

Modifying the security binding information for the Producer portal

This section describes how you add the necessary Producer security binding information for each WSRP portType. You can do this by one of the following two ways:

  • By using the WebSphere Application Server Administration Console. For details about how to do this refer to the WebSphere Application Server Information Center.
  • By editing the file was_root/config/cells/your_host/applications/wps.ear/deployments/wps/wps.war/WEB-INF/ibm-webservices-bnd.xmi

Provide the following binding information for the portType of each WSRP service interface:

  • The authentication method; this must be set to LTPA
  • The configuration name; for the LTPA authentication method, enter WSLogin for the JAAS login configuration name. This configuration understands how to validate an LTPA token.
  • The token value type; For LTPA authentication, specify a custom token type because LTPA is considered to be a custom type. LTPA is not part of the Web Services Security Specification. Provide the following token value type information:
    • The token value type URI; this must be set to http://www.ibm.com/WebSphere/appserver/tokentype/5.0.2
    • The token value type local name; this must be set to LTPA
    • The callback handler factory class name; this must be set to com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl
    Note: When you use the WebSphere Application Server Administration console to provide the binding information, select the Token Value Type option to get the custom token type options listed.

To provide the binding information, proceed by the following steps:

  1. Edit the file ibm-webservices-bnd.xmi
  2. For the pcBindings of each WSRP service interface, replace the line 
        <pcBindings xmi:id="PCBinding_1063269561875" 
        pcNameLink="WSRPServiceDescriptionService" 
        scope="Application"/>

    by the following lines: 

        <pcBindings xmi:id="PCBinding_1063269561875" 
        pcNameLink="WSRPServiceDescriptionService" scope="Application">
        <securityRequestReceiverBindingConfig 
                xmi:id="SecurityRequestReceiverBindingConfig_WSRP_SD_1">
            <loginMappings xmi:id="LoginMapping_WSRP_SD_1" 
                    authMethod="LTPA" configName="WSLogin">
                <callbackHandlerFactory xmi:id="CallbackHandlerFactory_WSRP_SD_1" 
                    classname="com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl"/>
                <tokenValueType xmi:id="TokenValueType_WSRP_SD_1" 
                    uri="http://www.ibm.com/WebSphere/appserver/tokentype/5.0.2" 
                    localName="LTPA"/>
            </loginMappings>
        </securityRequestReceiverBindingConfig>
    </pcBindings>
    The example is for the Service Description interface.
  3. Make the same change for the other interfaces:
    • Portlet Management.
    • Markup.
    • You do not need to update the Registration interface as it is not supported for WebSphere Portal V5.1.

Notes:

  1. You just add the <securityRequestReceiverBindingConfig> . However, make sure you add the closing tag for the </pcBindings> element.
  2. You can choose the IDs as you want to, but each ID must be unique.

If you want to enable Portal Access Control for the Producer portal, edit the file wp_root/shared/app/config/services/ConfigService.properties and set the following parameter to true: wsrp.security.enabled = true .

After you have specified LTPA authentication and modified the authentication method information for the Producer portal, restart your portal for the changes to take effect.

 

Known limitations with securing Web services by using LTPA token authentication

All-or-nothing setup: Producer portals that have been configured to do LTPA authentication will reject all SOAP messages that do not carry the valid LTPA token.

Consumer portals provide LTPA token in all cases: Consumer portals that have been configured to provide the LTPA token will do so for all target Producers, independent of whether the Producer requires the token or not. This can expose security issues if the token is unintentionally provided to other Producers.

IBM LTPA token is proprietary: The security setup of Web services by using LTPA token authentication uses a proprietary IBM LTPA token.

Consumer and Producer must be in the same LTPA cookie domain: The security setup of Web services by using LTPA token authentication works only if the Consumer and Producer portals are set up in the same LTPA cookie domain.

 

Security using Secure Socket Layer

You can enable security for the WSRP implementation in your portal by using Secure Socket Layer (SSL) with Client Certificate Authentication. To do this, complete the steps in the following sections:

  1. Set up WebSphere Portal for SSL support.
  2. Enable the WSRP Consumer portal to use HTTP over SSL (HTTPS) for communication with Producers.

As J2EE allows only for one authentication mechanism per WAR file, WSRP introduces a second WAR file for the Producer portal. This WAR file is named wps_facade.war . The WAR file contains servlets that work as a facade interface Web application that channels the WSRP requests to the Producer's access points.

You can now simultaneously use both SSL client authentication for your WSRP Producer portal and other means of authentication for the rest of your portal, for example form based authentication. You do this as follows:

  • Configure the primary portal WAR file for use of other means of authentication, for example form based authentication.
  • Configure SSL client authentication for the web.xml of the facade WAR file for the WSRP Producer.

This second WAR file for the Producer requires a separate context root for the Producer. The default value for this second context root is wsrp to give the full context root http://my.portal.com:myport/wsrp . You can configure this context root as required. To do this, set the property uri.context.path.facade in the file WP_ROOT/shared/app/config/services/ConfigService.properties to a different value. For more details about this, refer to Portal Service configuration, especially Configuration Service.

 

Set up WebSphere Portal for SSL support

  1. Configure WebSphere Portal for SSL support. This step is necessary if you want SSL communication between the Web browser and WebSphere Portal; otherwise it is optional. For more information, refer to Set up SSL for WebSphere Portal.
  2. Configure WebSphere Application Server for SSL support. For information, refer to Chapter 10, Administering WebSphere security, in IBM WebSphere V5.0 Security: WebSphere Handbook Series, SG24-6573-00.
    1. Enable security. For details about how to do this, refer to Configure Security.
    2. Enable SSL ID tracking. Click Application Servers > WebSphere_Portal > Web Container > Session Management.
    3. Configure your advanced LDAP security settings. Certificate-based authentication requires that you configure the authentication mechanism so that one of the following conditions apply:
      • WebSphere Application Server maps the entire Distinguished Name (DN) from the subject field of the certificate to a corresponding Distinguished Name in your LDAP. To use this option, set the mapping technique in the LDAP configuration panel to exact.
      • WebSphere Application Server maps the entry in the subject field to a different attribute than the Distinguished Name in your user registry. To use this option, set up the mapping technique in the LDAP configuration panel to use the certificate filter option. Using the certificate filter option allows you more flexibility in using other attributes than the Distinguished Name to identify the users. For example, the filter uid=${SubjectCN} maps the SubjectCN field of the client certificate to the uid attribute in your LDAP.
    4. Define a new virtual host alias. Click Environment > Virtual Hosts > default_host > Host Aliases > New, and define your SSL communication port. Use an asterisk as a wild card for the hostname: * . If you use an external HTTP server, regenerate the plug-in. Click Environment > Update Web Server Plugin > OK and follow the instructions on the screen.
    5. Restart the HTTP server for the changes to take effect.
  3. Enable client authentication in your Web server. For IBM HTTP Server (IHS), see IBM WebSphere V5.0 Security, SG24-6573-00.
  4. Exchange the public certificates to be used for the SSL connection between the Consumer and the HTTP servers and import them into the corresponding trust stores.
  5. Edit the file web.xml in the directory was_root/config/cells/your_host/applications/wps.ear/deployments/wps/wps_facade.war/WEB-INF, and add the following tags:
    • Add a new login-config tag for the client certificate authentication method with a new unique ID, for example: 
      <login-config id="LoginConfig_2">
   <auth-method>CLIENT-CERT</auth-method>
   <realm-name>WPS_FACADE</realm-name>
</login-config>
    • Add new security-constraint tags for the WSRPBaseService and WSRPPortletManagementService URL patterns. The following example shows the WSRPBaseService URL pattern: 
      <security-constraint id="SecurityConstraint_2">
   <web-resource-collection id="WebResourceCollection_2">
      <web-resource-name></web-resource-name>
      <url-pattern>/WSRPBaseService</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
   </web-resource-collection>
   <auth-constraint id="AuthConstraint_2">
      <description></description>
      <role-name>All Role</role-name>
   </auth-constraint>
   <user-data-constraint id="UserDataConstraint_5">
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>
  6. Edit the file wp_root/shared/app/config/services/ConfigService.properties, and update the affected properties as follows:
    1. If you want to enable Portal Access Control for the Producer portal, set the following parameter to true: wsrp.security.enabled = true .
    2. If the URLs of the WSRP ports have to point to different locations or use different ports, configure them accordingly. By default, the URLs of the WSRP ports are the same as the URLs by which the Web services WSDL document is addressed by Consumers. For details about how you can change these URLs, see Set the WSRP SOAP ports.
  7. Restart your portal for the changes to take effect.

For more details about how to perform these steps, see the following topics:

  • Set up SSL
  • Managing Security in the WebSphere Application Server Information Center.

 

Enable the WSRP Consumer portal to use HTTP over SSL (HTTPS) for communication with Producers

Enable transport layer security in the WebSphere Application Server Administrative Console for each of the four WSRP ports. To do this, proceed by the following steps:

  1. Click Applications > Enterprise Applications > wps.
  2. Under Related Items, click Web Module > wps.war > Web Services: Client Security Bindings.
  3. Under HTTP SSL Configuration, click Edit . . . and activate HTTP SSL enabled.
  4. Select the appropriate HTTP SSL configuration. Perform this step for each of the four WSRP ports.

For more information about securing Web services refer to the WebSphere Application Server Information Center.

Configure your WSRP Consumer portal if you use client authentication to integrate Producers: If your WebSphere Portal acts as a WSRP Consumer and uses client authentication to integrate other Producers, configure your portal as follows:

  1. Verify the CSIv2 outbound settings in the administrative console of WebSphere Application Server. To do this, click Security > Authentication Protocol > CSIv2 Outbound Transport. The SSL configuration that is assigned here is used for SSL connections to other servers. You can reuse this configuration by ensuring that client authentication is activated for this profile. Alternatively, you can create a new SSL configuration by clicking Security > SSL, and assign it to the CSIv2 outbound configuration. The key stores and trust stores that are assigned in the SSL configuration are used for your outbound connection.
  2. Verify the CSIv2 outbound authentication settings. To do this, click Security > Authentication Protocol > CSIv2 Outbound Authentication and verify that the property in the section Client Certificate Authentication is set to supported.

 

Enable Portal Access Control for WSRP with WebSphere Portal

If you are using one of the authentication mechanisms described above, you can configure Portal Access Control for the Producer. To enable Portal Access Control when using WSRP with WebSphere Portal, proceed by the following steps:

  1. Edit the file wp_root/shared/app/config/services/ConfigService.properties.
  2. Activate the WSRP security by setting the following parameter to true: wsrp.security.enabled = true .

Assign access rights based on the authentication information:

For more details and considerations about Portal Access Control, refer to Enable security and Security concepts.

 

Customize the WSRP configuration of your portal

This section describes various parameters that you can use to customize the WSRP support in your portal. Configuring these parameters is optional.

 

Set the WSRP SOAP ports

As a Producer you can modify the URLs for the WSRP SOAP (Simple Object Access Protocol) ports in your Producer WSDL document, for example if you want to provide Web services under different virtual Producers. In this case you provide different ports on different machines or use different proxy servers through which Consumers can access your Producer portal. To do this, edit the file wp_root/shared/app/config/services/ConfigService.properties. You can specify four different port URLs for HTTP and four different port URLs for HTTPS to be used with Secure Socket Layer (SSL). For more information about SSL see Security using Secure Socket Layer. The following characteristics apply to the URLs:

  • Each of the URLs must include the protocol, such as HTTP or HTTPS, the name or the IP address of the host, and the context root of the Producer portal. You can configure this context root as required. For more information about how to do this, see Security using Secure Socket Layer
  • To be able to support different authentication mechanisms for the regular portal and the WSRP Producer, the WSRP Producer uses a different Web module with a different context root. For details about this refer to Security using Secure Socket Layer.
  • The URLs must not end with a path separator slash ( / ).
  • The URLs can contain a port number.

An example of a valid URL is shown here:

    http://my.portal.com:myport/wp_facade_contextRoot

The keys for the HTTP WSRP SOAP URLs are listed here:

  • wsrp.soap.address.description.http
  • wsrp.soap.address.markup.http
  • wsrp.soap.address.portletmanagement.http

The keys for the secured HTTPs WSRP SOAP URLs are listed here:

  • wsrp.soap.address.description.https
  • wsrp.soap.address.markup.https
  • wsrp.soap.address.portletmanagement.https

In case you want to use different authentication mechanisms for the regular portal and the WSRP Producer, you can use a different web module with a different context root for the WSRP Producer. For more information about this refer to Security using Secure Socket Layer.

 

Proxy settings

To configure the proxy settings of a Consumer portal for the WSRP communication, you can use the settings of the ContentAccessService to do this. For more details see Portal Service configuration, especially Content Access Service.

 

Parallel portlet rendering

If you want to enable parallel portlet rendering in your portal, set one or both of the parameters for parallel portlet rendering to true. You change the values for these parameters in the file wp_root/shared/app/config/services/PortletContainerService.properties. The settings depend on the type of portlets you use and on whether you consume Web services as remote portlets or not:

  • For parallel rendering of your local IBM portlets, enable legacy.useParallelRendering.
  • For parallel rendering of your local JSR 168 compliant portlets, enable std.useParallelRendering.
  • For parallel rendering of WSRP services that you consume in your Consumer portal as remote portlets, enable std.useParallelRendering.

    Note: If you enable this parameter for use with remote portlets in your Consumer portal, increase the value for its timeout parameter parallelRenderingTimeOut to 10000.

Note: The settings that you specify do not influence the invocation via WSRP of portlets that you provide as a Producer. This is because the Consumer always sends a separate WSRP request for each single portlet.

 

Switching the caching off and on

By default, the portal caches the WSRP service descriptions from Producers whose portlets the Consumer has integrated. The caching increases performance and reduces network traffic.

If you encounter problems, or for any other reason want to turn off caching of the service description, edit the file wp_root/shared/app/config/services/CacheManagerService.properties, and set the parameter cacheinstance.wsrp.cache.servicedescription.enabled=false .

 

Known limitations

This section lists known limitations of the WSRP support in WebSphere Portal.

 

Remote portlets on unauthenticated pages

If you add remote portlets to unauthenticated pages that have public sessions switched off, this has the following two consequences:

  1. Session data is lost for each request.
  2. An additional request to the Producer is submitted to establish a session.

If you add remote portlets to unauthenticated pages, switch on public sessions. This way you can benefit portal performance and avoid unexpected behavior resulting from the lost session data.

 

Rendering URLs for forms

Submitting data to a portlet through forms is semantically an action as the state of the portlet is changed by this request. WSRP strongly enforces the separation of action and render requests according to the corresponding semantics. It prevents the submission of form data through render requests. This means that portlets that use render URLs to submit form data do not work remotely.

 

Portlets using portal internals

With WSRP you cannot use portal internals in portlets, such as engine objects or engine tags. Portlets that use such internals do not work remotely as WSRP does not supply the infrastructure required for this.

 

Dynamic titles for remote portlets

The WSRP proxy portlet is written according to the JSR 168 portlet API. As the implementation of the JSR 168 portlet container does not support dynamic titles for WebSphere Portal, dynamic titles do not work, even if the remote portlet is written according to the IBM V4.x portlet API. This includes calls to the methods of the IBM V4.x portlet API PortletTitleListener interface.

 

Invocation of minimized portlets

The WSRP proxy portlet is written according to the JSR 168 portlet API. As the implementation of the JSR 168 portlet container does not support the invocation of minimized portlets for WebSphere Portal, a minimized portlet is not called even if the remote portlet is written according to the IBM V4.x portlet API.

Remote Portlet Web Services (RPWS)

WebSphere Portal V5.1 does not support the IBM proprietary Remote Portlet Web Services (RPWS) that WebSphere Portal V4.x supported. (This is not the same as WSRP - Web Services for Remote Portlets.)

 

Troubleshooting

To ease debugging and monitoring of the WSRP communication, the servlet that generates the WSDL document of a WebSphere Portal Producer accepts the optional URL parameter port. Use this parameter to modify the ports of the WSRP interfaces that are exposed by that Producer. Specify this parameter as an addition to the URL for the Producer's WSDL document. Here is an example of a Web address that you can enter in your browser, with the port parameter added:

    http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl?port=portValue

Adding this parameter does not configure the actual ports of the WSRP interfaces. A direct communication against these ports will fail. This parameter only changes the values that appear in the WSDL document. Therefore you can monitor the WSRP communication. If the port parameter is missing, then the correctly configured ports of the WSRP interfaces are exposed in the generated WSDL document.

 

Monitoring WSRP messages between the Consumer and Producer

Use the TCPMon tool to monitor the WSRP messages between the Consumer and Producer, as described in the WebSphere Application Server Information Center topic Tracing Web services messages. To do this, configure the TCPMon tool to listen on the port that you specified for the optional port parameter. Also, set the target port to the actual port values of the Producer's WSRP interfaces. For the WebSphere Portal Producer, these are the ports that appear in the WSDL file when requesting the WSDL without the port parameter.

Run the TCPMon tool using the following command: java -cp was_root/lib/webservices.jar com.ibm.ws.webservices.engine.utils.tcpmon .

 

Parallel portlet rendering with remote portlets

If you encounter errors with parallel portlet rendering of remote portlets in your Consumer portal, try to improve this situation by further increasing the value of the timeout parameter parallelRenderingTimeOut beyond the value of 10000 given further above. For more details about parallel portlet rendering with remote portlets, see Parallel portlet rendering.

 

Using the WebSphere Portal run-time log file

You can enable run-time logs for the Consumer, Producer, and administration components of the WSRP implementation. Use the portal administration portlet Enable Tracing to do this. For more detailed information about how to enable WebSphere Portal run-time logging, refer to Using logs and Logging and tracing, especially WebSphere Portal run-time logs.

You can enable the following trace loggers for the WSRP implementation:

Component Trace string
Administration com.ibm.wps.command.wsrp.*=all=enabled

com.ibm.wps.wsrp.cmd.*=all=enabled

Consumer com.ibm.wps.wsrp.consumer.*=all=enabled
Producer com.ibm.wps.wsrp.producer.*=all=enabled
XMLAccess com.ibm.wps.command.xml.*=all=enabled

 

 

Abbreviations

J2EE

Java 2 Platform, Enterprise Edition

JSSE

Java Secure Socket Extension

JSTL

JSP Standard Tag Library

SOAP

Simple Object Access Protocol

UDDI

Universal Description, Discovery, and Integration

WSRP

Web Services for Remote Portlets

WSDL

Web Services Description Language

WSIA

Web Services for Interactive Applications

 

See also

Home |

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.