RE: Loose coupling is like pornography

> > So, to really compare between REST and SOAP, we just need to look
> > at compare
> > the artificial dependency and the cost introduced by them.

Not really trying to do a comparison matrix, just saving a lot of back &
forth messages and being overly chatty ;-)

>
> Let me speculate. REST advocates would point out that in REST the only
> artificial dependency is HTTP itself, while in SOAP you have both HTTP and
> SOAP. SOAP avocates will argue that using TCP without HTTP has even less
> artificial dependency, but since SOAP is becoming ubiquitous, this is a
> non-factor.
>
> <hh>Didn't understand the logic here.  SOAP always has more artificial
> dependency here. </hh>

Explain?

If you don't have HTTP servers then the least amount of AD is TCP. HTTP
introduces AD. But HTTP is ubiquitous so it's not an issue. Having HTTP is
like having a TCP stack. It's always there. SOAP requires something on top
of HTTP. Enforce XML, enveloping, attachements, etc. But if you assume SOAP
is ubiqituous and every system has SOAP just like it has HTTP, then there's
no additional AD.

There's an implicit assumption here that the SOAP advocates are making. They
are assuming SOAP is pervasive technology. Every system from mobile phones
to brand new spanking app servers to legacy 2-ton mainframes is going to be
SOAP-enabled. So SOAP is a non-issue. They could be wrong. They could be
right. If they're wrong than we're in deep s*&t, time to reconsider.


