|
|
The examples described in this section support AquaLogic Service Bus versions 2.0, 2.1 and 2.5 (see Example Prerequisites).
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:
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 the WSRP WSDL definition files, along with the XML schema files on which the definitions depend. All the files are available as part of the sample code associated with this example, but the standard resource locations are listed in Table 3-2.
Producers generated by BEA Portal extend the standard WSDLs by defining an additional port that allows messages to be sent using MIME attachments. It is 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, see Table 3-3.
For each service, the required attributes are listed in Table 3-4.
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, you can use any URI, 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 query provided in Table 3-5
.
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 is modified (for example, 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 provided in Table 3-6
.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
Generally, 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 manner may prove to be tedious. Therefore, 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.| Note: | Use the Transport Header action to minimize low level Xquery manipulation and simplify the configuration of a proxy service. See Transport Headers section in the AquaLogic Service Bus Console Online Help for details. |
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. Table 3-7 describes the properties of the business service.
All end point 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:
Table 3-8 provides the query definition in the wsrp project.
Create 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.
Create a proxy service used by consumers to get WSDLs from producers. This proxy service is appropriate for any producer configuration modeled on this sample. The example described in this section is only a suggestion—a different approach might 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.
Table 3-9 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 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 listed in Table 3-10.
You must map "name:" to "$producerName" and "BaseURL" to "$nonSecureBaseURL" similar to the "svg arg" mapping in the use table: table num_xref, 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 as in Table 3-11:
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
Default Route to nullSvc
Insert <http:http-response-code>404</http:http-response-code> as last child of ./ctx:transport/ctx:response in variable inbound
Reply With FailureAfter completing the configuration, verify it 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 the same as those used to create the portlet that is not proxied by AquaLogic Service Bus.
|