SOAP and State (was: Re: No consensus on draft findings on Unsafe Methods (whenToUseGet-7))

David Orchard wrote:
> 
> Paul,
> 
> I can't read every message that goes through my mailbox.  In the past 3
> months alone, I've gotten an average of 4 emails a day from you (369 to be
> exact).  And they are all typically long.  Granted, some are duplicates, but
> it's still impossible to read every new message.

Understandable. They are mostly repetitive because nobody else reads the
all either. ;)

> However, on this one I went through each of your links listed.  I never
> found something along the lines of "If you do POST always, xyz will happen
> and they are bad".  You've said that some stuff can't be used, like
> XInclude/XSLT/XQuery.  Interesting, but not a killer to me.  I do say this
> with sadness as an XInclude editor, BTW.

So even though there are various proposal on the table that would give
back compatibility with those tools you don't think that they are worth
pursuing?

Anyhow, those technologies are the canary in the mine-shaft.

There is a very subtle point I've been trying to get through with no
success. Let's take a paragraph from an article where Joel slams me
without really reading the article:

"The real problem with SOAP is that it's a completely inadequate
remoting system. It doesn't have events (which makes it useless for
large classes of applications). It doesn't support references (ditto)."

 * http://www.joelonsoftware.com/ 

Do you think that maybe Joel is on to something here? Nobody has ever
deployed a programming language, remote procedure system, database or
programming runtime without *SOME SUPPORT FOR REFERENCES TO STATE
FRAGMENTS*.

On the Web, URIs are the reference mechanism and HTTP has all sorts of
mechanisms for managing them. CORBA has object references, COM has some
similar features, etc.

Because SOAP lacks this, it must be done at the application level. This
means that every application invents its own addressing syntax (UUIDs in
UDDI, a 10-tuple in the Google doSearch API). This will be a killer
barrier to interoperability and service composition. Imagine trying to
compose a Java program with no references to objects. You can only call
functions, get back values, reorganize those values and pass them as
parameters to another function. It would never scale.

It also means that when you get into complicated web services, like
Hailstorm (may she rest in peace), you get really baroque addressing
models like red/blue elements. In the long run these will belie the
promise that web services are "easy to use" because you will have to
learn who a whole new data manipulation model for each and every family
of services. I don't think that anybody is consciously thinking of this
as an opportunity for lock-in, but it is.

I'm not trying to kill web services, I am trying to save them. 

> ...  You've said that GET/PUT/DELETE
> can be used.  That's fine, but not as compelling as saying it's broken.

I think that every working group's responsibility is to create
technologies that to whatever extent is possible enhance all of the
other W3C technologies and to whatever extent possible do not compete
with them. That's why the pointer technologies from XPointer and XSLT
were merged. That's why it would be inappropriate for the W3C to take on
a RELAX standarization project without deprecating XML Schema (or at
least clearly differentiating their market segments).

Now I will be happy with SOAP when people can use SOAP, URIs and HTTP as
three orthogonal technologies and get the *full* benefit of all three.
If SOAP had come to the W3C in another fashion I think that this request
would be fundamentally uncontroversial. We would have started out
saying: "Is this new protocol a replacement for HTTP or a complement to
it. If a replacement, how do we ensure that all of the virtues of HTTP
are maintained. If it is to be a complement...how?" 

Of all the SOAP services I've seen, every one gave up *substantial*
parts of the benefits of HTTP and URIs in order to use SOAP. That's not
an appropriate deployment record for a web protocol.

>...
> And as with all RESTafarians, 

;)

> ... you miss the point that sometimes (gasp)
> people want to use SOAP on things other than HTTP.  What some people want to
> do is have SOAP be a unified protocol on top of HTTP, SMTP, JMS, MQSeries,
> MyFavoriteMessagingProtocol, 

We're talking about an HTTP binding. While the message is on HTTP it
should be able to take advantage of all of the capabilities of HTTP.

If SOAP were a superset of HTTP's capabilities then it MIGHT make sense
to treat HTTP as "just another transport." But as I've shown and as I've
tried to express above, HTTP solves one of the most important problems
in a way that SOAP does not and likely will not as long as it is
"transport neutral."

> ... etc.  TimBL himself has said that the web is
> more protocols than HTTP. 

If we define a "web protocol" as one with capabilities for manipulating
web resources through URIs then we will probably find that once we do it
for HTTP it will be a lot easier to handle the rest of them also. As
Noah says, maybe we can do them all at once.

> ... So picking just HTTP POST makes software's job a
> LOT easier.  We might have an interesting discussion on why a whole bunch of
> other protocols is a bad idea, but that is a different issue.

Is it? If its a bad idea then forcing an HTTP-incompatibility in
exchange for a feature that won't work is a bad tradeoff.

 Paul Prescod

Received on Thursday, 25 April 2002 19:55:26 UTC