I’ve started reading up on DataPower in anticipation of writing the certification test in May (At the WebSphere Services Technical Conference 2008). Two of the usage scenarios that have caught my interest are ‘Proxy’ and ‘Co-processor’.
In Proxy, DataPower acts as proxy to your web service . The scenario given is a website that uses Cascading Style Sheets to create a website. In the non-DataPower scenario, your application server creates the XML, applies the style sheet to it and then sends it back to the client. Apparently, this is a very CPU-intensive task. When the box is introduced, the application server sends the XML content back to DataPower, and it applies the style sheet and sends the response to the client. The article described that DataPower was able to perform the transform seven times faster (7s to 1s) than the application server. The application server’s CPU usage already decreased substantially. Seems like a shoe-in product for style sheet heavy web sites. You decrease the load on the app server, making it able to do more business work and the load on the datapower box is also negligible. You could send transforms at it at ‘wire-speed’ (100Mb/s in and 100Mb/s out). Wow.
In the second scenario, the DataPower box is called by the application server to perform transformations on demand. Say a business process requires the invocation and transformation of three web service calls. Without the box, the app server does the conversion from Generic Business Object (GBO) to Application Specific Business Object (ASBO). It then invokes the endpoints, gets the resultant data and applies more transformations to create the final composed output. Depending on the size of the objects, your server could be spending a ton of time transforming data. With the DataPower box, you make WebServices calls to it to convert from GBO to ASBO, invoke the service and convert the ASBO response into the GBO response.
The very neat part of the co-processing solution is that your integration developer never needs to leave the ‘GBO’ view of the data. This makes the actual integration solution much easier to understand, and keeps the data at a generic level that most people in the company could understand.
The DataPower core business case is that they view data transformations as a commodity. It’s a commodity that shouldn’t be running on your expensive application server, mixing business logic with transformation logic. They think that your application server should spend it’s time providing business services and less time compiling stylesheets. It makes sense to me. You buy a single datapower box and it will probably be able to serve all your transformations from all your systems. You lower the cost of ownership and server maintenance (less servers) while increasing your transaction throughput (via the CPU time not spent transforming) and overall response times (DataPower is just faster than an app server).
Win-Win. Cool product.
We have a box that I can access in Perficient, so I should be able to provide some hands-on numbers once I get to that stage.
