From: Steve Ross-Talbot <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, June 28, 2006 11:09:00 AM
Subject: Re: [service-orientated-architecture] SOA and ESBs
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
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>
>
>
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
