[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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 / > > ---------------------------------------------------------------------- > ------------ > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]