Do one thing and do it well….
This is the part of the ESB market where
it becomes more and more unclear, if the ESB starts including process and state
management then its gone far beyond the concept of a “bus” and more
into the application space. I’d push for a model that says that the ESB
concentrates on being the best as a bus (or to use Neil Ward-Dutton’s
phrase “a piece of string and two tin cans) rather than drifting into
process and state. This gives the ESB enough challenges, service lifecycle
management, service versioning etc, without then adding other functionality. The
JBI model of then adding capabilities to a bus would help in adding in such
elements as state and process without adding specific complexity to the bus
itself.
Of course when I BUY an ESB Product I’d
like to see everything in the box, but conceptually (and logically) I’d
like to see them separated within the box.
Steve
From:
Ash Parikh [mailto:ash@rainingdata.com]
Sent: 07 December 2005 18:10
To: 'Duane Nickull'
Cc: Jones, Steve G;
marchadr@wellsfargo.com; Bisketa@agedwards.com;
soa-blueprints@lists.oasis-open.org
Subject: 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.
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
ash@rainingdata.com - Email
Co-Chair: SDForum Web
services SIG
Founding Member: OASIS SOA
Blueprints TC
From:
Duane Nickull [mailto:dnickull@adobe.com]
Sent: Wednesday, December 07, 2005
9:15 AM
To: Jones, Steve G;
marchadr@wellsfargo.com; Bisketa@agedwards.com;
soa-blueprints@lists.oasis-open.org
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
From:
Jones, Steve G [mailto:steve.g.jones@capgemini.com]
Sent: Wednesday, December 07, 2005
1:21 AM
To: marchadr@wellsfargo.com;
Bisketa@agedwards.com; soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] The
Myth of ESB... is it a blueprint or a pattern...
From:
marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com]
Sent: 06 December 2005 17:04
To: Jones, Steve G;
Bisketa@agedwards.com; soa-blueprints@lists.oasis-open.org
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.
-----Original Message-----
From: Jones, Steve G
[mailto:steve.g.jones@capgemini.com]
Sent: Tuesday, December 06, 2005
1:16 AM
To: Biske, Todd; Marchant, Dan R.;
soa-blueprints@lists.oasis-open.org
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:Bisketa@agedwards.com]
Sent: 06 December 2005 04:53
To: marchadr@wellsfargo.com;
Jones, Steve G; soa-blueprints@lists.oasis-open.org
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: marchadr@wellsfargo.com
To: steve.g.jones@capgemini.com; soa-blueprints@lists.oasis-open.org
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:steve.g.jones@capgemini.com]
Sent: Monday, December 05, 2005 3:33 PM
To: soa-blueprints@lists.oasis-open.org
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:steve.g.jones@capgemini.com>
steve.g.jones@capgemini.com
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.
|
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.
|
|