W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2003

Proposed text for SOA (1.6.2)

From: He, Hao <Hao.He@thomson.com.au>
Date: Wed, 13 Aug 2003 08:46:42 +1000
Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB046AE6F5@sydthqems01.int.tisa.com.au>
To: "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>
As discussed in the f2f, the current text on SOA is unclear.  I have taken
the action item to write more on SOA.

Hao


Service oriented architecture

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 it does not cause any change of state to its provider. A service
is defined 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.

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.


Received on Tuesday, 12 August 2003 18:44:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:22 GMT