A lot of posts to this group, and recent blogs by Joe McKendrick among others, have brought up the debate again about the Enterprise Service Bus.
For the most recent, see: http://blogs.zdnet.com/service-oriented/index.php?p=560 Among the questions debated here is the lifetime of the ESB product category. Some suggest that it's a temporary product category, soon to be subsumed by something else. I'm not so sure. It takes a long time for a new product category to get established. Just ask our friends at Sonic ;-). And with IBM, BEA, Oracle, Tibco, and others recently announcing they would ship an ESB the product category has definitely been validated and, I believe, established. But what is an ESB? This question does indeed continue to trouble the industry, since it still seems as if every vendor has a different definition. Several months ago I was invited to help deliver a 3 -hour tutorial on SOA and ESBs together with David Chappell of Sonic. He ended up injuring himself in a water skiing accident (which he blogged about) shortly before the tutorial date, so while the two of us collaborated on the development of the presentation a colleague of Dave's ended up physically joining me in Washington for the event. The way we split things up was: -- I did about 45 minutes on generic SOA -- Dave did about 45 minutes on generic ESB -- Each of us did about 30 minutes on our technologies, Artix and Sonic ESB, respectively (With breaks and Q&A that filled the time.) The interesting thing to me was how well the two of us could agree on the generic SOA and ESB definitions. I would say it was like 90-95%. Where we diverged was in our respective approaches to addressing the requirements of SOA infrastructure, aka our ESB products. I think up to this point Dave would agree with everything I've said. Now I will give my view. The difference is that Sonic started with its successful JMS product and added Web services support and other elements of integration software in order to create an ESB that meets SOA infrastructure requirements. We started with our patented configurable microkernel, ART, and added a Web services "personality" aka collection of plugins. The result on the one hand is JMS centric while on the other ours is a multi-communications protocol, multi data format, brokerless, hubless distributed architecture much better suited for SOA infrastructure. Unfortunately it seems like most vendors are adopting the JMS centric approach, and that is what leads to the controversy. I also wrote a bit about this in my blog: http://www.iona.com/blogs/newcomer/archives/000269.html I will try to post to this list now and then about why the distributed approach to an ESB makes more sense. Eric __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
