Re: granularity/definition of a "service"

If you are looking at a programmer kind of definition of certain 
activities being services, then this is my guess:

For a BPEL specified composition to be executable on a BPEL engine, both 
the BPEL composition as well as
an accompanying WSDL is required. The WSDL declares all endpoints which 
can be invoked by external entities.
This includes the BPEL composed service and other services which are 
part of the composition .Note that the invocation
of these other activities is contingent on the composition being 
instantiated.

Speicifically, the other services that WSDL declares:
receive ( one-way operation)
receive, reply ( two-way )
pick, onMessage (one/two-way)
event, messageHandlers (one/two-way)
.....

Note that "invoke" is not part of WSDL since it is used by the 
composition to invoke external web services and is not
a provided service by the composition. Ofcourse one could argue that 
certain "invokes: could be one-way operations
reporting to external entities.

So in this sense, a subset of activities (combination of activities) are 
services as they serve clients. Certain others which
was also mentioned like  compensate,  flow etc. provide internal service 
to the composition by doing certain set
of things, but cannot be classified as services.

-- Pranam
_____________________________________________________________________

Pranam Kolari 						
Department of Computer Science
University of Maryland, Baltimore County	 
Baltimore, MD 21250				

Contact:
(Work) +1 410 455 3971 :---: (Home) +1 410 536 4772
kolari1@cs.umbc.edu    :---: http://www.cs.umbc.edu/~kolari1
_____________________________________________________________________


Monika Solanki wrote:

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

Received on Thursday, 16 September 2004 14:14:01 UTC