Should this happen inside an ESB or a SOA Repository
Eric?
Cheers!
A S H
P A R I K H
Director of Development and Technology,
EAG
Raining Data Corporation (NASDAQ: RDTA)
"Technology for Innovative
Solutions"
www.rainingdata.com
+1 (510) 673-2922 - Office
+1 (510) 372-0432 -
eFax
- Email
Co-Chair: SDForum Web
services SIG
Founding Member: OASIS SOA
Blueprints TC
From:
[mailto:]
Sent: Monday, December 05,
2005 5:10 PM
To: ;
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 Fargo Private Client
Services Architecture
From: Jones,
Steve G [mailto:]
Sent: Monday, December 05, 2005 3:33
PM
To:
Subject: [soa-blueprints] The Myth of
ESB... is it a blueprint or a pattern...
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:
txt: +44 (0) 7891157026
Join the Collaborative
Experience
___________________________________________________________
This message contains information
that may be privileged or confidential and is the property of the
Capgemini Group. It is intended only for the person to whom it is
addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message
or any part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this
message.
