Service Level Agreement(SLA) in DataPower: Part 2: Integrating with a WSRR service model pattern

Introduction

The service level agreement (SLA) policy enforcement and service governance has become a critical component of proper SOA adoption and service management practices. In order to properly implement such capability in enterprise networks, the service proxies and gateways must be aware of business service endpoints and their consumer SLAs. This metadata may exist in the enterprise in varied forms, such as documents, spreadsheets, databases, repositories, and so on.

In Part 1 of this series, we discussed how a self-contained solution (for example, no external dependencies) using DataPower Application appliance can enforce business service SLA policies and help improve service governance in the enterprise. That initial article made use of a local "SLA Control File" pattern, which uses an XML file to provided the source of information for details about services, consumers, and their SLA policies.

This article, Part 2 in the series, takes the next step of taking the SLA Control File used in the first article and replacing it with a proper business service registry solution. We will use the WebSphere® Service Registry and Repository (WSRR) Governance Enablement Profile (GEP) service model to capture and publish the same (and more) service metadata as available in the SLA control file. The WSRR GEP service model provides a platform for applying governance best practices while the enforcement runtime (DataPower) can consume the same information being governed.

Part 3 of the series documents the WSRR solution's DataPower configuration artifacts and provides step-by-step testing and validation instructions.

Part 2 and Part 3 of this article series demonstrate the various types of business service policies that you can manage by using this solution's framework and how to easily associate these policies to service consumers and service providers for individual enforcement. It details the implementation of a simplified WSRR GEP service model focused on services, policy, SLA, and SLD registration. The SOA architecture pattern roles applied in this article are DataPower as the Policy Enforcement Point (PEP) and WSRR as the Policy Administration Point (PAP). This SOA pattern instantiation demonstrates the ability to manage different versions of a service, associated SLA policies, endpoint routing, and any data mediation (as needed).

You can apply this solution pattern to any type of service that the DataPower appliance can proxy and protect: XML, REST, or Web Services (SOAP). We will describe how to configure this solution by using the most widely used DataPower service gateways: Multi-Protocol Gateway (MPGW) and Web-Service Proxy (WS-Proxy). We will also describe in detail how to leverage key SOA features, such as service re-use, governance, and visibility in WSRR. The pattern implementation described in this article requires DataPower v4.0.2 (or higher) and WSRR v7.5 (or higher).

Figure 1 presents a high-level diagram of interaction between different components of the solution pattern. Notice, when compared to the Part 1article's local XML control file, that the service and policy metadata is consumed from a location external to DataPower (for example, WSRR). This provides the benefits of enabling distributed governance of service definitions and policies associated. This is a significant improvement from the first article, where local files have to be manually managed by custom scripts, and thus, likely suffer from spotty service and policy coherence. This gets worse as the solution is scaled out.

Figure 1. Components of the SLA policy enforcement solution

Back to top

Integration between DataPower Appliance and WSRR service model

This section discusses the proposed solution pattern that uses a WSRR service model to describe services and their associated SLA and SLD policy details. A WSRR service model allows consumers and providers to be managed by using governance capabilities and also exposes these services and associated SLAs, SLDs, and endpoints as visible resources to enable "reuse". The following simplified model is used by this article to allow basic governance capabilities. You can extend this model to fully encompass all the capabilities that WSRR provides, thus enabling more advanced features such as policy management and authoring, full governance enablement, search and reuse, and Enterprise Service Bus (ESB) integration.

The previous article made use of the SLA-check stylesheet and its configuration XML file, which both reside locally on the appliance. In this article, we'll set up the objects in WSRR v7.5 (all instructions also apply to a WSRR v8.0 installation), which the DataPower appliance will query and pull the required information from the specified WSRR server instance. The next article in this series will explain how to configure DataPower and show examples.

Figure 2 shows the WSRR service models that are created and used in this article. The objects and their additional properties are described later in the article.

Figure 2. WSRR service models

The simplified model uses the following key "governance" aspects:

1. Service level definitions (SLDs) are used to define the providing Service Version contract. This is the contract for all service level agreements (SLAs) that consume from the service version. Multiple SLAs can consume from one SLD definition.
2. The governance state of SLAs, SLDs, and back-end service endpoints is used to "control" the availability of endpoints and active consumer and provider service version relationships. Using the endpoint state management enables abilities such as phasing consuming clients by using older interfaces over to new versions with the aid of appliance message transformation by a simple activation of the new version service endpoint with the provision of the message transformation.

