Re: [service-orientated-architecture] SOA and ESBs

Wed, 28 Jun 2006 06:51:51 -0700

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
> >
> >
> >
> >
> >
>
>
>


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to