[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
Rebekah: I think that your breakdown is very similar to what we need. The service offer is made. This involves two components - have the offer and communicating the offer. For a legal contract to be established, "an offer must be duly made". This involves both components - formation of the offer and ensuring it is delivered and formatted properly for the potential second party. The service in IT terms can be built, a service description is then communicated (availability, presence etc...). D Metz Rebekah wrote: >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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]