Table 1. WSRR artifacts and description

WSRR Artifacts	Description
Application Version	The consuming application client version for the exposed DataPower appliance service.
Service Version	The providing service version that represents the exposed DataPower appliance backend service.
SLA (service level agreement)	The contract service level agreement between the consuming application and the backend service. The SLA custom property is dp_slmPolicyName, which is the name of an SLM policy on the DataPower appliance that should be enforced as an SLA enforcement point.
SLD (service level definition)	The providing service contract agreement that documents the capabilities of the providing backend service. The SLD custom properties are: dp_slmPolicyName: The name of an SLM policy on the DataPower appliance that should be enforced as an SLD enforcement point. dp_xformName_Request: The name of a stylesheet on the DataPower appliance that will perform a transformation on the request message. dp_xformName_Response: The name of a stylesheet on the DataPower appliance that will perform a transformation on the response message.
SOAPServiceEndpoint	The backend service endpoint for the SOAP Web Service provider.
ServiceEndpoint	The backend service endpoint for the XML/REST Web Service provider.
WSDLDocument	The WSDL document artifacts representing the backend SOAP service provider.
XSDDocument	The XSD schema document artifact representing the front and backend XML/REST service providers.

Back to top

Integration between DataPower and WSRR

This section demonstrates the integration between DataPower and WSRR to enforce SLA and SLD for the following gateways:

• Web-Service Proxy
• XML Gateway
• REST Gateway

For each type of gateway, a presentation of the WSRR components as well as the DataPower configuration are explained. XML and REST gateways are configured on DataPower using multi-protocol gateways.

Back to top

Web-Service Proxy

This type of proxy is used in DataPower to protect Web services that comply with W3C specifications (such as WSDL, SOAP, and WS-Policy). The proxy configuration will assume that the Web service expects messages to be SOAP (such as XML) and use HTTP(S) protocols, as well as provide a WSDL for defining the service interface.

WSRR components

When dealing with SLA and SLD enforcement for SOAP-based services, the following WSRR components must be created, as shown in Figure 3, where two service versions of the same service are created.

Figure 3. WSRR components when dealing with SOAP-based services

Every service version has its own SLD with only one online endpoint at a time. You must add the dp_slmPolicyName property at the SLD and SLA level to provide information about the SLD SLM policy and the SLA SLM policy that has to be enforced on the DataPower device at runtime.

These SLM policies need to be configured on the DataPower appliance with exactly the same names of those used in WSRR. The validation of SOAP messages (on both request and response side) is performed using the WSDL files retrieved by DataPower, once the subscription between DataPower and WSRR is established.

DataPower configuration (WS-Proxy)

The DataPower appliance integrates to WSRR using the "WSRR subscription" configuration. DataPower supports several different types of subscriptions to WSRR (one example is shown in Figure 4). DataPower Web Service proxies can consume and configure themselves with WSDLs and policies that reside in a WSRR server through the use of these WSRR subscription objects. DataPower WSRR subscriptions provide a mechanism in which a WS-Proxy can be configured by subscribing to one or more WSDLs stored on the WSRR server. The DataPower WSRR subscription may subscribe and consume one or more WSDLs (multiple WSDLs are supported via the concept or a saved search in WSRR).

Figure 4. WSRR saved search subscription object in DataPower

In this article, we take advantage of the existing interoperability between DataPower and WSRR and expand it to include the retrieval of SLA and SLD policies via custom named queries. We'll create a saved search subscription (Figure 4), which results in a set of WSDLs from WSRR that are configured into a Web Service proxy. Then, we'll create a processing rule at the top level of proxy, as shown in Figure 5, which contains actions that communicate with the WSRR server to retrieve policy directives for specific consumer and service. The fetched policy and service metadata from WSRR are then stored into known context variables. In this article, the values stored are the names of the SLM policies applied to SLA and SLDs, as well as any transformations and XSDs or WSDLs for schema validation.

Figure 5. WS-Proxy SLA Processing policy

The provided DataPower configuration also contains a Multi-Protocol Gateway (MPGW), which enforces the SLD processing policy, shown in Figure 6, serially after the WS-Proxy enforcement of the SLA processing policy. DataPower firmware 4.0.2 (and previous versions) require this two-gateway implementation as only one SLM action is allowed per processing rule.

