Re: Proposed text for SOA (1.6.2)

Hao,

Thanks for the work on this.  I have some suggestions in line below.

At 08:46 AM 8/13/2003 +1000, He, Hao wrote:
>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

s/centralises/centers/

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

I think it would be better to use the definition of "safe" provided by the 
TAG in http://www.w3.org/TR/webarch/#pr-deref-safe :

         "Safe retrieval: Agents do not incur obligations by retrieving a
         representation."

The key distinction here is that a safe interaction could cause a state 
change, but it does not incur an obligation.

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

I don't understand what you mean by this.

>The
>interfaces should be universally available for all providers and consumers.

I'm also not sure what you mean by this.

>2. Descriptive messages constrained by an extensible schema. Zero or minimum
>system behaviours are prescribed by messages.

I think this needs clarification also.

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

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Saturday, 23 August 2003 08:39:47 UTC