RE: Incorporating the REST and Loose Coupling threads into the WS A document (was RE: Myth of loose coupling)

Mike and Mark,

Some of the stuff I collected over time. Would this satisfy your proposal?

Comments, please!

Hao


Principles

The key value added by Web Services is that it enables information systems
to be 
loosely coupled together.  Loose coupling has the following meanings and/or
implications:
1. Reduced dependencies between systems.  Systems only have minimum
dependencies on others.
2. Late binding. Systems only know or understand the minimum about messages 
they are processing. They always defer processing as much as possible to
"expert" systems. 
This is also known as partial understanding.  The implication is to have
generic and 
uniform interfaces across all systems. 

A direct benefit of loose coupling is lower cost of coordination among
participating 
systems.

Basic REST architecture (this is from TAG)

According to Fielding:

"REST provides a set of architectural constraints that, when applied as a
whole, emphasizes scalability of component interactions, generality of
interfaces, independent deployment of components, and intermediary
components to reduce interaction latency, enforce security, and encapsulate
legacy systems." -- Roy Fielding, Section 5.5 of [6].

The basic REST constraints are: "
1. Client/server model. 
REST separates rendering concerns from the data model and control logic.
2. Stateless protocols
Each request from client to server contains all the necessary data for a
server to understand the request.
3. Caching
Some representations may be cached. Intermediaries may respond on behalf of
a server with the cached data.
4. Uniform Interface
The consistent constraints on interface between components, specifically
resource identification, resource manipulation through representations,
self-describing messages, and messages as the embodiment of application
state.
5. Layering
The encapsulation of each component so that components "know" only about the
components with which they are interacting.
6. Optional Code-on-demand
Clients may download and execute code (such as Java Applets, ActiveX
controls, scripts, and XSLT). ", [4]
Within the PTP context, constraints 1-5 are important while constraints 6 is
not significant currently.  Before applying those constraints, we need
refine them within the PTP context.


Additional REST constraints

1 No URI construction from clients: a client should not guess the structure
of a service URI.  The exception is that URI query is allowed only for
simple parameter passing. 
2 Safe GET: a GET operation to a service should not cause any side effect on
the server side.  A GET operation should be bound to MEP 1.
3 POST for unsafe operations.  Any request that can cause side effects on
the server side should be POSTed to the server. 
4 Idempotent POST. When a repeating POST request is received by a server,
the server should only return a receipt and ignore the request. From a
client's point of view, a POST request becomes idempotent.  Such constraint
only holds a period of time, determined by server implementation.
5 Uniform behavior: a client always receives a receipt regardless how its
request is processed.
6 Acknowledged asynchronous request: a client should receive a receipt for
each of its requests immediately and obtain its result later. 
7 XML messaging: all messages must be XML based and can be validated against
XML schema.  The exception is for simple URI query and GET only.
8 A service is identified by its URI.
9 A service type is identified by the schema its conforms to.  The same
client should be able to consume two services of the same type with changes
to the client itself apart from changing the server URI. 

REST Message exchange patterns:

1. Simple query type.  A client sends a simple query, which consists of a
small number of parameters, to a server, which returns query results.  Those
parameters together with their values can be used as a locator of query
result. Such a query does not cause any changes on the server side.
2. Complex query type. A client sends a complex query, which consists of a
large number of typed parameters, to a server, which returns query results.
There are additional relationships and constraints among those parameters.
Those parameters may not be used as a locator of query result. Such a query
usually needs additional work on the server side to validate the query.
3. Processing type. A client sends a complex message usually in XML together
with links to other resources, to a server, which needs to process the
message and take other necessary actions in order to return a message. This
MEP usually causes side effects on the server, usually by means of creating
new resources.
4. Notification type.  A server sends notifications to subscribed clients.
This type of MEP is much less frequent than other types.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Thursday, January 09, 2003 2:12 AM
To: www-ws-arch@w3.org
Subject: Incorporating the REST and Loose Coupling threads into the WSA
do cument (was RE: Myth of loose coupling)




-----Original Message-----
From: Abbie Barbir [mailto:abbieb@nortelnetworks.com]
Sent: Wednesday, January 08, 2003 9:54 AM
To: Champion, Mike; www-ws-arch@w3.org
Subject: RE: Myth of loose coupling



> PS: The question is when we will start moving fwd on the documents. 
> From the discussions on the list, it seems that we are stuck in the
sand.... 

Yes, ahem, I've gotten a few such reminders in private email :-)

So, although I'm mindful and respectful of the fact that this is a public
list and can't control where people want to go with it, I would ask everyone
to help us wrap this stuff up in a form that can be summarized in the WSA
document.  I think (and the people on the WG seem to think) that we have
identified a viable middle ground where the WSA will be *informed* by REST
principles and will *analyze* how they best complement and suggest
improvements in the SOAP and WSDL technologies, but will not adopt the REST
"paradigm" wholesale.  

At some point, Mark is just going to have to agree to disagree and do his
best to get the TAG or the Director to beat us up for him :-) if he thinks
there is any possibility that they will insist on an ideologically pure WS
Architecture document rather than a compromise that outlines the strengths
and weaknesses of various perspectives.   The chances of that, IMHO, are
infitesimal -- all W3C Recommendations are full of compromises. 

So, let's get on with documenting the principles and analyzing their utility
in different situations!