Note: Starting with DataPower firmware 5.0.0 (and later), this limitation no longer exists. Therefore, a WS-Proxy configuration can enforce both SLM actions (SLA and SLD policies) serially shown in the same WS-Proxy processing rule.

Figure 6. Multi-Protocol Gateway SLD Processing policy

The WS-Proxy forwards the request to the MPGW, which enforces the SLD policy. After it is done processing, the MGPW then routes the request to the desired remote endpoint for processing by the Web service.

Versioning of SOAP-based services

In order to deal with service versioning for SOAP-based services, we assume that "service A" (Service_Endpoint_A) is now offline. We continue to manage this service in WSRR, but the implementation of "Service A" does not exist anymore. We want to demonstrate how to deal with SOAP-based services versioning in DataPower and WSRR for this particular use case. From a WSRR perspective, the service endpoint Service_Endpoint_A is set as offline.

Some new properties are set at the SLD level to manage the data mediation on both request and response processing rules in DataPower, as shown in Figure 7.

Figure 7. WSRR components for versioning of SOAP-based services

Using this set of information, a DataPower Web-Service proxy is able to:

• Validate SOAP request messages of Consumer_A using WSDL_A.
• Perform SLA check to know if a contract exists between Consumer_A and the requested service.
• Perform data mediation of the SOAP request using the dp_xformName_Request property.
• Validate the result of the transformation using WSDL_B.
• Route the request of Consumer_A to the right online endpoint (ServiceEndpoint_B).
• On the response processing, the following steps are executed:
  • Validation of the SOAP response using WSDL_B.
  • Data mediation of the response using the dp_xformName_Response property.
  • Validation of the response before it is sent to Consumer_A, using WSDL_A.

Moreover, you can enforce the SLA SLM policy and the SLD SLM policy as desired.

Figure 8 shows the two DataPower request processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower.

Figure 8. Queried WSRR objects

Click to see larger image

We have added markers to each action in Figure 8, 1 through 8, in order to more easily reference them in the article. SLA and SLD enforcements can be completed with some classical security controls provided in DataPower like an AAA policy.

1. The Initial SLA-Check XForm Action sends the initial request for information to WSRR and sets the context variables accordingly. The NamedQueries are described in WSRR named queries used by sample stylesheets. As shown in Figure 9, the stylesheet requires various parameters.

   Figure 9. Initial transform action

   
   The parameters are:
   • WSRR Host: IP Address or Hostname of the WSRR server
   • WSRR Port: Port configured on the WSRR server
   • SLD Proxy Port Number: Port number of the Multi-Protocol Gateway used to enforce the SLD SLM policy
   The WSRR consumer and SLA modeling make use of a Consumer ID (a simple string property that identifies the business application consuming a service) and Context ID (a simple string property that identifies the SLA object associated with consumer and provider pair). The DataPower solution uses these two IDs to query WSRR for appropriate SLA and SLD policy metadata to use during enforcement actions. In the article, consumer and context identifiers are transmitted in the HTTP headers using, respectively, X-CONSUMERID and X-CONTEXTID parameters.
   This initial stylesheet parses the incoming requests and extracts a Consumer ID and SLA Context ID from the message. I It then uses those two values in a series of calls to the WSRR NamedQueries. The stylesheet then gathers and sets local context variables, which are used in subsequent enforcement actions. The stylesheet also creates and returns an action output context <result> XML nodeset with some of the queried data. Here is an example of action's output context nodeset:

   <result>
    <inputSchema>wsrr://9.20.88.69/ges6gtes-b45d-5j98.g2k4.78673231b765/
    </inputSchema>     
    <outputSchema>wsrr://9.20.88.69/bef0cdbe-b41d-4d08.a5a5.54624854a539/
    </outputSchema>
   </result>

2. The <result> nodeset returned in Action 1 is inspected by a conditional action. If it contains an <inputSchema> element, DataPower validates the input. The <result> element contains the bsrURI of the schema or WSDL to use in the schema validation. The bsrURI is obtained from the dp_xsd_frontEnd property of the Service Version object in WSRR. Figure 10 shows the conditional and the validate actions that will run when the match condition is true.

   Figure 10. Schema validation conditional action

   
   The validate action details are displayed in Figure 11.

   Figure 11. Details of the validate action before data mediation of the SOA request

   
   The schema validation method is based on the WSDL URL.
