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

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

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

My car is a boundary between me and the road, but that is not its
primary value - it gets me from point A to point B. That's the issue I
have with focusing on boundary.

Joe

Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
> 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
> 
> 
> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >
> 
> 
>