|
|
This section describes a WSRP interoperability example. It contains the following topics:
The WSRP interoperability example assumes the following components and configuration:
For an AquaLogic Service Bus configuration that supports the configuration defined in this example, see the AquaLogic Service Bus/WSRP code sample, available from the AquaLogic Service Bus code samples page on BEA dev2dev for:
This example describes the configurations corresponding to the ALSB 2.5 dev2dev code sample.
The structure of the sample is divided into two projects—one containing common resources, and the other containing resources for the sample producer.
Full example supports the most fine-grained monitoring. The folder contains producer-specified resources. See Monitoring Example.
|
The monitoring configuration example (in the operationExample folder) involves configuring AquaLogic Service Bus to monitor all services and operations of a producer.
The monitoring configuration uses both business services and proxy services that are based on the WSDLs defined by the WSRP standard. The example also defines the additional resources to describe the WSRP services and extend the message flows to support monitoring at the operation level. The rest of this section describes the tasks required to implement the monitoring configuration.
Import all of the WSRP WSDL definition files, along with the XML schema files on which the definitions depend. All of the files are available as part of the sample code associated with this example, but the standard resource locations are described in the following table.
Producers generated by BEA Portal extend the standard WSDLs by defining an additional port that allows messages to be sent using MIME attachments. Describing this extension is beyond the scope of this example, but it is still necessary to define these extension resources if the producer WSDL references them. In this example, an optional task is to create a resource for the WSDL used by the producer. After creating these WSDL and XML Schema resources, edit the references in each resource to resolve the dependencies on other resources.
This monitoring example uses the WSDL bindings for each port type implemented by the producer. Because a business service can be associated with only one WSDL port or binding, a separate business service resource must be created for each. A simple producer implements only the required Markup and Service Description interfaces, while a complex producer also implements the Management and Registration interfaces. The services are created identically (except for the service name and types), as shown in the following table.
For each service, minimally set the attributes listed in the following table.
Proxy services in this monitoring example are configured as follows:
As in the earlier example, create the proxy service using the existing operationExample/base business service as the model. This will automatically base the proxy service on the same WSDL binding as the business service, and it will create a message flow with an unconditional route action to the business service. For the Endpoint URI, anything may be used, such as the producer name with the port type abbreviation appended to it (for example, /operationExampleBase).
SOAPAction request header.By default, AquaLogic Service Bus does not copy transport headers from the inbound request to the outbound request, or from the outbound response to the inbound response. The message flow must therefore propagate the required headers both in and out of the business service. Because these transformations are required for every WSRP service, it is convenient to define two common XQuery resources—one for request headers and one for response headers—that extract the correct headers.
For request headers, use the following query.
The rqstHeaders query extracts all transport headers (except Content-Length) from the $in variable. AquaLogic Service Bus can sometimes reformat the message body so that its length no longer exactly matches the request message. Copying the length from the original request can result in transport errors if the body was modified (such as reformatted).
To copy the inbound request headers to the outbound business service, add the following Replace request action to the message flow:
Replace ./ctx:transport/ctx:request/tp:headers in variable outbound with xqTransform() |
Replace node contents |
Variable Mapping (wsrp/rqstHeaders): |
in: $inbound |
Similar to the request side, the response side defines a common XQuery resource to extract all but the Content-Length header from the response returned from the producer.
For response headers, use the following query.
The following Replace response action in the route node propagates the required headers:
Replace ./ctx:transport/ctx:response/tp:headers in variable inbound with xqTransform() |
Replace node contents |
Variable Mapping (wsrp/rspncHeaders): |
out: $outbound |
Normally, in a Route Action that routes to a WSDL-based service, an operation to invoke (by selecting the correct operation from the drop-down menu) is specified. However, each WSRP port implements several operations, and so the configuration requires a routing table with a case for each operation. Each case requires the same transformations to propagate the transport headers.
Creating all of the transformations in this way might prove to be quite tedious. Fortunately, there is a more convenient approach. Instead of using the drop-down menu, use another transformation to copy the operation from the proxy service to the business service. Configure this transformation by adding an Insert Action to the Request Actions of the message flow:
Insert $inbound/ctx:service/ctx:operation as last child of ./ctx:service in variable outbound |
The proxy services for the other business services can be created by repeating these steps, although a shortcut can be used to avoid recreating all of the transformations manually. For example, to create the proxy service for the Service Description service:
operationExample/base proxy service just created as the model. Following this example, use /operationExampleDesc for the Endpoint URI.WSRPServiceDescriptionService port.desc service.Create a service that will retrieve the WSDL from the producer and transform it to hide the actual producer endpoints. In this example the proxies for each producer have a different URI. The rest of this section describes how to create the resources to retrieve the producer WSDL.
Create a business service to obtain the WSDL from the producer. This resource is specific to the producer, so it must be created in the operationExample project. The following table describes the properties of the business service.
All endpoint addresses in the producer's WSDL must be transformed to reflect the AquaLogic Service Bus server address and the proxy service URI values. Because each producer WSDL can have four or more ports defined, it is convenient to create an XQuery expression to simplify the construction of the endpoint locations. The XQuery expression accepts the following three string variables as input and concatenates them together to form a SOAP address element:
The following table shows the query definition in the wsrp project.
A subsequent configuration task requires a service that does nothing. To create this service, define a new proxy service in the wsrp project folder with the resource name nullSvc. Accept all of the defaults for this service. Configuring this proxy service creates a message flow for the service of an echo node only, which is all that is required for this example.
Create a proxy service used by consumers to get WSDLs from producers. This proxy service is appropriate for any producer configuration modeled on this basic sample. The example described in this section is only a suggestion—a different approach might better suit the specific requirements of a given implementation. Because this proxy service is not specific to a single producer, it should be created in the wsrp project folder.
The approach used in this step requires the administrator to assign each producer a name that is included in part of the URL to retrieve the WSDL. The message flow for the proxy service will extract the name from the URL, use it to locate the business service specific to that producer, obtain the WSDL, and then transform the WSDL to rewrite the endpoints to AquaLogic Service Bus. The proxy service endpoint URI is configured as /getWSDL, and the URL that consumers use to obtain a WSDL is:
http://alsb:7001/getWSDL/producerName
where producerName is the name assigned to the producer by the administrator. In this example, the producer name is operationExample.
The following table describes how the proxy service is configured:
The message flow for this proxy service consists of a pipeline pair and a route node. The request side of the pipeline pair consists of a single stage whose job is to extract the producer name from the URL and assign it to a context variable. The action is:
Assign $inbound/ctx:transport/ctx:request/http:relative-URI to variable producerName
The response side of the message flow is a stage where all of the transformations are performed. Before executing the Replace Actions to transform the WSDL, assign the base URL of the AquaLogic Service Bus server to a context variable to avoid specifying it on every transformation:
Assign "http://alsb:7001/" to variable nonSecureBaseURL
Edit the stage of the Response Pipeline to modify each Replace Action to make the transformation match the Endpoint URI given to the proxies created earlier. In this example, the proxies were created using the producer name with an abbreviated service type appended to it. The addr XQuery resource created earlier accepts an extension argument to construct the URI location. Simply change that argument to the proper value, as shown in the following table.
You must map "name:" to "$producerName" and "BaseURL" to "$nonSecureBaseURL" similar to the "svg arg" mapping in the table, Extension Settings to Construct the URI Location.
The five Replace Actions are defined as shown in the following code listing. The value of name is replaced with the binding names from the table.
Replace ./*[local-name()="definitions"]/*[local-name()="service"]/*[local-name()="port"][ends-with(attribute::binding,"name")]/*[local-name()="address"
WSRP_v1_ServiceDescription_Binding_SOAP
WSRP_v1_PortletManagement_Binding_SOAP
WSRP_v1_Registration_Binding_SOAP
For the first Replace Action, the following User Namespace definitions must be added:
The route node of this message flow consists of a routing table that selects the case based on $producerName. For each known producer, add cases so that each case routes to the correct business service to retrieve the WSDL if the name matches. This example uses the following directive:
= "operationExample" Route to wsdlSvc
To handle cases in which an unknown producer name is given, add a Default Case that routes to the no-op service:
In this example, return an HTTP 404 status code by adding these response actions to the default case:
Insert <http:http-response-code>404</http:http-response-code> as last child of ./ctx:transport/ctx:response in variable inbound
Reply With Failure
Finally, edit the Routing Table in the route node to make the cases correspond to the producers known to the system.
After completing the configuration, test it to verify that it works correctly. The testing steps for testing the configuration are as follows:
http://alsb:7001/getWSDL/operationExample
Use either the WebLogic Workshop or Portal Administration Tool to create the remote portlet. Except for entering a different URL to retrieve the WSDL, the steps to create this portlet are no different from those used to create the portlet not proxied by AquaLogic Service Bus.
|