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.
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
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).
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
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.
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
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 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
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.
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
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.
Learn
-
IBM Press: IBM WebSphere DataPower SOA Appliance Handbook
-
Managing WebSphere DataPower SOA Appliance configurations for high availability, consistency, and control
-
Using DataPower SOA Appliances to query WebSphere Service Registry and Repository
-
IBM
developerWorks WebSphere
-
IBM
developerWorks Information Management
Discuss

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




