[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
All these people agreeing with me today...I can't take it anymore...:p Kind Regards, Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: John Harby [mailto:jharby@gmail.com] > Sent: Thursday, August 04, 2005 2:24 PM > To: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Definition(s) of "service" > > I agree. For example, I had a client that is an insurance > claims processor, they service many large insurance > companies. They found that every time they acquired a new > customer, they had to rewrite their code that did the agent > assignments and estimation handling. Their solution was to > move to an "SOA" where they designed many services and used > the orchestration to handle their processes. What they were > able to accomplish was reducing the problem of significant > changes to orchestrations only. In other words, the services > were not changed, only new BPEL was created for the most > part. This was a tremendous value add for the company. But > although some services such as DataTransformation were > orchestrations themselves and you could interpret that as > integration, the highest level container would be the > integration, not the service. Also, many services were not > compositions so would not qualify as containers. > > On 8/4/05, Chiusano Joseph <chiusano_joseph@bah.com> wrote: > > Depends on what we mean by "integration" - looking back at the > > messages below, I don't believe that the notion of a service > > "containing the integration" makes logical sense, as a service is > > "integrated" with another service and therefore the > "integration" really exists "external" > > to the service. > > > > Joe > > > > Joseph Chiusano > > Booz Allen Hamilton > > O: 703-902-6923 > > C: 202-251-0731 > > Visit us online@ http://www.boozallen.com > > > > > > > -----Original Message----- > > > From: John Harby [mailto:jharby@gmail.com] > > > Sent: Thursday, August 04, 2005 12:49 PM > > > To: soa-rm@lists.oasis-open.org > > > Subject: Re: [soa-rm] Definition(s) of "service" > > > > > > Why does the service need to contain the integration? I > would see it > > > as the other way around. I would think many services > should be able > > > to run standalone with no integration knowledge whatsoever. > > > > > > On 8/4/05, Ken Laskey <klaskey@mitre.org> wrote: > > > > The service is the container for the integration if the > > > integration is > > > > simple or the access to integration instructions (e.g. > > > > orchestration/choreography) if the integration is more complex. > > > > > > > > Ken > > > > > > > > At 11:47 AM 8/4/2005, John Harby wrote: > > > > >But what responsibility should the service have in > this "bringing > > > > >together of the parts"? > > > > >I would be very concerned about levying too much > responsibility > > > > >on the service for the integration. > > > > > > > > > >On 8/4/05, Ken Laskey <klaskey@mitre.org> wrote: > > > > > > 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. > > > > > > > > > > > > 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 > > > / > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > > ------------ > > > > > > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]