RE: Question about DAML-S Execution

Anupriya,
 your question about exceptions during execution is relevant and touches on
some earlier thoughts and discussions in the DAML-S coalition regarding
providing primitives for "success" and "failure" effects. I believe that it
would be useful to provide service providers with ways to explicitly
represent failure outcomes, since this could be useful in
the planning process for service composition. I hope we pick up this thread
in the next few coalition discussions.

Of course, the execution model should model the failure conditions and
outcomes.

 Cheers, Katia

-----Original Message-----
From: owner-daml-process@bbn.com [mailto:owner-daml-process@bbn.com]On
Behalf Of Anupriya Ankolekar
Sent: Friday, July 27, 2001 2:38 PM
To: daml-process@bbn.com; www-ws@w3.org; Sheila McIlraith
Subject: Re: Question about DAML-S Execution


Hi Sheila,

Upon further thought, I think I better understand what you meant about
exception-handling not being part of the process model. Please correct me
if I am wrong:

The process model describes a composite process assuming that each
sub-process will ultimately execute correctly and any condition that is
required for the correct execution of the process and its followers can be
specified through preconditions. Any error or exceptional condition
arising from the executional aspects of the model are not handled by the
model itself. They are lower-level things that the process model has no or
little knowledge of.

However, will the DAML-S process execution model have knowledge of the
kinds of exceptions thrown by the services and be able to handle them?
This would, as you mentioned, depend on the Grounding. I am basically
wondering about what the scope of the DAML-S process execution model will
be. While this may still need to be resolved, any thoughts/ideas on this
so far would be most welcome.

Many thanks,
Anupriya.

On 27 Jul 2001, at 7:28, Anupriya Ankolekar wrote:

> Hi Sheila,
> > > > I am wondering, in particular, what happens when an exception or a
failure
> > > occurs in one of the Bi and it does not
return or it returns an error?
> > > Would the entire process stop there and return the error? In WSFL,
the
> > > flow execution repeats the
process giving the error until it completes
> > > successfully. I am not
sure this is a good idea. It would probably be
> > > better to catch the
error and leave it up to the specifier to decide how
> > > to handle it.
The process model, at the moment, does not have an explicit
> > > way to
catch an error. Perhaps this is something we need?
> >
> >
> > The
process model only describes the control flow and data flow of the
> > composite process.  It does not talk about execution.  This is what we
> > envisaged being present in the process execution model (building on
> > the concepts in the process model and with some info from the service
> > grounding model), which we have not created yet.
> >
> > I know this doesn't solve your problem, but I hope it clarifies
> > DAML-S.
>
> Thanks for the clarification. However, I may be a little confused here,
> because I still do not see how exception-handling does not also come in
> the domain of the process model. When a sub-process returns an exception
> or a fault message, the handling of this exceptional case does involve
> both control flow and data flow, which can be (and I think needs to be)
> described within the process model. I am thinking of something like ...
>
> Process model of a service S:
> S: A -> (B: error1 -> D) -> C
 > D: E -> F
>
> General process execution model:
> If errorX, then [activity that generated error] disabled,
> [error-handling activity] active
>
> Is the above (rough) example correct or have I missed something?
>
>
> Many thanks,
> Anupriya.
>
> --
> [To unsubscribe to this list send an email to"majdart@bbn.com"
> with the following text in the BODY of the message "unsubscribe
daml-process"]


--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe
daml-process"]

Received on Friday, 27 July 2001 16:57:38 UTC