Re: Model of Concurrency in DAML-S -Reposted

Thanks Bijan.
Option 2:

>> Since communication will actually happen within the atomic services 
>> of these composite services and since atomic services can execute 
>> sequentially or independently in parallel with each other, the 
>>  representation of this problem in DAML-S is possible in terms of 
>> atomic services and control constructs.
>>
>
> I'm not sure I understand option 2. I don't see how communication 
> happens *within* the atomic services. 

Sorry.. I meant "Between Atomic services".

> If you mean that we can notice the dataflow dependancy and rewrite the 
> parallel construct as a sequential one, that seems right to me. 

I don't think, we need to even look at the dataflow dependency( I mean, 
ofcourse to determine "which is followed by which", we would have to do 
so, however that is not the issue here) to reason about this. Like I 
said earlier, that atomic processes will either execute sequentially or 
if in parallel, then they will do so, independently of each other(let me 
call this truly pararllel). So the question is, can we reduce every 
concurrent composition to a sequential execution /truly parallel 
execution of atomic processes ?

The more I think about it, the more I believe this would still not work 
We would need inclusion of some kind of concrete temporal constructs (in 
some form) in the "Process" model ( I am not defining anything here, 
however that is what I feel) rather than the "Process Control model" 
[Charlie's email on this thread], as this problem is more specific to 
designing of "a" process (i.e composite process)  model rather than 
controlling a designed process execution (the control model would be 
used for monitoring process execution and related things).

However the Big question (which is still unanswered... :-) ) is "Is this 
kind of a process representation, a part of the DAML-S model or should 
DAML-S restrict itself only to a certain level of abstraction in 
describing processes?"

>
>
> I'd go further and point out that if we have glass box views of the 
> communicating process, we might discover that B needs info for A in 
> step 47 of (rather than step 1). So, sequencing all of A before all of 
> B would be unfortunate. (It still could be handled. I'm not sure, but 
> I think SHOP2 would be able to build this compositoin (well, with 
> concurrancy awareness added in.) You should get something like a split 
> all of A, steps 1-46 of B, join on 47, etc..
>
> I'll note that this seems to be the kind of composition (coordinating 
> message exchanges) folks like Richard Hull are talking about.
>
> Cheers,
> Bijan.
>

-- 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
Monika Solanki
Software Technology Research Laboratory(STRL)
De Montfort University
Hawthorn building, H00.18
The Gateway
Leicester LE1 9BH, UK

phone: +44 (0)116 250 6170 intern: 6170
email: monika@dmu.ac.uk
web: http://www.cse.dmu.ac.uk/~monika
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**

Received on Monday, 22 September 2003 11:45:44 UTC