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