OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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]