D Interoperability with WSRP

This appendix describes how Oracle Service Bus provides Service Level Agreement (SLA) monitoring in applications that use Web Services for Remote Portlets (WSRP). WSRP is a mechanism used to generate markup fragments on a remote system for display in a local portal application.

This appendix includes the following sections:

D.1 WSRP Producers and Consumers

WSRP involves two integral components: producers and consumers.

A WSRP producer, referred to as producer in this document, is a remote application that implements standards-based web services using the SOAP specification over HTTP. You can create a producer using WebLogic Portal or third-party implementations of WSRP.
A WSRP consumer, referred to as a consumer in this document, is a portal application. Typically, the consumer application references the WSDL document of the producer when the portal is designed, and the consumer directly accesses the producer.

D.2 WSRP Architecture

This section describes the architecture of WSRP and shows how to enhance the architecture by adding Oracle Service Bus.

The following figure shows the WSRP SOAP request and response flow between a producer application and a consumer application.

Figure D-1 Basic Request/Response Flow Between Producer and Consumer Applications

Description of "Figure D-1 Basic Request/Response Flow Between Producer and Consumer Applications"

D.2.1 Enhanced Architecture with Oracle Service Bus

The following figure shows how to use Service Bus as an intermediary between the producer and the consumer to provide Service Level Agreement (SLA) monitoring.

Figure D-2 Enhanced WSRP Request / Response Flow Using Oracle Service Bus

Description of "Figure D-2 Enhanced WSRP Request / Response Flow Using Oracle Service Bus"

The WSRP SOAP request/response flow occurs in the following sequence:

Inbound Request: The consumer calls the proxy service in Service Bus.
Outbound Request: The proxy service routes the request, which is a message containing the SOAP body and transport headers, to the producer.
Outbound Response: The producer sends a response to Service Bus.
Inbound Response: The proxy service sends a response to the consumer. The response is a message that contains the SOAP body and transport headers.

For information about the actual configuration of Service Bus components, see Configuring Oracle Service Bus for WSRP.

D.3 WSRP Design Concepts

Two primary components in WSRP design are the WSDL documents that describe the services and the messaging format.

D.3.1 WSRP WSDL Documents

The following table describes various kinds of services offered by WSDL documents. WSDL documents are referred to as Producers.

Table D-1 Producer Services

Service	Description
Service Description	Required service. Describes the producer and the portlets that the producer makes available to consumers.
Markup	Required service. Manages user interaction with a remote portlet and returns the HTML markup used to render the portlet.
Registration	Optional service. Required for complex producers. Allows consumers to register themselves with the producer.
Management	Optional service. Provided by complex producers for managing portlet customization and portlet preferences.
Markup Extension	Provided by Oracle WebLogic Portal producers and replaces the Markup service. Markup Extension allows more efficient message handling by using multipart MIME messages for transmitting HTML markup content.

Each producer implements a minimum of two services, such as Service Description and Markup. A simple producer offers just these two services. A complex producer, however, provides two additional services, such as Registration and Management. In addition, WebLogic Portal producers implement an extension service, such as Markup Extension that replaces the standard Markup service.

These services are described using a standard WSDL format. The producer supplies a single URL for retrieving its WSDL document, which describes all the services that are provided by that producer. The end points for each service indicate whether the consumer should use transport-level security (HTTPs) or abstain from communication with the producer.

D.3.2 WSRP Messages

WSRP uses SOAP over HTTP for all messages exchanged between producers and consumers. In addition to using the standard message formats in the SOAP body, WSRP requires that consumers set at least a SOAPAction header, the cookie headers, and the usual HTTP headers, such as Content-Type. Producers return a session cookie, and any application-specific cookies, in the HTTP transport header of the response. The consumer must return the session cookie in subsequent request messages.

D.4 Configuring Oracle Service Bus for WSRP

You can configure Service Bus components in either Oracle JDeveloper or the Oracle Service Bus Console.

Configuring Service Bus for WSRP involves the following tasks:

Implement a service that consumers can invoke to obtain an appropriate WSDL document for a particular producer.
Implement the details of conveying a consumer's request to the producer and returning the response to the consumer.

The following sections describe how to configure Service Bus components to send requests for WSRP services through proxy services. They also describe the services that a producer provides, along with other attributes of WSRP that must be used to configure Service Bus components. Finally, they include information about monitoring producers with increasing degrees of detail, as well as load balancing and failover with WSRP.

For more information about creating WSRP-enabled portals using Oracle WebLogic Portal, see the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.

D.4.1 Getting the Producer WSDL Document

As a common practice, consumers directly contact a producer to obtain its WSDL document. However, if Service Bus is used as a proxy service, then all access to the producer occurs via Service Bus. Therefore, a proxy service is implemented for consumers. The proxy service calls the producer's real URL to obtain the producer WSDL file. The proxy service transforms the results as follows:

Rewrites the endpoint address for the producer to refer to the Service Bus IP address and port number.
Changes the endpoint URI to refer to the proxy service that reflects the required monitoring granularity as described in Monitoring WSRP Applications.
Changes the endpoint protocol and port number if transport security is used between the consumer and the proxy service.

D.4.2 Using SSL with WSRP Producers

When a producer is created, it can be configured to require SSL ("secure=true"). In addition, the Service Bus administrator can change the security requirement to the consumer in the Service Bus configuration. For example, if a producer does not require SSL, you can require consumers to use SSL by performing the following steps:

