Enable XML awareness in WebSphere Extended Deployment with WebSphere DataPower SOA Appliances

Learn how to use the newly acquired IBM® WebSphere® DataPower SOA Appliances to enable the WebSphere Extended Deployment On Demand Router (ODR) to classify requests based on XML.

Share:

Bob Callaway (rcallawa@us.ibm.com), Software Engineer, IBM

Bob CallawayBob Callaway is a software engineer with the WebSphere Technology Institute. He participates in research and development in the integration of middleware and application-aware networking technologies. Before joining the WSTI, Bob worked with the xSeries xPert Team on BladeCenter opportunities. He holds three degrees from North Carolina State University: BS in Electrical Engineering, BS in Computer Engineering, and MS in Computer Networking. He is currently pursuing the Ph.D. degree in Computer Engineering at N.C. State, with a concentration in application-aware networking.



Adolfo Rodriguez, Ph.D (adolfo@us.ibm.com), Senior Software Engineer, IBM

Adolfo RodriguezAdolfo Rodriguez is a member of IBM's WebSphere Technology Institute and an Assistant Adjunct Professor of Computer Science at Duke University, where he teaches networking courses. At IBM, he works on novel technologies that drive emerging applications, architecture, and systems. Dr. Rodriguez's recent contributions include projects in the areas of the WebSphere Partitioning Facility, XML processing, and application-aware networking. His primary interests are networking and distributed systems, application middleware, overlays, and J2EE architecture. He has written 12 books and numerous research articles. Dr. Rodriguez holds four degrees from Duke University: BS in Computer Science, BA in Mathematics, MS in Computer Science, and Ph.D. in Computer Science (Systems).



19 July 2006

Introduction

The On Demand Router (hereafter called ODR), a component of WebSphere Extended Deployment (hereafter called WebSphere XD), is a proxy to the application server tier that provides application-specific services to support policy goals. In order to effectively prioritize and throttle traffic to meet these goals, the ODR classifies traffic to the correct service policies. The ODR supports many methods for classifying requests based on the underlying transport protocol; including URL and other optional criteria, such as HTTP headers and IP addresses and ports. However, at this time, the ODR currently is unable to inspect the XML content of a message in order to classify requests, which means that it does not yet support XML-based operations like XPath and XSLT.

In this article, you'll learn how to leverage the XML capabilities of the WebSphere DataPower SOA Appliances to inspect the properties of incoming XML requests and provide this information to the ODR, so that these requests are properly classified, prioritized, and forwarded within the WebSphere XD environment. To do this, you'll configure the WebSphere DataPower appliance to set HTTP header variables based on the result of XML operations. Since the ODR already has the ability to map requests to service and routing policies based on HTTP header variables, you can use the WebSphere DataPower appliance to enable the ODR to map requests using XML criteria. The highly optimized engine of the WebSphere DataPower appliances enables you to provide this functionality with very little impact on end-to-end latency. We'll show you a sample scenario that demonstrates this functionality.


The On Demand Router

The ODR is a proxy built atop the runtime of the WebSphere Network Deployment proxy server, which provides a superset of the function provided by the WebSphere HTTP server plug-in. The ODR provides a centralized point for effecting operational policies, such as service policies that describe performance and prioritization goals. Topologically, the ODR fronts WebSphere Extended Deployment clusters and becomes the primary entry point into clusters. Clients send their HTTP requests to the ODR, which in turn forwards the requests to the appropriate WebSphere cluster.

The ODR may buffer requests in order to favor those with higher priority and more stringent performance goals. It may also drop requests altogether or respond with a cached result or error message. The WebSphere XD cluster may determine that additional node group resources are required to service a particular application. The ODR can load balance requests, as well as respect predetermined server affinity (session and partition). Features of the ODR include:

  • URI-based request mapping
  • Request classification
  • Request prioritization using the autonomic request flow manager (ARFM)
  • Request queuing
  • Load balancing of requests using either weighted least outstanding requests or weighted round robin algorithms
  • Dynamic routing to multiple WebSphere backend cells and clusters
  • HTTP session affinity
  • SSL ID affinity
  • WPF partition affinity

To increase availability and scaling, you can use multiple ODRs to simultaneously service the same set of clusters. Because they are stateless, each ODR can operate correctly without communicating directly with peer ODRs. In this case, the typical configuration is to load balance the client request flow to the ODRs using an IP sprayer. This is only possible because each ODR is capable of correctly servicing any received request.

