Enforcing Service Level Agreements using WebSphere DataPower, Part 2: Integrating with a WSRR service model pattern

Part 2 of this 3-part article series takes the next step of taking the SLA control file used in Part 1 and replacing it with a proper business service registry solution. The article will show how to use the WSRR Governance Enablement Profile (GEP) service model to capture and publish the same (and more) service metadata as available in the SLA control file.

Mario E. De Armas (drhoek@us.ibm.com), Senior Technical Staff Member, IBM

Photo of Mario De ArmasMario De Armas is a Senior Technical Staff Member on the WebSphere DataPower Appliance development team. He has worked on many different areas and features of DataPower appliances. He is currently the Software Architect responsible for DataPower's Web Services, SOA Governance, User Experience, and Appliance Management functionality. His past DataPower contributions include patterns, mediation policy, WSRR integration, AS1 protocol handler, B2B gateway, and appliance management functionality.



Oswaldo Gago (gago@us.ibm.com), Advisory Software Engineer, IBM

Photo of Oswaldo GagoOswaldo Gago is an Advisory Software Engineer on the WebSphere DataPower development. He is currently the lead developer for the DataPower Web Service Proxy, WSPolicy, and WebSphere Service Registry and Repository integration. Oswaldo joined IBM in 2002 as part of the IBM Text to Speech team after he graduated Summa Cum Laude with a Master's degree in Computer Science from the University of Miami, Florida.



Joel Gauci (gauci@fr.ibm.com), IT Specialist, IBM

Photo of Joel GauciJoel Gauci is a Client Technical Professional in the WebSphere Software group in France. He has worked on the first WebSphere DataPower SOA projects for European leading firms in mobile telecommunications and has been working in the Software Group since 2008. Joel mainly works on DataPower selling opportunities and assists potential customers from basic presentation to complex architecture definition. He has authored several IBM Redpapers and IBM Redbooks on DataPower SOA appliances.



Andrew Leonard (andrew_m_leonard@uk.ibm.com), Software Engineer, IBM

Photo of Andrew LeonardAndrew Leonard is a Lead Developer on the WebSphere Service Registry and Repository development team at the IBM Software Lab in Hursley, United Kingdom. He has been with IBM for 21 years and has worked in development roles on the CICS, WebSphere Application Server J2EE messaging, and WebSphere Application Server Service Integration Bus messaging development teams.



21 August 2013

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 1 article'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
Components of the SLA policy enforcement solution

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
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 ArtifactsDescription
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.

Integration between DataPower and WSRR

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

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.


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
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
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
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
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
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
Queried WSRR objects

Click to see larger image

Figure 8. Queried WSRR objects

Queried WSRR objects

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
    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
    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
    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
    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
    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
    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
    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
    Service level agreement SLM policy
  8. Figure 17 routes the message to the final endpoint.
    Figure 17. Route message to the backend
    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
    Queried WSRR objects

    Click to see larger image

    Figure 18. Queried WSRR objects

    Queried WSRR objects

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
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
Request and response types of the SLD gateway for SOAP and XML based services

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
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
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
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
Queried WSRR objects and location of their properties values (XML-based services)

Click to see larger image

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

Queried WSRR objects and location of their properties values (XML-based services)

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
Queried WSRR objects and location of their properties values in the DataPower response processing rule

Click to see larger image

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

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

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
SLD gateway validate action details for XML-based services

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
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)
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
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
Queried WSRR objects and location of their properties values used in DataPower request processing rule (REST-based services)

Click to see larger image

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

Queried WSRR objects and location of their properties values used in DataPower request processing rule (REST-based services)

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
Queried WSRR objects and location of their properties values used in DataPower response processing rule (REST-based services)

Click to see larger image

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

Queried WSRR objects and location of their properties values used in DataPower response processing rule (REST-based services)

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.


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
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
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
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
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
SLAOnlineEndpointLookup named query result

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.


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 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
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
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
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 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
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
Govern rhe 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 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
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
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
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
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
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 SOAP service endpoint and the Governance tab, and transition it to the Online state (Figure 50).

Figure 50. Govern endpoint as online
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 orderService endpoint (Figure 51).

Figure 51. Make endpoint available to the service level definition
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.


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
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
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
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.


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
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
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.


Conclusion

This second article in this SLA enforcement series introduced a solution pattern that provides an prescriptive approach to adopt proper SOA principles of service governance and policy-based enforcement based on DataPower and WSRR products. The solution's implementation leverages WSRR's strengths as an enterprise SOA Policy Administration Point (PAP), which is a natural evolution of the initial SLA Control File approach presented in Part 1.

It is difficult to fully adopt and meet SOA goals without proper centralized service and policy administration. Additionally, DataPower v5.0 (and later) provides integration with WSRR v7.5 (and later) that reduces the level of effort required to govern and deploy Web services and their associated policies. WSRR, as a centralized services registry, enables service administrators to gain control and insight as to what is happening with deployed business services and consumers. For example, WSRR provides "impact analysis" reports that detail what consumer applications are affected if a specific service fails, changes, or is retired.

You can import the reference implementation configuration (provided for download as part of this article) into WSRR and DataPower and use it immediately to enforce capabilities described here. You can modify the product configurations as needed to accommodate for different service and policy deployments' requirements.

Finally, the 3-part series was created to allow for ease of migration between SLA Control File (Part 1) and WSRR models (this article) as much as possible. That way, you can start with the Part 1 approach and, when ready, migrate to use the WSRR tooling described in this article. Part 3 of the series documents the WSRR solution's DataPower configuration artifacts discussed in this article and provides step-by-step testing and validation instructions.


Download

DescriptionNameSize
Code sampleSLAEnforcement_Part2_DataPower_WSRR_artifacts.zip20KB

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=941585
ArticleTitle=Enforcing Service Level Agreements using WebSphere DataPower, Part 2: Integrating with a WSRR service model pattern
publish-date=08212013