Re: granularity/definition of a "service"

My guess is PSMs actually deal with internals as well rather than just 
interfaces as in Atomic processes, so probably the semantics are 
different there slightly.

If you look at the range of the "Activity " construct in BPEL, you find
" <receive>, " <reply>, " <invoke>, " <assign>, " <throw>, " 
<terminate>, " <wait>
" <empty>," <sequence>," <switch>," <while>," <pick>," <flow>," 
<scope>," <compensate>

these include everything from communication primitives to control 
constructs. A BPEL service would then essentially be a composition of 
several "Activity" constructs. So the issue now is that can "Activity" 
be considered analogous to an "Atomic " service. I don't think it can, 
but it would be interesting to have other opinins.

Daniel Elenius wrote:

> Interestingly, Problem-solving methods (PSMs), which are in many ways 
> similar to owl-s atomic processes, seem to have been thought to have a 
> finer granularity than "services". What they describe is rather 
> algorithms, and these could be parts of services I guess...
>
> /Daniel
>
> Monika Solanki wrote:
>
>> Hi All,
>>
>> Keeping aside the "web" part, I am interested in understanding the 
>> semantics of the word "service". Within the web service world, what 
>> is the lowest level of granularity a service can have. What would be 
>> the most appropriate definition for the basic building block from 
>> which bigger units can be composed. Services communicate via sending 
>> and receiving messages. Can communication primitives also be 
>> classified as services i.e in this context is it appropriate to 
>> consider the operation of sending and receiving as services 
>> themselves and can they be modelled as such ? The BPEL4WS specifies 
>> these and other control constructs as "Activity". So in this context 
>> is a "service" at a higher level of abstraction then an "Activity" or 
>> do they have equivalent semantics.
>>
>> -Monika
>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>> Monika Solanki
>> Software Technology Research Laboratory(STRL)
>> De Montfort University
>> Gateway building, G4.61
>> 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
>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>
>
>
>

-- 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
Monika Solanki
Software Technology Research Laboratory(STRL)
De Montfort University
Gateway building, G4.61
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 Thursday, 16 September 2004 13:44:55 UTC