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

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

I agree with Frank's the goal of precise and carefully thought out use
of terminology.  Here is how our team has broken out these concepts into
several inter-related terms to wrangle through these types of concerns.
You'll note that we struggle (and continue to work through) the
definition and understanding of a service.  In the set of definitions
below, you'll see that there is not a definition for service, but rather
of a service offer - which may more accurately capture the essence of
the 'thing.'

At a conceptual level, there is: 

Mission (Business) Entity:
An entity operationally responsible for performing a function, or
operationally in need of having a function performed.

Currently relevant to this context are two categories; A service
provider which performs the function and a service consumer which
requests that a function be performed.

Then, there is - 
Service Offer:
A proposal to perform a set of behaviors for others

[A couple of interesting notes here from my conversations and my
colleague's work to accurately reflect the English language intent.  It
is the understanding that an offer must be made, it cannot just exist.
This is the nature of an offer and it comes with additional inherent
implications that (1) an offer is made by a party (2) to another party).
By thinking around the concept of a service offer, the need to
explicitly include service consumer, service provider or even
participant becomes irrelevant, because their existence is inherent in
the concept itself.  Also, there is an intentional selection of 'service
offer' as opposed to 'service offering.'  As a gerund, the offering
refers back to the thing offered, i.e. the promise included in the thing
we're trying to define.  A proposal is not the offering, it is the
offer.]

Service Specification: 
A formal description of a function to be offered

[I believe the service specification is analogous to the term service
description.  Interesting here is that when you consider the definition
of 'service offer', the description is part of that offer.  That is the
description of the set of behaviors is part of the proposal to perform
that set of behaviors. ]

Whereas at the concrete level [for consideration in the RA], there is:
Service Access Point:
A logical location where a function is made accessible
[Note that it isn't defined by where the "service offer" is made
accessible.  Rather it is where the function from the service proposal
is made accessible]


Then there are the concepts of 
Service Provider/Consumer Agent:
-A combination of hardware and software that a Provider deploys to
perform a mission function when requested by Consumers
-A combination of hardware and software that a Consumer uses when
requesting that a mission function be performed by a Provider

