Comment lines: Robert Peterson: High value features of WebSphere DataPower SOA Appliances that you're probably not using

Learn about five key IBM® WebSphere® DataPower® SOA Appliance technologies that can provide greater value to your DataPower applications. For whatever reason, the features described in this article are not frequently used -- but they should be. This content is part of the IBM WebSphere Developer Technical Journal.


Robert Peterson (, WebSphere Enablement, Austin, TX, EMC

Author photoRobert R. Peterson is part of the Enablement Team under IBM Software Services for WebSphere. He travels the world implementing strategic proof of concept projects for future IBM software systems. He has published numerous technical books and papers, is a frequent conference speaker, and has filed several US Patents for enterprise systems. You can visit his website here.

developerWorks Contributing author

10 December 2008

Also available in Chinese

Overlooked high value propositions

For three years now, I’ve had the pleasure of working on several proof of concept projects that have used IBM WebSphere DataPower, primarily for banks and insurance firms. Like most middleware products, DataPower often gets implemented by users in new and interesting ways. There is, however, the “80% case” in which the product is implemented for its most common uses, which include things like:

  • Protocol bridging (such as, HTTP to WebSphere MQ).
  • Message transformation.
  • Authentication and authorization.
  • Denial of Service (DoS) attack protection.

What I’d like to share with you here are five DataPower features that -- for whatever reason -- are not commonly used, but should be.

XACML support

EXtensible Access Control Markup Language (XACML) is an open standard for defining authorization to a resource. XACML is an XML-based standard from OASIS (Organization for the Advancement of Structured Information Standards) that is useful in expressing and evaluating access control decisions on a protected system resource.

A system that supports XACML is composed of two primary components: a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). The PEP is responsible for extracting information from a request (such as from a WS-Security header of a SOAP request) and generating an XACML message to the PDP for authorization permission. The PDP either accepts or rejects the access to the backend resource. The PDP uses an XACML policy XML file to make the decision, which is written in a rules-based language defined by the XACML specification.

What makes XACML powerful is how everything is open and standard -- the communication between the PEP and PDP, as well as the XACML policy file itself. This means that if you change PDP vendors, which are often proprietary, the PEP can be left unchanged. Also, if you switch PDP implementations, you can re-use the XACML policies written for the old PDP.

Figure 1. XACML as part of DataPower’s AAA framework
Figure 1. XACML as part of DataPower’s AAA framework

DataPower supports XACML authorization as part of its standard AAA (Authenticate, Authorize, Audit) framework as a PEP; it can serve as both the PEP and PDP as well. For the PDP, the location of the XACML policy file does not need to be on-box. For example, the policy can be fetched from an HTTP URL. The recently announced IBM Tivoli® Security Policy Manager supports XACML policies, and serves as an ideal central repository for authorization policies used by DataPower. As far as the XACML standard is concerned, Tivoli Security Policy Manager is a Policy Administration Point (PAP).

DB2 V9 XQuery support

IBM DB2® V9 (codenamed DB2 Viper) has industry leading XML storage capabilities through its pureXML™ technology. DB2 V9 supports native storage of XML with its new XML type. Queries via XQuery or combined SQL/XPath queries can be used to retrieve any subset of the nodes stored in an XML type. Advanced features, such as joins across several XML queries, views with XML types, and schema validation are supported. Most importantly, the storage and querying of XML with DB2 V9 is very efficient; indexes can be set up at any level of an XML nodeset to optimize XML queries.

Figure 2. DataPower SQL action with XQuery statement
Figure 2. DataPower SQL action with XQuery statement

DataPower fully supports XQuery queries to DB2 V9. XQuery is a language for fetching data similar to SQL, but it has more sophisticated data manipulation constructs. Like XSL, XQuery includes XPath as a subset of the language. If you are familiar with XPath, XQuery queries for DB2 should follow easily.

DB2 V9 and DataPower can be a powerful combination. DB2 can be used as a repository for XML metadata used by DataPower. For example, routing metadata could be stored in DB2 to select the destination for certain messages. However, keep in mind that DB2 V9 is not a Web service repository; it is not designed to store WSDLs and Web service endpoint or versioning information. IBM WebSphere Service Registry and Repository is better suited to store this type of XML metadata.

