Re: granularity/definition of a "service"

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?

- Monika

Received on Friday, 17 September 2004 05:50:43 UTC