Re: REST, uniformity and semantics

Frank,

I wish people wouldn't make assertions like

"REST is really a semantic issue"

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. :-)

Finally, as to "levels"

1. "Messages have senders".

2. "Server space complexity is not linear in the number of clients."

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 11:55:42 UTC