Service Level Agreement(SLA) in DataPower: Part 3:Testing the integration with WSRR

Introduction

This is the third article in the series on enabling the WebSphere DataPower appliance to perform service level agreement (SLA) policy enforcement and service governance. This article documents the DataPower configuration artifacts needed to implement the WebSphere Service Registry and Repository (WSRR) solution described in Part 2, and provides step-by-step testing and validation instructions. To understand the proposed WSRR and DataPower "SLA enforcement" pattern concepts, solution, and benefits, read Part 2before continuing.

Back to top

Creating the DataPower Gateway artifacts

You can implement SLA enforcement on two different types of DataPower service gateways:

1. Web-Service Proxy, when dealing with SOAP based services.
2. Multi-Protocol Gateway, when dealing with XML and REST based services.

The service level definition (SLD) enforcement is implemented on a separate Multi-Protocol Gateway when using a DataPower firmware version prior to 5.0.0.

In the provided material, the name of the gateways are as follows:

• wsp_sla-proxy is the name of the Web-Service Proxy responsible for SLA enforcement for SOAP-based services.
• mpg_xml_sla-proxy is the name of the Multi-Protocol Gateway in charge of enforcing SLA for XML-based services.
• mpg_rest_sla-proxy is the name of the Multi-Protocol Gateway in charge of enforcing SLA for REST-based services.
• mpg_sld is the name of the Multi-Protocol Gateway responsible for SLD enforcement for SOAP/XML and REST-based services.

Processing policies of the SOAP, XML, and REST gateways

DataPower processing policies of the services configured to enforce SLA are the same.

The request processing rule of the processing policy of services configured to enforce SLA is shown in Figure 1.

Figure 1. Request processing rule for SLA enforcement

The match action of the request processing rule is configured to match any URL.

The first transform action is configured to reference the ibm.devworks.wsxml.wsrr.request.xsl XSL stylesheet, as shown in Figure 2.

Figure 2. SLACheck transformation for SLA enforcement

This xform action is used to perform SLA check and also to set context variables used on the various processing actions to:

• Validate the input request message.
• Transform the input message.
• Validate the result of the input message mediation.
• Enforce the SLA SLM policy.
• Route the message to the SLD gateway.

In order to set these context variables, the ibm.devworks.wsxml.wsrr.request.xsl XSL stylesheet uses the WSRR named queries defined in the previous article.

The ibm.devworks.wsxml.wsrr.request.xsl template proposes configuration parameters related to WSRR for the DataPower device to integrate. These configuration parameters are shown in Figure 3.

Figure 3. Configuration parameters of the SLA check transformation

The same ibm.devworks.wsxml.wsrr.request.xsl template is used on the request processing rule of the mpg_sld gateway. The template is used to enforce an SLD SLM policy.

The request processing rule of the mpg_sld gateway is shown in Figure 4.

Figure 4. Request processing rule for SLD enforcement

The response processing rule of the mpg_sld gateway is shown in Figure 5.

Figure 5. Response processing rule for SLD enforcement

The match action of the response processing rule is configured to match any URL. The first transform action is configured to reference the ibm.devworks.wsxml.wsrr.response.xsl XSL stylesheet, as shown in Figure 6.

Figure 6. Xform action to retrieve context variables

This xform action is used to invoke WSRR using named queries and to set context variables used on the various processing actions to:

• Validate the input response message.
• Transform the response message.
• Validate the result of the output message of the data mediation.

The validate actions of the SLA and SLD enforcement gateways have different configurations for the type of services that must be exposed through the gateway. The schema validation method of the validate actions of the SLA and SLD gateways is based on schema URL for the XML-based services and WSDL URL for the SOAP-based services. You can use any value for the REST-based services as there is no validation in this particular case.

Request and response types of the SOAP, XML, and REST gateways

The following tables summarize the request and response types of the DataPower services used to implement SLA and SLD enforcement for the different types of gateways: SOAP, XML, and REST.

