Hey Steve, Here is what I found regarding the characteristics of ESB: http://en.wikipedia.org/wiki/Enterprise_Service_Bus http://www.oreilly.com/catalog/esb/
As an architectural construct, IMHO, ESB does not need to rely on technologies such as XML and Web Services. The reason for my statement is that, the way I see it, ESB is an approach to solving a problem of integration of applications developed in various languages and implemented on many platforms. However, to ease communication deciphering, IMHO, XML is used. because XML describes data and context and various other goodies XML provides. In a scenario where either XML or Web Services or SOA (!!) is used, what would an enprise do in 5-10 years. In 5-10 years, if there are better paradigms and architectures popular in the market (which probably will be), would an enterprise then strive to embrace those? In which case, when will the catch up with latest end? For the above reason, I believe architectural paradigms and mind-sets must be focussed on means of communicating with different applications in a manner that is nearly future proof. By being *nearly future proof* I mean sufficient amount of flexibility must be allowed in the architecture, in order to make room for future opportunities of change. How may one achieve that?? I dont know. And honestly, I am far down the learning ladder to even think of a way. What say? Cheers G --- In [email protected], Steve Ross-Talbot <[EMAIL PROTECTED]> 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/
