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"


I also prefer Ron's version.

-matt
Chiusano Joseph wrote:

>>-----Original Message-----
>>From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] 
>>Sent: Wednesday, July 27, 2005 5:34 PM
>>To: Duane Nickull; Francis McCabe
>>Cc: soa-rm@lists.oasis-open.org
>>Subject: RE: [soa-rm] Definition(s) of "service"
>>
>>I briefly suggested something similar to this during the F2F
>>
>>I'll toss out a slight modification based on this thread to 
>>the TC for their reaction.
>>
>>"A service is a prescribed interface to a set of behaviors"
>>    
>>
>
>I like that much better.
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>O: 703-902-6923
>C: 202-251-0731
>Visit us online@ http://www.boozallen.com
>  
>  
>
>>Ron
>>
>>
>>-----Original Message-----
>>From: Duane Nickull [mailto:dnickull@adobe.com]
>>Sent: Wednesday, July 27, 2005 3:24 PM
>>To: Francis McCabe
>>Cc: soa-rm@lists.oasis-open.org
>>Subject: Re: [soa-rm] Definition(s) of "service"
>>
>>
>>Frank:
>>
>>I wasn't happy with "observable" either.  Perhaps firing up the ole' 
>>thesaurus to find out an "observable / effective / RWE" 
>>synonym would be a good idea or just being vague and not 
>>using the word. 
>>
>>The wording of this is becoming somewhat scatalogical in 
>>nature due to the amount of FUD in the industry ;-)
>>
>>Duane
>>
>>
>>
>>
>>Francis McCabe wrote:
>>
>>    
>>
>>>I rather like this definition. I agree completely that 
>>>      
>>>
>>service should 
>>    
>>
>>>not mention the delivery mechanism.  Some additional comments:
>>>
>>>Firstly, I would shorten it to:
>>>
>>>"A service is an abstract action boundary to a set of behaviours"
>>>
>>>Rationale: The service is distinct from the results of the service.
>>>
>>>Secondly, building on the notion that behaviour is different to 
>>>effect, I would go on to:
>>>
>>>"A service is an abstract action boundary to a set of effective 
>>>behaviours"
>>>
>>>Not sure about the word effective, as it may be ambiguous 
>>>      
>>>
>>in ordinary 
>>    
>>
>>>English.
>>>
>>>Frank
>>>
>>>
>>>
>>>
>>>
>>>
>>>On Jul 27, 2005, at 2:04 PM, Duane Nickull wrote:
>>>
>>>      
>>>
>>>>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]