Table 1 presents the request and response types of the SLA and SLD enforcement gateway when dealing with SOAP-based services.

Table 1. Request and response type of gateways for SOAP-based services

Type	SLA Enforcement Gateway	SLD Enforcement Gateway
DataPower service type	Web-Service Proxy	Multi-Protocol Gateway
Request type	SOAP	SOAP or XML
Response type	SOAP	SOAP or XML

Table 2 presents the request and response types of the SLA and SLD enforcement gateway when dealing with XML-based services.

Table 2. Request and response type of gateways for XML-based services

Type	SLA Enforcement Gateway	SLD Enforcement Gateway
DataPower service type	Multi-Protocol Gateway	Multi-Protocol Gateway
Request type	XML	XML
Response type	XML	XML

Table 3 presents the request and response types of the SLA and SLD enforcement gateway when dealing with REST-based services.

Table 3. Request and response type of gateways for REST-based services

Type	SLA Enforcement Gateway	SLD Enforcement Gateway
DataPower service type	Multi-Protocol Gateway	Multi-Protocol Gateway
Request type	non-XML	non-XML
Response type	non-XML	non-XML

The request and response types of the gateways used to deal with REST services are set to non-XML as these gateways may support XML, JSON, or any other content types.

The persistent connection property of the SLA enforcement gateways must be set to "off", as shown in Figure 7.

Figure 7. Persistent connection configuration on SLA enforcement gateways

DataPower XMLManager object of the SOAP, XML, and REST gateways

You can use the same XMLManager object for the SOAP, XML, and REST gateways on both the SLA and SLD gateways. The name of the specific XMLManager is "XMLManager_WSRR".

A specific XMLManager object is created to deal with WSRR document caching. A document cache policy allows the DataPower administrator to determine how documents are cached by the XML Manager. The policy offers time-to-live, priority, and type configuration values. The document cache policy is shown in Figure 8.

Figure 8. DataPower cache policy

The two URL match expressions define the patterns used to define the WSRR server. The top entry of the list is the request URLs used to invoke a namedQuery. The second entry is used when referencing a WSDL or schema file.

A dedicated DataPower user agent object is also configured at the XML Manager level. This user agent (UserAgent_WSRR) is used to set the SSL proxy profile and basic authentication required when connecting to WSRR. The SSL proxy profile defines the cryptographic certificate (through a validate credentials object) that is required during the SSL handshake between DataPower and WSRR to establish a secured connection. he configuration of the user agent SSL proxy profile policy is shown in Figure 9.

Figure 9. UserAgent SSL proxy profile policy configuration

The configuration of the user agent basic-auth policy is shown in Figure 10.

Figure 10. Basic-auth policy configured at the user agent level

Back to top

Testing the XML Gateway

This section describes a full test scenario using an XML gateway for SLA and SLD enforcement as the first step, and demonstrates the versioning capabilities of the solution based on WSRR and DataPower as the second step.

Testing the XML Gateway for SLA and SLD enforcement

In this first test, we use both DataPower and WSRR to demonstrate SLA and SLD enforcement for an XML-based service. The name of this service is "CreditCheck". The components of the CreditCheck service in WSRR are presented in Figure 11.

Figure 11. CreditCheck XML-based service WSRR components

The only consumer that is able to consume the CreditCheck service is APP2-CONSUMER-001 (consumer identifier).Using the "Gold" context, this consumer consumes the CreditCheck service in a limit of 3 messages per 10 seconds. If this contract is not respected, then non-compliant requests are rejected.

The provider of the CreditCheck service cannot accept more than 10 messages per 30 seconds of time interval. This limit applies to all consumers of the CreditCheck service (only one in the example). Figure 12 shows the dp_slmPolicyName property defined on the CreditClientGoldSLA Service Level Agreement and used on the DataPower device for the SLA SLM policy enforcement.

Figure 12. dp_slmPolicyName property defined on the CrediClientGoldSLA service

The same dp_slmPolicyName property is set at the SLD level and is used for the SLD SLM policy enforcement in DataPower.

