Hi Awel, I would agree 100% with what you are saying, and I often tell our customers (and anyone else who might be attending one of my talks, such as the one next week at the InfoWorld forum in San Fran) that it is vitally important to start with the design and the architecture and make the technology choice later.
Especially if you are doing SOA it's important to do the design first and then see what technology maps best. We do not suggest anything different. We are also very happy to identify the areas where we can contribute to any such architecture, such as service enabling legacy applications, or abstracting the messaging layer, if those are important aspects of the architecture (as they are for some of our customers). If we don't fit, that's ok too. We are not trying to force ourselves into places that don't make sense. But we do believe strongly that our technology is good, proven in large scale demanding applications and it can be helpful. Not in every case of course but in many. So I think we are in agreement? Thanks, Eric --- Awel Dico <[EMAIL PROTECTED]> 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 > > > > > > > > > > __________________________________________________ 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/
