[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] The Myth of ESB... is it a blueprint or a pattern...
We’re 2+ years into a production ESB
implementation in my line of business, so I think I can speak with some
authority on this one. Writing services has become easier, but it’s
still not easy. Having an ESB and an associated team lets us approach
services from a ‘center of excellence’ standpoint. No vendor has come up with good solutions to
the challenge of versioning services. Indeed, it’s very hard to
write XML Schemas that version well – it’s a defect of the schema
for schemas itself, not just a vendor gap (though it is that too). So,
our ESB gives us an opportunity to buffer our development teams against the
thrash in the enterprise beyond. Services are often delivered in “one
size fits all” format. An ESB is a chance for us, as one of many
lines of business, to tailor that service to our own ends, adding caching or
applying security and visibility restrictions. This goes to Steve’s
point about needing to assume that buses are >1 in number. The ESB lets us forward responsibility for
certain kinds of complexity. If an enterprise service only provides a
SOAP/HTTP interface, we can put an ESB service in front of it that does
guaranteed delivery using JMS and then let the ESB be responsible for getting
it through to the less-reliable interface. The ESB is the natural place to implement
fan-out of parallel service calls. Multithreaded programming is hard
enough that we don’t want most developers doing it. Doing this sort
of thing in the ESB lets it provide “value add” aggregating
services that the enterprise will not cover. Looking into my crystal ball, I think the
next big push in this arena will be to virtualize ESBs. Today, our ESB is
a network-addressable endpoint with SLAs and the whole shooting match. In
a heterogeneous computing environment we’ll always need that to some
extent, but it is reasonable to ask why we’d continue to incur the cost
of network indirection for the ESB when we can just co-deploy. Perhaps
with the rise of ‘utility computing’ that will just “happen”
in infrastructure and we won’t have to think about it. Eric Friedman Wells From: Jones, Steve G
[mailto:steve.g.jones@capgemini.com] A question to the group Back in the old “Enterprise Application
Integration” days the vendors pushed a model which had either a single
broker in the middle, or a bus in the middle. The common element was
always that “one” thing in the centre. We are now seeing the
same thing with ESB, the concept of a single bus (product) that rules the
enterprise. With EAI one of the biggest challenges was that product
centric view of the world which led to organisations being left with
“legacy” EAI which is as much of an issue as the applications it
was meant to make easy to access (any Monk programmers out there?). So what my strawman is to this group (and as the
Soalogic thing evolves its quite important) is that concept of bus federation
is essential to an SOA Blueprint, you must assume that there will be multiple
busses, potentially at all levels, these may use similar technology (even identical)
but the principles of federation should be the default for a well formed SOA.
Now is this a pattern or a blueprint, and if a blueprint where should it
be considered. My viewpoint is that there needs to be an official
counterpoint to the vendor view that takes a Lord of the Rings (one ESB to find
them all and in the darkness bind them) approach to delivery. The best
ESB is the one that assumes it isn’t the only thing around. Steve ___________________________________________________________ Steve Jones | Capgemini CTO, Application Development Transformation T +44 870 906 7026| 700 7026| www.capgemini.com m: steve.g.jones@capgemini.com txt: +44 (0) 7891157026 Join the Collaborative
Experience ___________________________________________________________
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]