[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
Joe, We found resource to be too much of an overloaded term and proposed capability as appropriately descriptive without as much overload. Again, however, I am more interested in understanding the concept than getting the best term at the start. Ken On Aug 8, 2005, at 6:02 PM, Chiusano Joseph wrote: >> -----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 >> / >> >> -------------------------------------------------------------- >> -------------------- >> >> >> >> >> ------------------------------------------------------------------------ ------------------ 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]