Change the WSDL file to specify HTTP(s).
Configure the WSRP proxy services to use HTTP(s).

When configured in this way, Service Bus automatically bridges the secure messages from the consumer to the non-secure messages used by the producer.

D.4.3 Routing Messages Between Consumer and Producer

After retrieving a copy of the WSDL file, the consumer uses the WSDL definitions to formulate service requests and sends them to the producer using Service Bus. The WSRP request/response process involves the following steps:

The consumer sends a message to the Service Bus proxy service corresponding to the producer service.
The proxy service sends the message to a pipeline, which executes a simple message flow that routes the message (unchanged) to the actual producer service.
The producer formulates and sends a response to the consumer through Service Bus.
The consumer receives the response (unchanged) from the producer.

WSRP web services expose portlets, and those can rely on HTTP cookies and sessions. You must configure Service Bus to propagate HTTP transport headers, such as SOAPAction and cookies. However, by default, Service Bus does not pass transport headers from the proxy service to the business service because the proxy service may not use the same transport as the business service. Therefore, you must configure the pipeline to copy the request headers from the inbound request to the outbound request. Similarly, you must copy the response headers from the business service back to the proxy service's response to the consumer.

Although you can copy all transport headers between the proxy service and the business service, being more selective can avoid errors. You must copy the Set-Cookie and Cookie headers. The final message must own some headers, such as Content-Length because Service Bus assembles the final message to send. For example, if the message flow copies the Content-Length header from the proxy service to the business service, it can result in an error because the length of the message can change during processing. Therefore, Service Bus must own this header.

D.4.4 Monitoring WSRP Applications

Monitoring a WSRP application tracks the usage of a producer's individual services and operations. The message flow for WSRP services introduces very little overhead, and the mapping between proxy services and producers, and between business services and producers, is simple to configure. Therefore, to satisfy SLA requirements, it is sufficient to monitor only the proxy services.

D.4.5 Load Balancing and Failover

Service Bus allows business services to define multiple endpoints that provide the same web service. When multiple endpoints are defined, Service Bus can automatically distribute load balance requests across endpoints, and it can automatically failover requests when an endpoint is inaccessible.

D.4.5.1 WSRP Limitations Without Session Stickiness

Portlets are a means of exposing a user interface to an application, so they typically have session data associated with them. To preserve session data, requests to the portlet must be directed to the same server or cluster that serviced the original request. This requirement makes load balancing through Service Bus inappropriate unless the business process is configured for HTTP session stickiness. Multiple endpoints in a business service usually target different servers or clusters. Without session stickiness configured there is no way to preserve the session because there is no communication among servers that are in separate clusters. Therefore, if multiple endpoints are defined for a WSRP business service and session stickiness is not enabled, you must set the load-balancing algorithm to "none".

You can use multiple endpoints to provide redundancy in certain circumstances in the event that one of the endpoints is not available. The WSRP service is still available on a secondary endpoint. However, any session data that existed at the time the first endpoint failed will not be available on other endpoints. This failover configuration is an option only for simple producers, not for complex producers (see WSRP WSDL Documents). Complex producers require that their consumers register with the producer before sending service requests. The producer returns a registration handle that the consumer must include with each request to that producer. If a business service defines multiple endpoints, each endpoint provides and requires its own registration handle.

However, Service Bus is stateless across requests, it does not maintain a mapping of the correct handle to send to a particular endpoint. In fact, it sends the registration request to a single endpoint, so the consumer is registered with only one producer. If that producer is not available, then Service Bus routes a service request to another endpoint defined for that business service. Since the consumer is not registered with that new producer, the request fails with an "InvalidRegistration" fault.

The management of registration handles requires an application outside of Service Bus to maintain this state data, so the registration requirement avoids defining multiple endpoints for complex producers. Simple producers do not support the registration service, so a failover configuration that defines multiple endpoints in the business service is possible although session data is lost on failover.

D.4.5.2 Using WSRP with HTTP Session Stickiness

For load balancing with HTTP business services that have multiple endpoints, you can configure the service to use session stickiness, also known as session affinity. When using sticky sessions, all messages are processed by the server that processed the initial request in the session. Session stickiness can be configured at runtime without needing to restart the server.

When an initial request is sent for a session, it is sent to the first URI endpoint based on the load-balancing algorithm. The session ID is associated with the URI endpoint that serves this initial request, and the session is mapped to that URI index in a URI table. Subsequent requests in the same session go to that URI endpoint instead of the URI endpoint that would have been chosen based on a load-balancing algorithm.

Session stickiness behaves as follows, depending on the business service configuration:

Messages are retried on the same URI endpoint based on the retry configuration of the business process. If the retry count is exhausted, the URI endpoint is marked as offline and Service Bus throws an exception.
If a business service URI endpoint is dynamically configured from a message flow, the sessions will not be sticky even if session stickiness is enabled.
If the URI endpoint is offline, session stickiness is no longer maintained.
If the service URI table is modified mid-session and the index is out of the bounds of the URI table, a TransportException is thrown with an error code of TransportManager.TRANSPORT_STATUS_APPLICATION_ERROR.

When configuring business processes for session stickiness, be sure to transfer the cookie headers from inbound to outbound for requests and from outbound to inbound for responses.