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


On Jul 28, 2005, at 7:49 AM, Matthew MacKenzie wrote:


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