Re: [soa-rm] Proposal on key service concepts

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

Once again, I have to raise a few heckles.

While the real world effect of using a service is critical, I do not  
think that *we* should be trying to define what that is.

Also, I feel pretty strongly that for scalability and future proofing  
purposes, we need to take a more hands-off approach to the RWE. I.e.,  
to extend the on-the-wire approach to service interaction to the RWE  
itself. What that means is that rather than talking about actions/ 
functions/execution performed by the service, talk about expectations  
arising from the interaction with the service.

Finally, a lot of the definitions below about service consumer/ 
provider are either not necessary or are more appropriate for a  
reference architecture.

Frank

On Aug 24, 2005, at 8:16 AM, Metz Rebekah wrote:

> NB: In the interest of length (and time) I have only worked through
> approximately 1/2 of the comments.
>
>
>>> So I have a somewhat heretical proposal for the committee.  I
>>> am coming to conclusion that service is not a normative term.
>>>  That is not to say that at the core of SOA is the concept of
>>> service.  A service is the performance of work by one for another.
>>>
>>
>> I propose that "the performance of work by one for another" may be
>> better termed "service execution", which is (simply) the execution of
>>
> a
>
>> service.
>>
>>
>
> I believe that, as a term, "service execution" is redundant.  It only
> appears to not be redundant because the term service has been used
> imprecisely to convey a group of related concepts, namely:
>
> 1) The capability to perform work for another
> 2) The specification of the work offered for another
> 3) The offer to perform work for another
> 4) The performance of work for another
>
> Because of this imprecision, we continually add qualifiers to the term
> service, such as "service offer", "service specification, "service
> execution", etc to add to the precision.  At the heart of my  
> proposal is
> really an approach to dealing with that imprecision.  We have found  
> that
> establishing precision for fundamental concepts is crucial to the
> success of our clients.
>
>
>>> What is typically, and nebulously, referred to as a
>>> service in SOA is actually a service offer.
>>> A service offer is a proposal to perform a mission function
>>> for others.
>>>
>>
>> I propose that this is more about service *availability* than an
>>
> actual
>
>> offer. A service is available, and the service consumer (getting into
>> the RA now) does not necessarily receive an active proposal from the
>> service provider - rather, the action is initiated by the service
>> consumer. An active proposal *may* be received from a service  
>> provider
>> in some cases, such as through a message exchange pattern (MEP) in
>>
> which
>
>> the service provider initiates the "dialogue" with the service
>>
> consumer,
>
>> perhaps by asking the service consumer some sort of question (e.g.  
>> "Do
>> you have any data for me right now?").
>>
>
> If a service is available, an offer to perform work for another has  
> been
> made.  There is nothing in the definition of service offer that speaks
> to an active nature of an offer.  An offer exists, it is not made.
>
> <snip>
>
>>
>>
>>> The use of the word "service" is adopted from the notion of
>>> business services in commerce.  The noun "service" is defined
>>> in dictionaries as the performance of work (a function) by
>>> one for another.  Service is "an act" not "a function," a
>>> common misperception is that services are functions.
>>>
>>
>> I would submit that at a certain (high) level, the terms "act" and
>> "function" may be considered synonymous (i.e. performing an act,
>> performing a function). I would propose that for purposes of our
>> abstract RM, these 2 terms mean the same thing.
>>
>>
> I had to read my own paragraph several times before your answer made
> sense.  I was unclear above.  I was focusing on the difference between
> service as the performance (i.e. an act) and the function which is
> actually performed.  I would be equally comfortable with "the
> performance of work (*an action*)."
>
> Notice however, that I use action rather than act.  Merriam Webster
> defines act as "the doing of a thing, something done voluntarily"
> whereas action is "a thing done."  The definition of action goes quite
> nicely with the definition of function, "any of a group of related
> actions contributing to a larger action."  There are subtle language
> differences here - which we can work around in conversation through
> debate and shared frame of reference.  However, these differences lead
> to imprecision which I believe is badness for a normative concept.  In
> particular, imprecision is bad for a normative concept with the
> potential to ripple as much as service concepts.
>
>
>>> There
>>> are several supporting definitions that also need clear
>>> definitions to accurately communicate the definition of a
>>> service offer.
>>>
>>> Mission Entity
>>> An entity operationally responsible for performing a mission
>>> function, or operationally in need of having a mission
>>> function performed.
>>>
>>
>> I would propose that for our purposes we drop the term "mission", as
>>
> it
>
>> is tied to more specific uses (such as military). We may there
>>
> consider
>
>> use of the term "entity", which may be a human or machine.
>>
>>
>>> Mission entities may include entities such as individuals
>>> (humans) as well as organizational units, etc.
>>>
>>
>> Agreed, for the term "entities".
>>
>>
>>> Service Provider
>>> The mission entity that performs a mission function for
>>> another mission entity
>>>
>>
>> I would propose that "service provider" be tied more closely to the
>> notion of service, as in "An entity that provides a service" (perhaps
>> that's too simple - may need to expand).
>>
>
> When you say that service provider is tied more closely with the  
> notion
> of service - it is unclear what notion you are talking about.   
> There are
> multiple notions of service - the offer, the performance, the
> specification, the work.  What this definition does is tie the concept
> of provider to real world stuff - in a precise way.  The provider
> *performs* _____.  The blank is most appropriately filled with mission
> function.
>
> Again, a service is the performance of work for another.  I believe  
> this
> too points back to a basic misconception that we are struggling to  
> shed.
> That misconception is that the term 'service', as a singular
> representation of several related concepts with all of their  
> nuances, is
> the central term of the reference model.  This misconception limits us
> from understanding why Service Oriented Architecture differs from  
> other
> Distributed Architectures (Object-Oriented, Component Based, etc).
>
> A service provider is some *thing* that does some work/action for
> someone else.  If the provider is doing it for self-purposes; we don't
> care, because it is not a service.  What we do care about is what that
> work/action is that is provided and the recognition that someone other
> that the entity that wants it done will perform it.
>
> See my earlier comments about using the term mission and entity (and
> I've read ahead, so I believe we'll get into that debate in a few  
> lines
> here).
>
>>
>>
>>> Service Consumer - The mission entity that requests to have a
>>> mission function performed by another mission entity
>>>
>>
>> Same proposal as with Service Provider.
>>
>>
>>> Service Offer
>>> A proposal to perform a mission function for others (Service
>>> Consumers) An offer is made by a specified Service Provider.
>>> Mission function behavior is described by a referenced (or embedded)
>>>
>>
>> I believe that the notion of a service offer is pertinent to our RA,
>>
> but
>
>> not our RM (I believe Matt has also said this in the past). Having
>>
> said
>
>> that, I believe this gets into the contracts aspect.
>>
>>
> Ah.  I see.  I would pose the question, how can a service be available
> if an offer is not made.  The concept that an offer is made is
> independent of any reference architecture that would delve into the
> details of how the offer is actually made, how a consumer knows about
> it, etc.  However, in any permutation, it does not change the fact  
> that
> an offer exists.  Same goes for a contract.  How can a mission  
> function
> be performed for another without recognizing the concepts f a contract
> (again - apart from how they are architected).
>
>
>>> Service Specification
>>> The mission function is made accessible at Service Access Points
>>>
>>
>> Should this have been "Service Function" instead of "Service
>> Specification"?
>>
>
> No.  A service offer is all about a mission function.  I do not  
> believe
> that service function has meaning outside of mission function offered.
> Again, I believe we will benefit from the use more precise and  
> accurate
> terms
>
>>
>>
>>> Service Specification
>>> A formal description of a mission function to be offered.
>>> Includes a description of how to interact (inputs/outputs and
>>> associated semantics)
>>>
>>
>> I would propose bringing this closer to the notion of service (as
>> "service" does not appear in the above definition). Something along
>>
> the
>
>> lines of a formal description of the capabilities, interface, etc.
>>
> etc.
>
>> of a service. I seem to recall that we have had a similar definition
>>
> in
>
>> the past, in our listserv threads.
>>
>>
> Certainly we've touched on these aspects in previous threads.   
> However,
> as service specification does not equal a service offer or a service
> provider or the performance of work.  It is a formal description of  
> the
> mission function.  I believe the service specification is a critical
> concept for the RM and is *not* a service.
>
>
>>> Service Access Point
>>> A logical location where a mission function is made accessible
>>>
> (a.k.a.
>
>>> "endpoint").  A mission function may be offered from one or
>>> more Access Points
>>>
>>
>> Same proposal as with Service Specification - e.g. an electronic
>> location at which a service may be accessed. May be a URI, IP  
>> address,
>> etc. etc.
>>
>
> I believe it is important to retain the notion of 'logical location'
> which is separate and distinct from the service provider agent(s) that
> are accessible through that service access point and which actually
> perform the mission function offered.
>
>
>>> Within this service concept, there are several implicit dualities.
>>> There is the duality of capability and need.  Without a need,
>>> there is no reason to perform work.
>>>
>>
>> Agreed - and sometimes services exist before a need is identified.
>>
> Why would a service exist before a need is identified?  A service  
> offer
> is exists to satisfy a perceived need.  Perception vs. actuality is
> irrelevant.
>
>>
>>
>>> Where there is a need, a
>>> capability to satisfy the need will eventually emerge.
>>>
>>
>> I would propose the opposite, as a need is not guaranteed to be  
>> met by
>>
> a
>
>> capability. For example, I have a need to be able to withdraw money
>>
> from
>
>> a bank account and have it come through a PDA - yet that capability
>>
> may
>
>> never emerge.
>>
>
> With the correct consideration (with the contracts-specific definition
> of consideration), eventually a capability will emerge.  The money may
> not be in the form you expect (dollar bills), but then don't really  
> need
> the $$, you need the ability to pay for things.  I believe there is  
> some
> capability to do this in Austria already with cellular phones.  It may
> challenge basic misconceptions about the capability, but the  
> capability
> need is ultimately addressed.
>
>
>>
>>
>>> There
>>> is the duality of service offer and service provider.  An
>>> offer to perform a mission function for another cannot exist
>>> unless some entity offers to perform that service.  That
>>> entity is a service provider.  A final duality is that of a
>>> service provider and a service consumer.  The existence of
>>> both entities is implicit in the definition of service; 'by
>>> one' and 'for another.'  This necessary duality of provider
>>> and consumer gains clarity when thinking about contracts and
>>> exchange of value.
>>>
>>> Outside of technology, these notions of service, service
>>> offer and service provider track well with the business
>>> world.  For example, a caterer offers to prepare and provide
>>> food (appetizers, accoutrements,
>>> etc) for another, typically in exchange for a fee.  A caterer
>>> may also perform these functions for himself (for example a
>>> caterer most probably prepares his meals).  However, even if
>>> the caterer prepares exactly the same food, we do not refer
>>> to this act of food preparation as a catering service.
>>>
>>
>> I would propose that the existence of a catering capability may be
>> referred to as a service (a noun).
>>
>
>
>>
>>
>>> It is
>>> only when we introduce the concept of performing this
>>> act for another can it be accurately described as a service.
>>>
>>
>> Please see comment just above.
>>
>>
>>>
>>> This distinction between service provider (by one) and
>>> service consumer (for another) depends heavily on
>>> perspective.  The distinction between these two entities
>>> rests squarely on the exchange of value.
>>>
>>
>> I would propose that this is not necessarily heavily dependent on
>> perspective. If an entity is a service provider, that can be seen in
>> black-and-white terms - the same for consumer. I keep in mind,
>>
> however,
>
>> that a service provider may also be a service consumer and vice- 
>> versa.
>>
>
> <snip>
>
>
>
>>> If, however, our perspective is at
>>> the level of the individual, the caterer does perform a
>>> service.
>>>
>>
>>
> Why would it be black and white?  The perspective is indicative of  
> when
> there is exchange of value.
>
>
>>> The value that is exchanges may not be monetary, it
>>> may only be gratitude.  Nonetheless, there is an exchange of
>>> value.  This exchange of value tracks well with the themes of
>>> an offer, contract and consideration.  This closes the loop
>>> back to the definition of service - "performance of work by
>>> one for another."  First, there is an offer to perform that
>>> work.  Then there is agreement between two parties, the
>>> entity which offers to perform that work and the entity which
>>> needs the work to be performed.
>>>
>>
>>
>>> The performance of work has
>>> value for the entity which needs to work to be performed.
>>>
>>
>> Hopefully that is the case - not always.
>>
> Can you give an example of when there is not value?
>
>>
>>
>>> In
>>> turn, this entity must provide something of value
>>> (consideration) to the service provider.
>>>
>>> So where does this leave SOA?
>>>
> <snip>  This has already gotten too long, I'll try to add the rest  
> into
> a different email.
>
>>
>> Joe
>>
>>
>
> It is always good to examine opinions.  Discussing different points of
> view help bring precision to core definitions and will improve the
> quality of our RM.
>
> Rebekah
>