OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [soa-blueprints] The Myth of ESB... is it a blueprint or a pattern...

+1 on the wiki zone for schema's (a perennial thorny issue IMO)

ESB as myth - my 'take':

A Service Bus is any communications environment that supports composable
layers of interaction that include reliable messaging, event notification,
publish-and-subscribe, transformation, routing, orchestration, security, and
more. As such it appears more as a logical label for architectural
Blueprinting IMO. Composable layers of robust interaction may be implemented
within "all-in-one" ESB, EAI, and other integration ware offerings.
Enterprises may use several integration ware offerings--from the same or
different vendors--to provide multiplatform interoperability, therefore are
there different "ESB's" within an Enterprise? Likely.
Most vendors' market-offerings for 'ESB' blur the boundaries between this
approach and older "paradigms." Many vendors provide ESB, EAI, EII, BPM,
MOM, integration broker, and Web services offerings under comprehensive
integration product families - with a consequence of creating multiple
additional layers of integration/abstraction. Hmm, I think I'm persuading
myself of the case for a blueprint (blurprint?) so as to normalise an
open-standard against vendor-specifics (give a target and 'straightforward'
interoperability is more assured)

10 cents worth :) I'll now wait for someone to explain where I missed an
obvious point ... while I have another chortle over Steve's fabulously
inventive Christmas model... :)


-----Original Message-----
From: Miko Matsumura [mailto:mmatsumura@infravio.com] 
Sent: 07 December 2005 15:25
To: Eric.D.Friedman@wellsfargo.com; ash@rainingdata.com;
steve.g.jones@capgemini.com; soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] The Myth of ESB... is it a blueprint or a

I think Ash is indicating the role of the repository as a system of record
for things like service contracts and policies. As such, you can indicate
whether service consumer A should get service version 1 and consumer B
should get version 2 and you can deal with migration and other change time
governance issues. 
The in flight stuff etc is definitely happening in an intermediary, but
perhaps one that talks to a repository. Registry from an OASIS perspective
typically means UDDI, whereas repository can mean a lot of things including
ebXML RegRep, source code control systems, databases, file systems and just
about anything under the sun. +1 on this distinction being poorly specified.
The schema problem is a very hard one, and as such quite interesting.
perhaps we should create wiki areas for this topic as well as some of the
other major topics that have been emerging...

	-----Original Message----- 
	From: Eric.D.Friedman@wellsfargo.com
	Sent: Tue 12/6/2005 10:21 AM 
	To: ash@rainingdata.com; steve.g.jones@capgemini.com;
	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
emaEvolution.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:ash@rainingdata.com] 
	Sent: Monday, December 05, 2005 7:14 PM
	To: Friedman, Eric D.; steve.g.jones@capgemini.com;
	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?




	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 <file:///\\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: Eric.D.Friedman@wellsfargo.com
	Sent: Monday, December 05, 2005 5:10 PM
	To: steve.g.jones@capgemini.com; soa-blueprints@lists.oasis-open.org
	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: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



	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 Jones | Capgemini 

	CTO, Application Development Transformation

	T +44 870 906 7026| 700 7026| www.capgemini.com

	m: steve.g.jones@capgemini.com <mailto: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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]