[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
The service primarily accesses behaviors of others. Behaviors associated with the service are the policies and effects included in its service description. Ken At 05:06 PM 7/27/2005, Chiusano Joseph wrote: > > Duane suggests: "A service is an abstract action boundary to > > a set of behaviours or the observable result of some functionality." > >Rather than think of a service as a boundary to something, can it also >be thought of as an entity that encapsulates (or "carries out") a set of >behaviors? > >Joe > >Joseph Chiusano >Booz Allen Hamilton >O: 703-902-6923 >C: 202-251-0731 >Visit us online@ http://www.boozallen.com > > > > -----Original Message----- > > From: Duane Nickull [mailto:dnickull@adobe.com] > > Sent: Wednesday, July 27, 2005 5:04 PM > > Cc: soa-rm@lists.oasis-open.org > > Subject: Re: [soa-rm] Definition(s) of "service" > > > > Perhaps combining all of these is closer to the answer: > > > > Duane suggests: "A service is an abstract action boundary to > > a set of behaviours or the observable result of some functionality." > > > > I would want to refrain from mentioning any actors such as > > provider, consumer, participant in this definition since we > > may define those later by referring to service (avoidance of > > circular references). I used the word "abstract" specific to > > our RM. In an RA, it may be a more concrete action boundary > > (see Microsoft def. below). > > > > More definitions of services: > > > > W3C says: "A Web service > > <http://www.w3.org/TR/ws-arch/#service> is an abstract notion > > that must be implemented by a concrete agent > > <http://www.w3.org/TR/ws-arch/#agent>." (Thank you W3C. I am > > more confused now. Next!) > > > > Microsoft says: "A software entity whose interactions with > > other entities are via messages. Note that that a service > > need not be connected to a network." (too concrete but good > > for RA. I wonder why they felt compelled to point out that it > > need not be connected to the network to be a service. This is > > in alignment with our notion of "a service is a service, even > > if not invoked" so I like that part.) > > > > CISCO says: "A group of related functions (or operations) > > that work together to provide a functional capability." > > (interesting but does really state what a service is, just > > what it represents). > > > > The US EPA says: "Breeding, the deposition of boar semen into > > the female." (Hmmm - probably not useful - let's leave this one alone) > > > > DOI says: "A defined result from a defined action ie, do X > > and the result will be Y. Services perform functions when > > invoked into action." > > (paraphrased slightly. Too concrete but interesting) > > > > Apple says: " A service is an I/O Kit entity, based on a > > subclass of IOService, that has been published with the > > registerService method and provides certain capabilities to > > other I/O Kit objects. In the I/O Kit's layered architecture, > > each layer is a client of the layer below it and a provider > > of services to the layer above it. A service type is > > identified by a matching dictionary that describes properties > > of the service. A nub or driver can provide services to other > > I/O Kit objects." > > > > I liked part of the latter analogy about the layering - being > > a slave to the entity above it while being a client of the > > entity below it. This effectively addresses the concept of > > service context. In one context, something is a service > > consumer while in another it is a service provider. The > > definition is far to specific to Apple but is useful to > > expand thinking. > > > > To continue extrapolating from Ken's ramblings, "Two things > > are needed to effectively use a capability under SOA: > > - understanding the underlying capability; > > - understanding the accessing service." > > > > I fundamentally think that all that is really required is an > > understanding of the behavioural aspects of the service, the > > data model the service uses, the other metadata and the > > policies of the service. > > > > Duane > > > > > > > > > > -- --------------------------------------------------------------------------------- / 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]