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"


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