The ODR leverages intricate knowledge of back-end WebSphere XD servers to better route, queue, and load balance requests. It does this through a messaging infrastructure called on demand configuration (ODC). The ODC component is a publication mechanism for disseminating cluster state among WebSphere Extended Deployment nodes. It enables the ODR to learn of applications installed on back-end servers with their appropriate metadata; for example, URI context root. The ODR also learns of routing rules that indicate, beyond URI, how requests are mapped to policies. These rules can be used to map requests to individual application endpoints, including servers that are not even WebSphere-based.

Like the HTTP server plug-in, the ODR respects session affinity for routing requests. After an HTTP session is established on a server, subsequent requests for the same session are routed to the original server, thereby maintaining session semantics. The ODR likewise supports partition affinity, where requests for particular portions of data are routed to the same server within a cluster. This increases cache and batch effectiveness.

How the ODR classifies requests

In the ODR, incoming requests can be mapped to a particular routing or service policy based on HTTP criteria. Following are some of the HTTP fields that are valid for WebSphere XD V6.0.1:

  • URL
  • GET variables
  • Header variables
  • Cookie header variables
  • MIME Types
  • HTTP method
  • Client IP(v4/v6) address
  • Server IP(v4/v6) address
  • Port
  • Protocol
  • Virtual Portal
  • SOAPAction header

WebSphere DataPower SOA Appliances

The WebSphere DataPower SOA Appliances family consists of three appliance form-factors with increasing model numbers: XA35, XS40, and the XI50. Appliances with higher model numbers include the the lower-numbered appliances. All appliances share a common engine, as well as management and monitoring interfaces. The basic management mechanism of DataPower is a purpose-built command line interpreter (CLI) that enables users to perform administrative actions on the box. It is very similar to the IOS CLI provided by Cisco. The appliances provide console and SSH access to this CLI. A Web GUI provides an interface to all WebSphere DataPower appliances. All management actions that can be done via the CLI can also be performed from the Web GUI. In the next section, you'll see an example of the building and processing flow using the Web GUI.

WebSphere DataPower appliances also support a SOAP management interface that enables programmatic access to appliance configuration. An Eclipse plug-in, included with the appliances, leverages this interface and provides IDE support. In addition, all WebSphere DataPower appliances come with support for monitoring, event logging and alerting. The appliances support a wide variety of event levels and criteria (IP, TCP, HTTP, XML, SOAP), and output can be directed to a number of targets including file systems, SNMP, SOAP endpoints, Common Base Event, the IBM Tivoli® Composite Application Manager for SOA, the console, or a system cache.

The most basic WebSphere DataPower appliance, the XA35, delivers a number of routing and transformation features. It supports routing based on IP, TCP, HTTP, XML and SOAP criteria. Routing tables can be defined (or queried) to determine the appropriate routing action. Load balancing algorithms such as least-used and round-robin are also available. Additionally, the XA35 can throttle or adjust request rates based on routing criteria to employ traffic shaping. From a transformation perspective, the XA35 provides a high-performance XSLT processing engine. Built on the underlying premise of all WebSphere DataPower appliances, purposed hardware converts one XML schema to another at wire speed. XSLT 1.0 and XPath 1.0 support (with some 2.0 support) is available. The XA35 appliance can use and apply internal as well as external schema.

Building on the XA35, the XS40 adds security capabilities by enabling XML encryption and XML digital signature processing. Supporting Web Services Security (WSS) 1.0, WS-Trust, and WS-SecureConversation, the XS40 is the foundation upon which Web Services Security can be deployed in an enterprise. It supports authorization (or access) checking to offboard entities, such as the Tivoli Access Manager, RSA, Netegrity, Oblix, and more. It provides partial support for Security Assertion Markup Language (SAML) 2.0, as well as the ability to extract and use security credentials from LDAP, RADIUS, and XKMS. But perhaps the most significant security feature of the XS40 is its firewall capability. In addition to filtering input traffic (as is done in the XA35 routing capabilities), the firewall feature of the XS40 enables XML Denial of Service protection. Used in conjunction with schema validation and well-formedness checking, the XS40 is an integral part of the network security within an enterprise.

