- From: David Martin <martin@ai.sri.com>
- Date: Wed, 28 Jan 2004 22:08:17 -0800
- To: public-sws-ig <public-sws-ig@w3.org>
[This is a re-post of a message I sent to the www-ws list back in October. I am re-posting it because the OWL-S Coalition recently started discussing some of these issues again. I should say there were several replies on www-ws. I meant to reply to some of the replies, but regretfully didn't get around to it. In any case, we can revisit all the relevant issues as needed here.] ----- Following up on recent messages (in particular, http://lists.w3.org/Archives/Public/www-ws/2003Sep/0111.html ), here's a proposal for 3 new constructs for OWL-S - "invoke", "accept", and "select". These constructs are simple and non-novel. (By the way, since no DAML-S coalition members responded to the message referenced above, I'll assume that we have consensus on the points made there :-). This proposal is still somewhat sketchy. I'll follow up at some point with a more precise spec with an example or two. Although I believe there are many good reasons for having these additional constructs, I will just highlight 4 points here: (1) For purposes of this discussion, I'm assuming that a process model is executable and is meant to be executed in a single execution engine, and that most service modelers will be concerned with writing 2 or more process models that will run on separate execution engines, and will synchronize and interact at various points. I'm not necessarily claiming that we should *only* support these particular assumptions, but I am claiming that it's crucial for us to support them, and support them well. Once we're explicit about these assumptions, I think it becomes clear fairly quickly that one normally wants to be explicit about whether some atomic subprocess X should be (a) executed completely locally (like a subroutine), (b) executed remotely (requested of some other execution engine), or (c) executed locally at the request of some other execution engine. These proposed constructs are intended to indicate (b) and (c) explicitly. I realize that it may also be possible to indicate these things by means of the grounding ontology and the referenced WSDL specs - but as I indicated in the earlier message, I think there are some unresolved problems with that approach. (2) More important, I think developers are going to want to make these distinctions explicit in their OWL-S code for easier comprehensibility, and it may also be extremely useful for OWL-based reasoners to have visibility into these distinctions. I think both of these points represent important requirements. (3) I accept that there may be some times when you want to specify a process model so abstractly that you prefer just to say "process X needs to get done at this point (within some larger composite process)", without specifying anything about how or where X is to be executed (as Bijan, at least, has been arguing). That is, you might not want to indicate whether it's being invoked for execution somewhere else, or executed locally, or whatever. And I think the introduction of these new constructs doesn't have to prevent that style of representation. (4) But I claim that it'll be *far* more common, in real uses, that you will already know this kind of information about process X, and you will want to make it as clear as possible. That is, most developers, most of the time, will find it useful and desirable to have this kind of information made explicit at the OWL-S process level (not just in the WSDL specs to which X is grounded). In fact, it strikes me that there will be many cases where you may want to express this info about X well before you are able to complete the grounding for X. That makes it even more important to allow for these constructs. Now, for a brief, sketchy description of these constructs. Each of these would be a new subclass of ControlConstruct (just like Sequence, Split, and all the rest). INVOKE ------ The invoke construct, used something like this: <invoke> <service resource="http://..../SomeService.owl"> </invoke> simply means "request the execution of the given atomic process-based service". The reference is to a service instance, which is important because it specifies both a process model and a grounding. For simplicity, I'm assuming here and throughout this message that the specified process model is an atomic process. Normally, this means the atomic process will be executed by some other execution engine. How to contact a particular execution engine will be given by WSDL, via grounding declarations. There are some grounding details here that still need to be worked out. One important question that arises: Should we employ a conventional means of binding arguments, that happens inside this construct? Say, something like this: <invoke> <service resource="http://..../SomeService.owl"> <binding> <input>"http://..../SomeProcess.owl#Input1"</input> <value>15</value> </binding> ... other bindings ... </invoke> I think that depends in part on the final resolution of this other, fundamental question: Is there a single source for all the inputs of an atomic process, or can there be multiple sources? Similarly for outputs? (Note that in a recent telecon, several coalition folks favored a "yes" answer to this question; noone present seemed to favor "no".) ACCEPT ------ The accept construct, something like this: <accept> <service resource="http://..../SomeService.owl"> </accept> simply means "accept an invocation request for the given atomic process-based service, execute the atomic process, and return the outputs to the requestor". The same comments as above apply regarding the reference to a service instance. SELECT ------ The select construct, something like this: <select> <accept> <service resource="http://..../SomeService.owl"> <followWith> ... other control constructs </followWith> </accept> <accept> <service resource="http://..../SomeOtherService.owl"> <followWith> ... other control constructs </followWith> </accept> ... other accept clauses ... </select> means "accept an invocation request for any of the given (atomic process-based) services (whichever request comes first), then handle that request, then do whatever follows". Cheers, David
Received on Thursday, 29 January 2004 01:09:22 UTC