Here is an example of a CreditCheck consumer request:

<?xml version="1.0" encoding="UTF-8"?>
<p:creditCheckRequest 
xmlns:p="http://ibm.com/sr/test/wsdl/creditCheck.schema">
 <request>This is a CreditCheck request</request>
</p:creditCheckRequest>

When submitting this request, the consumer application must provide the two required parameters, which are a consumer and a context identifier. In the example, these parameters are transmitted using HTTP headers: X-CONSUMERID for the consumer identifier and X-CONTEXTID for the context identifier.

Here is an example of the cURL command used to post a CreditCheck XML message on the XML gateway of a DataPower device:

curl --data-binary @CreditCheckSchema.xml -H "X-CONSUMERID: APP2-CONSUMER-001" 
 -H "X-CONTEXTID: Gold" -H "Content-Type: text/xml" http://datapower.xi50.devworks:2082/

Figure 13 shows the details of the HTTP POST.

Figure 13. CreditCheck HTTP POST request

The request that is received on the SLA Enforcement Gateway for the XML-based service can be displayed in the DataPower probes of the "mpg_xml_sla-proxy" Multi-Protocol Gateway, as shown in Figure 14.

Figure 14. XML request received on the SLA Enforcement Gateway

The SLA enforcement gateway routes the request to the SLD gateway (outbound-url). The DataPower probe capture for a sample CreditCheck request is presented in Figure 15.

Figure 15. DataPower probes for the CreditCheck request (SLA)

After the first Xform action is used to perform the SLA check and to retrieve properties from WSRR, the context variables are extracted as shown in Figure 16.

Figure 16. Extract of context variables on the CreditCheck service request

The context variables used on the SLA Enforcement Gateway are:

• var://context/wsxml/input-schema-req: This is the URL of the schema used to validate the request message before it is transformed. As there is no data mediation in this example, the validation is performed using the schema URL provided by the var://context/wsxml/output-schema-reqcontext variable.
• var://context/wsxml/output-schema-req: This is the URL of the schema used to validate the request message if it has been transformed or not.
• var://context/wsxml/sldproxy-endpoint: This is the URL of the SLD gateway.
• var://context/wsxml/xform-req: This is the name of the transformation to apply on the request message. In this case, the identity transformation is executed as there is no specific transformation.
• var://context/wsxml/sla: This is the name of the SLA SLM policy that must be executed on the DataPower device. Its value isSLA_SLMPolicy_3MessagesPer10Seconds_Throttle. This means that if the consumer (APP2-CONSUMER-001) requests the CreditCheck service more than 3 times in 10 seconds, then other messages in the same time interval are rejected (throttling).

The request that is received on the SLD Enforcement Gateway for the XML-based service can be displayed in the DataPower probes of the "mpg_sld" Multi-Protocol Gateway, as shown in Figure 17.

Figure 17. XML request received on the SLA Enforcement Gateway

