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'm on board with this as well.  Wow.  What a productive thread!

-matt
John Harby wrote:

>"A service is a set of behaviors accessible via a prescribed interface."
>
>I like this one also.
>
>On 7/28/05, Oleg Mikulinsky <oleg.mikulinsky@weblayers.com> wrote:
>  
>
>>+1.
>>
>>I would prefer to remove the notion of boundary in favor of the
>>interface. As the definition of the interface implies boundary in my
>>mind.
>>
>>Oleg.
>>
>>-----Original Message-----
>>From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
>>Sent: Thursday, July 28, 2005 9:33 AM
>>To: Chiusano Joseph; soa-rm@lists.oasis-open.org
>>Subject: RE: [soa-rm] Definition(s) of "service"
>>
>>I like that as well.
>>
>>Ron
>>
>>
>>-----Original Message-----
>>From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>>Sent: Thursday, July 28, 2005 7:30 AM
>>To: soa-rm@lists.oasis-open.org
>>Subject: RE: [soa-rm] Definition(s) of "service"
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
>>>Sent: Thursday, July 28, 2005 9:27 AM
>>>To: Thomas Erl; soa-rm@lists.oasis-open.org
>>>Subject: RE: [soa-rm] Definition(s) of "service"
>>>
>>>Believe it or not I thought about this at about 2 AM this morning. I
>>>agree with Thomas that a service is a set of behaviors. To fully
>>>define a service in the context of a reference model for SOA, I
>>>suggest the following (a slight modification of Thomas' words)
>>>
>>>A service is a set of behaviors within a given action boundary
>>>accessible via a prescribed interface.
>>>      
>>>
>>I like that. I also wonder if the reference to a prescribed interface
>>might imply the notion of a boundary (or action boundary) - in which
>>case we can remove the reference to action boundary. The new version
>>would be:
>>
>>"A service is a set of behaviors accessible via a prescribed interface."
>>
>>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: Thomas Erl [mailto:thomas.erl@soasystems.com]
>>>Sent: Wednesday, July 27, 2005 8:23 PM
>>>To: soa-rm@lists.oasis-open.org
>>>Subject: Re: [soa-rm] Definition(s) of "service"
>>>
>>>
>>>I would view the interface and the action boundary as elements that
>>>partially comprise a service. I would therefore not state that a
>>>service
>>>*is* a prescribed interface or *is* an action boundary (to a set of
>>>behaviors). Would a service not represent a set of behaviors within a
>>>given action boundary accessible via a prescribed interface?
>>>
>>>Thomas
>>>
>>>----- Original Message -----
>>>From: "Behera, Prasanta" <pbehera@visa.com>
>>>To: <soa-rm@lists.oasis-open.org>
>>>Sent: Wednesday, July 27, 2005 5:05 PM
>>>Subject: RE: [soa-rm] Definition(s) of "service"
>>>
>>>
>>>
>>>Ron: "A service is a prescribed interface to a set of behaviors"
>>>Frank: "A service is an abstract action boundary to a set of
>>>behaviours"
>>>
>>>The difference between the two seems to be "prescribed interface" Vs.
>>>"abstract action boundary" (Skipping the "behaviors" and "behaviours"
>>>debate).
>>>
>>>I would lean more towards Ron's suggestion.
>>>Thanks,
>>>/Prasanta
>>>
>>>
>>>-----Original Message-----
>>>From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
>>>Sent: Wednesday, July 27, 2005 2: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"
>>>
>>>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]