[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]