Just thought I’d outline my current thinking towards which tests I’m going to prepare to write at the WebSphere Services Technical Conference 2008:

1. 284 - IBM WebSphere DataPower SOA Appliances Firmware V3.6.0
2. 093 - IBM WebSphere Process Server V6.0, System Administration
3. 252/253 - IBM WebSphere Application Server Network Deployment V6.0/V6.1 Core Administration
4. 664 - SOA Fundamentals
5. 807 - Web Services Development for IBM WebSphere Application Server V6.1
6. 735 - Developing Applications with IBM Lotus Sametime 7.5

284: Top priority for me as I foresee a lot of opportunity in this space and a potential skill gap that I could fill.

093: Sweet revenge for failing this last year.

252/253: WAS 6.1 server is the latestet even though most of my experience is on WAS 6.0. So it will be a game time decision over which one I choose.

664: This is a prerequisite to becoming a “IBM Certified Administrator for SOA Solutions” (664, 093 & 252/253 prereq).

807: Leverage all the experience I have with WSDL and XSD into a certification.

735: Before I left IBM, I wrote a few fun utility plugins for SameTime 7.5. The first would just display the last message received into a text box. I used to be involved in group chats and didn’t want to give focus to the window but still wanted to read what was being said. The second (and far more fun) was the “Early Warning System”, a plug in that could detect when someone had opened a new chat window with you but hadn’t yet started typing. It could give you a chance to either surprise them with a “hi”, or for the more devious, jump off line and plead ignorance. Alas, I wrote them both at IBM so they’re IBM property. If you are an IBMer and interested in either I can direct you to someone internal who has them.

Related Posts

• IBM Certification Tests
• Passed Certification Test 284: IBM WebSphere DataPower SOA Appliances Firmware V3.6.0
• IBM Certification Tests 253, 142 & 664
• Impact 2008: Free Certification Testing
• Steve Mills Responds to My SOA Jam Idea about ESB

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.

Related Posts

• WebSphere DataPower vs WebSphere Enterprise Service Bus
• WB552: Random DataPower Thoughts Part 12
• Make SOA real with IBM WebSphere Enterprise Service Bus and IBM WebSphere DataPower SOA Appliances
• IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting Started
• WB552: Random DataPower Thoughts Part 9