[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
> -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Thursday, August 04, 2005 12:26 PM > To: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Definition(s) of "service" > > 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. Attached is a posting I just sent to the XML-DEV list (has not yet hit archives) - it highlights the various types of services (simple to complex integration), and may/may not resonate given your point above. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > 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 > / > > -------------------------------------------------------------- > -------------------- > > > >
--- Begin Message ---
- From: "Chiusano Joseph" <chiusano_joseph@bah.com>
- To: "Bullard, Claude L \(Len\)" <len.bullard@intergraph.com>,<xml-dev@lists.xml.org>
- Date: Thu, 4 Aug 2005 12:32:19 -0400
Ah - now I see where you're going. Yes, a "dispatcher" service can categorized in three ways: (1) a "composite" service, (2) a "coordinator" service, or (3) a "process" service. With (1), multiple services are invoked as needed by a "primary" (for lack of a better term) service. This is a classic case in which - for example - a primary service invokes another service to execute some calculation, and the result is returned to the primary service. With (2), a service (called a "coordinator" service) whose sole mission is to coordinate the interactions among multiple other services as part of a single activity exists. This coordinator service is more of an "infrastructure"-type service in that it is not carrying out domain- or application-specific functions. An example of an emerging standard in this area is OASIS WS-CAF (Web Services Composite Application Framework), while an example of a specification is the combination of WS-Coordination/WS-Transaction (with the understanding that WS-Transaction is comprised of 2 specifications, WS-AT (WS-Atomic Transaction) and WS-BA (WS-BusinessActivity)). And WS-CAF, given the "C" in its name, can be considered as category (1) above, although I think it is more (2) since it is infrastructure. With (3), the service's functionality, when carried out, actually causes a state change in one or more resources. That is, inventory may be reduced, an account may be debited, etc. This is also different from (1) in that (3) involves orchestration (sequencing of activity steps, dependencies among services, etc.). An example of a service in this category would be a Purchase Order service that may be expressed using a specification/emerging standard such as OASIS WS-BPEL (which is not yet ratified - but will be soon), or its predecessor BPEL4WS. Hope that helps-- Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com] > Sent: Thursday, August 04, 2005 12:14 PM > To: Chiusano Joseph; xml-dev@lists.xml.org > Subject: RE: [xml-dev] SOA and the Single URL > > Too bad. You missed a really fine party and a really bad war. > > The question is a good one. Services. In some approaches, a > single service may be acting as a dispatcher to other > services and the SOA is only exposing the one to the world. > > len > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > Sorry - I was born in the late 60s;) > > > but the > > question is, given an Enterprise Service Bus and an SOA, should one > > use a single URL to identify multiple processes? > > Yes, I know what a dispatching service is, but given REST > vs SOA, what > > do you think the consequences of a single URI approach are? > > Sorry Len, not following you 100% here - are you referring to > run-time processes, or separate services? >--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]