Re: Proposed text on 'SOA' (resend)

He, Hao wrote:

Hao,

I'm glad someone is taking this on. Comments from someone who builds 
these things for living.


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


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


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


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


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


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


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

More generally with reagrd to the SOA style it's worth considering 
them in terms of David Gelertner's 'specialist parallelism' bucket.

Bill de hÓra
-- 
Technical Architect
Propylon
http://www.propylon.com

Received on Friday, 5 September 2003 16:07:08 UTC