Finally, the XI50 adds integration capabilities to the WebSphere DataPower appliance family. It enables any-to-any transformation, in which data can be received in any format over any protocol and be converted to any other format over any other protocol using WebSphere DataPower core transformation technology. Supported protocols include HTTP, HTTPS, and MQ. Formats include SOAP/XML, EDI, CICS Cobol Copybook, Corba, ISO 8583, CSV, ASN.1, ebXML, and more.


Sample scenario

In our scenario, we use the WebSphere DataPower Integration Appliance XI50 to set an HTTP header based upon the evaluation of an XPath expression.

Figure 1 shows how the WebSphere DataPower appliance proxies requests before forwarding them to the ODR. A simple servlet is deployed on the application server, which merely echoes the XML message back to the client. We use the extension functions provided by WebSphere DataPower within an XSL stylesheet to set an HTTP header according to the result of evaluating an XPath expression.

Figure 1. Logical diagram of the sample scenario
Logical diagram of the sample scenario

Listing 1 shows the stylesheet used in this scenario, which sets an HTTP header based on the amount of a bank transaction (amounts greater than or equal to $50 are high priority and less than $50 are low priority).

Listing 1. Header hint XSL stylesheet: xpathHH.xsl
<?xml version='1.0' encoding='UTF-8' ?>
<xsl:stylesheet version="1.0" 
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
	xmlns:dp="http://www.datapower.com/extensions" 
	xmlns:dpconfig="http://www.datapower.com/param/config" 
	extension-element-prefixes="dp" exclude-result-prefixes="dp dpconfig">

<xsl:output method="xml"/>
<xsl:template match="/">
  <xsl:choose>
   <xsl:when test="/bank/transaction[amount >= '50.00']">
    <dp:set-http-request-header name="'HeaderHint'" value="'hp'"/>
   </xsl:when>
   <xsl:otherwise>
    <dp:set-http-request-header name="'HeaderHint'" value="'lp'"/>
   </xsl:otherwise>
  </xsl:choose>
</xsl:template>
</xsl:stylesheet>

Configure the WebSphere DataPower Integration Appliance XI50

Note: All screen shots and configuration steps in this article use the WebSphere DataPower XI50 firmware version 3.5.0.8; other firmware versions (and appliances) may have slightly different steps, but should be very similar to those provided below.

The first step is to configure the XI50 appliance to process incoming XML requests. To do this, complete the following steps:

  1. Create a new XML firewall in the DataPower Web GUI by clicking the Services tab, then selecting New Advanced Firewall.
  2. In the firewall configuration dialog, do the following:
    • Specify XPathHeaderHint for the Firewall Name (though any name will do).
    • Select static-backend for the Firewall Type.
    • Enter the IP address and port number of the ODR in the Server Address and Server Port fields.
    • Choose XML as the Response Type and Request Type.
    • Select a unique port number in the Device Port field.
    • Click the + symbol next to the Firewall Policy list as shown in Figure 2.
    Figure 2. XML firewall configuration
    XML firewall configuration
  3. A pop-up message displays. Click OK.
  4. Click New next to the Policy Name field, then click OK.
  5. Name the new policy XPathHeaderHintPolicy (once again, any name will do), then click OK to acknowledge the new name, and click OK again to begin defining the rules for this policy.
    Figure 3. XML firewall policy configuration
    XML firewall policy configuration
  6. Double-click the = symbol to define which URLs will match this rule.
  7. In the window that appears, click the + symbol next to the Matching Rule list. Another window appears, in which we define the actual matching rule.
  8. Begin by naming the new matching rule AllURLs, then click the Matching Rule tab at the top of the window.
  9. Click Add at the bottom of the screen.
  10. In the next window, choose the url option in the Matching Type list, and specify * as the URL Match. This matches all URLs that connect to this particular XML firewall.
  11. Click Save, then click Apply, then Close.
  12. The Configure a Match Action window displays. The AllURLs matching rule should be selected. Click Done to return to the policy configuration window.
  13. Now we need to configure a Filter action to execute our XSL stylesheet against the incoming XML document. Click the Filter icon and drag it onto the rule line, then double-click on the newly placed Filter action.
  14. Click Upload to upload the XSL stylesheet to the XI50 device.
  15. In the next window, click Browse and select xpathHH.xsl, then click Upload.
  16. You'll see a message that the file was successfully uploaded. Click Continue. xpathHH.xsl now appears in the Processing Control File field.
  17. Click Done.
  18. In the policy configuration window, change the rule type from Both Directions to Client to Server, so that the HTTP header variable HeaderHint is set only on the request. The servlet running on the application server has been modified to report the value of the HTTP header variable HeaderHint in the request in an HTTP header variable called HeaderHintFromRequest. This enables our client to display the applied header hint.
  19. Click Apply next to Rule Actions. The rule displays as shown in Figure 4.
    Figure 4. New rule
    New rule
  20. Click Close at the top of the policy configuration window.
  21. The firewall configuration window displays again. The Firewall Policy list should now show XPathHeaderHintPolicy.
  22. Click Commit, then Done to return to the XI50 Control Panel.
  23. Save the changes to the device by clicking Save Config in the top right of the Control Panel.

