RE: Compositions Types:Static and Dynamic

Good paper, thank you very much. 
I can probably position my work in relation of your paper at C (planning options) . Actually I do not consider all parts (A,B,C,D) as you have implemented. 

In my planning phase, I propose some results based on my composition, that I can call automatic composition or dynamic composition. The meant of dynamic or automatic here is that I will have some activities that need to be in an order to be executed by a web service. My planning algorithm needs to *find* services that are prerequisites from others. These services will also be part of the composition. Actually my plan works with activities and tasks, and the real execution process is done after I have created the plan. I gave an exemple in the last email posted. 

After that, "Heidi" can choose among the results. 

Thanks a lot, 
Daniela 

> -----Message d'origine-----
> De : Abraham Bernstein [mailto:bernstein@ifi.unizh.ch] 
> Envoyé : vendredi 14 avril 2006 21:43
> À : Bijan Parsia
> Cc : Daniela CLARO; SWS-IG '
> Objet : Re: Compositions Types:Static and Dynamic
> 
> 
> 
> Bijan Parsia wrote:
> > (Keeping the discussion on list)
> >
> > On Apr 14, 2006, at 5:23 AM, Daniela CLARO wrote:
> <cutting out a lot>
> >
> > BPEL also has a distinction between...er...abstract? and concrete 
> > workflows? They point is that if there are *in fact* concrete, in 
> > principle executed services in the composition, that's 
> something worth 
> > marking (i.e., in principle, assuming no failure, you can 
> execute the 
> > composition without further planning/composition). I don't 
> see that as 
> > "static" per se. The composition is immediately executable. 
> When the 
> > composition doesn't concretize things entirely, there's 
> further work 
> > to be done (from a composition, or dispatch/selection, perspective).
> > If I have conditionals in the composition, then in at least that 
> > respect, though the composition itself might never change, what 
> > services actually get invocated will depend on (simple) runtime 
> > decisions.
> >
> > So there really is a continuum here. It might help if we knew the 
> > purpose you have in trying to make this distinction.
> Daniela
> 
> You may want to look at some work that I did on the 
> specificty frontier (or continuum - thanks Bijan) back in 
> 2000 (see 
> http://www.ifi.unizh.ch/ddis/staff/goehring/btw/files/CSCW2000
> -final.pdf). 
> There I discuss various degrees of specificity that a process (or
> service) description can have. The paper also discusses that 
> different degrees of specificity warrant different types of 
> support (by the system). While the paper focuses on machine 
> support for human process enactment the ideas can easily be 
> translated to the support of service executions.
> 
> Best
> 
> Avi
> 
> >
> > Cheers,
> > Bijan.
> >
> 
> --
> -----------------------------------------------------------------
> |  Professor Abraham Bernstein, PhD
> |  University of Zürich, Department of Informatics
> |  phone: +41 1 635 4579
> |  eMail: bernstein@ifi.unizh.ch
> |  web: www.ifi.unizh.ch/~bernstein
> |  mail: Binzmühlestrasse 14, CH-8050 Zürich, Switzerland
> 
>

Received on Tuesday, 18 April 2006 12:33:26 UTC