Re: granularity/definition of a "service"

Monika Solanki wrote:

> David Martin wrote:
> 
>>> I would say a <receive> alone is a service if it represents a one-way 
>>> operation  in the BPEL composition. <receive> can also be accompanied 
>>> with a corresponding <reply> in which case both of them put together 
>>> is a service. A subset of activities ( and a combination of 
>>> activities) are services based on the way they serve clients.
>>
>>
>>
>>  I agree that a <receive> or a <send> *can* be offered as a (WSDL) 
>> service - but for many purposes it seems unnecessarily cumbersome and 
>> counterintuitive to do so.  I prefer to think of a "service" as an 
>> interesting unit of functionality that's "packaged up" for external 
>> invocation and reuse.   If a <receive> or a <send> operation is only 
>> needed as part of a larger flow of control (e.g., as expressed in 
>> BPEL), in general it doesn't seem appropriate to have it declared as a 
>> service.  In that case, it is preferable to think of it just as a WSDL 
>> *operation*, rather than a service.  I believe this view is consistent 
>> with Joachim's comment earlier in this thread, that
>>
>> - a service consists of a collection of (probably related) operations
>> - BPEL constructs like "invoke" or "receive" refer to such *operations*
>> (not to the service as a whole)
> 
> 
> This is precisely what I had in mind, till I came across certain views 
> where everything in the scope of Web services, was considered as a 
> service ... :-)  and this is what led to this thread. The w3c glossary 
> definition is even more interesting
> 
> A service is an abstract resource that represents a capability of 
> performing tasks that form a coherent functionality from the point of 
> view of providers entities and requesters entities. To be used, a 
> service must be realized by a concrete provider agent.
> 
> Keeping this definition in context, would it  be now appropriate to call 
> a "receive" or "send" as a coherent functionality?

My quick answer is: it depends on the context; that is, on how the 
service provider chooses to organize things.  I think I can imagine an 
organization in which an isolated "receive" or "send" could be regarded 
as a coherent stand-alone functionality.  But, as I said earlier, in 
most cases I would not want to think of it that way.

-- David

Received on Saturday, 18 September 2004 00:57:51 UTC