Ken,
What I have been asking for when I keep mentioning "gap analysis" is
that what we are missing in SOA is a decent service consumer
description, so that consumers who all have their own individual
requirements can, in a way similar to publishing a wsdl, publish
their requirements to make the initial selection of services or
"pre-qualified services" possible. Right now the onus is on the
consumer to make choices amongst the bewildering, and often
under-specified, service providers and while what we have is far
ahead of what we had a few years ago, with developments like Ajax in
combined server-side and client-side processing, we are always
back-filling against innovations that get a head start on us.
So what I am looking at is perhaps tasking the W3C with developing
the consumer-side equivalent of WSDL, and that is why I asked about
the W3C Choreography effort, since that is where I would start
nibbling at the ankles of the problem.
Just FYI in general, I am bringing this up because I need it in both
the Emergency Management and Health Informatics arenas, and Medical
Banking, too. Of course, I don't have the personal bandwidth to
pursue this the way it deserves.
Cheers,
Rex
At 6:37 PM -0400 10/9/06, Ken Laskey wrote:
>I've taken responsibility for service description and will hopefully
>get to revising shortly. But in case that shortly slips, here are
>some key thoughts for advance discussion.
>
>- Description is very important both for the consumer and the
>provider. This includes abilities, protocols, formats, policies,
>... and differences need to be resolved to establish an execution
>context. This is alluded to in the RM but not explored. I will
>probably expand on that here.
>
>- All interactions with a service must be based on informations
>contained in or referenced by the service description or by further
>information established during an interaction initiated solely on
>the basis of the service description. The consumer may know more
>(there is no way to guarantee a limit on knowledge) but SOA would
>say the additional information should not be used. If this
>additional information is critical (or just very useful), it should
>somehow be included in the service description.
>
>- The description must somewhere convey technical assumptions, i.e.
>the world is like this and that is why you can expect real world
>effects as described.
>
>- Is sufficiency of description that which would support automated
>use, assuming the contained information can be unambiguously
>included, understood, and used?
>
>Ken
>
>
>------------------------------------------------------------------------------------------
>
>Ken Laskey
>
>MITRE Corporation, M/S H305 phone: 703-983-7934
>
>7515 Colshire Drive fax: 703-983-1379
>
>McLean VA 22102-7508
>
>
>
>Attachment converted: Macintosh HD:smime 273.p7s ( / ) (00195E6D)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
