|
|
The AquaLogic Service Bus Console, which is described in the AquaLogic Service Bus Console Online Help, is used to configure AquaLogic Service Bus. For more information about creating WSRP-enabled portals using WebLogic Portal, see Federated Portals Guide.
Configuring AquaLogic Service Bus for WSRP involves the following tasks:
This topic describes the following tasks:
As a common practice, consumers contact a producer directly to obtain its WSDL. However, if AquaLogic Service Bus is used to proxy the service, then all access to the producer occurs via AquaLogic Service Bus. Therefore, a proxy service must be implemented for consumers that calls the producer's real URL to obtain its WSDL, and then transforms the results by:
The developer who creates a producer can specify whether the producer requires SSL or not ("secure=true"). In addition, the AquaLogic Service Bus administrator can change the security requirement to the consumer via AquaLogic Service Bus configuration. For example, suppose a producer does not require SSL. The AquaLogic Service Bus administrator can require consumers to use SSL by:
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 the consumer has retrieved a copy of the WSDL, it uses the definitions in the WSDL to formulate service requests that it then sends 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. Therefore, WLSB must be configured 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 it cannot assume that the proxy service uses the same transport as the business service. Therefore, the message flow must be configured to copy the request headers from the inbound request to the outbound request. Similarly, the response headers from the business service must be copied 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. The Set-Cookie and Cookie headers must be copied. Because AquaLogic Service Bus is the entity that assembles the final message to send, it must own some of the headers information (such as Content-Length). For example, if the message flow were to copy the Content-Length header from the proxy service to the business service, it might result in an error because the length of the message could change during processing.
Monitoring tracks the usage of a producer's individual services and operations. Monitoring proxy services is very easy to set up. Fortunately, 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.
To configure monitoring for WSRP proxy services, create a proxy service for each of the services implemented by the producer.
These proxy services should be based on the standard WSRP WSDLs using SOAP bindings. Only a single business service for the producer should be created, and it should be configured to use "Any SOAP Service" instead of being based on a WSDL. The message flow between the proxies and the business service should not modify the SOAP body in any way. However, just as for all WSRP message flows, it must pass the request headers via HTTP from the client request to the actual producer. Similarly, the response HTTP headers returned by the producer must be copied back to the client in the message flow.
Monitoring is required for producer business services. Individual business services must be created for each of the Web services described in the producer's WSDL, and the business services must be defined using the WSDL. There is a one-to-one mapping between the proxy services and the business services—a simple, unconditional routing node is sufficient in the message flow.
For the operations to be counted correctly, AquaLogic Service Bus must be told which operation to use. Normally, the administrator would do this by selecting one of the operations from a drop-down menu when the business service is selected for the Route action. However, the operation specified by the client message is not the same for all messages, so a single, hard-coded value will not work here.
The administrator must ensure that the business service uses the same operation as the proxy service. While this could be achieved by specifying a Routing Table action that selects the case using the $operation variable, it is a very tedious approach because the WSRP standard defines 14 operations across all WSRP services, and each would require a Route action with transformations to propagate the transport headers.
Fortunately, there is a more effective alternative. When routing to the business service, rather than selecting the operation from the drop-down menu, an administrator should use another transformation in the request actions to insert the value of $inbound/ctx:service/ctx:operation into $outbound/ctx:service. With this transformation, the operation for the business service is dynamically set to the same value as was specified for the proxy service, and AquaLogic Service Bus will correctly count and monitor all operations of the service.
AquaLogic Service Bus allows business services to define multiple endpoints that all provide the same Web service. When multiple endpoints are defined, AquaLogic Service Bus can automatically load balance requests across endpoints, and it can automatically fail over requests when an endpoint is inaccessible. However, WSRP imposes some limitations on the use of these features.
Portlets are a means of surfacing a user interface to some 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 will usually target different servers or cluster. Because there is no communication among servers that are in separate clusters, there is no way to preserve the session. Therefore, if multiple endpoints are defined for a WSRP business service, then the load balancing algorithm must be set to "none".
Multiple endpoints can be used to provide redundancy in certain circumstances in the event that one of the endpoints is unavailable. The WSRP service is still available via 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 first 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. In the case where a business service defines multiple endpoints, each endpoint requires its own registration handle.
AquaLogic Service Bus is, however, stateless across requests—it does not maintain a mapping of the correct handle to send to a particular endpoint. In fact, it would only send the registration request to a single endpoint, so the consumer would be registered with only that one producer. If that one producer crashed, then AquaLogic Service Bus would route a service request to another endpoint defined for that business service, but the consumer would never have registered with that new producer, and the request would fail with an "InvalidRegistration" fault.
The management of registration handles therefore requires an application outside of AquaLogic Service Bus to maintain this state data. Error handling could be challenging to implement. Therefore, the registration requirement precludes defining multiple endpoints for complex producers. Because simple producers do not require or support the Registration service, a failover configuration that defines multiple endpoints in the business service is possible, although session data is lost on failover.
|