RE: Proposed text on 'SOA' (resend)

hi, Bill,

Thanks for your very constructive comments. You did raise some quite
interesting points. I have added my comments within:
 > 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.  

+1 I would add that the contract is largely expressed through the 
documents passed in and out of the service.

<hh>+1</hh>

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

This is interesting. Would you be making a distinction between a 
service and an agent? If so, how does a service reduce coupling 
between agents?

<hh>Yes, services are provided by agents and agents consume services. There
are two types of coupling: real and artificial. You cannot reduce real
coupling, otherwise, your system is not the one people want.  However, you
can reduce artificial coupling or the cost of artificial coupling.  Service
itself does not reduce coupling but SOA can reduce artificial coupling using
the following constraints. </hh>


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

+1


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

+1


> An extensible schema allows new
> versions of services being introduced without breaking existing services.

I think I understand what you're saying, but I  don't belive a 
schema (syntactic constraints on a message) are adequate to prevent 
breakage (though they certainly help). You need extensible semantics 
or something like a model theory.

<hh>Agree but that goes one level up.  It would be nice if we can define
that. </hh>

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

> 2.	MUST define service contracts between providers and consumers.

I'm slightly concerned about this. While it's an obvious requirement 
to some level to define a contract, it's difficult to make this 
operational without a good sense of what is meant by 'a contract' - 
is there a definition of contract agreed by this group? I also don't 
know that the SOA's job is contract definition, which sounds 
somewhat centralised. I would express this as a system characteristic:

"2 MUST allow for providers and consumers to communicate through an 
explicit service contract"

<hh>That sounds good. </hh>

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

As a practical matter, consider sending all the needed information 
as a MUST (or at least an architectural risk if one decides not to). 
However that's somewhat different from being stateless - for example 
if I  send a transaction token in a message, it may well contain all 
the information needed, but that's not quite saying it's stateless.

<hh>Yes, that is the question. If a message contains references to some
context information shared between agents, would this still be stateless
messaging? </hh>

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

Granted. I'd suggest that in certain circumstances statefulness 
isn't avoidable and I would be looking for architectural guidance to 
manage state from this group rather than make moralizations about 
state being a 'bad' thing. I consider this lack of guidance a 
weakness of the current web, as evidenced by cookies - a solution 
that is the not unlike hiding the dead body in a shallow grave. 
Addressing the web's cookie problem can help WS greatly.


<hh>+1</hh>

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

I think you may want to declare a /class/ of messages entering a 
service idempotent.

<hh>Good point. </hh>

Hao