RE: Proposed text for section 1.6.2 and 1.6.3

ok i'm going to bite (who put the worm on the hook????)



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Wednesday, May 07, 2003 7:03 PM
> To: www-ws-arch@w3.org
> Subject: Re: Proposed text for section 1.6.2 and 1.6.3
>
>
>
> On Wed, May 07, 2003 at 05:00:30PM -0400, Champion, Mike wrote:
> > > I'm surprised to see that distinction drawn.  I think it's quite clear
> > > that RESTful Web services can do that too, because I order
> > > books through
> > > my browser, and people move around to deliver me those books as a
> > > result.  8-)
> >
> > I'm struggling with the idea that an API SOA would invoke some code that
> > causes the books to be shipped, and a REST SOA would manipulate an
> > information resource that a human or software agent could interpret as a
> > request to ship the books.
>
> That doesn't seem to be an apples-to-apples comparison though.  I'd
> say that both styles could be described in either of those terms.
>
> But if I understand what you're getting at, I'd say that in both cases
> the code behind the interface would "cause the books to be shipped".
> The difference is that with the REST approach, the orderBooks() method
> is invoked by the code behind the POST (i.e. the code that puts that
> system "on the Web"), whereas with API SOAs, orderBooks() is invoked
> directly.

So how are these REALLY different?

In both cases there is "order book" implementation code on the server and
this impl code gets up called from a protocol stack.

In the SOA case, the SOA Protocol (acronym not implied:-) receives a request
at a particular transport endpoint, and has to look somewhere
in the envelope to find out which implementation code to upcall.
If there is nothing recognizable in the  envelope that matches some code to
upcall, then there is some sort of type mismatch and the request fails.
It's true that at the application programming level the client calls "order
books" but that is just an api on to a proxy that sits on top of the
protocol stack - its convenience code.

In the REST case, each impl code will have its own transport endpoint, and
thus there is no need for the rest stack to look inside any envelope to
decide what to upcall - as you say the code behind the post knows what impl
to upcall. The impl code however now has to check whether it understands the
contents it is given (such as PO in this case). If it doesn't then some sort
of type mismatch has occurred and the request fails. In this approach, it is
possible to  post multiple content types to the same port, with the impl
code deciding what to do based on the content; the dispatch code in the case
is in the impl code.


So some observations:
0) both solutions require agreement on the application content model
(types/schemas etc)
1) both solutions have to maintain some form of mapping so as to be able to
dispatch a request to the correct impl code
2) both solutions can end in failure if unrecognizable content is received
3) the impl code in soa can assume the correct contents are received
(syntactically speaking)
4) the imlp code in the rest case has to check the type of the contents to
see if it is  something it can handle
5) the processing model  for both  is identical: receive request, examine
content, decide application functionality to invoke (reject if can't decide)
6) both solutions require code changes if the application content model
changes, and in both cases there are mechnisms to help maintain
   client backwards compatibility.

Cheers,
   Martin.

Received on Thursday, 8 May 2003 16:38:10 UTC