Ah yes how could I forget...
-----Original Message-----
From: John Harby [mailto:]
Sent: Wednesday, December 07, 2005 6:56 AM
To:
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, <> 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: ; ;
>
> 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.
>
>
