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

["Metz Rebekah" <metz_rebekah@bah.com>]

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