3. Transform the request from one format to another. This action looks for the value if it is provided in the SLD object and is set as a context variable by Action 1. For example, transform a Version 1 request to a Version 2. Figure 12 shows the transform action configuration.

   Figure 12. Transform message action

   
4. The second conditional will look in the <result> node from Action in 1 and look for the <outputSchema> element to do a second validation if present. Figure 13 shows the conditional and the schema validate action that occurs if the schema value has been set.

   Figure 13. Output schema conditional

   
5. The SLM Action used by the service level agreement is shown in Figure 14. Note the SLM Policy name is read from the DataPower context variable "var://context/wsxml/sla". The actual DataPower SLM policy configuration is expected to already exist on the appliance and be operational (up state) as shown later in this article. This means that SLM policy options are designed up-front and deployed as part of the gateway configuration lifecycle process.

   Figure 14. Service level agreement SLM action

   
6. The last action in the WS-Proxy, shown in Figure 15, sets the forward route to be the Multi Protocol Gateway, which handles enforcing the SLD SLM policy. If you adopt this solution in DataPower v5.0 (or later), this step is not necessary as you do not need a second gateway in the sequence and can fold the processing actions in the Multi Protocol Gateway into WS-Proxy.

   Figure 15. Route message to Multi-Protocol Gateway used for SLD enforcement

   
7. Figure 16 shows the SLM Policy for the service level definition.

   Figure 16. Service level agreement SLM policy

   
8. Figure 17 routes the message to the final endpoint.

   Figure 17. Route message to the backend

   
   Figure 18 shows the two DataPower response processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower.

   Figure 18. Queried WSRR objects

   
   Click to see larger image

The processing is similar with what we have seen on the request processing side. In the first step, the Xform action is responsible for retrieving information from WSRR, using specific named queries. Validation of the SOAP response is performed in a second step, and then comes the data mediation. These three actions are processed on the response processing rule of the Multi-Protocol Gateway used to enforce SLD through an SLM policy.

The SOAP response, with a format required by the consumer (Consumer_A), is then validated and sent back to the consumer application. The last Xform (on the right side) corresponds to a custom log action.

Note: On the SOAP-based service use case, the schema validation method of the validate actions of the SLD gateway is based on the WSDL URL. On the SLD gateway, the validate actions are configured on the response processing rule. Figure 19 shows an example of such a validate action.

Figure 19. SLD gateway validate action details for SOAP-based services

You can set the request and response types of the SLD gateway to "XML" when dealing with SOAP and XML based services, as shown in Figure 20.

Figure 20. Request and response types of the SLD gateway for SOAP and XML based services

Back to top

XML Gateway

This gateway type refers to a DataPower Multi-Protocol Gateway (MPGW) configured to assume that service messages will be in the XML format. It is basically a MPGW with configuration settings that are enabled to process XML (validate, parse, and create) and enforce XML protections (schema validations, crypto standards, limits, threats, and so on). This allows a gateway configuration to be optimized to use many of DataPower's XML features.

WSRR components

When dealing with SLA and SLD enforcement for XML-based services, you must create the following WSRR components, as shown in Figure 21, where two service versions of the same service are created.

Figure 21. WSRR components when dealing with XML-based services

Consumer_A consumes Version A of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device. Consumer_B consumes Version B of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device.

Every service version has its own SLD with only one online endpoint at a time. You must add a dp_slmPolicyName property at the SLD and SLA level to provide information about the SLD SLM policy and SLA SLM policy that has to be enforced on the DataPower device at run-time. These SLM policies need to be configured on the DataPower appliance with exactly the same names of those used in WSRR.

The validation of XML messages (on both request and response side) is performed using schema files (XSD) retrieved by DataPower using a specific named query (GetBackEndSourceDoument). The result of a named query invocation can be cached to improve performance and reduce the number of REST calls to WSRR.

DataPower configuration (MPGW)

When dealing with XML based services, the DataPower appliance integrates to WSRR using custom named queries. The type of DataPower service used to implement the XML gateway for SLA enforcement is a Multi-Protocol Gateway.