The SLD Enforcement Gateway routes the request to the CreditCheck service endpoint (http://demoserver:8101/creditcheck).

The DataPower probes for the CreditCheck request are presented in Figure 18.

Figure 18. DataPower probes for the CreditCheck request (SLD)

After the first Xform action is used to retrieve properties from WSRR, the context variables are extracted as shown in Figure 19.

Figure 19. Extract of context variables on the CreditCheck service request (SLD)

The context variables used on the SLD enforcement gateway are:

• var://context/wsxml/input-schema-req: This is the URL of the schema used to validate the response message before it is transformed. As there is no data mediation in this example, the validation is performed using the schema URL provided by thevar://context/wsxml/output-schema-req context variable.
• var://context/wsxml/output-schema-req: This is the URL of the schema used to validate the response message if it has been transformed or not.
• var://context/wsxml/service-endpoint: This is the URL of the service endpoint.
• var://context/wsxml/xform-res: This is the name of the transformation to apply on the response message. In this case, the identity transformation is executed as there is no specific transformation.
• var://context/wsxml/sld: This is the name of the SLD SLM policy that must be executed on the DataPower device. Its value here isSLD_SLMPolicy_10MessagesPer30Seconds_Throttle. This means that if the number of requests to the CreditCheck service is above 10 messages per 30 seconds, then other messages in the same time interval are rejected (throttling).

The XML response received on the SLD Enforcement Gateway is shown in Figure 20.

Figure 20. XML response received on the SLD Enforcement Gateway

The response is validated and sent back to the SLA Enforcement Gateway. The XML response received on the SLD Enforcement Gateway is shown in Figure 21.

Figure 21. XML response received on the SLA Enforcement Gateway

The Xform action shown on the response processing rule corresponds to a log action. It has nothing to do with a processing action used in the context of the SLA enforcement

Finally, the response is sent back to the consumer application as shown in Figure 22.

Figure 22. CreditCheck response

If an incorrect or no consumer identifier is posted, then the SLA check fails on the SLA Enforcement Gateway, as shown in Figure 23.

Figure 23. XML response received in the case of an SLA check failure

If an SLM policy specified at the SLA or SLD level is not respected, then the request is rejected, as shown in Figure 24.

Figure 24. SLA SLM policy throttling

In this example, the SOAP faults are returned to the consumer application in case of problems. Another solution is to return a simple HTTP status code bound to a specific reason phrase.

Testing the XML Gateway for versioning

Let us assume that the same consuming application (CreditClientVersion) must now consume a new version of the CreditCheck service. This new version of the CreditCheck service is defined through the following elements:

• A new schema file: CreditCheck2Schema.xsd
• A new endpoint: http://demoserver:8102/creditcheck

WSRR components

The components of the CreditCheck service in WSRR are shown in Figure 25.

Figure 25. CreditCheck XML-based service WSRR components for the versioning use case (see enlarged Figure 25)

Because of the relations and extra properties modified or added at the service version and SLD levels, it is now possible to implement the versioning use case without any modification from the DataPower configuration or from the consumer application. The only required action is to flush the DataPower cache used to store the WSRR namedQueries responses. You can perform this action using a SOMA request. Such a SOMA request must specify the DataPower domain and the XML Manager object, which is responsible for managing the WSRR namedQueries responses cache. You can use this XMLManager cache object on the SOAP/XML/REST SLA gateways as well as on the SLD Gateway.

Listing 1 is a sample of a SOMA request message used to flush a document cache.

Listing 1. Sample SOMA call to flush an XML document cache

<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 <env:Body>
  <dp:request domain="XMLServices"
xmlns:dp="http://www.datapower.com/schemas/management">
   <dp:do-action>
    <FlushDocumentCache>
     <XMLManager>XMLManager_WSRR</XMLManager>
    </FlushDocumentCache>
   </dp:do-action>
  </dp:request>
 </env:Body>
</env:Envelope>

Note that in this case, the XML management interface accessed through the default domain of the appliance must be enabled and must support the SOMA format.

Figure 26 shows the dp_xformName_Request, dp_xformName_Response, and dp_slmPolicyName properties set at the SLD level of the CreditCheck service. To implement the versioning use case, you must add both dp_xformName_Request and dp_xformName_Response as SLD properties.

Figure 26. Data mediation and SLD SLM policy properties defined

Figure 27 shows the two service endpoints define as relations at the SLD level. Note that one of the endpoint is "online", whereas the other endpoints are "offline".

Figure 27. List of available endpoints at the SLD level of the CreditCheck service

Figure 28 shows the governance state of the http://demoserver:8101/creditcheckservice endpoint (offline).

Figure 28. Governance state of the demoserver-8101 service endpoint (offline)

Figure 29 shows the governance state of the http://demoserver:8102/creditcheck service endpoint (online).

Figure 29. Governance state of the demoserver-8102 service endpoint (online)

Figure 30 shows the dp_xsd_frontEnd relation added at the service version level of the CreditCheck service version (CreditCheckSV).

Figure 30. Frontend XSD relation defined at the service version level of the CreditCheck service

DataPower test results

The request that is submitted is the same as the one that was transmitted in the Testing the XML Gateway for SLA and SLD enforcement section. To improve the analysis of the versioning test, it is possible to activate the DataPower probes on the SLA Gateway for XML services (mpg_xml_sla-proxy) and the SLD gateway (mpg_sld).

The input message posted on the SLA Gateway is shown in Figure 31.

Figure 31. Input of the SLA Gateway service for XML services (versioning)

The context variables used on request and response processing rules of the SLA and SLD gateways can be seen after the execution of the first transformation, as shown in Figure 32.

Figure 32. Context variables after the execution of the SLA check transformation

A first validation is performed using the XSD schema file referenced by the var://context/wsxml/input-schema-req context variable. Then a data mediation is executed. This is the transformation of CreditCheck request message in version 1 into the CreditCheck request message in version 2. The output context of the second transform action is shown in Figure 33.

Figure 33. Result of the data mediation action

The transform action is successful as the new namespace for the message is "http://ibm.com/sr/test/wsdl/creditCheck2.schema", replacing the namespace "http://ibm.com/sr/test/wsdl/creditCheck.schema".

A second validation is performed using the XSD schema file referenced by the var://context/wsxml/output-schema-req context variable and the SLA SLM policy is enforced. The final "Set Variable" action is used to route the request message (CreditCheck message in version 2) to the SLD Gateway.

On the SLD Gateway probes (mpg_sld), the route to the online endpoint of the CreditCheck service (version 2) is shown in Figure 34.

Figure 34. Outbound URL on the SLD Gateway

The actions executed on the request processing rule of the SLD gateway are shown in Figure 35.

Figure 35. Processing policy of the SLD Gateway (mpg_sld)

The SLD is enforced once the first transform action has retrieved the name of the SLD SLM policy. The name of the SLD SLM policy is defined by the value of the var://context/wsxml/sld context variable. The request message is then posted to the backend server, which returns an XML response as shown in Figure 36.

Figure 36. Response of the CreditCheck service (v2)

The response of the CreditCheck service (version 2) is validated and transformed into a CreditCheck response message based on the version that the consumer application can understand (version 1 in our example).

The CreditCheck message after data mediation on the response processing rule of the SLD Gateway is shown in Figure 37.

Figure 37. CreditCheck message after data mediation

The content of the <response/> element is not modified, but only the namespace value of the creditCheckResponse tag is set to "http://ibm.com/sr/test/wsdl/creditCheck.schema", as required by the schema defining the version 1 of the CreditCheck service.

After the data mediation, the response message is validated and sent back to the consumer application. Finally, the response that is sent back to the consumer application as displayed in Figure 38.

Figure 38. CreditCheck service response (versioning)

Import the configuration provided using the WebGUI

To import the configuration provided, perform the following steps:

1. Install the WSRR certificate for your WSRR Server in the sharedcert:/// directory of the default domain of the DataPower device.
2. Create a specific domain on the DataPower appliance and import the provided MockServices_Article-3.zip archive file into it. This domain contains the various mock services used as backend services.
3. Create a specific domain on the DataPower appliance and import the provided DataPower_Export_SOAP-UseCase.zip archive file into it. This domain contains the SLA and SLD gateways used for SOAP.
4. Create a specific domain on the DataPower appliance and import the provided DataPower_Export_XML-UseCase.zip archive file into it. This domain contains the SLA and SLD gateways used for XML and REST based services.
5. In the default domain, create three host aliases, as shown in Figure 39.
   • The "demoserver" alias is one of the IP addresses of your appliance. It is used by mock services, which are used to provide SOAP, XML, and JSON responses.
   • The "wsrr7.5.0" alias refers to the IP address of your WSRR server.
   • The "dp.loopback" alias is used for internal communication between the SLA and SLD gateways.

   Figure 39. Host alias configuration

6.