[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
I disagree. These are not bindings. These are three different applications that use the same service. We get into these problems if we forget about the Service Consumer. Michael At 05:56 PM 8/15/2005, Chiusano Joseph wrote: >Just got a thought on this thread from last week - original question >was: > > >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 > >I would say no - these are separate bindings (akin to SOAP's various >bindings). > >Joe > >Joseph Chiusano >Booz Allen Hamilton >O: 703-902-6923 >C: 202-251-0731 >Visit us online@ http://www.boozallen.com > > > > -----Original Message----- > > From: Ken Laskey [mailto:klaskey@mitre.org] > > Sent: Monday, August 08, 2005 10:43 AM > > To: soa-rm@lists.oasis-open.org > > Subject: RE: [soa-rm] Definition(s) of "service" > > > > 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 > > / > > > > -------------------------------------------------------------- > > -------------------- > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]