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

[John Harby <jharby@gmail.com>]

"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
> > >>
> > >>
> > >>>
> > >>
> > >
> >
> >
> >
>