RE: Loose coupling is like pornography

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

As you can imagine my keyboard does not like me that much ;-)


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

That's one way to distinguish the two approaches. The WSA people are saying:
you can use REST or SOAP and we give you an architecture that is vague
enough to supports both (e.g. WSDL can define REST methods) and we don't
preclude one or the other. The SOAP people are saying, thank you, we'll
mostly use SOAP and if it doesn't become pervasive we'll have to eat our
hats. The REST people are saying, you guys are going to eat your hats. But
they are also saying, we want to prevent you from having this option. It's
the last part that I don't understand, because being in the SOAP camp I
don't preclude REST, I just elect to use REST some of the time and use SOAP
some of the time.


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

Not sure I understand. The only thing you always need to know is the input,
if the operation has input. If it's an output only operation (HTTP GET) you
don't need to know anything. Though it's helpful if you do. If it requires
an input you need to somehow construct the input. Otherwise, how do you
propose we construct it? How can I send you a purchase order if I don't know
how to create one (regardless of whether I SOAP it or HTTP PUT it)?

What I need to know is the message schema. WSDL is one way to define the
message schema. I then need to encode it inside a SOAP envelope, put it
inside an HTTP message, break it into TCP packets, transform them into
Ethernet frames, etc. But that's standardized. It always happens the same
way, it's uniform, so I don't see the issue.


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

How about defining them in a separate schema?

Let SOAP be a way to encode multiple headers and body parts into a uniform
representation as an XML document.


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

That has yet to be determined.

So I have a message with two parts and I want to encrypt one using key A and
one using key B, and I want to carry my transaction identifier (like it or
not, I need to talk to a system that expects it), and I want to put an
expiration time that is calculated from my clock + time-to-live.

So I have a bunch of message handlers that do all that for me. And because
there's a uniform way to represent where the body goes and where the headers
go, they can do that for any SOAP message I sent. And at the other hand I
have handlers that can extract that information from the message without
having to understand the contents (the consumer does, though).

Now I want to do that without SOAP. Plain XML over HTTP. But these handlers
don't have a place where to put all the information. HTTP headers work, but
they're not XML. So I have to do a lot of binary coding there, just like we
do with cookies?

That's the value proposition of SOAP. It's a carrier mechanism just like
HTTP, but as opposed to HTTP the headers are XML and the parts are XML, and
they are all wrapped in an XML envelope. Otherwise, quid pro quo.

I just think SOAP is more XML-ized than plain XML over HTTP, that's all. It
costs a little, but we were discussing the loosely coupled proposition and I
think SOAP makes a better loosely coupled proposition as far as message
handlers are concerned. (Plus some other benefits)


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

Let's assume HTTPR is the only thing I need beyond HTTP. (In separate e-mail
I discussed security explaining why XML signature/encryption is better for
handlers/firewalls than SSL or PGP encryption of the entire message).

Wouldn't HTTPR be much better if and more decoupled if instead of working on
HTTP headers it worked on SOAP headers using XML, just like ebXML TRP and
WS-Reliability?

And what about transactions, security, authentication, etc? Do we want to
invent HTTP headers for all that? Would it not be more loosely coupled if we
elevated these into XML SOAP headers?

arkin

>
> Hao
>

Received on Friday, 10 January 2003 01:11:19 UTC