|
|
The AquaLogic Service Bus Console, which is described in Using the AquaLogic Service Bus Console, is used to configure AquaLogic Service Bus. For more information about creating WSRP-enabled portals by using WebLogic Portal, see Federated Portals Guide.
Configuring AquaLogic Service Bus for WSRP involves the following tasks:
This chapter describes the following tasks:
As a common practice, consumers directly contact a producer to obtain its WSDL. However, if AquaLogic Service Bus is used as a proxy service, then all access to the producer occurs via AquaLogic Service Bus. Therefore, a proxy service is implemented for consumers. The proxy service calls the producer's real URL to obtain the producer WSDL. The proxy service transforms the results as follows:
The developer who creates a producer can specify whether the producer requires SSL ("secure=true"). In addition, the AquaLogic Service Bus administrator can change the security requirement to the consumer via AquaLogic Service Bus configuration. For example, if a producer does not require SSL, the AquaLogic Service Bus administrator can require consumers to use SSL by doing the following:
When configured in this way, AquaLogic Service Bus automatically bridges the secure messages from the consumer to the non-secure messages used by the producer.
After retrieving a copy of the WSDL, the consumer uses the WSDL definitions to formulate service requests and sends them to the producer via AquaLogic Service Bus. The WSRP request/response process involves the following steps:
WSRP web services expose portlets, and those can rely on HTTP cookies and sessions. You must configure WLSB to propagate HTTP transport headers, such as SOAPAction and cookies. However, by default, AquaLogic 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 message flow 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 it is possible to copy all transport headers between the proxy service and the business service, it is necessary to be more selective to avoid errors. You must copy the Set-Cookie and Cookie headers. The final message must own some headers, such as Content-Length because AquaLogic Service Bus is the entity that 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, ALSB must own this header.
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.
For more information about monitoring WSRP Applications, see Monitoring ALSB at Run Time in Operations Guide.
AquaLogic Service Bus allows business services to define multiple endpoints that provide the same web service. When multiple endpoints are defined, AquaLogic Service Bus can automatically distribute load balance requests across endpoints, and it can automatically failover requests when an endpoint is inaccessible. However, WSRP imposes some limitations on the use of these features.
Portlets are a means of exposing a user interface to an application. Therefore, portlets 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 via AquaLogic Service Bus inappropriate. Multiple endpoints in a business service usually target different servers or clusters. 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, then you must set the load-balancing algorithm to "none".
You can use multiple endpoints to provide redundancy in certain circumstances if 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 (see WSRP WSDLs), not for complex produces. 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, AquaLogic 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 AquaLogic Service Bus routes a service request to another endpoint defined for that business service. However, the consumer is not registered with that new producer, and the request fails with an "InvalidRegistration" fault.
The management of registration handles requires an application outside of AquaLogic Service Bus to maintain this state data. Therefore, the registration requirement avoids defining multiple endpoints for complex producers. As simple producers do not support the registration service, a failover configuration that defines multiple endpoints in the business service is possible although session data is lost on failover.
|