RE: Proposed text for SOA (1.6.2)

hi, David,

Thanks for your comments.  

1. I agree that using TAG's "safe" definition is a good one.
2. About the first constraint: "Simple and ubiquitous interfaces to all
participating software agents. Zero or minimum application semantics is
encoded at the interfaces." What I intended to say was that the artificial
dependency at the interface level should be reduced to the minimum for all
agents. 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.
In other words, you want the cost of interfacing to be absolutely minimum in
an SOA.
3. About the second constraint: "Descriptive messages constrained by an
extensible schema. Zero or minimum system behaviours are prescribed by
messages."  The point here is that we should make messages descriptive.  It
is up to its receiver to decide what to do and how to do with it. The reason
is that it is very difficult (if not impossible) to prescribe
system/application behaviours in a distributed environment.  An extensible
schema allows partial-understanding, so a receiver can act on only the part
of the message. A real life example is that when you order a dish, you tell
your waitress what you would like but you don't tell her how to cook the
dish.  You can even tell her that you are studying quantum physics but she
can safely ignore that and still bring you the dish you want.

Do this make sense?

Hao


-----Original Message-----
From: David Booth
To: He, Hao; www-ws-arch@w3.org
Sent: 22/08/03 4:08
Subject: 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