Re: [soa-rm] Definition(s) of "service"

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

I rather like this definition. I agree completely that service should  
not mention the delivery mechanism.  Some additional comments:

Firstly, I would shorten it to:

"A service is an abstract action boundary to a set of behaviours"

Rationale: The service is distinct from the results of the service.

Secondly, building on the notion that behaviour is different to  
effect, I would go on to:

"A service is an abstract action boundary to a set of effective  
behaviours"

Not sure about the word effective, as it may be ambiguous in ordinary  
English.

Frank






On Jul 27, 2005, at 2:04 PM, Duane Nickull wrote:


> Perhaps combining all of these is closer to the answer:
>
> Duane suggests: "A service is an abstract action boundary to a set  
> of behaviours or the observable result of some functionality."
>
> I would want to refrain from mentioning any actors such as  
> provider, consumer, participant in this definition since we may  
> define those later by referring to service (avoidance of circular  
> references). I used the word "abstract" specific to our RM. In an  
> RA, it may be a more concrete action boundary (see Microsoft def.  
> below).
>
> More definitions of services:
>
> W3C says: "A Web service <http://www.w3.org/TR/ws-arch/#service> is  
> an abstract notion that must be implemented by a concrete agent  
> <http://www.w3.org/TR/ws-arch/#agent>." (Thank you W3C. I am more  
> confused now. Next!)
>
> Microsoft says: "A software entity whose interactions with other  
> entities are via messages. Note that that
> a service need not be connected to a network." (too concrete but  
> good for RA. I wonder why they felt compelled to point out that it  
> need not be connected to the network to be a service. This is in  
> alignment with our notion of "a service is a service, even if not  
> invoked" so I like that part.)
>
> CISCO says: "A group of related functions (or operations) that work  
> together to provide a functional capability." (interesting but does  
> really state what a service is, just what it represents).
>
> The US EPA says: "Breeding, the deposition of boar semen into the  
> female." (Hmmm - probably not useful - let's leave this one alone)
>
> DOI says: "A defined result from a defined action ie, do X and the  
> result will be Y. Services perform functions when invoked into  
> action." (paraphrased slightly. Too concrete but interesting)
>
> Apple says: " A service is an I/O Kit entity, based on a subclass  
> of IOService, that has been published with the registerService  
> method and provides certain capabilities to other I/O Kit objects.  
> In the I/O Kit’s layered architecture, each layer is a client of  
> the layer below it and a provider of services to the layer above  
> it. A service type is identified by a matching dictionary that  
> describes properties of the service. A nub or driver can provide  
> services to other I/O Kit objects."
>
> I liked part of the latter analogy about the layering - being a  
> slave to the entity above it while being a client of the entity  
> below it. This effectively addresses the concept of service  
> context. In one context, something is a service consumer while in  
> another it is a service provider. The definition is far to specific  
> to Apple but is useful to expand thinking.
>
> To continue extrapolating from Ken's ramblings,
> "Two things are needed to effectively use a capability under SOA:
> - understanding the underlying capability;
> - understanding the accessing service."
>
> I fundamentally think that all that is really required is an  
> understanding of the behavioural aspects of the service, the data  
> model the service uses, the other metadata and the policies of the  
> service.
>
> Duane
>
>
>
>>
>>
>
>