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

Paul,

SOAP can support remote references. Systinet WASP, Microsoft .NET, and XSOAP
all support remote references. There was a discussion on the axis-dev list
[1] in December about adding support for remote references. Jacek (Systinet)
and Alek (Indiana University) explain their two approaches in this thread.
In both cases the approach is transport-independent, which, as Dave said, is
one of the primary goals of SOAP.

Obviously we have incompatible SOAP header structures in each of these
products, but one of the things we'd like to do at W3C is establish
*standards* for these things: remote references, conversations, security,
transactions, routing, attachments, etc, etc. That's why we're here.

[1] http://marc.theaimsgroup.com/?t=100807673100003&r=1&w=2

Best regards,
Anne


> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
> Paul Prescod
> Sent: Thursday, April 25, 2002 7: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))
>
>
> 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 Friday, 26 April 2002 09:05:07 UTC