|
|
The examples described in this section support AquaLogic Service Bus versions 2.0, 2.1, 2.5, and 3.0 (see Example Prerequisites).
This section describes a WSRP 2.0 interoperability example. For an example of WSRP 1.0 interoperability, see WSRP Interoperability Example in BEA AquaLogic Service Bus 2.6 Documentation.
This section discusses 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:
https://codesamples.projects.dev2dev.bea.com/servlets/Scarab/remcurreport/true/template/ViewIssue.vm/id/S403/nbrresults/13
This example describes the configurations that are relevant to the ALSB 3.0 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 resources specified by the producer. 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 section discusses the following topics:
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. You must 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. You must create a separate business service resource for each business service because a business service can be associated with only one WSDL port or binding. 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 model creates the proxy servicey based on the same WSDL binding as the business service, and it creates 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 propagate the required headers both in and out of the business service.
| Note: | To retrieve all the headers from the transport, select Yes in the Get All Headers field of the Transport Configuration page of the ALSB proxy. For more information, see Transport Configuration Page in the Using the AquaLogic Service Bus Console. |
| Note: | Add Transport headers to the Request & Response actions of the Route Node in the Message Flow and enable the Pass all headers through pipeline option. For more information, see Adding Transport Header Actions in Using the AquaLogic Service Bus Console. ALSB automatically ensures that content-length is not copied. |
With this transformation, the operation for the business service is dynamically set to the same value as was specified for the proxy service. AquaLogic Service Bus counts and monitors all operations of the service.
The proxy services for the other business services can be created by repeating these steps although you can use a shortcut to avoid recreating all of the transformations manually.
For example, to create the proxy service for the Service Description service:
operationExample/base proxy service that is 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. |
For each service, the proxy service configurations are listed in Table 3-5.
For each proxy service, the required attributes are listed in Table 3-7.
Create a service that retrieves the WSDL specific to WSRP 2.0 from the producer and transform it to hide the actual producer endpoints. In this example, the proxies for each producer have a different URI. In addition, the 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 you must create the resource in the operationExample project. Table 3-7 describes the properties of the business service.
You must transform all endpoint addresses in the producer's WSDL to reflect the AquaLogic Service Bus server address and the proxy service URI values. You must create an XQuery expression to simplify the construction of the endpoint locations because each producer WSDL can have four or more ports defined. 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 is necessary based on the specific requirements of a given implementation. You must create this proxy service in the wsrp project folder because the proxy service is not specific to a single producer.
/getWSDL, and the URL that consumers use to obtain a WSDL is as follows:
http://alsb:7001/getWSDL/<producerName>
where <producerName> is the name assigned to the producer by the administrator. In this example, the producer is operationExample.
Table 3-9 describes the configuration properties for the proxy service getWSDL2.0 :
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 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_v2_ServiceDescription_Binding_SOAP
WSRP_v2_PortletManagement_Binding_SOAP
WSRP_v2_Registration_Binding_SOAP
For the first Replace Action, you must add the User Namespace definitions listed 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 Failure
The message flow for getWSDL2.0 proxy service consists of a pipeline pair and a route node. To define the message flow for this proxy service, do the following:
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. To achieve this, add the Assign action as follows:
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.
Assign http://alsb:7001/ to variable nonSecureBaseURL
./*[local-name()="definitions"]/*[local-name()="service"]/*[local-name()="port"][ends-with(attribute::binding,"WSRP_v2_Markup_Binding_SOAP")]/*[local-name()="address"][starts-with(attribute::location,"http:")]Base-2.0, baseURL to $nonSecureBaseURL, and name to $producerName.$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-2.0
<http:http-response-code>404</http:http-response-code> as last child of ./ctx:transport/ctx:response in variable inbound In order to consume the producer, the consumer must register the producer using its WSDL. By default, the WSDL uses WSRP version 1.0. To make consumer use WSRP version 2.0, producer WSDL with WSRP version 2.0 must be made available to the consumer. Generally, the default producer WSDL (one which uses WSRP 1.0) contains a link to the WSDL with WSRP version 2.0. This link enables consumer to use WSDL of WSRP version 2.0.
The getWSDL proxy service provides the WSDL of the producer with WSRP 1.0 version. This WSDL contains an URL of the WSDL of the same producer with version WSRP 2.0. This is the direct URL of the producer's WSDL. Instead of using the direct URL, you must the access the WSDL through ALSB using proxy service getWSDL2.0. This can be achieved in following way.
declare variable $baseURL external;
declare variable $name external;
declare variable $svc external;
<import location="{concat($baseURL, $svc, $name )}" namespace="urn:oasis:names:tc:wsrp:v2:wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/" />
getWSDL proxy service. This replace action replaces the WSDL URL in the response to the getWSDL2.0 proxy service endpoint URI. This can be done as follows:./*[local-name()="definitions"]/*[local-name()="import"][ends-with(attribute::location,"/producer/wsrp-2.0/markup?WSDL")]getWSDL2.0, baseURL to $nonSecureBaseURL, and name to $producerName.After completing the configuration, verify it as follows:
http://alsb:7001/getWSDL/operationExample
Use either Workspace Studio 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.
|