The configuration of this Multi-Protocol Gateway used to expose XML-based services is the same as the one used for SOAP-based services.

The only difference is the schema validation method that is based on the schema URL for XML-based services (instead of the WSDL URL for SOAP-based services).

Figure 22. DataPower processing policy of the Multi-Protocol Gateway for SLA enforcement

The SLD gateway is also the same as the one used for SOAP-based services, but again, the schema validation method for all the validate actions of the processing policy must be based on the schema URL.

Versioning of XML-based services

To deal with service versioning for XML-based services, we assume that "Service A" (Service_Endpoint_A) is now offline. We continue to manage this service in WSRR, but the implementation of "Service A" does not exist anymore. We want to demonstrate how to deal with XML-based services versioning in DataPower and WSRR for this particular use case.

From a WSRR perspective, the service endpoint Service_Endpoint_A is set as offline. The schema of Service A is always used to validate XML messages for both request and response processing. Thus, a dedicated relationship is used to reference this schema through the use of the dp_xsd_frontEnd property at the service version level. Some new properties are set at the SLD level to manage the data mediation on both the request and response processing rules in DataPower, as shown in Figure 23.

Figure 23. WSRR components for versioning of XML-based services

Using this set of information, a DataPower Multi-Protocol Gateway is able to:

1. Validate XML request messages of Consumer_A using XSD_A.
2. Perform SLA check to know if a contract exists between Consumer_A and the requested service.
3. Perform data mediation of the XML request using the dp_xformName_Request property.
4. Validate the result of the transformation using XSD_B.
5. Route the request of Consumer_A to the right online endpoint (ServiceEndpoint_B).

On the response processing, the following steps are executed:

1. Validate the XML response using XSD_B.
2. Data mediation of the response using the dp_xformName_Response property so that custom response formatting can be applied.
3. Validate the response before it is sent to Consumer_A, using XSD_A.

Moreover, the SLA SLM policy and the SLD SLM policy can be enforced as desired.

Figure 24 shows the two DataPower request processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower.

Figure 24. Queried WSRR objects and location of their properties values - XML-based services

Click to see larger image

Figure 25 shows the two DataPower response processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower.

Figure 25. Queried WSRR objects and location of their properties values in the DataPower response processing rule

Click to see larger image

The processing is similar with what we have seen on the request processing side. The Xform action is responsible for retrieving information from WSRR using specific named queries. Validation of the XML response is performed in a second step, and then comes the data mediation. These three actions are processed on the response processing rule of the Multi-Protocol Gateway, which is used to enforce SLD through an SLM policy.

The XML response, with a format required by the consumer (Consumer_A), is then validated and sent back to the consumer application. The last Xform (on the right side) corresponds to a custom log action.

Important: The XML-based service use case, the schema validation method of the validate actions of the SLD gateway, is based on the schema URL. On the SLD gateway, the validate actions are configured on the response processing rule. An example of such a validate action is shown in Figure 26.

Figure 26. SLD gateway validate action details for XML-based services

Back to top

REST Gateway

This gateway type refers to a DataPower Multi-Protocol Gateway (MPGW) configured to assume that service messages will be in non-XML format. It is basically a MPGW with configuration settings enabled to process non-XML payloads. This allows support for services that expect JSON or HTML, for example. Therefore, no validation or parsing of payload is performed. This is in contrast to the XML Gateway where XML protections can be enforced.

WSRR components

When dealing with SLA and SLD enforcement for the REST-based services, you must create the following WSRR components, as shown in Figure 27, where two service versions of the same service are created.

Figure 27. WSRR components when dealing with REST-based services

Consumer_A consumes Version A of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device. Consumer_B consumes Version B of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device.

Every service version has its own SLD with only one online endpoint at a time. A dp_slmPolicyName property must be added at the SLD and SLA level to provide information about the SLD SLM policy and the SLA SLM policy that have to be enforced on the DataPower device at run-time.

No schema file is mentioned for the REST use case, as a REST service invocation can be based on an HTTP GET request. It cannot be schema validated. If control of the query parameters must be performed, then use a transformation on the request side to enforce it.

DataPower configuration (MPGW)

When dealing with REST-based services, the DataPower appliance integrates to WSRR using custom named queries. The type of DataPower service used to implement the REST gateway for SLA enforcement is a Multi-Protocol Gateway.