<see continued comments below>
> -----Original Message-----
> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> Sent: Thursday, July 28, 2005 12:10 PM
> To: SOA-RM
> Subject: Re: [soa-rm] Definition(s) of "service"
> 
> I hesitate to spoil this party ... but I'm going to :)
> 
> 1. There is a distinction between action and result. (Just ask any
> roboticist) Behaviour sounds a child misbehaving with no discernible
> effect. Computer Scientists have a tendency to focus on the purely
> technical aspects of their work: bytes shuffling around at random
> within hopefully enormous memories.
> 2. Also, we have to bear in mind that nobody invests millions of $s
> (or even 100's of them) in systems that contemplate their navels or
> have no business payoff. I think that we have to directly address the
> reason that services are deployed.

Here is where the concepts of offer, acceptance and consideration come
to fruit.  These are a bit trickier to place within the context from
above given that while an offer is made at one conceptual level, the
contract, acceptance and consideration appear at a different level.
When an offer is made, only one part is known - the provider.   Moving
to concrete, only when a consumer binds to the 'service offer' does a
contract exist.  The reason that services are deployed, to me, seems to
be an expression of consideration.  Consideration doesn't really seem
make sense without engaging a service.
 
> 3. One of the movitating best practice aspects of SOAs is that
> clarity and 'separation' between the providers of services and the
> consumers of services leads to more scalable and robust architectures.
> 
Right.  I would suggest that the term 'service offer' captures that
essence of separation.

> All of the above is fuzzy language; but, at the same time,  "A
> service is a set of behaviors accessible via a prescribed interface."
> sounds a lot like bureauspeak.
> 
Frank's points are crystallizing the struggle we're having with the
definition of service.  Maybe its because we're trying to equate service
with service offer, and we'll only resolve these when we've account for
that in our definitional concepts.  So, based on the above, and many
conversations that my explanation above probably does not adequately
capture, what comes to mind when reading Frank's 5 points below are:

> I believe that there is strong consensus on the following
> characteristics:
> a. The concept of service is 'at the boundary' between service
> providers and consumers.


Service Offer is a boundary by its nature as a proposal.

> b. The service is 'there' to get things done; but doesn't itself
> denote the engine that performs the tasks.
Resolved by the distinction between Service Offer, Service Provider and
Service Provider Agent

> c. There is a reason for using a service.
Consideration
> d. There is a lot of extra metalogical information about services
> that make it possible for third parties to develop partners for
> services.
This is the Service Specification(Service Description)which is part of
the service offer.

> 
> I, for one, would prefer a strongly anglo-saxon phrasing of the
> definition of service that speaks to these points.
> 
> Frank

How's this as a start?

Rebekah


> 
> 
> On Jul 28, 2005, at 7:49 AM, Matthew MacKenzie wrote:
> 
> 
> > I'm on board with this as well.  Wow.  What a productive thread!
> >
> > -matt
> > John Harby wrote:
> >
> >
> >
> >> "A service is a set of behaviors accessible via a prescribed
> >> interface."
> >>
> >> I like this one also.
> >>
> >> On 7/28/05, Oleg Mikulinsky <oleg.mikulinsky@weblayers.com> wrote:
> >>
> >>
> >>
> >>> +1.
> >>>
> >>> I would prefer to remove the notion of boundary in favor of the
> >>> interface. As the definition of the interface implies boundary in
my
> >>> mind.
> >>>
> >>> Oleg.
> >>>
> >>> -----Original Message-----
> >>> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> >>> Sent: Thursday, July 28, 2005 9:33 AM
> >>> To: Chiusano Joseph; soa-rm@lists.oasis-open.org
> >>> Subject: RE: [soa-rm] Definition(s) of "service"
> >>>
> >>> I like that as well.
> >>>
> >>> Ron
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> >>> Sent: Thursday, July 28, 2005 7:30 AM
> >>> To: soa-rm@lists.oasis-open.org
> >>> Subject: RE: [soa-rm] Definition(s) of "service"
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> >>>> Sent: Thursday, July 28, 2005 9:27 AM
> >>>> To: Thomas Erl; soa-rm@lists.oasis-open.org
> >>>> Subject: RE: [soa-rm] Definition(s) of "service"
> >>>>
> >>>> Believe it or not I thought about this at about 2 AM this
> >>>> morning. I
> >>>> agree with Thomas that a service is a set of behaviors. To fully
> >>>> define a service in the context of a reference model for SOA, I
> >>>> suggest the following (a slight modification of Thomas' words)
> >>>>
> >>>> A service is a set of behaviors within a given action boundary
> >>>> accessible via a prescribed interface.
> >>>>
> >>>>
> >>>>
> >>> I like that. I also wonder if the reference to a prescribed
> >>> interface
> >>> might imply the notion of a boundary (or action boundary) - in
which
> >>> case we can remove the reference to action boundary. The new
version
> >>> would be:
> >>>
> >>> "A service is a set of behaviors accessible via a prescribed
> >>> interface."
> >>>
> >>> Joe
> >>>
> >>> Joseph Chiusano
> >>> Booz Allen Hamilton
> >>> O: 703-902-6923
> >>> C: 202-251-0731
> >>> Visit us online@ http://www.boozallen.com
> >>>
> >>>
> >>>
> >>>
> >>>> Ron
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Thomas Erl [mailto:thomas.erl@soasystems.com]
> >>>> Sent: Wednesday, July 27, 2005 8:23 PM
> >>>> To: soa-rm@lists.oasis-open.org
> >>>> Subject: Re: [soa-rm] Definition(s) of "service"
> >>>>
> >>>>
> >>>> I would view the interface and the action boundary as elements
that
> >>>> partially comprise a service. I would therefore not state that a
> >>>> service
> >>>> *is* a prescribed interface or *is* an action boundary (to a set
of
> >>>> behaviors). Would a service not represent a set of behaviors
> >>>> within a
> >>>> given action boundary accessible via a prescribed interface?
> >>>>
> >>>> Thomas
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Behera, Prasanta" <pbehera@visa.com>
> >>>> To: <soa-rm@lists.oasis-open.org>
> >>>> Sent: Wednesday, July 27, 2005 5:05 PM
> >>>> Subject: RE: [soa-rm] Definition(s) of "service"
> >>>>
> >>>>
> >>>>
> >>>> Ron: "A service is a prescribed interface to a set of behaviors"
> >>>> Frank: "A service is an abstract action boundary to a set of
> >>>> behaviours"
> >>>>
> >>>> The difference between the two seems to be "prescribed
> >>>> interface" Vs.
> >>>> "abstract action boundary" (Skipping the "behaviors" and
> >>>> "behaviours"
> >>>> debate).
> >>>>
> >>>> I would lean more towards Ron's suggestion.
> >>>> Thanks,
> >>>> /Prasanta
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> >>>> Sent: Wednesday, July 27, 2005 2:34 PM
> >>>> To: Duane Nickull; Francis McCabe
> >>>> Cc: soa-rm@lists.oasis-open.org
> >>>> Subject: RE: [soa-rm] Definition(s) of "service"
> >>>>
> >>>> I briefly suggested something similar to this during the F2F
> >>>>
> >>>> I'll toss out a slight modification based on this thread to the
> >>>> TC for
> >>>>
> >>>> their reaction.
> >>>>
> >>>> "A service is a prescribed interface to a set of behaviors"
> >>>>
> >>>> Ron
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Duane Nickull [mailto:dnickull@adobe.com]
> >>>> Sent: Wednesday, July 27, 2005 3:24 PM
> >>>> To: Francis McCabe
> >>>> Cc: soa-rm@lists.oasis-open.org
> >>>> Subject: Re: [soa-rm] Definition(s) of "service"
> >>>>
> >>>>
> >>>> Frank:
> >>>>
> >>>> I wasn't happy with "observable" either.  Perhaps firing up the
> >>>> ole'
> >>>> thesaurus to find out an "observable / effective / RWE"
> >>>> synonym would be
> >>>>
> >>>> a good idea or just being vague and not using the word.
> >>>>
> >>>> The wording of this is becoming somewhat scatalogical in nature
> >>>> due to
> >>>>
> >>>> the amount of FUD in the industry ;-)
> >>>>
> >>>> Duane
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Francis McCabe wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >
>