Putting my moderator's hat on: Hmmm. That wasn't so much billboarding as a gentle but deadly sales pitch. I like the assumptive (how could he possibly say anything but "yes") close at the end. Ever thought of moving into sales, Eric???
Have fun! Gervas ----- Original Message ----- From: "Eric Newcomer" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, March 08, 2006 3:35 PM Subject: Re: [service-orientated-architecture] Re: SOA Infrastructure > 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 > > > > > > 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/
