Re: Question about DAML-S Execution

The statement about exception processing in WSFL below (second paragraph in
the original mail) was not accurate. WSFL activities have WSDL signatures.
In particular, this means that they can throw faults. Currently in WSFL the
standard way to process a fault resulting from the execution of an activity
is to have a control link leading to the fault processing code, which is
triggered only when the fault is generated (in WSFL syntax, you use the
"result" and "transitionCondition" attributes to control this). There is
thus no default processing model for exceptions/faults. The mechanism that
Anupriya mentions (repeat until exit condition is true) is the way WSFL
allows iterative processing within a single activity. Exit conditions are
thus coded not for the purpose of doing exception processing, but to
achieve iterative behavior. That is certainly not the best way to handle
exceptions.

Regards.



Sheila McIlraith <sam@KSL.Stanford.EDU>@w3.org on 07/26/2001 02:16:45 PM

Sent by:  www-ws-request@w3.org


To:   anupriya+@cs.cmu.edu, daml-process@bbn.com
cc:   www-ws@w3.org
Subject:  Question about DAML-S Execution



Hi Anupriya


> Hello all,
>
> In trying to understand the semantics of the process model constructs, I
> came up against the following question:
>
> If I have a process
>
> A -> B -> C
>
> that is a Sequence [A, B, C] with
>
> B: Split+Join [B1, B2, B3]
>
> Do the three processes B1, B2, B3 join back at A, the process which
> "called" them or at C, the next process? Assuming it is C, which seems
> more correct, is the join condition at C an AND condition, such that all
> Bi processes must successfully finish execution, for C to begin
> execution?

They join back at C.

>
> 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,
> Anupriya.
>


Regards,
Sheila

Received on Thursday, 26 July 2001 15:31:41 UTC