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:
- GET variables
- Header variables
- Cookie header variables
- MIME Types
- HTTP method
- Client IP(v4/v6) address
- Server IP(v4/v6) address
- 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.
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
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 184.108.40.206; 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:
- Create a new XML firewall in the DataPower Web GUI by clicking the Services tab, then selecting New Advanced Firewall.
- In the firewall configuration dialog, do the following:
XPathHeaderHintfor 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
- A pop-up message displays. Click OK.
- Click New next to the Policy Name field, then click OK.
- 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
- Double-click the = symbol to define which URLs will match this rule.
- 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.
- Begin by naming the new matching rule
AllURLs, then click the Matching Rule tab at the top of the window.
- Click Add at the bottom of the screen.
- 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.
- Click Save, then click Apply, then Close.
- The Configure a Match Action window displays. The
AllURLsmatching rule should be selected. Click Done to return to the policy configuration window.
- 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.
- Click Upload to upload the XSL stylesheet to the XI50 device.
- In the next window, click Browse and select xpathHH.xsl, then click Upload.
- You'll see a message that the file was successfully uploaded. Click Continue. xpathHH.xsl now appears in the Processing Control File field.
- Click Done.
- In the policy configuration window, change the rule type from Both Directions to Client to Server, so that the HTTP header variable
HeaderHintis set only on the request. The servlet running on the application server has been modified to report the value of the HTTP header variable
HeaderHintin the request in an HTTP header variable called
HeaderHintFromRequest. This enables our client to display the applied header hint.
- Click Apply next to Rule Actions. The rule displays as shown in Figure 4.
Figure 4. New rule
- Click Close at the top of the policy configuration window.
- The firewall configuration window displays again. The Firewall Policy list should now show XPathHeaderHintPolicy.
- Click Commit, then Done to return to the XI50 Control Panel.
- 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 220.127.116.11 and WebSphere Extended Deployment 18.104.22.168; 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
lp. For help with installing the application or defining the service policies, refer to the WebSphere Application Server or WebSphere Extended Deployment Information Centers.
- Log into the WebSphere Administration Console. Click on the Applications bar on the left frame, then select Enterprise Applications.
- Assuming you have already installed the
EchoXMLServletservlet, click the name of the application in the right frame to bring up the properties of the application.
- Click the Service Policies tab.
- 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
- On the configuration screen for the new work class, enter
XPathHeaderHintWCfor the name of the work class, and click Next.
- 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.
- 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.
- 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.
- A new, blank rule displays. Click Rule Builder to launch the Rule Builder to help you create the desired rule.
- Click Add to set the conditions for classification.
- You'll see the Edit Rule Condition dialog, as shown in Figure 6.
Figure 6. EchoXMLServlet properties: Edit rule condition
In the Select Operand list, select Request Header Name. Specify
HeaderHintfor 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
hpfor the Value (our XSL stylesheet sets the header variable to
hpfor high priority requests). Click OK.
- In the Rule Builder, select the transaction class that corresponds to the desired service policy (
hp), and click OK.
- In Figure 7, you can see that the rule has been created. Incoming requests to the ODR to the
EchoXMLServletapplication 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
Figure 7. EchoXMLServlet properties: Service Policies tab with rule
- Repeat these steps to add a new rule to classify requests to the
Default_TC_lptransaction class if the
HeaderHintvariable is equal to the string
- Finally, you'll see that requests that have the HTTP header variable
HeaderHintunset or set to any value other than
lpwill be mapped to the
Default_TCtransaction class, which corresponds to the default service policy.
- 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
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
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>
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
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
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.
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.
|stylesheet, servlet, and sample XML files||xpathHH.zip||3KB|
- IBM WebSphere DataPower SOA Appliances: Get detailed production information.
- WebSphere Application Server V6.0 Information Center: Get details on how to use WebSphere Application Server.
- WebSphere Extended Deployment V6.0 Information Center: Get details on how to configure WebSphere Extended Deployment.
- Using WebSphere Extended Deployment V6.0 to build an On Demand production environment: Get detailed information about the ODR and its capabilities in this IBM Redbook.
- developerWorks WebSphere Web services zone: Get all the latest information and downloads for WebSphere Web services.
- WebSphere Application Server zone: Get the latest WebSphere Application Server technical resources and information.
- developerWorks SOA and Web services zones: Get all the latest information and downloads for IBM SOA and Web services technologies.
- developerWorks technical events and Webcasts: Keep up to date with the latest events.
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.
- developerWorks blogs: Get involved in the developerWorks community.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.