White Papers
Abstract
This is the third article in the series on enabling the WebSphere DataPower appliance to perform service level agreement policy enforcement and service governance. This article documents the DataPower configuration artifacts needed to implement the WSRR solution described in Part 2 and provides step-by-step testing and validation instructions.
Content
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 2 before continuing. You can implement SLA enforcement on two different types of DataPower service gateways: 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: 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. The match action of the request processing rule is configured to match any URL. The first transform action is configured to reference the This xform action is used to perform SLA check and also to set context variables used on the various processing actions to: In order to set these context variables, the The The same The request processing rule of the mpg_sld gateway is shown in Figure 4. The response processing rule of the mpg_sld gateway is shown in Figure 5. 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. This xform action is used to invoke WSRR using named queries and to set context variables used on the various processing actions to: 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. 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 2 presents the request and response types of the SLA and SLD enforcement gateway when dealing with XML-based services. Table 3 presents the request and response types of the SLA and SLD enforcement gateway when dealing with REST-based services. 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. 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. 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. The configuration of the user agent basic-auth policy is shown in Figure 10. 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. 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. 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. 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: 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: Here is an example of the cURL command used to post a CreditCheck XML message on the XML gateway of a DataPower device: Figure 13 shows the details of the HTTP POST. 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. 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. 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. The context variables used on the SLA Enforcement Gateway are: 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. The SLD Enforcement Gateway routes the request to the CreditCheck service endpoint ( The DataPower probes for the CreditCheck request are presented in Figure 18. After the first Xform action is used to retrieve properties from WSRR, the context variables are extracted as shown in Figure 19. The context variables used on the SLD enforcement gateway are: The XML response received on the SLD Enforcement Gateway is shown in Figure 20. 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. 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. If an incorrect or no consumer identifier is posted, then the SLA check fails on the SLA Enforcement Gateway, as shown in Figure 23. If an SLM policy specified at the SLA or SLD level is not respected, then the request is rejected, as shown in Figure 24. 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. 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: The components of the CreditCheck service in WSRR are shown in 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. 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 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 28 shows the governance state of the Figure 29 shows the governance state of the Figure 30 shows the 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 ( The input message posted on the SLA Gateway is shown in Figure 31. 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. A first validation is performed using the XSD schema file referenced by the 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 On the SLD Gateway probes (mpg_sld), the route to the online endpoint of the CreditCheck service (version 2) is shown in Figure 34. The actions executed on the request processing rule of the SLD gateway are shown in Figure 35. 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 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. The content of the 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. To import the configuration provided, perform the following steps: This third, and last, article in the SLA enforcement series provided DataPower configuration details and demonstrated the practical usage of the concepts and solution introduced in Part 2. If you are running DataPower V5.0 (or newer) and WSRR V8.0 (or newer), you have the option of taking advantage of tighter integration capabilities between them. The newer integration capabilities removes the need for most of the DataPower and WSRR configuration artifacts discussed in Part 2 and this article. For more information, reference the DataPower V5.0 and WSRR V8.0 article series.Introduction
Creating the DataPower Gateway artifacts
Processing policies of the SOAP, XML, and REST gateways
ibm.devworks.wsxml.wsrr.request.xsl
XSL stylesheet, as shown in Figure 2.
ibm.devworks.wsxml.wsrr.request.xsl
XSL stylesheet uses the WSRR named queries defined in the previous article.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.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.
Request and response types of the SOAP, XML, and REST gateways
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
Type SLA Enforcement Gateway SLD Enforcement Gateway DataPower service type Multi-Protocol Gateway Multi-Protocol Gateway Request type XML XML Response type XML XML
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 DataPower XMLManager object of the SOAP, XML, and REST gateways
Testing the XML Gateway
Testing the XML Gateway for SLA and SLD enforcement
<?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>
X-CONSUMERID
for the consumer identifier and X-CONTEXTID
for the context identifier. 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/
var://context/wsxml/output-schema-req
context variable.SLA_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).http://demoserver:8101/creditcheck
).
var://context/wsxml/output-schema-req
context variable.SLD_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).Testing the XML Gateway for versioning
CreditCheck2Schema.xsd
http://demoserver:8102/creditcheck
WSRR components
<?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>
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.http://demoserver:8101/creditcheck
service endpoint (offline).http://demoserver:8102/creditcheck
service endpoint (online).dp_xsd_frontEnd
relation added at the service version level of the CreditCheck service version (CreditCheckSV
).DataPower test results
mpg_xml_sla-proxy
) and the SLD gateway (mpg_sld
).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.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.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.<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.Import the configuration provided using the WebGUI
Conclusion
Was this topic helpful?
Document Information
Modified date:
08 June 2021
UID
ibm11109613