W3C home > Mailing lists > Public > www-ws@w3.org > September 2003

Re: Model of Concurrency in DAML-S

From: Charlie Abela <charlie@semantech.org>
Date: Mon, 22 Sep 2003 15:11:02 +0800
Message-ID: <1064214662.3f6ea08664857@>
To: Monika Solanki <monika@dmu.ac.uk>
Cc: "www-ws@w3.org" <www-ws@w3.org>

Quoting Monika Solanki <monika@dmu.ac.uk>:

> In DAML-S we have the notion of an Atomic service and a Composed 
> Service. Composed services are built out of Atomic Services using 
> Control constructs. The control constructs that we can use for 
> specifying concurrency are Split, Concurrent, Parallel, Split-Join, 
> Fork-Join, unordered etc. Now as per my understanding, if I specify say 
> Split as a control construct, for a composite service built out of two 
> atomic services, it would mean that both of them execute independently.. 
> Basically as per my conclusion, atomic services  can either execute 
> sequentially or in parallel, independent of each other.
> For a scenario given below, I have two thoughts
> 1. There are 3 composite processes, A, B and C.
> 2. All the 3 start execution in parallel i.e split.Now after some 
> computation, B needs a value from A.It requests A for the value, gets 
> the value and carries on computation.
> 3. After some time B needs value from C. It requests C for the value, 
> gets it and carries on computation, and finally terminates
> 4. In some cases it may happen that one of the processes may have to 
> wait for some value from some other process, because it did not finish 
> on time .
In DAML-S specs, there is a mention of some scheduling (process control) 
ontology that has yet to be built. I think that the necessary features to 
obtain such controlled states would be catered for in this ontology. IMHO 
workflow and scheduling should go together, you cannot have one without the 
other, for complex compositions. 

> Option 1:
>  >From here we see that some kind of a synchronization is needed between 
> the 3 processes. Can we capture that in the DAMl-S model ? Is such a 
> specification part of the model ? Do we have control constructs for them?
>  From all the examples that we have on the website and the 
> documentation, I have not been able to answer all these questions. I 
> want to build up such kind of an example and analyse the level of 
> complexity that can be handled through the DAML-S specs.
I also add that there is no specific example that shows how the majority of the 
control constructs can be used.

> 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 think that if services A, B and C are composed then this does not mean that 
all the atomic services in every composite one would be involved. Altough it 
could be the case that for example some B' would require the output of Services 
A (hence this would have to totally execute to give the required output). I'd 
say that there will be some limit to the possible decomposition of a composite 
service into its atomic ones. Since some of the atomic services would be 
defined as a black box, and the developer doesn'want to expose them. 

What seems to be an issue is the how to generate the new DAML-S spec for such a 
service. I think that this issue has not been tackled, at least not on this 
list, after all composition should be delegated to an agent, that could 
possibly be able to reason and plan with a number of web services. Is it not 
time that composition issues be tackled with such perspective in mind?

> I am certain abut option 1, however option 2 may solve this problem. I 
> want a second opinion about option 2. Will the actual solution need new 
> constructs or is option 2 the solution
> Thanks,
> Monika
> -- 

Charlie Abela
Research Student,
CSAI, Department,
University of Malta

This mail sent through IMP: http://horde.org/imp/
Received on Monday, 22 September 2003 03:24:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:12 UTC