Service-level monitoring

DataPower is often placed in high-load situations, either as a gateway servicing large volumes of client requests, or as an Enterprise Service Bus (ESB) where it services transactions for many heterogeneous systems. DataPower provides service-level monitoring (SLM), which can be implemented on either a Web Service Proxy or Multi-Protocol Gateway DataPower service.

SLM has the ability to monitor traffic and to take action if traffic patterns meet some criteria. For example, consider the case where you have a mainframe backend that can only process 300 transactions per second (TPS). SLM can be used to take action when more than 300 TPS inbound transactions are received.

As another example, suppose DataPower is a gateway for REST XML services and the customers accessing these services are billed per transaction; however, each customer has a TPS cap, such as a cap of 100 transactions per minute. DataPower can be used to ensure this cap is not exceeded or to send notifications to ensure that any overage is appropriately billed.

DataPower SLM can take action at a transaction threshold in three ways:

  • Notify: DataPower can send a notification to its logging system via any protocol supported by the device including e-mail, WebSphere MQ, and HTTP. For example, in the case where the REST customer has met its cap, DataPower could send a notification to a business process that notifies the customer.
  • Shape: DataPower can delay traffic in an attempt to keep the transaction rate at the given threshold. Take the example where the backend can only process 300 TPS. Here, shaping can be used to queue any transactions that exceed that rate.
  • Throttle: DataPower can reject transactions that exceed the given threshold.
Figure 3. Graph of service-level monitoring traffic
Figure 3. Graph of service-level monitoring traffic

The different SLM policy actions can be used together for the same transaction type. Consider the case where a particular Web service is expected to service 500 TPS. An SLM policy can be set up such that a notification is sent when 400 TPS is reached, shaping is asserted when 500 TPS is reached, and throttling activates when 600 TPS is reached.

You might wonder whether SLM can be used when multiple DataPower appliances are used behind a load balancer. SLM is supported on multiple appliances that share load with SLM peer groups. The appliances in a peer group continuously communicate with each other to ensure SLM thresholds are shared across the entire group.

IMS Connect

IMS™ Connect is a TCP/IP server that enables TCP/IP clients to exchange messages with IMS Open Transaction Manager Access (OTMA). This server provides communication links between TCP/IP clients and IMS (data stores). It supports multiple TCP/IP clients accessing multiple data store resources. IMS Connect runs on z/OS.

Figure 4. DataPower IMS Connect configuration
Figure 4. DataPower IMS Connect configuration

DataPower now includes a client for IMS Connect, offering an alternative to WebSphere MQ for communicating with IMS COBOL applications. Multi-protocol gateways offer IMS Connect as a backside URL option. A new front-side handler for IMS Connect has also been added. Thus, IMS is now a standard ESB on- and off-ramp for DataPower.

A common use case is to expose an IMS COBOL application as a Web service with DataPower. This can be implemented with a multi-protocol gateway with an HTTP front-side handler and IMS Connect backside URL. SOAP <-> COBOL non-XML transformations can be developed with IBM WebSphere Transformation eXtender to perform the message mapping within the gateway’s processing policy.

Scheduled rules

DataPower supports scheduled processing policy rules. A scheduled rule is a standard processing policy rule that is invoked periodically. To define a scheduled rule, select your XML Manager and then scroll to the last tab at the top as shown in Figure 5.

Figure 5. Scheduled processing policy rule
Figure 5. Scheduled processing policy rule

The figure shows a rule called Recurring_Rule with an invocation interval of 120 seconds. An example use case for a scheduled rule might be periodic fetching of an XML property file from a repository (such as WebSphere Service Registry and Repository) that updates global variables. A scheduled rule must have a match action that matches all incoming URLs, otherwise the rule does not get executed.


Hopefully, this information has provided you with some new ideas for utilizing WebSphere DataPower. Much of the technologies discussed here, like XACML and DB2 pureXML, are relatively new so you will hear more about them as they continue to gain momentum over time.





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

Zone=WebSphere, SOA and web services, Information Management
ArticleTitle=Comment lines: Robert Peterson: High value features of WebSphere DataPower SOA Appliances that you're probably not using