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

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
> Sent: Thursday, April 25, 2002 4:56 PM
> To: David Orchard; www-tag@w3.org
> Subject: SOAP and State (was: Re: No consensus on draft findings on
> Unsafe Methods (whenToUseGet-7))
>
>

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

Oh, I totally do.  In fact, about 3 years ago I worked on a SOAP/HTTP GET
binding.  I think doing a binding of some kind is very valuable.  I've
suggested that the TAG should ask the web services architecture WG to look
at it.  Remember, wsawg owns the usage scenarios and requirements for any
new or rechartered wg is in the web services arena.  I just don't think that
not doing GET as a required binding makes web services in a state of sin and
in dread contradiction of the web, and therefore they should be booted from
w3c.  For some reason, that just seems a very bizarre and naive suggestion.

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

Paul, I don't want to spend too much time on this.  Here's yet another
example of where revisionist history is happening.  Most web sites do NOT
use URLs for state management, despite all the claims that they can.  Most
web sites use cookies for this purpose.  If we made "SOAP Cookies", or "SOAP
Biscuits", that functioned similarly, would that solve your remoting issue?

I find it somewhat funny that many of the folks that knock the SOAP world
often use the same arguments that were used against the web.  "It doesn't
have state" "oh look, here's cookies".  "No security" "oh look, SSL".  The
web services world will go through evolution as well.

<snip/>

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

But HTTP was never developed this way.  SSL came afterwards.  Cookies came
after.  Digital Certificates came after.  HTTP 1.1 came after 1.0.  CSS came
after.   XSL came after.  Dynamic HTML came after.  Java came after.
There's a whole reality that was built up over time around certain usage
scenarios.  The criteria for deciding whether to do the web was that we
could do interesting things right away, and that it was evolvable.  The Web
Services folks want the same right to evolve.  In fact, they will insist
upon it.  And they can do interesting things right away, and it's evolvable.

How could SOAP have come to the W3C in a different fashion?  Some members
proposed it, but the W3C didn't really want to do it at the time.  Now that
there is momentum in web services, members now want the W3C to be the forum.

<snip/>

Cheers,
Dave

Received on Thursday, 25 April 2002 20:24:05 UTC