Yesterday, I blathered on about how great DataPower would be for usage in WebSphere Process Server. Your developer would be able to stay completely inside the Generic Business Object (GBO) data view while leveraging DataPower’s awesome ability to transform efficiently. Very neat indeed.
An interesting is scenario where DataPower IS the ESB. No WebSphere Process Server, No WebSphere Enterprise Service Bus. Do it all inside the appliance. How can this be done? Well DataPower possesses all the major services that are required in order to implement an integration: Routing, Transformation/Normalization, Validation, Authentication, Logging and protocol bridging.
- Routing: A single request can cause multiple endpoints invocations
- DataPower provides variables that span the context of a Request/Response
- Currently datapower does them in serial but I hear that parallel invocations may be supported.
- Transformation/Normalization: As we all know, the XSLT abilities of the product
- Validation: Again, a built-in feature of Datapower to validate SOAP envelops and also against XSD schema
- Authentication: DataPower can integrate with Tivoli Access Manager (TAM) and Tivoli Federated Identity Manager (TFIM)
- Logging: Datapower can write events to it’s own logs, or even emit Common BaseEvents (CBE)
- Protocol Bridging: Datapower supports MQ, SIBus (WebSphere Default Messaging Provider) and Web Services (along with some pure TCP protocols)
If you gave me a system that can just do this, I can provide you an Enterprise Service Bus that’s pretty damn good. 99% of the time in your system will be spent waiting on web service responses, rather than bottlenecked inside of your application service. With the appliance, I get both the ‘server hardware’ and the ‘application server’ in a single box for a cost thats substantially less than a license for ESB, server hardware to support it and administrators to maintain it.
Now, if I look at the functionality of WebSphere Enterprise Service Bus, I notice a lot of the same constructs.
- Routing: Mediation Flow Component*, Imports/Exports
- Transformation/Normalization: Also done via XSLT (in v6.0.2) + various primitives
- Validation: Built into some primitives.
- Authentication: Leverages all the capabilities of WebSphere
- Logging: WebSphere tracing, CBE Emittal
- Protocol Bridging: MQ, MQ/JMS, SOAP/HTTP, SOAP/JMS, HTTP (v6.1)
* Mediation Flow Components are great for mapping a single request to a single response, but they fall apart when you want to invoke multiple endpoints and compose a new service from them.
I’m hard pressed to find a ton of scenarios where I can recommend WESB to a customer with no plans to ‘move up’ to Process Server. Scenarios exist, but I’m trying to take the view of the most common constructs in an integration. Process Server is relatively safe, you’ll still need it for Human Tasks, Long running BPEL, State machines etc. So I see the market for that product alive and well.
Of course, there are trade offs to using DataPower as your ESB. It doesn’t integrate with WebSphere Adapters. It doesn’t participate in a dual phase (XA) transaction. You have to be an XSLT guru. You don’t have a nice candy-coated UI like WebSphere Integration Developer. If you are a mid-size company looking to get your bang for a buck, you may not even miss those features.
In summary: I still like what I see with DataPower 🙂