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