Another link…
http://www.adobe.com/products/server/formmanager/main.html
-matt
From:
[mailto:]
Sent: Wednesday, December 07, 2005
9:45 AM
To:
; ;
;
Subject: RE: [soa-blueprints] The
Myth of ESB... is it a blueprint or a pattern...
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.
