- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Fri, 14 Apr 2006 12:27:55 -0400
- To: "Daniela CLARO" <Daniela.CLARO@eseo.fr>
- Cc: SWS-IG ' <public-sws-ig@w3.org>
(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. > 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. 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? > 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. Cheers, Bijan.
Received on Friday, 14 April 2006 16:27:59 UTC