Re: Compositions Types:Static and Dynamic

On Apr 14, 2006, at 3:43 PM, Abraham Bernstein wrote:

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

heh. You use the term too :)

> back in 2000 (see  
> http://www.ifi.unizh.ch/ddis/staff/goehring/btw/files/CSCW2000- 
> final.pdf).

Interesting paper! Thanks.

> There I discuss various degrees of specificity that a process (or  
> service) description can have.

Which helps sharpen a point I didn't make very clear. Consider the  
following workflow templete:

	A, then B

We can make this more detailed in a number of ways:
	(operation)A(at endpoint foo, with input bar, with its output going to  
input baz of)
		then (operation)B(at endpoint foo)
or
	(any process that has the same function as)A(that is compatible with a  
related process)
		then B (on the same server as A)

(presuming we have a description of the function of A and can express  
the notion of compatibilty, etc.)

Obviously, these descriptions can be combined. The combined template is  
more specific than the second (in the sense of detailing particular  
operations at certain endpoints). (Oh, I presume the dataflow stuff is  
the same in each.) However, since the combined description has the same  
information as the second, it can serve as an abstract template as well  
(presuming, of course, that the abstract slots are clearly  
distinguished from the instantiations).

Just given the more combined workflow, we don't necessarily know how  
it's going to be used. A processor might treat it entirely as the  
second, or it could ignore the extra stuff and just execute the  
services. In other words, we need to *say* "use the services detailed  
in this description and no others). Often this happens by default as  
either the descriptions aren't rich enough to allow useful  
substitution, or the processer just never *does* substitute.

(And, of course, unless we specify the specific endpoint, protocol, and  
wire format, a wsdl system might use the alternatives described in a  
WSDL document to select these at runtime. And of course, the *server*  
isn't going to promise that it is executing a specific chunk of code on  
a certain machine. it's free to delegate as it sees fit.)

Notice the continuity with late binding OO systems.

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

Nice paper.

Cheers,
Bijan.

Received on Sunday, 16 April 2006 21:03:16 UTC