Proposed text on 'SOA' (resend)

Per my action item from today's phone meeting, I am POSTing my text on SOA
again.  The main purpose is to give a better definition of SOA, its purposes
and architectural constraints it uses to achieve its goals.  The text has
incorporated comments from David Booth in the explanation.

Hao


An SOA is a style of software architecture, which centralises on the concept
of service. A service is a unit of work done by a service provider to
achieve desired end results for a service consumer. Both provider and
consumer are roles played by software agents on behalf of their owners. The
end results are usually the change of state for the consumer but can also be
the change of state for the provider or for both. A service is considered
"safe" if agents do not incur obligations by invoking the service[1]. A
service is specified by a contract between a provider and a consumer.  A
contract typically prescribes the means of service consumption and expected
end results from a consumer's prospect. Additionally, quality of service may
also be specified.  

The main purpose of SOA is to achieve loose coupling among software agents
through the following constraints:
1.	Simple and ubiquitous interfaces to all participating software
agents. Zero or minimum application semantics is encoded at the interfaces.
The interfaces should be universally available for all providers and
consumers. 
2.	Descriptive messages constrained by an extensible schema. Zero or
minimum system behaviours are prescribed by messages. A schema limits the
vocabulary and structure of messages. An extensible schema allows new
versions of services being introduced without breaking existing services.

Explanation:

1. The purpose of constraint 1 is to reduce the artificial dependency at the
interface level for all agents and therefore reduce the cost of consuming
and providing services. For example, one might create a special service
interface but then the interface requires a very specific language,
platform, in a very specific manner. In such an example, it is a violation
of this constraint. 

2. The motivation behind constraint 2 is that It is it is very difficult (if
not impossible) to prescribe system/application behaviours in a distributed
environment. It is up to the receivers of a message to decide what to do and
how to do with it. An extensible schema allows partial-understanding, so a
receiver can act on only part of a message. This allows a complicated
service to be decomposed into smaller services and evolve independently from
consumers.


An SOA,
1.	MUST provide a mechanism that enables the communication between a
provider and a consumer under the context of a service sought by the
consumer. 
2.	MUST define service contracts between providers and consumers.

Optional constraints:
1.	Stateless messaging. Each message that a consumer sends to a
provider must contain all information necessary for the provider to process
the message.   This constraint makes a service provider more scalable
because it does not store state information about consumers. 
2.	Stateful messaging. Both the consumer and the provider share the
same consumer specific context, which is either included or referenced by
messages exchanged between the provider and the consumer. This constraint
makes the communication between a provider and a consumer more efficient but
reduces the overall scalability of the service provider because it must
remember the shared context for each consumer.  It increases the coupling
between a service provider and a consumer and makes switching service
providers more difficult.
3.	Idempotent messaging.  Duplicated messages received by a software
agent cause exactly the same effects as a single unique message does.  This
constraint allows providers and consumers to improve the overall service
reliability by simply repeating messaging if faults are encountered.


[1] http://www.w3.org/TR/webarch/#pr-deref-safe