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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Wednesday, July 27, 2005 5:18 PM
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Definition(s) of "service"
> 
> Joseph:
> 
> At the F2F we discussed this in great depth.  The service 
> itself does not seem to carry out the request, it is more 
> like the door than the room.  It allows the request to be 
> carried to the thing  that does the work (the room).

I believe it's all a matter of perspective. Some would consider the room
to be the service, with the door being its interface. However, that's
not the best analogy since a room doesn't exhibit any certain behaviors.
If one has a shoe shining service, I believe that the set of behaviors
(in this case shoe shining) *is* the service, and it also has an
interface (e.g. the front desk of the shoe shining storefront) that is
the "gateway" to the service, or its interface.

Not recommending that we adopt this viewpoint - just expressing it.

Joe

Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
> We did sort of concur that a service is conceptually a zero 
> thickness thing, therefore it is not specifically able to 
> encapsulate anything.  
> In fact, adhering to the OO conventions, encapsulation of 
> logic and data in a class only works with an API to the class 
> for mutator and accessor methods (functions in C++).  The 
> service is more synonymous with the API than the class itself.
> 
> Regardless, we have to define it in the abstract.  It might 
> not be an entity, it may be an abstract entity but this got 
> into the "is it a noun or a verb" conversation.  My view is 
> that it is sort of an "abstract meta-verb" (clear_as_mud).
> 
> ;-)
> 
> Duane
> 
> Chiusano Joseph wrote:
> 
> >>Duane suggests: "A service is an abstract action boundary 
> to a set of 
> >>behaviours or the observable result of some functionality."
> >>    
> >>
> >
> >Rather than think of a service as a boundary to something, 
> can it also 
> >be thought of as an entity that encapsulates (or "carries 
> out") a set 
> >of behaviors?
> >
> >Joe
> >
> >Joseph Chiusano
> >Booz Allen Hamilton
> >O: 703-902-6923
> >C: 202-251-0731
> >Visit us online@ http://www.boozallen.com
> > 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Duane Nickull [mailto:dnickull@adobe.com]
> >>Sent: Wednesday, July 27, 2005 5:04 PM
> >>Cc: soa-rm@lists.oasis-open.org
> >>Subject: Re: [soa-rm] Definition(s) of "service"
> >>
> >>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
> >>
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
>