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: Proposal on key service concepts


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.  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.
A service is the actual performance of that work by a service provide
for a service consumer.  

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.  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.
Mission entities may include entities such as individuals (humans) as
well as organizational units, etc.

Service Provider
The mission entity that performs a mission function for another mission
entity

Service Consumer - The mission entity that requests to have a mission
function performed by another mission entity

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) 

Service Specification 
The mission function is made accessible at Service Access Points

Service Specification
A formal description of a mission function to be offered.  Includes a
description of how to interact (inputs/outputs and associated semantics)

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

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.  Where there is a need, a capability to
satisfy the need will eventually emerge.  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.  It is only when we introduce the concept of performing this
act for another can it be accurately described as a service.   

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.  Consider a
caterer that prepares food for his wife.  If our perspective is the
"household"; then food preparation is really an internal function, not a
service.  If, however, our perspective is at the level of the
individual, the caterer does perform a service.  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.  In turn, this entity must provide something of value
(consideration) to the service provider.  

So where does this leave SOA?

Consider first the definition for architecture - the structure of
components, their relationships, and the principles and guidelines
governing their design and evolution over time.  

In the technical sphere, people often equate architecture with design.
However, design is only a part of architecture; it is the representation
of structure and relationships.  Architecture encompasses more than just
design, it is a methodology to evaluate questions like:  what are the
appropriate components?  What aspects of relationships are critical to
represent?  What are the principles that guide these selections?  What
are the criteria that are used to shape design decisions?  

Therefore, SOA is a methodology whereby business services are the key
organizing principles that drive the design of IT to be aligned with
business needs.  These business needs may be about is the buying and
selling, or exchange, of goods and services.  In the government,
business needs are suitably described as mission needs.  

It is often difficult for those of us (myself certainly included) with a
technical background to recognize how "adopting a SOA approach" will
transform the way we think about systems.  There are three sequential
areas of analysis:
1)	An operational analysis of the mission needs and mission
functions to satisfy that need.  
2)	A definition of service specifications for service offers
3)	Analysis of the access points and agents that make accessible
and implement those mission functions.  

This third step is where we start getting into the design of software
and devices that actually implement a mission function as a Service
Provider Agent.  Often, such agents are defined using Web Service
technologies.  Joe identified an important difference between creation
of a Web Service and the creation of a SOA.  Let me take that a step
farther.  Focusing only on definition and development of web services
will not automatically result in the alignment of technology with
business needs.  Therefore, developing web services does not imply a SOA
Focus.  

Rebekah

Rebekah Metz
Associate
Booz Allen Hamilton
Voice:  (703) 377-1471
Fax:     (703) 902-3457




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]