Interoperability Solutions Guide
|
 |
 |
|
 |
 |
Interoperability with Web Services for Remote Portlets (WSRP)
Web Services for Remote Portlets (WSRP) is an increasingly popular mechanism for generating markup fragments on a remote system for display in a local portal application. This section describes how AquaLogic Service Bus can be used to provide Service Level Agreement monitoring in applications that use WSRP.
The topics discussed in this section include:
- WSRP Producers and Consumers
- Architecture
- WSRP Design Concepts
- Configuring AquaLogic Service Bus for WSRP
- WSRP Interoperability Example
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 Using WSRP with WebLogic Portal.
WSRP Producers and Consumers
WSRP involves two integral components:
- The remote application, called a WSRP producer (referred to as a producer in this section) implements standards-based Web Services using the SOAP specification over HTTP. Producers can be easily created using WebLogic Portal or third-party implementations of WSRP.
- A WSRP consumer (referred to as a consumer in this section) is a Portal application. Typically, the consumer application references the producer's WSDL when the portal is designed, and the consumer directly accesses the producer.
Architecture
This section describes the basic WSRP architecture and then shows how this architecture can be enhanced by adding AquaLogic Service Bus.
Basic WSRP Architecture
The following figure shows the basic WSRP SOAP request and response flow between a producer application and a consumer application.
Figure 6-1 Basic Request/Response Flow Between Producer and Consumer Applications
Enhanced WSRP Architecture with AquaLogic Service Bus
Because a WSRP producer implements SOAP Web Services, an enterprise service bus (such as the AquaLogic Service Bus) can be used as an intermediary between the producer and consumer to provide Service Level Agreement monitoring, as shown in the following figure.
Figure 6-2 Enhanced WSRP Request / Response Flow Via AquaLogic Service Bus
In this architecture, the WSRP SOAP request / response flow occurs in the following sequence:
The remainder of this section provides instructions for configuring the AquaLogic Service Bus to proxy service requests for WSRP services. It describes services that a producer provides, along with other attributes of WSRP that must be used to properly configure AquaLogic Service Bus. It provides different possible strategies that can be used to monitor producers with increasing degrees of detail. Finally, it discusses load balancing and failover with WSRP.
WSRP Design Concepts
This topic describes the following WSRP design concepts:
WSRP WSDLs
The following table describes the kinds of services offered by producers.
Each producer implements a minimum of two services (Service Description and Markup). A simple producer offers just these two services. A complex producer, however, provides two additional services (Registration and Management). WebLogic Portal producers also implement an extension service (Markup Extension) that replaces the standard Markup service.
These services are described using a standard WSDL format. The producer supplies a single URL for retrieving its WSDL, which describes all of the services that are available from that producer. The endpoints for each service indicate whether the consumer should use transport-level security (HTTPS) or not to communicate with the producer.
WSRP Messages
WSRP uses SOAP over HTTP for all messages sent between producers and consumers. In addition to using standard message formats in the SOAP Body, WSRP requires that certain transport headers be set in the request message—at a minimum, consumers must set the SOAPAction header, cookie headers, and the usual HTTP headers (such as Content-Type). Producers will return a session cookie, plus any application-specific cookies, in the HTTP transport header of the response message. The consumer must return the session cookie in subsequent request messages.
Configuring AquaLogic Service Bus for WSRP
Configuring AquaLogic Service Bus for WSRP involves the following tasks:
- implementing a service that consumers can invoke to obtain an appropriate WSDL for a particular producer
- implementing the nuts and bolts of conveying a consumer's request to the producer and returning the response to the consumer
This topic describes the following tasks:
- Getting the Producer WSDL
- Routing Messages Between the Consumer and Producer
- Choosing the Monitoring Level
Getting the Producer WSDL
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:
- rewriting the endpoint address for the producer to refer to the Service Bus IP address and port
- changing the endpoint URI to refer to the AquaLogic Service Bus proxy service that reflects the required monitoring granularity (as described in Choosing the Monitoring Level)
- changing the endpoint protocol and port to reflect whether transport security is used between the consumer and the AquaLogic Service Bus proxy service
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:
- changing the WSDL to specify HTTPS
- configuring the proxy services for WSRP to use the HTTPS transport
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.
Routing Messages Between the Consumer and 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:
- The consumer sends a message to the AquaLogic Service Bus proxy service corresponding to the producer service.
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.
Choosing the Monitoring Level
When monitoring WSRP applications, an AquaLogic Service Bus administrator must decide about the degree of granularity that is required.
The decision about which monitoring level to implement has an impact on the complexity of the AquaLogic Service Bus configuration. It determines the type and number of proxies or business services that must be created for each producer. In addition, the AquaLogic Service Bus administrator can choose to monitor both the proxy service and the producer service—the granularity of monitoring does not need to be the same for each side.
Producer-Level Monitoring
Producer-level monitoring tracks the total number of requests sent to a producer, without regard to the specific service being requested. As such, producer-level monitoring is the simplest to configure within AquaLogic Service Bus. Because the service types are not significant, it is not necessary to create the proxy service or business service based on a WSDL. Instead, the service type is configured as "Any SOAP Service". Each producer requires only a single proxy service and a single business service. For an example implementation, see Producer-Level Monitoring Example.
To configure producer-level monitoring, complete the following tasks:
- Configure the message flow in the proxy service to unconditionally route any message to the business service.
The suitability of producer-level monitoring depends on the specific requirements of a given implementation. In producer-level monitoring, the elapsed time for all services and operations for the producer are averaged together, regardless of the differences among them. However, a producer's services and operations can have vastly different characteristics, and it might not be meaningful to consider aggregated measurements. For example, the Markup service is the workhorse of WSRP—it requires substantially more time to execute than the Registration service. However, producer-level monitoring does not distinguish between the two. Nonetheless, producer-level monitoring can be useful to gauge the extent to which a producer is being utilized, or to help when there is a severe performance problem at the producer. Because the Markup service typically gets used more often (almost 99%) in a production system, it might still be useful to monitor Service Level Agreement (SLAs) at the producer level.
Operation-Level Monitoring
Operation-level monitoring tracks operations for services individually. Monitoring proxy services via operation-level monitoring is very easy to set up. Configuring operation-level monitoring for business services, however, requires more work. 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 often sufficient to monitor only the proxy services at the operation level. For an example implementation, see Operation-Level Monitoring Example.
Operation-Level Monitoring for Proxy Services
To configure operation-level monitoring for WSRP proxy services, create a proxy service for each of the services implemented by the producer.
- Simple producers require only two proxies—one for the Markup service and one for the Description service.
- Complex producers require these two proxies plus two additional proxy services for Registration and Management.
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.
Operation-Level Monitoring for Business Services
If operation-level monitoring is required for producer business services, then 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.
Load Balancing and Failover
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.
WSRP Interoperability Example
This section describes a WSRP interoperability example. It contains the following topics:
- Example Prerequisites
- Example Projects and Folders
- Producer-Level Monitoring Example
- Operation-Level Monitoring Example
Example Prerequisites
The WSRP interoperability example assumes the following components and configuration:
- WebLogic Platform 8.1 SP4
- AquaLogic Service Bus 2.0
- Sample Platform domain configured at
platform:7001 - AquaLogic Service Bus domain configured at
alsb:7001 - Sample Portal application consumer
- Sample producer
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/
Example Projects and Folders
This example includes separate configurations for two producers. Although the actual producer is the same for both examples, from the consumer's point of view, the producers are different.
The structure of the sample is divided into three projects—one containing common resources, and two containing resources for two example producers.
|
Contains common resources that are not specific to any producer. |
|
|
Basic example that is the easiest to configure. Folder contains producer-specified resources. See Producer-Level Monitoring Example. |
|
|
Full example supports the most fine-grained producer monitoring. Folder contains producer-specified resources. See Operation-Level Monitoring Example. |
Producer-Level Monitoring Example
The basic configuration example (in the producerExample folder) is the easiest configuration to implement. This configuration supports the monitoring of a producer in the aggregate (see Producer-Level Monitoring), but it does not consider the constituent services or operations.
Implementing this producer-level monitoring configuration involves:
- creating one business service and one proxy service to retrieve the WSDL from the producer
- creating one business service and one proxy service to invoke the producer services
The rest of this section describes the tasks required to implement this producer-level monitoring configuration.
Step 1: Retrieve the WSDL from the Producer
To configure producer-level monitoring, the first step is to create the resources needed to retrieve the producer's WSDL and return it to the consumer. Because the WSDL contains the endpoints of the producer's services, it is necessary to transform them to hide the IP address and port of the actual server. Instead, the addresses must refer to the AquaLogic Service Bus server, and the URIs must match the URIs that the proxy service defines for this producer.
Step 1.1: Create a Business Service
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 producerExample project. The following table describes the properties of the business service.
Step 1.2: Create an XQuery Expression to Construct URLs
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:
- base URL for the AquaLogic Service Bus server
- name to identify the producer
- extension used to differentiate ports for a producer
The following table shows the query definition in the wsrp project.
Step 1.3: Create a No-Op Proxy Service
A subsequent configuration task (see Step 1.4: Create a Common Proxy Service) 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.
Step 1.4: Create a Common Proxy Service
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 /producerWSDL, and the URL that consumers use to obtain a WSDL is:
http://alsb:7001/producerWSDL/producerName
where producerName is the name assigned to the producer by the administrator. In this example, the producer name is producerExample.
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
Because a producer can implement four ports, the proxy service must transform each port. If the producer does not implement a particular port, the XQuery transformation simply does nothing. Because a single endpoint will be defined to handle all WSRP traffic for this producer, the Replace Action uses the addr XQuery resource created earlier (see Step 1.2: Create an XQuery Expression to Construct URLs) to transform the endpoint to the value:
The four 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 ./wsdl:definitions/wsdl:service/wsdl:port[@binding="name"]/soap:address[starts-with(attribute::location,"http:")]in variable body with xqTransform()
Replace entire node
name
urn:WSRP_v1_Markup_Binding_SOAP
urn:WSRP_v1_ServiceDescription_Binding_SOAP
urn:WSRP_v1_PortletManagement_Binding_SOAP
urn:WSRP_v1_Registration_Binding_SOAP
For the first Replace Action, the following User Namespace definitions must be added:
Note: Producers created by BEA tools implement an extension service (urn:WLP_WSRP_v1_Markup_Ext_Binding_SOAP). This port is not used in this example. It is harmless to leave its endpoint unmodified.
The route node of this message flow consists of a routing table that selects the case based on $producerName. For each known producer (this example uses only one producer named producerExample), 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:
= "producerExample" 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 (defined in Step 1.3: Create a No-Op Proxy Service):
Default Route to nullSvc
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
Step 2: Configure WSRP Service Processing
After the resources needed to retrieve the producer's WSDL have been created, create the configuration resources to handle normal WSRP service requests via AquaLogic Service Bus. The easiest configuration involves creating a single proxy service and a single business service, and then linking them via a message flow that propagates the transport headers that WSRP requires.
Step 2.1: Create the Business Service
The minimal business service required for WSRP is not based on a WSDL—instead, it is created to accept any SOAP message. This approach simplifies configuration and allows a single business process to handle all port types used by WSRP. The trade-off with this approach is that it limits monitoring capabilities. Configure the business service with the following settings:
Step 2.2: Create the Proxy Service
The most convenient way to define the proxy service is to create it from the existing business service defined in the previous step. This creates a proxy service with the correct type ("Any SOAP Service", the same type configured in the business service) and also constructs the basic message flow that unconditionally routes messages to the proper business service. The message flow must be edited in a subsequent step. Configure the proxy service using the following settings.
Step 2.3: Edit the Message Flow
WSRP relies on data conveyed in the transport headers to function properly. In particular, producers will return to consumers any session cookies in the response headers that they expect consumers to supply in subsequent requests. Similarly, producers expect consumers to provide the requested operation in the 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
Step 3: Test the Configuration
After completing the simple configuration for the producer-level example, activate the changes made in the session. To test the configuration:
- Verify that all of the endpoint URLs (except for the BEA extension service) have been modified to the AquaLogic Service Bus IP address, port, and correct proxy service for the sample.
When configuring AquaLogic Service Bus, monitoring of any of the components has not yet been explicitly enabled. The procedure to enable monitoring is no different for WSRP services than it is for any other Web service in AquaLogic Service Bus. For each component of interest, select (check) the Enable Monitoring box on the Manage Monitoring page and set the aggregation interval. Consider setting up any alert rules, if applicable. After these changes have been activated, the configuration can be monitored from the dashboard facility of the AquaLogic Service Bus console.
Operation-Level Monitoring Example
The full monitoring configuration example (in the operationExample folder) involves configuring AquaLogic Service Bus to monitor all services and operations of a producer (see Operation-Level Monitoring). All of the concepts described for the producer-level monitoring example (see Producer-Level Monitoring Example) still apply to this example; to simplify configuration tasks, certain elements of that configuration will be copied. The operation-level monitoring example uses the same producer application as the producer-level monitoring example.
The fundamental difference between this example and the producer-level monitoring example is that the operation-level monitoring configuration uses both business services and proxy services that are based on the WSDLs defined by the WSRP standard. This example 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 this operation-level monitoring configuration.
Step 1: Define WSDL Resources
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.
Step 2: Create Business Services
In the producer-level monitoring example, a single business service was created to process all messages for the producer, an approach that worked because the business service was not associated with a WSDL.
This operation-level 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.
Step 3: Create the Proxy Services
Proxy services in this operation-level monitoring example are very similar to the proxy services created for the producer-level monitoring example, with some important differences:
- Just as the business services are based on a WSDL, the proxy services must be based on the same WSDL.
- One proxy service is created for each business service, but each proxy service must have a different URI.
- The configuration must specify which operation is being invoked (described later in this section).
As in the earlier example, create the proxy service using the existing
operationExample/basebusiness 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).- Edit the message flow to add the same transformations that were added for the producer-level monitoring example (see Step 2.3: Edit the Message Flow) to copy the request transport headers and response transport headers between the consumer and producer.
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:
- Create a new proxy service using the existing
operationExample/baseproxy service just created as the model. Following this example, use/operationExampleDescfor the Endpoint URI.
Step 4: Retrieve the WSDL from the Producer
Just as in the producer-level monitoring example, create a service that will retrieve the WSDL from the producer and transform it to hide the actual producer endpoints. The resources created are very similar to those created in the producer-level monitoring sample, but 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.
Step 4.1: Create the Business Service
The business service used to obtain the producer WSDL for this example is identical to the resource used in the producer-level monitoring example (see Step 1.1: Create a Business Service).
Step 4.2: Create the Proxy Service
Creating a proxy service (named wsrp/getWSDL) using wsrp/producerWSDL (see Step 1.4: Create a Common Proxy Service) as the model. 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 (see Step 1.2: Create an XQuery Expression to Construct URLs) accepts an extension argument to construct the URI location. Simply change that argument to the proper value, as shown in the following table.
Finally, edit the Routing Table in the route node to make the cases correspond to the producers known to the system.
Step 5: Test the Configuration
After completing the configuration, test it to verify that it works correctly. The testing steps for testing the configuration are similar to the producer-level monitoring example (see Step 3: Test the Configuration)—the only difference is with the URL used to retrieve the WSDL from the producer:
http://alsb:7001/getWSDL/operationExample
