RE: Proposed text on 'SOA' (resend)

hi, David,

I agree with you that defining SOA using constraints is a good idea and the
approach taken by Roy is a good one.

However, I don't agree with the details you define SOA in [1].  My view is
that SOA is to achieve loose coupling via the two constraints I listed.  SOA
may not be REST but REST is an instance of SOA. Good Web Services are
instances of SOA as well but not all of them are good.  So if you have a
closed schema, you might still have a Web service but you have also defeated
the purpose of loose coupling.  Again, SOA is not the Web architecture
although the Web architecture is an instance of SOA.

Using this SOA definition, we can add additional constraints to get REST,
and WSDL/SOAP Web services as you suggested:
  
SOAP/WSDL Web service
SOAP/WSDL Web service introduces the following constraints:
1. Except for binary data, messages must be in SOAP.
2. The description of a service must be in WSDL.
SOAP Web service is the most common form of "Web service" in the industry.
There are two "favours" of SOAP Web Services: SOAP RPC Web service and
Document-centric SOAP Web service, depending on how SOAP is used.  
SOAP RPC Web service
A SOAP RPC Web service intended to be an SOA but breaks the second
constraint required by an SOA. A SOAP RPC Web service encodes Remote
Procedure Calls in SOAP messages. Effectively, it prescribes both system
behaviours and application semantics together.  Because system behaviours
are very difficult to prescribe in a distributed environment, applications
created with SOAP-RPC are not interoperable by nature. Many real-life
implementations have confirmed this statement. 

Hao
-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Saturday, September 06, 2003 9:25 AM
To: www-ws-arch@w3.org
Subject: RE: Proposed text on 'SOA' (resend)



A long time ago, I proposed what I thought were the constraints on SOA wrt
those defined for REST.  I think they are a better formulation of the
constraints on SOAs.  [1] Some of this made it into the web arch document in
1.6.3 (yes, somebody actually quoting the doc!) but it got totally watered
down (like dropping the layered client server aspect) and then muddled (the
"also, with emphasis on messages" and remaining paragraph). This is quite
frustrating, having contributions that are solid undergo such a morphing.
FYI, my assertion about representations being transferred in the post case
has been validated by the tag and is being described in the latest web arch
document.

I'll say again.  I think the web service architecture document should
describe any constraints that it applies to components and the relationships
between componenents.  I took a first pass at that and I think it's a good
start if the group decides to look at component architecture descriptions.
Describing technologies and their relationships is also good, but is
separate from the components.
>
> 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.
> The interfaces should be universally available for all providers and
> consumers.

huh?  What is "simple and ubiquitous" and "all participating software
agents"?  That sounds a like REST.  Either the interfaces are constrained,
or they're not.  I thought that we moving to a model of where REST is a more
constrained SOA.  This seems to say that SOA=REST.  Which is rather wrong.
I'll observe that there is a message oriented model that defines agents (so
why use "software agent") and messages and descriptions (but not interface).

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

I don't get this whatsoever.  A schema may limit portions of the vocabulary,
but not all.  It may or may not allow extensibility.  And having an
extensible schema by no means is sufficient to allow new versions of
services to be introduced in a backwards or forwards compatible way.  are
the constraints "1. all messages must be constrained by a schema.  2. said
schemas must be extensible"?  So if I create a closed schema it's not a web
service?  eek.

I completely agree that extensibility and evolvability are key properties of
the web and web services, and that we should look at how versioning should
be done.  Trick question: How does extensibility and evolvability for web
services differ than that of the web?  Answer: WSDL and SOAP are constraints
in web services.  We should describe what is different than the rest of the
web from an extensibility and evolvability perspective.

FYI, the TAG (particularly myself and Norm Walsh) is looking at the
evolvability and extensibility from a web perspective.  So let's not
reinvent web architecture (yet again) for web services.  Let's focus on what
is different about web services than the web.  And that's particularly soap
and wsdl.

> 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://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0055.html