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"


> -----Original Message-----
> From: Ken Laskey [mailto:klaskey@mitre.org] 
> Sent: Thursday, August 04, 2005 10:18 AM
> To: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Definition(s) of "service"
> 
> I'd still like to emphasize service as the access to 
> capabilities for which there are extra-service motivations 
> for their existence and requirements for use of the 
> capabilities that must be navigated by the service.  Thus,
> 
> "A service is a mechanism to enable access to a set of 
> capabilities, 

I would say that access control mechanisms enable such access, and that
the service *provides* the capabilities. Note: Use of "access control"
is too concrete for our RM - I stated it only to illustrate the point.

Joe

Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
> where the access is provided using a prescribed 
> interface and is exercised consistent with constraints and 
> policies as specified by the service description."
> 
> Ken
> 
> At 11:15 PM 8/3/2005, joe@pantella.net wrote:
> 
> >Just trying to sort through this; some common themes that seem to be
> >acceptable:
> >
> >A service provides capabilities.
> >A service is accessible. (If this is true, then service cannot be a
> >verb.) A service has an interface. (If this is true, then a 
> service has 
> >a boundary.) A service interface is prescribed. (Then a 
> service and its 
> >interface are distinct, and the interface has associated rules.  I'm 
> >not sure this is true, the interface may describe the rules, 
> but Im not 
> >sure it has rules.  In fact, I'm inclined to suggest that 
> the interface 
> >defines the rules for accessing the service.  Which would lead me to 
> >suggest that the service interface is more than a 
> specification of the 
> >data model, but also of the policies associated with the service.) A 
> >service is a set of behaviors.  (Not sure I'm on board with this, 
> >something about behaviors doesn't sit well.)
> >
> >Given this, perhaps something like:
> >
> >"A service is a bounded set of capabilities that are 
> accessible through 
> >a prescribed interface."
> >
> >
> >-- JJP
> >
> >P.S. I think this definition might just be flexible enough 
> to navigate 
> >the service offer/contract discussion also.
> >
> >
> >-----Original Message-----
> >From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> >Sent: Thursday, July 28, 2005 12:32 PM
> >To: Frank McCabe; SOA-RM
> >Subject: RE: [soa-rm] Definition(s) of "service"
> >
> >
> >Frank,
> >
> >While I believe that the previously proposed definition is 
> sufficient, 
> >I offer the following as a compromise. Hopefully, the notion of 
> >"capabilities" addresses your issue of needing to get things done.
> >
> >"A service is a set of behaviors to provide capabilities 
> accessible via 
> >a prescribed interface."
> >
> >Ron
> >
> >
> >-----Original Message-----
> >From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> >Sent: Thursday, July 28, 2005 10:10 AM
> >To: SOA-RM
> >Subject: Re: [soa-rm] Definition(s) of "service"
> >
> >
> >I hesitate to spoil this party ... but I'm going to :)
> >
> >1. There is a distinction between action and result. (Just ask any
> >roboticist) Behaviour sounds a child misbehaving with no discernible 
> >effect. Computer Scientists have a tendency to focus on the purely 
> >technical aspects of their work: bytes shuffling around at random 
> >within hopefully enormous memories.
> >2. Also, we have to bear in mind that nobody invests 
> millions of $s (or 
> >even 100's of them) in systems that contemplate their navels 
> or have no 
> >business payoff. I think that we have to directly address the reason 
> >that services are deployed.
> >3. One of the movitating best practice aspects of SOAs is 
> that clarity 
> >and 'separation' between the providers of services and the 
> consumers of 
> >services leads to more scalable and robust architectures.
> >
> >All of the above is fuzzy language; but, at the same time,  
> "A service 
> >is a set of behaviors accessible via a prescribed interface."
> >sounds a lot like bureauspeak.
> >
> >I believe that there is strong consensus on the following
> >characteristics:
> >a. The concept of service is 'at the boundary' between service 
> >providers and consumers.
> >b. The service is 'there' to get things done; but doesn't 
> itself denote 
> >the engine that performs the tasks.
> >c. There is a reason for using a service.
> >d. There is a lot of extra metalogical information about 
> services that 
> >make it possible for third parties to develop partners for services.
> >
> >I, for one, would prefer a strongly anglo-saxon phrasing of the 
> >definition of service that speaks to these points.
> >
> >Frank
> >ti
> 
> --
>       
> --------------------------------------------------------------
> -------------------
>    /   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]