Anne, Now you have confused me a little. If MOM++ (as you put it) can be perceived as ESB, then are all MOM++ architectures ESBs??
Further, if ESB, as per their intended definition (for the lack of the right word) is for stream lining inter/intra enterprises work flow, why web services and MOM? Why not good old HTTP (REST) or RMI or RPC? Cheers G --- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > LOL! > > Spot on, Steve. > > For the most part, "ESB" is a marketing term. Sonic invented the term is > 2002 (I think -- maybe it was 2001) to describe its then new XML-enabled > messaging system. Shortly after that, Gartner picked up the term and > proclaimed that it referred to a combination of SOA and EDA (event driven > architecture) -- i.e., something that supports SOAP request/response and > MOM-oriented reliable messaging and pub/sub. At that point nearly every MOM > vendor had to have one. From that perspective, I refer to ESB as MOM++. > Products that fall in this camp include Fiorano ESB, IBM WebSphere Message > Broker, Sonic ESB, Tibco BusinessWorks, webMethods Fabric, Mule, and > ServiceMix. > > But by 2003, a bunch of other vendors hijacked the term and applied it to > their own integration products, which weren't necessarily MOM-based. > Products that fall into this category include BEA AquaLogic Service Bus, > Cape Clear ESB, IBM WebSphere ESB, IBM WebSphere Process Server, IONA Artix, > Polar Lake, Oracle ESB, Software AG crossvision, Sun SeeBeyond, and Celtix. > These systems tend to be pretty different -- the one thing in common is > integration and support of web services. > > Then there are what I categorize as pure-play mediation systems: Apache > Synapse and SOA Software Blue Titan -- not really ESBs, but certainly a > viable alternative. > > Anne > > On 6/27/06, Steve Ross-Talbot <[EMAIL PROTECTED]> wrote: > > > > So what is an ESB? > > > > Is there any sort of stable and accepted definition of what an ESB > > really is? > > > > What is the difference between a JMS vendor with some basic brokering > > ability (for message xformation and routing) > > against an ESB vendor? > > > > Having founded Spiritsoft in 1997 and having given birth to the > > SpiritArchitecture I see no differentiation between > > what I have said above and an ESB. So what is new and cool and needed > > about and ESB? > > > > Is it just marketecture or is there substance behind? > > > > Sorry for posing the questions but, oddly enough, I don't have an > > answer myself so I thought I'd ask you folks > > what you think. > > > > Looking fwd to the replies. > > > > Cheers > > > > Steve T > > > > > > On 27 Jun 2006, at 21:09, Stefan Tilkov wrote: > > > > > On Jun 27, 2006, at 5:15 PM, Eric Newcomer wrote: > > > > > > > > > > > This kind of brings up the "bottom up" vs "top down" approach > > > > debate I think, at least if I understand you correctly. > > > > > > > > > > Hi Eric - Partially, yes. > > > > > > > > > > > I would think the top-down, or WSDL first, or contract first > > > > approach is preferable but we often encounter developers who prefer > > > > the bottom up approach. > > > > > > > > Maybe there's room or need for both? > > > > > > > > > > I agree that contract-first is preferable to code-first. What was > > > referring to, though, was something different: I believe a "service" > > > is something that is semantically different from a distributed > > > objects's interface, not just a different messaging protocol. That's > > > why I'm deeply suspicious of any toolkit that "just" maps CORBA, DCOM > > > or RMI to SOAP ... > > > > > > Stefan > > > > > > > > > > > Eric > > > > > > > > ----- Original Message ---- > > > > From: Stefan Tilkov <[EMAIL PROTECTED]<stefan.tilkov%40innoq.com> > > > > > > > To: [email protected]<service-orientated-architecture%40yahoogroups.com> > > > > Sent: Tuesday, June 27, 2006 7:44:33 AM > > > > Subject: Re: [service-orientated-architecture] SOA and ESBs > > > > > > > > On Jun 27, 2006, at 1:08 PM, Stefan Tilkov wrote: > > > > > > > > > Anything that promises to turn local or remote objects or > > > > > component interfaces is most likely going to introduce more > > > trouble > > > > > than it's worth. > > > > > > > > That was supposed to be "Anything that promises to turn local or > > > > remote objects or component interfaces *into 'services' > > > > automatically* is most likely going to introduce more trouble than > > > > it's worth." > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
