The problem I have with all of this is that it just seems like we're
putting the cart before the horse. The vendors and some analysts
(not all, especially ones who participate on this list) are telling
the potential customers, "You need an ESB." What customers should
be saying is, "I need these capabilities, and I want this group to be
responsible for them." The latter is key, because it helps
differentiate between activities that are may still be considered
programming efforts, such as orchestration/choreography, from those
that are configuration efforts, such as routing. Every organization
will have a different set of capabilities that are important, and
different operational models. Take that information and now go talk
to your vendors to decide whether you need an application server, a
message bus, an EAI tool, an ESB, a WSM product, a network appliance,
pixie dust, a roving band of trolls, or whatever it takes.
Unfortunately, that doesn't bode well for vendor marketing.
The definition of what an ESB does will be ever-changing, just as the
definition of what an application server does has been ever-
changing. It's a fruitless exercise to try to nail it down.
-tb
On Mar 28, 2007, at 10:55 AM, Steve Jones wrote:
To me you've just said that ESB = Application Development. JBI
does a good job of standardising how products are plugged together
from an IT infrastructure perspective, but I wouldn't say its an
ESB as its focus is on connecting engines and not on connecting
services.
In my view the Bus should be just that, a bus. This means that it
should do mediation (including security but excluding protocol)
and not contain any business logic, hence the reason that
choreography, rules, process and even registry are external
elements to the bus. I know that some people are pushing the idea
of the ESB as the "next" development platform, and indeed some of
these products are good development products, but there is a really
big difference between a bus architecture (proper bus, not hub and
spoke pretending to be a bus) and an application development stack.
The question really is whether the ESB is actually a bus (a
connection approach) or an application platform. If its the later
then it really isn't a bus its just an App Server with another
name. On the IBM list I'd say that 1 (if not CBR), 2 and 9 belong
in a bus the others belong in an App Server.
On 28/03/07, Bill Barr <[EMAIL PROTECTED]> wrote:
I think that JSR 208 and the JBI specification does a reasonable
enough job at providing a standard definition of an ESB. At it's
heart, the ESB provides 4, core components:
Choreographer
Mediator
Rules Engine
Service Registry
Mark Richards of IBM has distilled the 10 core capabilities of an
ESB as:
Routing
Message Transformation
Message Enhancement
Protocol Transformation
Service Mapping
Process Choreography
Transaction Management
Service Orchestration
Security
EAI is little more than peer-to-peer, real-time, ETL. At a minimum,
an ESB removes the peer-to-peer connection thereby simplifying the
management of all the connection points. Also, any enterprise is
going to need at least 2 buses, maybe more; one for business
messages and one for management messages. Those of you who live in
older cities where wastewater and sewage share the same system know
the downfalls of a uni-bus architecture every time there is a
torrential downpour! Anyhow, an ESB-based SOA and a non-ESB-based
SOA only differ in their messaging metaphors. Chappel explains this
far more eloquently than I can but, with the former, every endpoint
sends a message to the bus and with the latter, endpoints send
messages to each other.
Bill Barr
Sr. Software Architect
Expedia
3150 139th Ave. SE
Bldg. 3 #4320
Bellevue, WA 98005 USA
We're hiring! Work: 425-679-3533
Mobile: 650-533-0691
Fax: 425-679-7240
Email: [EMAIL PROTECTED]
Professional Profile
See who we know in common Want a signature like this?
