In
addition to this it may be a good idea to define what a bus really should do at
a practical level.
This
may be a realization of a blueprint in my mind than an actual blueprint. A bus
is an enabling technology unless people think it is an
approach?
2
cents.
-
Dan
-----Original Message-----
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.