The configuration of the processing policy used to deal with REST-based services is the same as the one used for SOAP and XML based services. Neither schema nor WSDL validation is performed on the request and response side for REST-based services. Only routing, SLA and SLD enforcements, as well as transformation can be executed in this case.

The SLD gateway is also the same as the one used for SOAP or XML based services, but again, the validate actions of the processing policy are not executed. Figure 28 presents the request and response types for both SLA (mpg_rest_sla_proxy) and SLD (mpg_sld) enforcement gateways.

Figure 28. Request and response types for REST-based services (SLA and SLD gateways)

Versioning of XML-based services

In order to deal with service versioning for REST-based services, we assume that "Service A" (Service_Endpoint_A) is now offline. We continue to manage this service in WSRR, but the implementation of "Service A" does not exist anymore. We want to demonstrate how to deal with REST-based services versioning in DataPower and WSRR for this particular use case. From a WSRR perspective, the service endpoint Service_Endpoint_A is set as offline.

Some new properties are set at the SLD level to manage the data mediation on both the request and response processing rules in DataPower, as shown in Figure 29.

Figure 29. WSRR components for versioning of REST-based services

Using this set of information, a DataPower Multi-Protocol gateway for REST services is able to:

1. Perform an SLA check to know if a contract exists between Consumer_A and the requested service.
2. Using the dp_xformName_Request property, the user controls the required query parameters, such as HTTP(S) GET calls, and controls the format of these parameters. You can add extra parameters to the request and remove or modify existing parameters for the ServiceEndPoint_B service.
3. Enforce the SLA SLM and SLD SLM policies.
4. Route the request of Consumer_A to the right online endpoint (ServiceEndpoint_B).

On the response processing, data mediation of the response using the dp_xformName_Response property is executed.

Figure 30 shows the two DataPower request processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower.

Figure 30. Queried WSRR objects and location of their properties values used in DataPower request processing rule - REST-based services

Click to see larger image

Figure 31 shows the two DataPower response processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower.

Figure 31. Queried WSRR objects and location of their properties values used in DataPower response processing rule - REST-based services

Click to see larger image

The processing is similar with what we have seen on the request processing side to handle REST services. An Xform action is responsible for retrieving information from WSRR using specific named queries. Then comes the data mediation that you can use to transform or control the REST service response. These two actions are processed on the response processing rule of the Multi-Protocol Gateway used to enforce the SLD through an SLM policy.

The REST service response, with a format required by the consumer (Consumer_A), is sent back to the consumer application. The last Xform (on the right side) corresponds to a custom log action.

Back to top

WSRR named queries used by sample stylesheets

This article uses some user-defined WSRR named queries to make the DataPower appliance stylesheet logic simpler, as well as allowing easy configuration of the WSRR configuration profile. These named queries are provided in the Download section of this article as WSRR XML configuration objects.

To load these into WSRR, switch to the "Configuration" perspective in the Web GUI and then select Active Profile >Named Queries. Select Load Named Query Configuration and upload each of the attached Named Query configuration XML files, specifying the "name" of the query as the same as the XML file name (without the .XML extension, see Figure 32).

Figure 32. WSRR load named query configuration file

The provided named queries are:

• SLACheckForOnlineEndpoint(consumerId, contextId)
• GetServiceSLD(consumerId, contextId)
• GetFrontEndXSD(SLDBsrUri)
• GetBackEndSourceDoument(consumerId, contextId)
• SLAOnlineEndpointLookup(consumerId, contextId)

SLACheckForOnlineEndpoint(consumerId, contextId)

This performs a check for an "Active" SLA contract of the required level contextId between the consuming Application (consumerId) and the provided service, which must have an "Online" available endpoint. The DataPower configuration uses a Consumer ID of "OrderServiceConsumer001" and a Context ID of "OrderServiceGold". A sample query looks like the following:

https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/SLACheckForOnlineEndpoint?p1=
 OrderServiceConsumer001&p2=OrderServiceGold

The response resembles Figure 33, where the name of the SLM policy for the given SLA is highlighted.

Figure 33. SLA named query response

GetServiceSLD(consumerId, contextId)

This is a query to return the provided service SLD to help the stylesheets navigate to the associated modeled objects. Using the same Consumer ID and Context ID, the request is:

https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/GetServiceSLD?p1=
 OrderServiceConsumer001&p2=OrderServiceGold

