Re: Proposed text on 'SOA' (resend)

Comments in-line

On Thursday, September 4, 2003, at 08:27  PM, He, Hao wrote:

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

This needs tightening up. You can't 'use' work that already been done, 
you can only use (i.e., activate) a potential for action. That is the 
essence of my definition of service.


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

This puts the cart before the horse. The *purpose* of using a service 
is to get something done. Changing state reflects the success or 
failure of that.


> A service is considered
> "safe" if agents do not incur obligations by invoking the service[1].

Unnecessary to the core concept of SOA


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

I thought that we agreed that the word contract was too loaded. While I 
agree that it may be accurate, it at least needs to be qualified here.

>
> The main purpose of SOA is to achieve loose coupling among software 
> agents
> through the following constraints:

I really think that this is upside-down thinking. As David O has 
pointed out, loose coupling is a property that is v. difficult to pin 
down.

The main purpose of the SOA is surely to permit a dynamically 
reconfigurable, world scale service network to be established across 
ownership boundaries. That in turn requires a form of loose coupling 
because without it the network would be too brittle to scale properly.

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

There has been a *lot* of ink spilled over this topic. I do not think 
that this reflects the consensus. And it is not clear why it is here.

For what it is worth, my real opinion is this:

Some kind of 'ubiquitous' interface is probably necessary. The reason 
being that a standardized semantics reduces the cost of entry to new 
participants and reduces the cost of integrating/combining services. 
However, while this might have a superficial resemblance to HTTP's GET 
etc., I do not believe that the resource-oriented model is sufficiently 
strong for the fundamental reason that service is about *action* not 
*resource*.

I think that something along the lines of speech acts is necessary. 
However, having said that, I also quite strongly believe that the 
community is not yet ready for speech acts, and that, for now, the 
community is going down the route of application-specific interfaces, 
specified in WSDL. Perhaps some genius will help us to sort out the 
coming mess :-)


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

A lot of the rest of this is unnecessarily over-detailed... Certainly, 
this text would not qualify for an elevator speech on SOAs.

Frank



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

Received on Tuesday, 9 September 2003 12:25:26 UTC