FWIW, my default explanation of an ESB is "something that allows you to keep your endpoints dumb by putting intelligence in your integration layer".
I never liked the ESB concept, and I've always felt the JMS requirement was only there because the initial proponents happened to be JMS vendors. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ On Jun 28, 2006, at 5:09 PM, Steve Ross-Talbot wrote: > Thanks Anne for you usual clarity on these matters. > > The reason why I posted my questions, and you are the only one to > respond, is because I am unclear when people come to > the list or we debate some point about ESB what it is we understand by > an ESB. It is impossible to have a proper discussion or > proffer advice when one is not clear about the the definitions of the > terms used. And so I was beginning to think that the chap that > posted a request for advice and guidance could not be given suitable > advice and guidance that was unambiguous. And indeed > this turns out to be the case. Until and unless we can agree, and > maybe > this is as good a forum as any, as to what we mean by an > ESB and what the fundamental interfaces and behaviors of an ESB really > should be we cannot possibly give clear advice and > guidance. > > As a starter, and this is all it is, we might say that an ESB should > exhibit: > > 1. An ability to transform an XML message stream from one XML dialect > to another using XPath, XSLT, XMLSchema and maybe > XQuery to describe the transformations required. This would make > it possible to reuse some of the "mappings" in different > implementations. > 2. An ability to move messages between distinct processes using a JMS > interface. We might add WS-RM or similar to make it > broader beyond a Java idiom. > 3. An ability to interact with a database to perform look ups and > comparisons using JDBC/ODBC. > 4. To perform one or more steps within an XA type transaction using > WS-Transactions. > > The exact configuration of processes to marshall, transform and > unmarshall information is vendor specific. It is what marks out one > vendor from another. > > How does this sound? Does it get close or do we need more or less? > > Cheers > > Steve T > > On 28 Jun 2006, at 13:20, Anne Thomas Manes 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]> > >> > > To: [email protected] > >> > > 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/
