Eric,
You
bring up a good point in relation to what needs to be addressed by a
blueprint.
There
is the concept of initial creation of an SOA that has different requirements
than maintainence of an SOA environment.
Maintainence of an SOA environment involves versioning other concepts
that may roll up into an overall governance approach in addition to how one may
managed multiple versions to support the N number of Service
Actors.
This
can also be a problem not only of the service support multiple versions but a
service actor supporting multiple entity versions from consumed
services.
How
does a service actor deal with entity Y with version 1 from service B and entity
Y with version 2 from service C?
Interesting problem to address.
-
Dan
-----Original Message-----
From: Friedman, Eric D.
Sent: Tuesday, December 06, 2005 10:21 AM
To:
; ;
Subject: RE: [soa-blueprints]
The Myth of ESB... is it a blueprint or a pattern...
Ash, I assume you
mean “should [versioning] happen inside an ESB or a SOA Repository?” as the
other things that are happening, like fan-out, in-flight transformation,
aggregation, filtering, etc. are all runtime “orchestration” activities that
(to my mind) belong in an ESB.
I confess to being
ignorant about SOA Repositories – will assume that’s another word for
registries, like UDDI.
Finding services is
not a problem in our environment. Building services (and consumers of
them) that upgrade gracefully is a big problem. This is so for a couple
of reasons. One is that with multiple service providers in different
business lines, it’s not unusual to get into a situation where provider A is
using version X of a common entity schema (for things like ‘account’) and
provider B is using version Y. But consumers C-M need both services (and
others besides) and they need them to work together. Provider A will
eventually upgrade to version Y, but in the interim, how do M consumers work
with N producers given entity definitions that are evolving? There is no
easy answer to this problem – short of forced synchronization of upgrades,
which is not realistic – so an ESB becomes a place to encapsulate the M*N
problem. It does many other things besides, but ensuring that you can
take the output of A and use with as input to B is very much an orchestration
activity that ESBs are positioned to address.
The other versioning
challenge lies in schema itself. Dave Orchard, of BEA, spoke
thoughtfully about this at BEAWorld a couple of months back and has a few good
articles here (http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html).
The gist of it is that XML Schema presents real challenges for a
business that wants to futureproof its SOA investment. I don’t know
whether this TC would call solutions to those challenges blueprints, patterns,
antipatterns, or best practices, but it’s difficult for me to imagine anyone
being successful with SOA without giving careful thought to these
questions. Orchard reports that the W3C group is working on fixes for
this problem in future versions of Schema, but clearly the horse is already
out of the barn on this one.
From: Ash
Parikh [mailto:]
Sent: Monday, December 05, 2005 7:14
PM
To: Friedman, Eric D.;
;
Subject: RE: [soa-blueprints] The Myth of
ESB... is it a blueprint or a pattern...
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.
