Ron Schmelzer on ESBs
October 24th, 2007 | Published in integration, services | 4 Comments | Bookmark on Pinboard.in
A little over a week ago, Ron Schmelzer of ZapThink, who’s pretty well known as an expert SOA analyst, quietly snuck an interesting comment into the ESB brouhaha that developed here recently. The ESB proponents who expressed displeasure at my view of ESBs, especially those who quoted ZapThink in their defense, will want to read what Ron had to say. If you don’t feel like chasing that link, here’s what he said:
The poster (Curt) who says that ZapThink says that ESBs are an enabling technology on the road to SOA has mischaracterized our position. Speaking from ZapThink’s perspective, we don’t believe that ESBs are neither necessary nor sufficient to enable SOA. In fact, we’ve seen plenty of SOA solutions that leverage a wide variety of non-ESB infrastructure. To be as unambiguous as possible: ESB is vendor marketing spin. True, there is certainly capabilities within an ESB that *might* enable companies to produce truly loosely coupled, composite, and heterogeneous Services in an environment of continuous change, but you can just as easily build tightly-coupled, proprietary, point-to-point Service integration with ESBs. There’s nothing about an ESB that substitutes for the need to do architecture. And there’s nothing about architecture that requires the adherence to a particular technological infrastructure.
If you want to make SOA work in a heterogeneous environment, why would you want to limit yourself to one technology, one approach? You’re buying right into their strategy of locking you into a platform. That’s only good if you sell platforms. Wake up folks – architecture is YOUR responsibility, not that of some vendors hawking middleware!
So, don’t put ZapThink in the camp of the ESB bigots. We certainly are not. Implement SOA with intermediaries and REST. Why not?
October 25th, 2007 at 11:59 am (#)
Steve,
There is no single solution to implementing SOA partly because we are all learning and partly because there are many different types of enterprise integration problems to be solved and wildly different types of enterprise to solve them in. If I may quote from what I think is an excellent comment left by Jonas Ekstrom on another of your blog pieces on this subject:
“There is no single path or a single answer for the future. It’s not about losing a religion or having a religion. It’s about being part of the evolution. Religions are based on beliefs and hopes, but there is no single answer to the future, to the past or to why we’re here. You and your initiatives are just part of the natural selection. CORBA, ESB, J2EE, REST, SOAP, all of them plays a role in the presence, but none will be ultimate choice for the future….
Religions give easy answers, but there are no easy answers. Natural selection will strike again and again until we have reached the perfect SOA.”
(The full comment is at: http://steve.vinoski.net/blog/2007/10/04/the-esb-question/#comment-58)
Anybody who suggests that todays ESBs solve all problems is promoting a religon (even ESB vendors would admit that their products are not panaceas). ESBs can solve certain types of problem when used in the right way and can solve nothing if used in the wrong way. However, the reverse is also true: REST is not necessarily “perfect”, any more than ESBs are necessarily always “evil”. Therefore I am not surprised by Ron’s comments, nor disagree with them. Nor do I think that his comments undermines the concept of an ESB as a possible solution for some classes of problem.
Ronan
October 26th, 2007 at 9:42 am (#)
Ronan mentioned:
“CORBA, ESB, J2EE, REST, SOAP”
I think that maybe the above is an example of why we as a community tie ourselves up in knots. CORBA, ESB, J2EE, SOAP are all technologies or at least a collection of specifications implemented in various products (don’t think ESB is standardized as yet so maybe there aren’t specs for that).
REST does not fit that category – from where I stand it’s mostly a collection of good architectural practices (and I think it might even be accepted that we don’t always use all those good practices in a real system or we relax things a little).
One designs or architects solutions to problems – technologies be they ESB’s, CORBA etc are merely implementations of (parts of) an architectural solution. Note that one might compromise one’s architecture slightly because it’s expedient to use an off-the-shelf product. Regardless the important point is that architecture comes first not last and that seems to be missing in most discussions.
October 26th, 2007 at 3:32 pm (#)
[…] these behaviours is challenging: Architecture RIP? Possibly but a recent comment on ESB’s from Ron Schmelzer means there’s still hope. And there is at least one part of the developer […]
October 28th, 2007 at 7:38 am (#)
Ronan: “There is no single solution to implementing SOA partly because we are all learning and partly because there are many different types of enterprise integration problems to be solved and wildly different types of enterprise to solve them in.”
Not because SOA has no conceptual weight or operational definition? How can I not think SOA is a flim-flam?
“There is no single path or a single answer for the future. It’s not about losing a religion or having a religion. It’s about being part of the evolution.”
I suspect the evolutionary idea is flawed. What actually happens is rip and replace along with ambitious big works projects. If IT actually evolved, would SOA be needed conceptually?