Had a look. All I can say is that this is amongst the worst definitions of anything that I have seen for a long time. It is a unification of all possible ESB implementations. It is inconsistent and impractical for pretty well anything and anyone.
Sorry but read it and see for your self. (standards-based ha ha ha). Cheers Steve T On 30 Jun 2006, at 01:19, Stanley Stanev wrote: > you can find ESB characteristics, benefits, disadvantages and more at > > http://en.wikipedia.org/wiki/Enterprise_Service_Bus > > hope this helps, > Stanley Stanev > > Steve Ross-Talbot wrote: >> Stefan, >> >> as a default explanation of what an ESB might do for you it falls >> somewhat short of the mark in trying to >> explain the shape of an ESB. What I am after, and maybe it is not >> possible, is a definition of the key >> standard interfaces that we feel an ESB must exhibit and what the key >> behavioral contracts it must >> exhibit. If we can establish these, hence my definitions below, then >> we >> have a yard stick by which we >> can measure any vendor claiming to have an ESB. >> >> If we think of it like a RDBMS for a moment, we have SEQUEL and we >> all >> know how to use it. >> We know more or less how the schemas are created too because that is >> also in SEQUEL. >> So we can populate a specific vendors RDBMS offering and manipulate >> it >> to see how it compares >> to another. >> >> I want to be able to do something similar with ESB's if they are to >> be >> useful at all. The last thing I want >> is total vendor lockin. So I need to be clear, as I think the >> industry >> does, on what the key interfaces >> are for an ESB. Then I can compare and choose one over the other. The >> decision to choose one over >> the other may boil down to some obscure value added feature that they >> support and only they support. >> But at least I can choose from a point of knowledge. >> >> Cheers >> >> Steve T >> >> On 28 Jun 2006, at 21:20, Stefan Tilkov wrote: >> >> > 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/