Configure the ODR to classify traffic

Note: The following screen captures are from WebSphere Application Server 6.0.2.9 and WebSphere Extended Deployment 6.0.1.1; other versions could have slightly different steps to implement the desired functionality.

Now you need to configure the ODR to place requests with the HTTP header variable HeaderHint into different transaction classes based on the value of the variable. To accomplish this, you'll need to configure this on a per-application basis. The following steps assume you've already installed the EchoXMLServlet application and defined two service policies called hp and lp. For help with installing the application or defining the service policies, refer to the WebSphere Application Server or WebSphere Extended Deployment Information Centers.

  1. Log into the WebSphere Administration Console. Click on the Applications bar on the left frame, then select Enterprise Applications.
  2. Assuming you have already installed the EchoXMLServlet servlet, click the name of the application in the right frame to bring up the properties of the application.
  3. Click the Service Policies tab.
  4. Expand Work Classes for HTTP Requests, and click New to create a new work class for the application.
    Figure 5. EchoXMLServlet properties: Service Policies tab
    EchoXMLServlet Properties: Service Policies Tab
  5. On the configuration screen for the new work class, enter XPathHeaderHintWC for the name of the work class, and click Next.
  6. Now you need to define the memberships of the work class for the application. In the example application, there is only one module, so you can select it in the list.
  7. Only one available HTTP pattern displays, so select that, then click Add to add it as a member of the work class. The pattern displays in the Members of XPathHeaderHintWC list. Click Next, then Finish to complete the creation of the new work class.
  8. Back on the Service Policies tab, expand the newly created work class, and click Add Rule to begin creating rules to map requests to transaction classes.
  9. A new, blank rule displays. Click Rule Builder to launch the Rule Builder to help you create the desired rule.
  10. Click Add to set the conditions for classification.
  11. You'll see the Edit Rule Condition dialog, as shown in Figure 6.
    Figure 6. EchoXMLServlet properties: Edit rule condition
    EchoXMLServlet Properties: Edit rule condition
    In the Select Operand list, select Request Header Name. Specify HeaderHint for Appended value equal to. This is the name of the HTTP header variable that is being set by the XI50 Integration appliance. Select Equals (=) in the Operator field, and specify hp for the Value (our XSL stylesheet sets the header variable to hp for high priority requests). Click OK.
  12. In the Rule Builder, select the transaction class that corresponds to the desired service policy (hp), and click OK.
  13. In Figure 7, you can see that the rule has been created. Incoming requests to the ODR to the EchoXMLServlet application URL (/echo/EchoXMLServlet) will be inspected for an HTTP header variable named HeaderHint. If that variable is equal to the string hp, the request will be classified to the transaction class Default_TC_hp.
    Figure 7. EchoXMLServlet properties: Service Policies tab with rule
    EchoXMLServlet Properties: Service Policies Tab With Rule
  14. Repeat these steps to add a new rule to classify requests to the Default_TC_lp transaction class if the HeaderHint variable is equal to the string lp.
  15. Finally, you'll see that requests that have the HTTP header variable HeaderHint unset or set to any value other than hp or lp will be mapped to the Default_TC transaction class, which corresponds to the default service policy.
  16. Click OK at the top of the right frame, then click Save in order to synchronize your changes with all the nodes in the cell.

Test the implementation

On the client machine, you can test by posting two different XML files to the EchoXMLServlet application using the GNU wget application. The first XML file is a bank transaction that deposits $49.00 into an account. The WebSphere DataPower appliance should set the HTTP header variable HeaderHint to lp since the dollar amount is less than $50.00. The XML document, deposit49.xml, is shown in Listing 2:

