[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
> -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Monday, August 08, 2005 5:50 PM > To: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Definition(s) of "service" > > As appeared earlier in this thread, there are contexts in > which it is not necessary to discriminate between the > capability and the service that accesses it, Ken, are you equating capability with resource? I recall a reference to resource that fits the above description, but not one to capability. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > and our > discussion of service can make this clear. However, I think > this thread has also shown ample examples of where the > service and the capability are clearly separate concepts and > where it may be useful to allow that difference to be > captured. For example, it is likely for someone to ask if > two services are the same. While we do not address that > particular question, it is far simpler to handle if we know > whether the underlying capability is the same than if we > obscure that difference at first principles. > > Ken > > At 05:03 PM 8/8/2005, Chiusano Joseph wrote: > > > -----Original Message----- > > > From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] > > > Sent: Monday, August 08, 2005 12:10 PM > > > To: Ken Laskey > > > Cc: soa-rm@lists.oasis-open.org > > > Subject: Re: [soa-rm] Definition(s) of "service" > > > > > > This is going in a weird direction. > > > I believed that there was significant consensus that the > notion of > > > service that we are interested in *is* the > > > interface/boundary/offering. > > > > > > The capability behind the service -- that which makes the service > > > possible -- is private and out of bounds. That capability > is, by the > > > way, best described using agent terminology. > > > >Respectful non-concur. IMHO, the service *is* the > capability, and the > >service *has* an interface through which interaction with that > >capability may be possible. > > > >Joe > > > >Joseph Chiusano > >Booz Allen Hamilton > >O: 703-902-6923 > >C: 202-251-0731 > >Visit us online@ http://www.boozallen.com > > > > > Frank > > > > > > On Aug 8, 2005, at 8:50 AM, Ken Laskey wrote: > > > > > > > This is good because it highlights the bits of > confusion we have > > > > to explain our way around. > > > > > > > > The user interface is the facade through which the user > > > interacts with > > > > a service (i.e. inputting information/requests, viewing > > > > results) but there may be delivery capabilities that > are invoked > > > > through relevant services and the delivery capabilities are the > > > > mechanisms through which results are packaged and sent to the > > > > requester/consumer. For example, if I make a request for > > > an image and > > > > as part of that request, information about my connectivity is > > > > provided, logic (capability) can be executed (possibly > > > invoked through > > > > a service) to decide which delivery mechanism is most > appropriate > > > > (e.g. high res or low res, what kind of compression, ...). > > > > > > > > Ken > > > > > > > > At 11:18 AM 8/8/2005, Michael Stiefel wrote: > > > > > > > >> Actually, I think two things are being confused here. > > > >> > > > >> There is one service being used by several different > > > applications. > > > >> The user interface (i.e. the actually delivery mechanism) > > > is not part > > > >> of the service, or strictly speaking part of the SOA. > > > >> > > > >> Michael > > > >> > > > >> At 10:43 AM 8/8/2005, Ken Laskey wrote: > > > >> > > > >>> I'd have to think about this further but in general I > > > would say yes. > > > >>> The underlying capability is making pizza and offering > > > the product > > > >>> for sale. The mechanisms for accessing the capability are in > > > >>> person, by phone, online. Note, the capability existed > > > before there > > > >>> was online ordering and this is just another > mechanism to access > > > >>> a capability that already existed. > > > >>> Interestingly from an orchestration/choreography sense, > > > the delivery > > > >>> of the pizza (in person pickup, delivery service from > > > pizza place, > > > >>> third-party delivery (e.g. Takeout Taxi around > > > >>> here)) constitutes another set of capabilities that can > > > have service > > > >>> interfaces and can be combined in response to invoking > > > the ordering > > > >>> service. All of these can be used for delivery of things > > > other than > > > >>> pizza (even the pizza place might also deliver sandwiches). > > > >>> > > > >>> I think part of the confusion is that a *physical* > > > delivery service > > > >>> is a millennia-old, longstanding capability that has > > > nothing to do > > > >>> with SOA and is *not* the service in the SOA sense > but it uses a > > > >>> different aspect of the S word. > > > >>> > > > >>> Ken > > > >>> > > > >>> At 07:11 PM 8/7/2005, joe@pantella.net wrote: > > > >>> > > > >>>> Does this imply that if I order a pizza online vs. order a > > > >>>> pizza over the phone vs. order a pizza by walking into the > > > >>>> store, that these are all separate services? > > > >>>> > > > >>>> --JJP > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: Ken Laskey [mailto:klaskey@mitre.org] > > > >>>> Sent: Thursday, August 04, 2005 12:35 PM > > > >>>> To: soa-rm@lists.oasis-open.org > > > >>>> Subject: RE: [soa-rm] Definition(s) of "service" > > > >>>> > > > >>>> > > > >>>> This gets back to the previous discussion when we > talked about > > > >>>> resources, i.e to what extent the service is the > mechanism to > > > >>>> access (possibly coordinate) capability vs. when is it > > > considered > > > >>>> the capability itself. > > > >>>> > > > >>>> I think any consideration of the service as the > > > capability/resource > > > >>>> should be very limited. > > > >>>> > > > >>>> Ken > > > >>>> > > > >>>> At 11:07 AM 8/4/2005, Chiusano Joseph wrote: > > > >>>> > > -----Original Message----- > > > >>>> > > From: Ken Laskey [mailto:klaskey@mitre.org] > > > >>>> > > Sent: Thursday, August 04, 2005 11:04 AM > > > >>>> > > To: Chiusano Joseph; soa-rm@lists.oasis-open.org > > > >>>> > > Subject: RE: [soa-rm] Definition(s) of "service" > > > >>>> > > > > > >>>> > > Somehow saying service *provides* capabilities > > > misses the SOA > > > >>>> > > motivation to provide an effective way to bring together > > > >>>> > > the > > > >>>> parts I > > > >>>> > > need to solve a problem. Integration is often > of disparate > > > >>>> parts > > > >>>> > > that exist for their own purposes. Service can help > > > >>>> coordinate but > > > >>>> > > the challenge is to make use of the tools/resources/ > > > >>>> capabilities > > > >>>> > > that already exist, not to create new stovepipes. > > > Saying the > > > >>>> > > service provides all this is a tempting > simplification but > > > >>>> > > I > > > >>>> fear it > > > >>>> > > will trivialize the concepts most in need of > clarification. > > > >>>> > > > > >>>> >Agree - and I should clarify that I was merely saying that a > > > >>>> service > > > >>>> >provides capabilities (in general). Combining a > > > capability here, a > > > >>>> >capability there, here a capability, there a capability, > > > >>>> everywhere a > > > >>>> >capability (oops sorry - that's the EIEIO song), we > > > have composite > > > >>>> >capabilities. > > > >>>> > > > > >>>> >Joe > > > >>>> > > > > >>>> >Joseph Chiusano > > > >>>> >Booz Allen Hamilton > > > >>>> >O: 703-902-6923 > > > >>>> >C: 202-251-0731 > > > >>>> >Visit us online@ http://www.boozallen.com > > > >>>> > > > > >>>> > > Ken > > > >>>> > > > > > >>>> > > At 10:35 AM 8/4/2005, Chiusano Joseph wrote: > > > >>>> > > > > -----Original Message----- > > > >>>> > > > > From: Ken Laskey [mailto:klaskey@mitre.org] > > > >>>> > > > > Sent: Thursday, August 04, 2005 10:18 AM > > > >>>> > > > > To: soa-rm@lists.oasis-open.org > > > >>>> > > > > Subject: RE: [soa-rm] Definition(s) of "service" > > > >>>> > > > > > > > >>>> > > > > I'd still like to emphasize service as the access to > > > >>>> > > > > capabilities for which there are extra-service > > > >>>> motivations for > > > >>>> > > > > their existence and requirements for use of the > > > >>>> capabilities > > > >>>> > > > > that must be > > > >>>> > > navigated > > > >>>> > > > > by the service. Thus, > > > >>>> > > > > > > > >>>> > > > > "A service is a mechanism to enable access > to a set of > > > >>>> > > capabilities, > > > >>>> > > > > > > >>>> > > >I would say that access control mechanisms enable such > > > >>>> > > access, and that > > > >>>> > > >the service *provides* the capabilities. Note: Use of > > > >>>> > > "access control" > > > >>>> > > >is too concrete for our RM - I stated it only to > > > >>>> > > >illustrate > > > >>>> > > the point. > > > >>>> > > > > > > >>>> > > >Joe > > > >>>> > > > > > > >>>> > > >Joseph Chiusano > > > >>>> > > >Booz Allen Hamilton > > > >>>> > > >O: 703-902-6923 > > > >>>> > > >C: 202-251-0731 > > > >>>> > > >Visit us online@ http://www.boozallen.com > > > >>>> > > > > > > >>>> > > > > where the access is provided using a prescribed > > > >>>> interface and is > > > >>>> > > > > exercised consistent with constraints and policies as > > > >>>> > > specified by > > > >>>> > > > > the service description." > > > >>>> > > > > > > > >>>> > > > > Ken > > > >>>> > > > > > > > >>>> > > > > At 11:15 PM 8/3/2005, joe@pantella.net wrote: > > > >>>> > > > > > > > >>>> > > > > >Just trying to sort through this; some common themes > > > >>>> > > that seem to > > > >>>> > > > > >be > > > >>>> > > > > >acceptable: > > > >>>> > > > > > > > > >>>> > > > > >A service provides capabilities. > > > >>>> > > > > >A service is accessible. (If this is true, then > > > >>>> > > > > >service > > > >>>> > > cannot be a > > > >>>> > > > > >verb.) A service has an interface. (If this is true, > > > >>>> then a > > > >>>> > > > > service has > > > >>>> > > > > >a boundary.) A service interface is > prescribed. (Then > > > >>>> > > > > >a > > > >>>> > > > > service and its > > > >>>> > > > > >interface are distinct, and the interface has > > > >>>> associated rules. > > > >>>> > > > > >I'm not sure this is true, the interface may > > > describe the > > > >>>> > > > > >rules, > > > >>>> > > > > but Im not > > > >>>> > > > > >sure it has rules. In fact, I'm inclined to > > > suggest that > > > >>>> > > > > the interface > > > >>>> > > > > >defines the rules for accessing the service. Which > > > >>>> > > would lead me > > > >>>> > > > > >to suggest that the service interface is more than a > > > >>>> > > > > specification of the > > > >>>> > > > > >data model, but also of the policies > associated with > > > >>>> > > > > >the > > > >>>> > > service.) > > > >>>> > > > > >A service is a set of behaviors. (Not sure I'm on > > > >>>> > > > > >board > > > >>>> > > with this, > > > >>>> > > > > >something about behaviors doesn't sit well.) > > > >>>> > > > > > > > > >>>> > > > > >Given this, perhaps something like: > > > >>>> > > > > > > > > >>>> > > > > >"A service is a bounded set of capabilities that are > > > >>>> > > > > accessible through > > > >>>> > > > > >a prescribed interface." > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > >-- JJP > > > >>>> > > > > > > > > >>>> > > > > >P.S. I think this definition might just be > > > flexible enough > > > >>>> > > > > to navigate > > > >>>> > > > > >the service offer/contract discussion also. > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > >-----Original Message----- > > > >>>> > > > > >From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] > > > >>>> > > > > >Sent: Thursday, July 28, 2005 12:32 PM > > > >>>> > > > > >To: Frank McCabe; SOA-RM > > > >>>> > > > > >Subject: RE: [soa-rm] Definition(s) of "service" > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > >Frank, > > > >>>> > > > > > > > > >>>> > > > > >While I believe that the previously proposed > > > definition is > > > >>>> > > > > sufficient, > > > >>>> > > > > >I offer the following as a compromise. > Hopefully, the > > > >>>> notion of > > > >>>> > > > > >"capabilities" addresses your issue of > needing to get > > > >>>> > > things done. > > > >>>> > > > > > > > > >>>> > > > > >"A service is a set of behaviors to provide > > > >>>> > > > > >capabilities > > > >>>> > > > > accessible via > > > >>>> > > > > >a prescribed interface." > > > >>>> > > > > > > > > >>>> > > > > >Ron > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > >-----Original Message----- > > > >>>> > > > > >From: Frank McCabe > > > >>>> > > > > >[mailto:frank.mccabe@us.fujitsu.com] > > > >>>> > > > > >Sent: Thursday, July 28, 2005 10:10 AM > > > >>>> > > > > >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. 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 > > > >>>> > > > > >ti > > > >>>> > > > > > > > >>>> > > > > -- > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > -------------------------------------------------------------- > > > >>>> > > > > ------------------- > > > >>>> > > > > / Ken > > > >>>> > > > > Laskey > > > >>>> > > > > \ > > > >>>> > > > > | MITRE Corporation, M/S H305 phone: > > > >>>> 703-983-7934 | > > > >>>> > > > > | 7515 Colshire Drive fax: > > > >>>> > > > > 703-983-1379 | > > > >>>> > > > > \ McLean VA 22102-7508 > > > >>>> > > > > / > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > -------------------------------------------------------------- > > > >>>> > > > > -------------------- > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > >>>> > > -- > > > >>>> > > > > > >>>> > > > > > -------------------------------------------------------------- > > > >>>> > > ------------------- > > > >>>> > > / Ken > > > >>>> > > Laskey > > > >>>> > > \ > > > >>>> > > | MITRE Corporation, M/S H305 phone: > > > 703-983-7934 | > > > >>>> > > | 7515 Colshire Drive fax: > > > >>>> > > 703-983-1379 | > > > >>>> > > \ McLean VA 22102-7508 > > > >>>> > > / > > > >>>> > > > > > >>>> > > > > > -------------------------------------------------------------- > > > >>>> > > -------------------- > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > >>>> -- > > > >>>> > > > > ------------------------------------------------------------------- > > > >>>> -------------- > > > >>>> / Ken > > > >>>> Laskey > > > > > > >>>> \ > > > >>>> | MITRE Corporation, M/S H305 phone: > 703-983-7934 | > > > >>>> | 7515 Colshire Drive fax: > > > >>>> 703-983-1379 | > > > >>>> \ McLean VA > > > >>>> 22102-7508 / > > > >>>> > > > > ------------------------------------------------------------------- > > > >>>> --------------- > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> - > > > >>>> > > > >>> > > > >>> -- > > > >>> > > > > -------------------------------------------------------------------- > > > >>> ------------- > > > >>> / Ken > > > >>> Laskey > > > > > > >>> \ > > > >>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | > > > >>> | 7515 Colshire Drive fax: > > > >>> 703-983-1379 | > > > >>> \ McLean VA > > > >>> 22102-7508 / > > > >>> > > > > -------------------------------------------------------------------- > > > >>> -------------- > > > >>> > > > >> > > > >> > > > >> > > > > > > > > -- > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > > ----------- > > > > / Ken > > > > Laskey > > > > > > > \ > > > > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > > > > | 7515 Colshire Drive fax: > > > > 703-983-1379 | > > > > \ McLean VA > > > > 22102-7508 / > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > > ------------ > > > > > > > > > > > > > > > > > > > > -- > > -------------------------------------------------------------- > ------------------- > / Ken > Laskey > \ > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > | 7515 Colshire Drive fax: > 703-983-1379 | > \ McLean VA 22102-7508 > / > > -------------------------------------------------------------- > -------------------- > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]