I actually don't think the issue is the JMS-centricity of some products as Eric implies. It definitely contributes to the controversy, but I wouldn't say it's the main issue. As an end user working primarily on the infrastructure side of things, I've had to give a lot of time and thought to this space. I've actually brought it down to one major point. Do you want the space in the middle to be the domain of developers or the domain of operations? On the one hand, we have flexibility. Flexibility will require some more skill in getting the product do what you want it to do. This typically will fall to the development staff. For example, an application server is a very flexible product. On the other end of the spectrum are the niche needs in the middle: routing, security, etc. These are configure-and-go black boxes that can be completely handled by the operations staff.
For at least the near term, companies will exist that have needs across the whole spectrum. Only time will tell what winds up defining the product space that comprises the SOA infrastructure. Eventually, the common needs will come out, and the product space will converge. Personally, the thing that I find the most interesting going on in this space is the open source efforts. The reason for this is that you now have open source products competing against appliances (and closed source), rather than against closed source products. I'm not sure how it will turn out, but it's fun to watch. -tb On Mar 7, 2006, at 3:21 PM, Awel Dico wrote: > Hi Eric; > > It is a good observation as to how the vendors are approaching the > ESB product implementation. That diversity may be positive for the > users - choose what best fit to their situation. The reality from > your customers (users) perspective is different though. Many > enterprises do not just go and buy those "ESB products". They look > at the ESB capabilities as a pattern first - at least from the point > of view of the enterprise I work for. With clear understanding of > the capabilities, they map those capabilities with the SOA > infrastructure requirement. This is important because you may not > need ESB at all (XML appliances may do the job); or it is something > that you need right away, or it may be something for the future. The > enterprise architecture has to come up with the SOA technology > infrastructure reference architecture accordingly. Based on the > understanding of the capabilities required and enterprise > architectural guidelines, they start to evaluate ESB products - may > take them for a test drive (Proof-of-concept type). The point I am > trying to make here is that it is not an issue or controversial from > the users perspective. It may be an issue from vendor's perspective. > > Regards, > Dico > >> 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. > > > --- In [email protected], Eric > Newcomer <[EMAIL PROTECTED]> wrote: >> >> 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 > > > > > > > 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/
