A stratification picture

This picture is intended to help clarify some of what I meant about 
stratification.

The white concepts belong to what I was calling level 0 stratification: 
We have a message, and the message has a sender. (There is of course 
much more)

The yellowed box (description) is at level 1. By having an agreed way 
of describing messages we can gain increased interoperability, 
primarily at the syntactic level.

The green boxes are examples of concepts belonging to a level 2 
stratification. REST, application specific and ACTION SOA are all 
alternatives.

The relationship between these concepts is interesting, as it also 
points to automation tools.

1. Having a machine readable description of a message allows tools to 
verify that a message conforms to the description, and may also help 
tools to generate conforming messages.

2. When a description encodes a semantics, that means that valid 
messages (in this case) are also valid entities in the semantics. In 
the case of REST, that would mean that we could state that a particular 
message is a GET message for example.

3. Similarly, when we state that a message satisfies a semantics, we 
state that the message is a valid POST message, or a valid invoice 
request message (in the case of application specific semantics). If it 
is possible to describe the semantics in a machine readable form, then 
we could have tools that automatically verify that a message is a valid 
REST message -- potentially meaning more than syntactic; it could 
include a check for example that a referenced URI denoted a valid 
resource.

Finally, some additional comments.

I believe that one of the key interoperability benefits that REST 
brings is a uniform view of the world. This brings a great deal of 
leverage in the sense that REST tools can offer utility at the level of 
resources etc. without being required to understand what the resources 
actually `are'.

On the other hand, the resource view of the world is not `spanning': 
there are many many situations where the REST perspective doesn't help 
very much.

The temptation is obviously to go into the application-specific or 
domain-specific direction; enabling application developers to use the 
technology in the way that fits their needs best; while giving as much 
support as we can.

However, imagine a world of 1 million+ different application-specific 
tailored Web services. We immediately have a big 
interoperability/integration problem all over again.

Hence, I believe that a longer term goal of the W3C should be to 
encourage the development of something like the ACTION SOA that should 
similarly allow leverage for large scale systems for non-REST like 
scenarios.

In the immediate term, having an architecture that can account for REST 
semantics, and application semantics, in a principled way seems to me 
to be pretty handy!

Frank