The response resembles Figure 34. The transforms from one version to another are highlighted, along with the name of the SLM Policy for the SLD.

Figure 34. GetServiceSLD named query response

GetFrontEndXSD(SLDBsrUri)

This is a query to return the optional frontend XSD document for scenarios where a message transformation is required in the appliance before routing to the provided backend endpoint. In our example, a frontend XSD is not used, so the results from the query is empty and the bsrURI used is obtained from the previous GetServiceSLD named query.

https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/GetFrontEndXSD?p1=
 07f99f07-15c0-4099.b0c8.18ef6718c820

GetBackEndSourceDoument(consumerId, contextId)

This is a query to return the providing service WSDL or the XSD document representing the backend service.

Using the same consumer and context ID, the query is:

https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/GetBackEndSourceDocument?
 p1=OrderServiceConsumer001&p2=OrderServiceGold

The response shown in Figure 35 contains the bsrURI of the WSDL or XSD to use in the validation step.

Figure 35. GetBackEndSourceDocument named query result

SLAOnlineEndpointLookup(consumerId, contextId)

This queries the "Online" backend endpoint for the given "Active" SLA contract and the consuming application. The query results in a response similar to Figure 36.

https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/SLAOnlineEndpointLookup?
 p1=OrderServiceConsumer001&p2=OrderServiceGold

Figure 36. SLAOnlineEndpointLookup named query result

Back to top

Scenario: Service version retirement and rerouting clients to a new version

A typical scenario in an SOA organization, which manages multiple online versions of service providers, is exposing multiple versions (such as v1.1, v1.2) of the same service, but maintaining those using only a single backend service version ( v1.2). This then maintains a back-level external service version (v1.1) for those consuming application clients that have not yet moved to the latest version specification, but enables the service provider to only provide and maintain the latest (v1.2) backend endpoints.

The following sections describe how to configure both the DataPower appliance and WSRR to manage this scenario.

Back to top

Scenario: Creating service models in WSRR

The following sections describe the WSRR Web GUI interactions to create the example of simplified WSRR artifacts shown in the model diagram (Figure 2). Using an administrator role, log into the WSRR Web GUI.

Create the OrderService service version

Navigate to Business Objects > Service Version and create a new service version for the providing service (Figure 37).

Figure 37. Create a new service version

Create the OrderService service level definition

Navigate to Business Objects > Service Level Definition and create the providing service contract (Figure 38).

Figure 38. Create a new Service Level Definition

Add OrderService-SLD to OrderService

From the OrderService service version detail, select Edit Relationships so that the OrderService-SLD can be applied to the providing service (Figure 39).

Figure 39. Edit service version relationships

Load the OrderService WSDL definition

Now load the example OrderService.wsdl service definition along with its schema, OrderServiceSchema.xsd. Select Service Documents > WSDL/XSD Documents and then Load Documents (Figure 40).

Figure 40. Load WSDL documents

Add the service interface to the OrderService service level definition

Now add the service interface just created from loading the WSDL service definition as the "Service Interface" for the OrderService-SLD (Figure 41). This defines the interface for the providing service contract.

Figure 41. Add the service interface to the service level definition

Add the service port to the OrderService service level definition

Now add the service port just created from loading the WSDL service definition as the "Bound Web Service Port" for the OrderService-SLD (Figure 42). This defines the bound port for the providing service contract.

Figure 42. Add service port to the service level definition

Govern the OrderService-SLD to the SLD subscribable state

The OrderService-SLD can now be governed and transitioned to the "SLD Subscribable" state. Navigate to the OrderService-SLD detail panel and select the Governance tab. Then using the Transition button, transition its state to SLD Subscribable (Figure 43).

This providing service contract is now available for consumers.

Figure 43. Govern the service level definition to the SLD subscribable state

Create the OrderApplication application version

Now switch to create the consuming application version called "OrderApplication" in this example. Navigate to Business Objects > Application Version, and create a new application version, ensuring to set both the version and consumer identifier properties (Figure 44).

Figure 44. Create a new application version

Create the OrderApplication-OrderService-SLA service level agreement

You can now create the consumer to providing service version service level agreement contract. Navigate to Business Objects > Service Level Agreement and create a new service level agreement called "OrderApplication-OrderService-SLA" with a "Context Identifier" attribute of "OrderServiceGold" (Figure 45). The context identifier attribute is a unique key identifying this contract with the providing service.

