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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----Original Message-----
> From: Metz Rebekah [mailto:metz_rebekah@bah.com] 
> Sent: Wednesday, August 10, 2005 12:06 PM
> To: SOA-RM
> Subject: [soa-rm] 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.

I am going to very respectfully differ with my good colleague here:) - I
believe that what is typically referred to as a service in SOA *is*
actually a service, which exists even before any type of offer is made.

Joe

Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com 

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