RE: REST, uniformity and semantics

Frank, your Action SOA with INFORM, REQUEST, PROMISE, DECLARE is
interesting.  In the first place, I infer that your basic interest is
the possibility of providing some sort of base semantics for business
transactions.  That is, a small set of commonly understood terms that
everyone will recognise and can be used to build up more
industry-specific stuff.

That seems like a good idea to me, but I have two immediate reactions:

1 - I am certainly not an expert in this, and certainly others on this
list are more expert, but it is my impression that most people would
expect the base semantics for business to be much larger.  Put another
way, it seems to me that if you could convincingly demonstrate that such
a small set of terms is adequate to base business semantics, I think
that would be quite interesting.

2 - Aren't the UBL people thinking about, or going to think about, stuff
like this?

Now, on a more immediate level, if you are suggesting using these verbs
in the same way as GET/POST etc in HTTP, possibly enhancing HTTP -- I
don't see the point.  Would it be so that one could cache one's
acceptances of business offers, just in case one had a slow day in
business and wanted a few more offers accepted?  Or would it be so that
the details of business transactions would be visible at the network
router level?

In fact, I think that most business messages are part of extended
conversations and are, by their nature, unique.  Not candidates for
caching.  And in my experience most business transactions are properly
visible only at the very ends of the communication chain.  Although
there are certainly some exceptions (automated access to catalogues
comes to mind), I don't think that the REST paradigm works very well for
business.

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: Monday, May 12, 2003 2:58 PM
To: www-ws-arch@w3.org
Subject: REST, uniformity and semantics



This is a follow-up to a comment that I made in the last telcom. It 
represents my personal understanding of the relationship between 
REST/SOA etc.

It is possible to stratify the space of Web services along the 
following lines (going bottom-up):

Level 0: Transport SOA.

At this level we have notions of messages, transports, encodings (XML 
etc), package formats etc. etc. The key aspect of a SOA is that 
everything is defined in terms of the messages exchanged and not in 
terms of any particular processing of those messages.

What is particularly missing from this level is ANY commitment as to 
the processing/understanding implied by sending or receiving a message; 
all that you have is the text/DOM tree of the message itself. (You can 
add types with no loss of generality.)

Level 1: Open/Custom SOA

The extra interpretation/commitment incorporated by the notion of an 
Open or custom SOA is that it is possible for parties to describe -- 
using standard specs -- the processing/understanding entailed by 
sending or receiving a message. This may be in the form of an API-like 
model but does not have to be. Currently SOAP/WSDL go a long way to 
permitting this kind of SOA.

Level 2a: REST SOA

The extra interpretation added here is that we restrict our language to 
one that is appropriate for manipulating resources. This comes in two 
parts: a limited vocabulary (GET/PUT/POST/DELETE) and a particular 
interpretation of the `payload' of a message (in particular, the 
argument of a PUT and POST is the representation of a resource)

A Level 2a SOA has some attractions in that it captures the world of 
the Web pretty well; but requires some bending to deal with many (if 
not most) real-world interactions between legal entities: namely 
ACTION. This leads to:

Level 2b: ACTION SOA

(This is mythical, but demonstrates that there are many alternatives to 
REST)

The extra interpretation added in ACTION SOA is that we restrict our 
language to one that is appropriate for expressing actions between 
legal entities; here I suggest INFORM, REQUEST, PROMISE, DECLARE as a 
reasonable initial starting point. In addition, the `payload' of a 
message takes the form of a fact or an action.

The real point behind this message is that by taking this kind of 
stratified view of the different levels of Web services it is clearer 
(to me anyway) what the relationship between SOA, REST, Web services 
etc. etc. is.

I hope that this helps.

Frank

Received on Wednesday, 14 May 2003 09:14:35 UTC