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"


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]