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 don't think that the analogy is perfect. However, the steering  
wheel etc. is definitely an interface. And the purpose of the  
steering wheel is not to turn the wheel but to enable a change in  
direction of the car.

Frank

On Jul 28, 2005, at 9:15 AM, Chiusano Joseph wrote:


>> -----Original Message-----
>> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
>> Sent: Thursday, July 28, 2005 12:10 PM
>> 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.
>>
>>
>
> My car is a boundary between me and the road, but that is not its
> primary value - it gets me from point A to point B. That's the issue I
> have with focusing on boundary.
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> O: 703-902-6923
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
>
>
>> 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]