|
|
The AquaLogic Service Bus Console, which is described in the Using the AquaLogic Service Bus Console, 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 chapter describes the following tasks:
As a common practice, consumers contact a producer directly 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 must be implemented for consumers that calls the producer's real URL to obtain its WSDL, and then transform the results as follows:
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, if 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 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. 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 the proxy service may or may not use 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 headers (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. Therefore ALSB must own this header.
Monitoring 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.
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 a producer’s business services. Separate 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—an unconditional routing node is sufficient in the message flow.
AquaLogic Service Bus requires information about which operation to use, in order that operations are counted correctly. 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.
An alternative when routing to the business service is, 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.
Another alternative on the AquaLogic Service Bus console is when you are configuring the routing to a business service, select the Use inbound operation for outbound check box when you are editing a route node to avoid low level Xquery manipulation as in Figure 2-1.
" id="wp1050161"/>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 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 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 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 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. If a business service defines multiple endpoints, each endpoint provides and 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 is unavailable, 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 requires an application outside of AquaLogic Service Bus to maintain this state data. Therefore, the registration requirement precludes 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.
|