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

[Ken Laskey <klaskey@mitre.org>]

Somehow saying service *provides* capabilities  misses the SOA 
motivation to provide an effective way to bring together the parts I 
need to solve a problem.  Integration is often of disparate parts 
that exist for their own purposes.  Service can help coordinate but 
the challenge is to make use of the tools/resources/capabilities that 
already exist, not to create new stovepipes.  Saying the service 
provides all this is a tempting simplification but I fear it will 
trivialize  the concepts most in need of clarification.

Ken

At 10:35 AM 8/4/2005, Chiusano Joseph wrote:
> > -----Original Message-----
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Thursday, August 04, 2005 10:18 AM
> > To: soa-rm@lists.oasis-open.org
> > Subject: RE: [soa-rm] Definition(s) of "service"
> >
> > I'd still like to emphasize service as the access to
> > capabilities for which there are extra-service motivations
> > for their existence and requirements for use of the
> > capabilities that must be navigated by the service.  Thus,
> >
> > "A service is a mechanism to enable access to a set of
> > capabilities,
>
>I would say that access control mechanisms enable such access, and that
>the service *provides* the capabilities. Note: Use of "access control"
>is too concrete for our RM - I stated it only to illustrate the point.
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>O: 703-902-6923
>C: 202-251-0731
>Visit us online@ http://www.boozallen.com
>
> > where the access is provided using a prescribed
> > interface and is exercised consistent with constraints and
> > policies as specified by the service description."
> >
> > Ken
> >
> > At 11:15 PM 8/3/2005, joe@pantella.net wrote:
> >
> > >Just trying to sort through this; some common themes that seem to be
> > >acceptable:
> > >
> > >A service provides capabilities.
> > >A service is accessible. (If this is true, then service cannot be a
> > >verb.) A service has an interface. (If this is true, then a
> > service has
> > >a boundary.) A service interface is prescribed. (Then a
> > service and its
> > >interface are distinct, and the interface has associated rules.  I'm
> > >not sure this is true, the interface may describe the rules,
> > but Im not
> > >sure it has rules.  In fact, I'm inclined to suggest that
> > the interface
> > >defines the rules for accessing the service.  Which would lead me to
> > >suggest that the service interface is more than a
> > specification of the
> > >data model, but also of the policies associated with the service.) A
> > >service is a set of behaviors.  (Not sure I'm on board with this,
> > >something about behaviors doesn't sit well.)
> > >
> > >Given this, perhaps something like:
> > >
> > >"A service is a bounded set of capabilities that are
> > accessible through
> > >a prescribed interface."
> > >
> > >
> > >-- JJP
> > >
> > >P.S. I think this definition might just be flexible enough
> > to navigate
> > >the service offer/contract discussion also.
> > >
> > >
> > >-----Original Message-----
> > >From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> > >Sent: Thursday, July 28, 2005 12:32 PM
> > >To: Frank McCabe; SOA-RM
> > >Subject: RE: [soa-rm] Definition(s) of "service"
> > >
> > >
> > >Frank,
> > >
> > >While I believe that the previously proposed definition is
> > sufficient,
> > >I offer the following as a compromise. Hopefully, the notion of
> > >"capabilities" addresses your issue of needing to get things done.
> > >
> > >"A service is a set of behaviors to provide capabilities
> > accessible via
> > >a prescribed interface."
> > >
> > >Ron
> > >
> > >
> > >-----Original Message-----
> > >From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> > >Sent: Thursday, July 28, 2005 10:10 AM
> > >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.
> > >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.
> > >
> > >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.
> > >
> > >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.
> > >b. The service is 'there' to get things done; but doesn't
> > itself denote
> > >the engine that performs the tasks.
> > >c. There is a reason for using a service.
> > >d. There is a lot of extra metalogical information about
> > services that
> > >make it possible for third parties to develop partners for services.
> > >
> > >I, for one, would prefer a strongly anglo-saxon phrasing of the
> > >definition of service that speaks to these points.
> > >
> > >Frank
> > >ti
> >
> > --
> >
> > --------------------------------------------------------------
> > -------------------
> >    /   Ken
> > Laskey
> >         \
> >   |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
> >   |    7515 Colshire Drive                    fax:
> > 703-983-1379   |
> >    \   McLean VA 22102-7508
> >            /
> >
> > --------------------------------------------------------------
> > --------------------
> >
> >
> >
> >

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------