Figure 45. Create a new service level agreement

Bind OrderApplication-OrderService-SLA to the agreed OrderService-SLD contract

The service level agreement now needs to bind to the agreed OrderService-SLD. Edit the relationships of the OrderApplication-OrderService-SLA to add the OrderService-SLD as the agreed endpoint (Figure 46).

Figure 46. Add agreed service level definition to the service level agreement

Govern OrderApplication-OrderService-SLA to the SLA Active state

The service level agreement can now be transitioned to the "SLA Active" state, indicating this contract between the consumer and providing service version is available. Navigate to the OrderApplication-OrderService-SLA detail panel and the Governance tab, and transition it to the SLA Active state (Figure 47).

Figure 47. Govern service level agreement to the SLA Active state

OrderApplication-OrderService-SLA to OrderApplication

Now relate the SLA to the actual consuming Application Version (OrderApplication) by editing the relationships of the OrderApplication and selecting the OrderApplication-OrderService-SLA object for the target of the "Consumes" service level agreement (Figure 48).

Figure 48. Assign service level agreement to the consuming Application Version

Classify OrderService endpoint for production

The OrderService endpoint created when the WSDL definition was loaded now needs to be classified to an environment before it is made available and set online. Navigate to Business Objects > SOAP Service Endpoint and select the orderService endpoint. Then from its detail panel, select the Edit Classifications link, add the classification Governance Profile Taxonomy > Environment > Production, and select OK (Figure 49).

Figure 49. Classify endpoint for production

Govern endpoint to the online state

The orderService endpoint can now be set to the "online" state, making it available for a providing service. Navigate to the orderService SOAPservice endpoint and the Governance tab, and transition it to the Online state (Figure 50).

Figure 50. Govern endpoint as online

Add endpoint to the OrderService-SLD available endpoints

The orderService endpoint can now be made available to the OrderService-SLD. Navigate to Business Objects > Service Level Definition for OrderService-SLD and select Edit Relationships, then select Add Service Endpoint for Available Endpoints and add the orderServiceendpoint (Figure 51).

Figure 51. Make endpoint available to the service level definition

The complete set of the WSRR artifacts for the SOAP WebService OrderApplication consuming from the OrderService version example are now created and available for integration with the DataPower appliance.

Back to top

Scenario: XML WebService endpoint

You can now extend the OrderService-SLD to add additional types of endpoints. This section demonstrates the addition of an XML-based WebService endpoint.

Create the XML ServiceEndpoint

Navigate to the Business Objects > Service Endpoint and create a new service endpoint called http://host:port/xmlEndpoint with an endpoint type attribute of XML (Figure 52).

Figure 52. Create a new XML service endpoint

Add OrderServiceSchema as sourceDocument of ServiceEndpoint

Add the XML schema document that describes the XML endpoint interface as the sourceDocument relationship of the service endpoint (Figure 53).

Figure 53. Add XML interface XSD to the endpoint

Classify and govern XML endpoint and add to the OrderService-SLD available endpoints

In the same way as the SOAP service endpoint, the XML service endpoint now needs to be classified with a "production" environment, governing and transitioning to the "online" state, and then adding as an "available endpoint" for the OrderService-SLD (Figure 54).

Figure 54. Add XML endpoint to the service level definition

The complete set of WSRR artifacts for the XML-based WebService example is now created and available for integration with the DataPower appliance.

Back to top

Scenario: REST endpoint

You can extend the OrderService-SLD to add the final example type of the endpoint for REST. This section demonstrates the addition of the REST service endpoint.

Create the REST ServiceEndpoint

Navigate to the Business Objects > Service Endpoint and create a new service endpoint called http://host:port/restEndpoint with an endpoint type attribute of "REST" (Figure 55).

Figure 55. Create the new REST service endpoint

Classify and govern REST endpoint

In the same way as the XML service endpoint, the REST service endpoint now needs to be classified with a "Production" environment, governing and transitioning to the "Online" state, and then adding as an "Available Endpoint" for the OrderService-SLD (Figure 56).

Figure 56. Add REST endpoints to the service level definition

The complete set of WSRR artifacts for the REST-based WebService example is now created and available for integration with the DataPower appliance.