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]com>
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 <stefan.tilkov@innoq.com>
> > >> > > To: service-orientated-architecture@yahoogroups.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
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
