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 🙂
Interesting post and analysis of a datapower. Have you looked at all at the Intel SOA Expressway? I saw the activity this week and my understanding is it is based off technology from a former competitor of Datapower. Was interested to hear what you thought.
Hi Albert,
All my experiences come from IBM products because I have access to them via IBM PartnerWorld to play around with. Unfortunately, this means I don’t get exposure to any non-IBM products that compete in the same space, so I don’t have any opinion on Intel’s offering.
These network ‘xml devices’ really interest me. I’m curious to see how they continue to be marketed and how they will contain feature creep to retain performance.
I have been following Joe Natoli’s blog from intel. (http://softwareblogs.intel.com/2008/08/11/does-a-soa-soft-appliance-an-esb/). Interesting question to consider – if you can get the equivalent or better performance that comes from IBM’s hardware appliance(as listed above) but on general purpose x86 platform, AND, you get the flexibility to address some of the weak points listed – would hardware appliance still be preferred? Would be interested to know the answer.
Here we have DataPower as the entry point for the EAI layer. One of the products sitting behind it is Message Broker.
Now, I understand DataPower’s capabilities and what Message Broker can do. But I’m not 100% sure where WESB or Process Server fits. Could you elaborate on that? Thanks.
First things first: IBM is selling a topology not a general purpose platform for ESB. Its not in their interest to sell you the ideal platform running on any architecture.
WebsphereESB is a SCA Activation inside an EJB. So the threading model and all resource contention are within the constructs of an EJB.
Websphere ESB seems to have a hard problem correlating Async to Sync requests. Protocols are limited.
DataPower seems to have better management with less Protocols, and higher Low Latency Model (LLM) performance.
Its hard to find a polished SEDA scheduler based model for ESB. Although if your willing to put up with a Beta capability in managing your App, or writing your own JMX controllers there are plenty.
Wikipedia has a good review of all of them.
I question this comment – You don’t have a nice candy-coated UI like WebSphere Integration Developer…
You can use eclipse or xmlspy w/ plugin to develop and unit-test your xslt’s AND you get the web-gui interface for configuring your policies… my $0.02 🙂