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...


Ah yes how could I forget...

-----Original Message-----
From: John Harby [mailto:jharby@gmail.com]
Sent: Wednesday, December 07, 2005 6:56 AM
To: soa-blueprints@lists.oasis-open.org
Subject: Re: [soa-blueprints] The Myth of ESB... is it a blueprint or a
pattern...


Don't forget this one ;)

http://www.infravio.com/products/

On 12/7/05, marchadr@wellsfargo.com <marchadr@wellsfargo.com> wrote:
>
> Looks like the SOA Repository is a lot like the ESB discussions.
>
> Currently it is sold as either:
> -  is a registry with a combination of a CMS essentially.
> -  a subset to your registry to support more data around your services
> -  a caching and xml database solution for your service runtime
> -  policy management building on first point
>
> Probably would make sense to get a solid definition from someone creating
> the products.
>
> See a product on the market by Fujitsu and Software AG:
> http://www.soaworks.com/products.html
>
> Also here are a couple other links:
>
> -
> http://www.javaworld.com/javaworld/jw-06-2005/jw-0627-webservices.html
> - http://www.rainingdata.com/products/tigerlogicsoar/
> - http://www.aboveallsoftware.com/product_repository.asp
>
>
>
> -----Original Message-----
> From: Friedman, Eric D.
> Sent: Tuesday, December 06, 2005 10:21 AM
> To: 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
> 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:ash@rainingdata.com]
> Sent: Monday, December 05, 2005 7:14 PM
> To: Friedman, Eric D.; 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...
>
>
>
> 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
> ash@rainingdata.com - Email
>
> Co-Chair: SDForum Web services SIG
>
> Founding Member: OASIS SOA Blueprints TC
>
>
>
>
>
>  ________________________________
>
>
> From: Eric.D.Friedman@wellsfargo.com [mailto: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
> 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: 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]