RE: Compositions Types:Static and Dynamic

> -----Message d'origine-----
> De : Bijan Parsia [mailto:bparsia@isr.umd.edu] 
> Envoyé : vendredi 14 avril 2006 18:28
> À : Daniela CLARO
> Cc : SWS-IG '
> Objet : Re: Compositions Types:Static and Dynamic
> 
> (Keeping the discussion on list)
> 
> On Apr 14, 2006, at 5:23 AM, Daniela CLARO wrote:
> 
> > Thanks for your answer...
> > Actually I understood what you meant about dynamic in 
> workflow, it was 
> > that even if in a workflow you could not know all services 
> that will 
> > be part of the composition, because one of them can be unavailable.
> 
> Or you might find a better one at runtime.

Ok, I understood.  

> > However, what I meant about static is that even if you can choose 
> > another service in execution time, you know all the 
> services that will 
> > achieve your predertermined goal.
> 
> Well, first, I'm suggesting that "groudned" might be a better 
> term. Or something similar (concrete; fully concrete). Static 
> just doesn't seem *correct*.
> 
> >  You know all the activities that will be composed to achieve your 
> > goal in a static manner.
> 
> But notice that this is different than before. If I have a 
> planning domain with a fixed set of operators, I, in some 
> sense, know all the activities that will be composed (if they 
> can be) to achieve my goal. 
> Is it a "static" manner? I don't know. I have to *do* the 
> planning, but it is, indeed, off line.

Yes, the plan will be generated off-line, but I do not see as *static* because even if you know all candidate services, you do not know which composition will be used. For example, imagine that I am constructing a house and I have some services as: supply and place a window, construct stair, placing the floor, concrete supply, etc. 

If I choose the service costruct stair, for example, it has as precondition concrete alrealdy supplied. But actually, I haven't chosen the concrete supply.  

This is actually the momment where my plan takes place and it is because I called dynamic composition. Even if I hadn't chosen the service(I have chosen construct stair), my application will automatically add the service concrete supply in my composition. Even if I know all services in advance, because they are probably deployed and described in domain ontology, I do not know which one will be part of my composition. 

Of course, the next problem is in execution time, because I can have a lot of candidate services that can do the task: concrete supply. 
 

> And since you allow for subsitution in the grounded, concrete 
> composition, I DON'T know which activities will be, in fact, 
> executed to achieve my goal.
> 
> >  Probably the service 1 that will execute the activity 1 is 
> > unavailable, and so it is the dynamic concepts in workflow for 
> > composition.
> >
> > About my concepts of dynamic composition, I meant that you 
> know your 
> > goal, but you do not know which activities or tasks you 
> need to do to 
> > achieve this goal. It is what I understood about the planning role.
> > You can also have the same problem explained above, because you can 
> > know the activities, but actually a service 1 that executes the 
> > activity 1 can also be unavailable.
> 
> Or, as I said, you could change your might and replace it 
> with 5 activities that also achieve the goal. I just think 
> you aren't capturing the distinction you want.
> 
> > Writing all these, I can probably make a difference between 
> them: One 
> > thing is dynamic execution of composed services, and another is 
> > dynamic composition in order to find which tasks are necessary to 
> > achieve the goal.
> 
> Perhaps, though I can find concrete services in the latter 
> case. And what's the difference between dynamic *execution* 
> and "static" 
> execution?

For me, dynamic execution is what you are doing, searching for services when you try to execute it or try to execute a composition. For exemple, in my example above, I am doing a dynamic composition with a static execution, because I do not search for other services in runtime, I compose my service and I execute them, considering that all of them will be executed and available at runtime. 

> 
> > It isn't simple, this domain... :)
> > Thank you again, and if you or anybody else can comment 
> these lines, I 
> > will apreciate it!
> 
> 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.

My purpose in trying to make this distinction it is only to understand and to classify my thoughts!!! I am writting a report about that and I thought that it was a good idea to classify the composition. However, I changed this opinion and I am thinking of separating in my rapport as: off-line compositions (as I did) and runtime compositions(as you did).
> 
> Cheers,
> Bijan.

Thank you one more time! 
Daniela

Received on Tuesday, 18 April 2006 08:39:33 UTC