Title: RE: [soa-blueprints] The Myth of ESB... is it a blueprint or a pattern...
Hi Duane,
I fully agree...an ESB is a concept or an architectural
depiction of how a loosely-coupled integration can be enabled. At the very core
of an ESB should be the functionality that enables the plug-and-play of
services, hence providing rapid integration. ESBs can then be extended in many
ways to provide not just services integration, but also messaging, process
management, state management etc. They can also be enhanced with complementary
technologies such as SOA Registries and Repositories, Ochestration Engines,
etc.
My 2
cents...
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: Duane Nickull [mailto:]
Sent: Wednesday, December 07, 2005 9:15 AM
To: Jones, Steve
G; ; ;
Subject: RE: [soa-blueprints] The
Myth of ESB... is it a blueprint or a pattern...
I’ve always though of
ESB as an architectural view. It illustrates the concept of a virtual bus
based on the fact all the services connected to it use like
protocols.
Duane
*******************************
Adobe
Systems, Inc. - http://www.adobe.com
Vice
Chair - UN/CEFACT http://www.uncefact.org/
Chair - OASIS SOA Reference Model
Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************
From: Jones,
Steve G [mailto:]
Sent: Wednesday, December 07, 2005 1:21
AM
To: ;
;
Subject: RE: [soa-blueprints] The Myth of
ESB... is it a blueprint or a pattern...
From:
[mailto:]
Sent: 06 December 2005 17:04
To: Jones, Steve G; ;
Subject: RE: [soa-blueprints] The Myth of
ESB... is it a blueprint or a pattern...
On thing I would note
is that the ideal of getting "legacy" to magically be exposed through a service
seems to be a bit counter intuitive.
They are legacy because
they don't or are not really designed for a service.
[Jones,
Steve G] Magically implies a magician… and I certainly agree that enabling
legacy systems functionality to become more service oriented is hard. But
this is a critical part of the challenge.
Slapping them into an
ESB doesn't necessarily make them a service and there needs to be much more
thought about taking "legacy" environments and turning them loose into your SOA.
Granted a lot of the legacy are based on a CICS or some sort of mainframe
environment which in some ways do have a notion of services. But the granularity
of those services is something to evaluate and re-engineer to a certain
extent.
[Jones,
Steve G] Hence the reason I’m separating Integration out as a separate effort.
Its aim is to put “lipstick on the pig” of the legacy environment to help
it look a little more service oriented. The real work is then to do the
additional effort that maps that to the business service architecture. But
if you don’t do exposure of legacy in a more SOA way then its storing up
problems for the future.
Also Policy in some
cases can be in the infrastructure with validation of service actors to a
service. A service in some sense should care to much about that unless there is
functionality differences based on a policy of a client.
[Jones,
Steve G] I’d say that Policy based ESBs is more about the Business Service Bus
side of the equation than the integration side.
Thoughts?
Dan
-----Original
Message-----
From: Jones,
Steve G [mailto:]
Sent: Tuesday, December 06, 2005 1:16
AM
To: Biske, Todd; Marchant,
Dan R.;
Subject: RE: [soa-blueprints] The Myth of
ESB... is it a blueprint or a pattern...
SOI isn’t in SOA-RM,
it aims to deal with the software side of the services and doesn’t include
composition/ /orchestration or proscribe how mediation should be
done.
I’ve been separating
(gratuitous plug for IT Week Webinar on Wednesday) the “ESB” world into two
separate elements recently both conceptually and for implementation.
There is the ESB that is really an Integration Service Bus, which is all about
turning your legacy systems into Services that can then play in the SOA
Playground. The other one is the Business Service Bus, which is about
taking the Services in the SOA Playground and adding the policy and mediation
control between those services. The ISB and BSB perform distinctly
different tasks, the BSB is about achieving IT/Business alignment and
flexibility, the ISB is about getting the legacy into a position where it can
be used as part of that alignment.
Make
sense?
Steve
From: Biske,
Todd [mailto:]
Sent: 06 December 2005 04:53
To: ; Jones, Steve
G;
Subject: RE: [soa-blueprints] The Myth of
ESB... is it a blueprint or a pattern...
I have a couple comments on this
thread. First, ESB lacks a clear definition. I'm here at the
Gartner Summit in Orlando, and that fact has been very
apparent. If we're going to deal with SOA Infrastructure as part of this
TC (I haven't reviewed the SOA-RM stuff yet, I had presumed infrastructural
patterns belonged there), I'd prefer to call it a mediation layer. That
doesn't imply any particular architecture, only that there is some logical
processing occuring between a consumer and a provider.
Second, I agree
with Dan's comment on the realization of a blueprint, versus the actual
blueprint. In either case, I think our focus should be in showing the
different blueprints, the possible realizations of those blueprints, and some
pros/cons.
-tb
-----Original Message-----
From:
To: ;
Sent: 12/5/05 5:40 PM
Subject: RE:
[soa-blueprints] The Myth of ESB... is it a blueprint or a
pattern...
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| <http://www.capgemini.com>
www.capgemini.com
m:
<mailto:>
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.
-------------------------------------------------------------------------------------
A.G.
Edwards & Sons' outgoing and incoming e-mails are
electronically
archived and subject to review and/or disclosure to someone
other
than the
recipient.
-------------------------------------------------------------------------------------
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.
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.
