Re: REST, uniformity and semantics

Roger:
   I was elaborating a bit.

   What I do think is relevant to the WSA is (1) the key relationships 
of encodes and satisfies; and (2) we do need to account for REST. What 
I am proposing is that REST is really a semantic issue: the constraints 
imposed by REST represent a higher-level constraint than `messages have 
senders'

Frank

On Thursday, May 15, 2003, at 12:11  AM, Cutler, Roger (RogerCutler) 
wrote:

> I like this stuff, but is it germane to the WSA?  That's not an
> assertion, it is a question.
>
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Wednesday, May 14, 2003 11:56 AM
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: 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 Thursday, 15 May 2003 10:30:58 UTC