> REST advocates would then point out you don't need to know anything about
> the structure of the message so the artificial dependency is lower. WSA
> advocates would point out that in practice you do need to know
> the structure
> of the message (or at least machines do, we humans don't), and since the
> problem they are addressing (machine understanding) requires that, they
> would consider REST and SOAP to be equivalent.
>
> <hh>It is not always true that one always needs to know the
> structure of the
> message. In fact, for
> different consumers/handlers, each of them only needs to know the
> part they
> need to know.  So, the
> problem is do we require consumers/handlers to know all the structure up
> front or at their choice.
> With SOAP, one needs to know SOAP up-front. With REST, it does not prevent
> you from knowing the structure and it offers you the choice of not knowing
> the structure. It appears REST wins this round.</hh>

Here's the assumption. All applications need to know the message schema.
Even your Web browser needs to know whether it's HTML or PDF. How much they
need to know about the message schema is a different issue. Maybe all you
care is that it's some piece of text. So your message schema is xsd:anyType.
Maybe you need to know it's a BOM PO. So your definition needs to be more
precise.

Now, if you don't need to know what the message schema is beyond the fact
that there's some content there, then it works the same way if you use REST
or SOAP. Look at an HTTP server. Its a handler and it doesn't know what the
message schema is and surprisingly it can pass SOAP messages around. Look at
MOMs. They don't need to know what the message schema is, they are handlers,
and again they can move SOAP messages around.

But if you look at the purchase order fulfillment, it just won't work if you
send it any old document you happen to have. You need to send it a purchase
order. You can make the same application support different schemas using,
e.g. XSLT, but you still need to send a purchase order.

So what the WSA architecture is saying is: for those consumers that do need
to know what the message schema is, we define it. For those that don't, you
can leave it opaque. Handlers can live a happy and fruitful life without
knowning anything. For some reason, the REST people advocate an approach by
which even if you needed to know the message schema to determine it's a PO
and not the local weather report, you won't be able to do so.


> REST advocates would then point out you only need to know four
> methods: GET,
> PUT, DELETE and POST. SOAP advocates would point out you only need to know
> two methods: GET and POST. REST advocates would point out that
> all you need
> is a URI, SOAP advocates would point out that it's a message
> encoding issue,
> XML vs URI makes no difference, and besides it's URL not URI. URLs are not
> loosely coupled.
> <hh>I agree that you only need to know GET and POST so the REST Artificial
> Dependency (AD) is even lower. I don't agree that all you need is a URI.
> XML is far superior to URI encoding.  Since XML
> technology is universally available, the XML AD cost is lower than URI
> encoding. </hh>

So that's two points for SOAP? ;-)


> REST advocates would point out that you can expect an operation to have
> specific semantics based on the method name, SOAP advocates would
> point out
> not having to manage the individual state transitions of the service
> actually reduces coupling.
> <hh>If you don't put any semantics on the method name at all, the overall
> cost of AD will be actually
> higher since everyone has to come up with their own semantics.

True. So what REST is saying is that all methods are equivalent. I mean, all
methods would give me the local weather report. And all PUT operations are
free of charge.

What we are seeing in business applications is that semantics are beyond "I
get information/I change information". There's also the "I get information
and pay for it", the "I ask to change information and accept partial
change", the "I give you information but don't expect any change to happen",
the "I don't give you any information I just ask you to stop doing what
you're doing". There's the semantics of "I ask you do to this but I'm not
committed" and the semantic of "this is commited and enforced by law".

I wish the semantic issue could be narrowed down to just GET vs PUT. Then we
won't need XML Schema or RDF or even a PDF definition of the service and
what it does. That would make a whole lot of problems disappear.


> On the other
> extreme, if you put all
> semantics on the method name, you introduce too much AD (this is
> effectively
> RPC). So, the middle
> ground is to put some generic semantics on the method name.  GET and POST
> seems to be universally understood so the AD cost is low. </hh>

I definitely agree that there are two semantics that should be captured in
the method name. GET should be retrieval of information only, POST should be
the dissimenation of information. I don't agree with the current WSDL
approach that lets you mix and match. But saying that's all the semantics
you need is kind of avoiding the real problem. There's way more semantics
that need to be expressed.


> <hh>I agree that you can build loosely coupled system from SOAP using the
> document centric approach.
> However, the question is whether it is more loosely coupled when compared
> with an equivalent system built with REST. IHO, it is less. </hh>

Still has to be proven that it's more loosely coupled with REST, because you
can define a uniform interface given SOAP that would only differ from HTTP
by having different encoding. Instead of identifying the resource with a
URL, you would identify it with a URI. Instead of getting the information
blank you would have to extract it from a standardized schema. And you could
call that operation tns:get. So you could deine a uniform interface at the
SOAP level and achieve what REST calls connector (or something like that)
and be RESTful and SOAPful and happy and merry.


> REST advocates would then explain how you put a queue in the middle to
> decouple the services, SOAP advocates would point out that you
> need to know
> there's a queue, so the SOAP approach is more loosely coupled.
>
> <hh>The queue should be invisible to consumers.  This is an AD
> introduced by
> implementation, not by REST
> itself. </hh>

Due to certain constraints which I for one do not understand the REST people
have decided to remove the deliver aspect of the queue and instead elect to
constantly poll. So given this example which has been circulated around, it
actually required higher AD. You need to know the response won't come back
to you and continue polling for it. In the SOAP approach you just sit and
wait. There's also less information management since you don't need to
record the URL of the queue where you would poll for the response.


> Deadlock?
>
> <hh>Not really. SOAP advocates can win if they can put some real
> values into
> the SOAP header and therefore reducing the overall cost of SOAP AD. For
> example, if doing reliable messaging is too difficult without
> SOAP, then one
> would have to use SOAP. REST advocates can win if they can do
> similar things
> simply using HTTP. If I can get reliable messaging for free in HTTP, why
> should I bother with SOAP?  Currently, it is difficult to see what real
> value SOAP really provides apart from doing RPC over HTTP (but we
> agree that
> RPC is not loosely coupled). </hh>

There's an implicit assumption that with REST all you need is REST. We know
that with SOAP you need headers. But given that assumption SOAP doesn't buy
anything.

So how do you do reliable messaging over when you don't get it for free with
HTTP? And if you get reliable messaging for free from HTTP, why do we have
so many specifications out there that deal with reliable messaging? And why
it's not reliable?

arkin


>
>
>
> Hao
>

Received on Thursday, 9 January 2003 23:59:27 UTC