Re: Question about DAML-S Execution

Hello Francisco,

On Thu, 26 Jul 2001, Francisco Curbera wrote:

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

Thanks for the clarification. I realised that 'repeat until exit condition
is true' was meant primarily for achieving iteration (and that I
unfortunately implied otherwise). What I meant to say was that the exit
condition in WSFL allows the return code/output/exception of an activity
to be checked and the activity to be repeated in case the exception
indicates a transient problem, one that might not occur the next time
processing of the activity is attempted. An illustrative problem mentioned
in the WSFL specification is "automatic rollback due to detected
deadlock".  Certainly, for exceptions that will occur when the process is
repeated, i.e 'deterministic' exceptions, this would not be helpful.
However, this was not an appropriate example to use in my question about
DAML-S. I am sorry for the confusion caused. 

Regards,
Anupriya.


> 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 Friday, 27 July 2001 07:52:21 UTC