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

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

Please see below for my additional comments on the "proposal on key
service concepts" presented 2 weeks ago.

Joe

Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.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.  

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.

> 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?").

> A service is the actual performance of that work by a service 
> provide for a service consumer.  

Please see above (I see this as "service execution").

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

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

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

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

Should this have been "Service Function" instead of "Service
Specification"?

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

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

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

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

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

> Consider a caterer 
> that prepares food for his wife.  

Probably a rare occurrence, since he is probably so tired of preparing
food by the time he gets home. Lucky wife. ;)

> If our perspective is the 
> "household"; then food preparation is really an internal 
> function, not a service.  

Sounds good.

> If, however, our perspective is at 
> the level of the individual, the caterer does perform a 
> service.  

Did not follow that (sorry).

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

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

One may also say that it follows from 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 

Q: Do SOA services *have* to be *business* services? And what are
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.  

And lots more steps, of course;)
 
> 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.  

I would propose that for our RM (and probably even RA) purposes, the
notion of "agent" may be too low-level, and we may be able to do without
it and still convey the proper concepts.

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

Amen.

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