W3C home > Mailing lists > Public > www-ws@w3.org > July 2001

Question about DAML-S Execution

From: Sheila McIlraith <sam@KSL.Stanford.EDU>
Date: Thu, 26 Jul 2001 11:16:45 -0700 (PDT)
Message-Id: <200107261816.LAA23930@hpp-ss10-3.Stanford.EDU>
To: anupriya+@cs.cmu.edu, daml-process@bbn.com
Cc: www-ws@w3.org
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 14:16:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:38 GMT