[OWL-S]: Proposal for 3 new control constructs

[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