RE: T is for Transfer

> Given the reality of the industry, we need to find the best 
> resolution to both sides of the transport/transfer argument. 
> SOAP envelopes will be "sent" via HTTP, BUT we also need to 
> preserve SOAP's protocol neutrality.  I like Joe's PDU view 
> of the SOAP envelope sitting on top of HTTP(see snip below), 
> but HTTP does provide features we should not ignore.  
> Concerns addressed by Scott Cantor (and others) should be 
> addressed by separate HTTP Bindings.

That's ok with me, certainly, but as others have noted from time to
time, I'm not so sure you folks are going to get anywhere useful with
your default binding in the long run. Not because custom RPC and
messaging is useless, but because the key difference between SOAP and
the earlier ways of doing them seems to me to be a temporary and
misguided firewall hide and seek game. Inside the firewall, I guess if
you really need yet another way to do the same stuff, have at it.

> Until the process of publishing a 
> Normative Protocol Binding is ironed out and well understood, 
> developers may be driven to use the Default HTTP POST binding 
> even if another HTTP method is more appropriate for their application.
>
> Thoughts?

That's certainly a necessary thing if SOAP's protocol neutrality is
going to be of any real use.

The vast majority of the developers, however, are using (or will use)
the default binding because they want to do RPC over HTTP and the
vendors are encouraging it. The apps will follow the tools, and the
focus is almost entirely on RPC from where I sit. I don't think the mere
presence of an "official" HTTP application-friendly binding will cause
developers in general to use it, especially if there aren't a lot of
press releases and tools behind it.

But, I think for those of us that would like to see how SOAP could
complement the use of XML-based resource representations on the web,
having a binding to interoperate with would be a great thing, so if the
XMLP group has ruled it to be out of scope for now, then it's up to
somebody else to do it or we wait.

-- Scott

Received on Friday, 29 March 2002 03:47:58 UTC