[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
I take issue with the concept of an offer in this context, particularly given the relationship to a contract as is being discussed here. A contract may begin with an offer, but a contract implies something much stronger than an offer, it implies a commitment to honor a promise or set of promises from one party to another, for which there exists a remedy for one party in the event that the other fails to honor its committment. The problem with offer here is that it implies a contract, and without two parties the concept of offer means to provide, or furnish, which causes issues for the rationale used in selecting "service offer" over "service offering" in one of the previous notes in this thread. All this is not to say that I don't think that the notion of a service contract or offering is important, I just think that we need to think of these concepts as they relate to one another if we are going to adopt this language. -- JJP -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Thursday, July 28, 2005 2:18 PM Cc: SOA-RM 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]