Listing 2. Sample bank transaction: deposit49.xml
<?xml version="1.0"?>
<bank>
    <account type="checking">
        <name>Joe Schmoe</name>
        <number>12345678</number>
    </account>
    <transaction type="deposit">
        <amount>49.00</amount>
        <destination>87654321</destination>
    </transaction>
</bank>

The second XML file is a bank transaction that deposits $51.00 into an account. The WebSphere DataPower appliance should set the HTTP header variable HeaderHint to hp since the dollar amount is greater than $50.00. The XML document, deposit51.xml, is shown in Listing 3.

Listing 3. Sample bank transaction: deposit51.xml
<?xml version="1.0"?>
<bank>
    <account type="checking">
        <name>Joe Schmoe</name>
        <number>12345678</number>
    </account>
    <transaction type="deposit">
        <amount>51.00</amount>
        <destination>87654321</destination>
    </transaction>
</bank>

Results

Now use the wget application to post each XML file to the WebSphere DataPower appliance. First, post deposit49.xml. In the output in Listing 4 (in bold), you can see that the value of the HeaderHint HTTP header variable was set to lp when it was delivered to the EchoXMLServlet application.

Listing 4: Posting deposit49.xml to EchoXMLServlet application
nep335a:~/headerHints # wget -S --post-file=deposit49.xml 
http://xi50b:2048/echo/EchoXMLServlet
--10:32:41--  http://xi50b:2048/echo/EchoXMLServlet
           => `EchoXMLServlet'
Resolving xi50b... 100.100.100.111
Connecting to xi50b[100.100.100.111]:2048... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Content-Type: text/xml
 3 Content-Language: en-US
 4 Server: On-Demand Router/1.0
 5 Date: Tue, 18 Apr 2006 14:33:11 GMT
 6 HeaderHintFromRequest: lp
 7 Via: 1.1 headerHintXPath
 8 Warning: 214 headerHintXPath DataPower Transformation Applied
 9 Connection: Keep-Alive
10 Content-Length: 263

100%[====================================>] 263           --.--K/s

10:32:50 (2.51 MB/s) - `EchoXMLServlet' saved [263/263]

Next post deposit51.xml. You can see in the output in Listing 5 (in bold) that the value of the HeaderHint HTTP Header variable was set to hp when it was delivered to the EchoXMLServlet application.

Listing 5: Posting deposit51.xml to EchoXMLServlet application
nep335a:~/headerHints # wget -S --post-file=deposit51.xml
http://xi50b:2048/echo/EchoXMLServlet
--10:32:50--  http://xi50b:2048/echo/EchoXMLServlet
           => `EchoXMLServlet'
Resolving xi50b... 100.100.100.111
Connecting to xi50b[100.100.100.111]:2048... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Content-Type: text/xml
 3 Content-Language: en-US
 4 Server: On-Demand Router/1.0
 5 Date: Tue, 18 Apr 2006 14:33:20 GMT
 6 HeaderHintFromRequest: hp
 7 Via: 1.1 headerHintXPath
 8 Warning: 214 headerHintXPath DataPower Transformation Applied
 9 Connection: Keep-Alive
10 Content-Length: 263

100%[====================================>] 263           --.--K/s

10:32:50 (2.51 MB/s) - `EchoXMLServlet' saved [263/263]

The requests have been assigned the correct values of the HTTP header variable HeaderHint based on the amount of the bank transaction. The ODR uses the HTTP header values to map the requests to the appropriate service policies.


Summary

This paper showed you how to use the WebSphere DataPower SOA Appliances suite together with the WebSphere Extended Deployment On Demand Router to enable XML-based classification of requests. The article gave you a brief review of the ODR, as well as an overview of WebSphere DataPower appliances. The article walked you through a sample scenario that leveraged the efficient and extensible XML processing capabilities of the WebSphere DataPower appliances to provide HTTP header hints to the ODR for classifying traffic based on application content.


Download

DescriptionNameSize
stylesheet, servlet, and sample XML filesxpathHH.zip3KB

Resources

Learn

Get products and technologies

  • wget: Download a copy of the GNU tool , a command line HTTP/HTTPS/FTP tool.
  • Build your next development project with IBM trial software , available for download directly from developerWorks.

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, XML, SOA and web services
ArticleID=146809
ArticleTitle=Enable XML awareness in WebSphere Extended Deployment with WebSphere DataPower SOA Appliances
publish-date=07192006