Re: REST, uniformity and semantics

You take me out of context:
>
> I wish people wouldn't make assertions like
>
> "REST is really a semantic issue"

This is shorthand for: the REST constraints represent constraints on 
the semantics of message delivery.

>
> because in the first place, the irony is so intense as to
> be painful (statements about "semantics" whose meaning
> I can't seem to extract, no matter how hard I try)
>
> and in the second place, all of "services", as I understand
> it (them) is "really a semantic issue".  If a change wrought on
> your behalf (you are the client) has no meaning to you,
> hence no "semantic", then it COULD NOT be a service.  Not
> no way; not nohow. :-)

Well, I guess you have semantics, Semantics and SEMANTICS :-)

>
> Finally, as to "levels"
>
> 1. "Messages have senders".
>
> 2. "Server space complexity is not linear in the number of clients."

This would be a `level 2' assertion; however, I don't see what kind of 
constraint this is. How do I measure conformance to it?

Frank

>
> Which of those statements is at the "higher" "level", please?
>
> (For those who didn't recognize it, #2 is one of the REST
> constraints.)
>
> --Walden
>
>
> ----- Original Message -----
> From: "Francis McCabe" <fgm@fla.fujitsu.com>
> To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
> Cc: <www-ws-arch@w3.org>
> Sent: Thursday, May 15, 2003 10:30 AM
> Subject: 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 12:23:43 UTC