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

["Metz Rebekah" <metz_rebekah@bah.com>]

Duane et all:

> 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).

In current work, we're finding traction with terming this distinct (and
concrete) "stuff" that actually request or perform as "Service Provider
Agent" and "Service Consumer Agent."  Note:  I am NOT suggesting these
be in the Reference Model, however, the separation between "Service
Offer" and "Service XX Agent" concepts resonates.
> 
> 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).

Another email is coming from me that talk to this point as well.  It
sounds like you're poking at the distinction between "offer" and
"perform", and ties back as well to the concept that we should
acknowledge the duality "potential vs actual" within this context.
> 
> ;-)
> 
> 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
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>