Re: REST, uniformity and semantics

Roger:
   I promise you that caching was far from my mind!!

   BTW I like the term ACTION SOA.

   I used an incredible amount of shorthand when I talked about INFORM 
etc. That is because I was trying to hint that there was more than one 
way of lifting from a described service network to a (words fail me 
here) useable service network (or at least one in which there is a 
greater amount of shared understanding.

   I am not sure about UBL; I would need to do more digging.

   The basic idea behind INFORM/REQUEST/PROMISE/DECLARE is that each 
message has essentially two parts: a `content' expression and a speech 
act that defines the force of the content.

   A simple example:

   Imagine that the message:


   <invoice/>

   stands for the statement `this is an invoice for the goods I sold you 
yesterday'

   Then

   <inform><invoice/></inform>

   means

   "I am telling you that there is this invoice"

   Whereas

   <declare><invoice/></declare>

   means

   "This is my official invoice to you for goods that I sold to you"

   and

   <request><invoice/></request>

   means "please give me your invoice" (The actual form of the content 
would probably be different for this case).

   The PROMISE verb doesn't seem to apply to invoices, but it does apply 
to signing and/or agreeing contracts.

   I may be that the base set of verbs would have to be larger; but our 
experience suggests that a larger vocabulary can be formed by 
`macro-ing' these primitives together.

   What is left unsaid here is that agreement/standardization is also 
needed on the form of the content structures too. That relates to some 
work on strong content languages that a few of my colleagues have been 
noodling over.


   I don't want to go overboard on this whole thing. At the 
architectural level, I see a couple of major points:

1. We need to account properly for any additional interpretation of the 
messages that flow between services. This is a gap in the current 
proposal; and I think that it is pretty important. I would suggest the 
stratification as a way of architecturally accounting for this.

   This includes REST; I.e., how to account for REST within the 
architecture.

2. The ACTION SOA model does hint at a higher-level view of Web 
services that could significantly enhance interoperability. By being 
able to account for it would prove the merit of the stratification 
approach.

Frank


On Wednesday, May 14, 2003, at 12:24  AM, Cutler, Roger (RogerCutler) 
wrote:

> 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 12:56:08 UTC