[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
I had coined one slight alternative but that one is also equally acceptable. Is anyone opposed to adopting it? D 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]