Todd Biske: Outside the Box

Phil Howard of Bloor Research recently wrote a series of articles after attending IBM’s annual analyst conference. In this one, he does a comparison of an ESB-based SOA to EAI-based hub-and-spoke. It was this comparison that caused me to give some thought to why ESB is such a strange beast. It starts with the name: Enterprise Service Bus. Clearly, there are products that are marketed as an ESB that truly implement a bus. There’s also many products that are marketed, and even named, as an ESB that don’t. Perhaps they use ESB to stand for Enterprise Service Broker, but no one’s ever asked them. It would be very interesting if the products had more representative names using the ES* prefix. We could have Enterprise Service Integrator, Enterprise Service Orb, Enterprise Service Broker, Enterprise Service Hub, Enterprise Service Router, Enterprise Service Appliance, etc. That’s not the point I’m trying to make, however.

The point where we can actually have some meaningful discussion in the space, in my mind, is what truly belongs in the middle, and what belongs on the endpoints/nodes. The most controversial point of most of the ESBs for me, is when they begin to include orchestration. To me, an orchestration engine is an endpoint, not something that sits in the middle. It can act as a service provider (typically kicked off through a fire-and-forget style service request, more on service invocation styles for another blog), and certainly acts as a service consumer, in response to events occurring in the enterprise. Taking orchestration out of the picture, the question is all about what technology is at the endpoints, and what capabilities you need in the middle to best handle the communication between those endpoints. Once you know what capabilities are needed, make the call as to whether you need a bus architecture, a hub-and-spoke architecture, or a fabric/network. There are products that provide all of these approaches in a variety of form factors. One thing you can always assume, however, is that standards will win out. Heterogeneity is here to stay, and the major vendors are committed to supporting interoperable standards.

The grey area is in the transformation space, specifically in the semantic space. When it’s as simple as applying an XSL stylesheet, putting it “in the middle” makes sense. What if that semantic translation requires calls out to multiple back end systems, though? Making calls out to multiple systems and then combining the results to pass along sounds much more like either a composite service or some automated orchestration to me. Per my previous argument, this belongs on the endpoints. Simply put, there is no right answer. The beauty of IT systems is that there are many viable choices, and every one will have different contexts that may point in a different direction. The debate around ESBs, intelligent networks, etc. is often simply about moving the location where processing occurs, not introducing new processing. My advice? Take it all into account. Understand how the processing rules can change over time, who uses them, who changes them, and look at the vendor space to determine products that have the right vision and the right fit for your organization. Those products that try to define the space in a way that doesn’t match up with the viewpoint of too many consumers won’t survive. Some will find a niche will enough demand to sustain the product for a healthy amount of time, and others will find the space with the most growth potential. And then it will all change again.

One Response to “Some ESB thoughts”