Next in thread →
Next in month →
Re: [soa-rm-ra] Service description bits
Rex, What you are asking for is very much what I have in mind. That said, my next challenge is to figure out what to say about it and how. Choreography could be a good tie-in, and I need to get back to that also. Let's see if we can move ahead on stating the problem and then we can see whose lap we feel it best to dump it into. Ken On Oct 11, 2006, at 12:04 PM, Rex Brooks wrote: 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 ------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 smime.p7s
Next in thread →
Next in month →