RE: Loose coupling is like pornography

hi, Assaf,

You must have four hands typing.  How can you answer four emails at the same
time? ;)

Anyway, my comments are within as usual.

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

<hh>Ok. If SOAP is everywhere already, there is no point of having this
discussion.  
We will just have to "brain-wash" all REST advocates with SOAP.
However, we are still in the process of determining which approach is
better: using 
SOAP or extending HTTP based on REST. SOAP advocates have the advantage of
being 
supported by major vendors.  However, REST advocates have the advantage of
easier 
implementation, despite of the lack of tools. </hh>

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

<hh>I could be wrong here but I don't think REST would prevent one from
knowing
the message schema.  I do agree that there is no standard way of informing
clients
where the schema is in REST.  The only difference here is that in SOAP, you
need to know
the SOAP schema before you can know the actual message schema. </hh>


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.

<hh>Agree that business applications needs more semantics beyond GET and
POST.  However, 
the question is whether we define them in SOAP or simply in a separate
schema. </hh>


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


<hh>Agree. The question is: if we can do all these without SOAP, why
bother?</hh>

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

<hh>I believe this is an implementation issue. You could just as easily
provide a notification service
so the client does not have to poll. </hh>

> 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?

<hh>Sorry, I did not make it clear here.  What I meant was that if could do
reliable
messaging using HTTP (by extending it, for example the HTTPR by IBM), then
we don't 
need SOAP. So the question becomes: which is easier: to build RM on top of
HTTP or SOAP? 
We have built a simple RM on top of HTTP and it works quite well for our
purpose.  Of course,
what we have done is not for general purpose so it cannot be used to answer
this question.
Still, it appears to me that extending HTTP headers is easier. </hh>

Hao