> I hear everything from "DCOM for the web" to "just an envelope
> format" [and] from RPC to "fully asychronous." Why would we even try
> to put all of those things into one spec?

Here's the problem: the Web Services stack is more subdivided than the
Web stack.

The Web Web Services
=================================================================
Encoding (HTML) Data Format/App Logic (e.g. OFX, RSS...)
Transport/App Logic (HTTP) Envelope (SOAP, XML-RPC)
Encoding (XML)
Transport (HTTP, IM, SMTP, BXXP, ...)

(I mean Transport in the FTP/HTTP sense, the transport protocol that
in turn makes use of TCP or UDP or whatever.)

Because the goal here is to add flexibility everywhere, layers lower
than the data format itself make many fewer assumptions about the
application logic or the transport binding than the Web stack
does. Now you can argue, as the RESTanians do, that this is The Wrong
Answer, and I'm sympathetic to that view, but if your goal is
something that looks like the stack above, you need just enough
structure to encapsulate XML into something that is both transport and
data-format insensitive, without adding so much structure that it
forestalls undreamt of uses.

Thus much of the bloat of SOAP comes not from designing it to do
certain things, but from bending over backwards not to design it to do
*only* certain things. One of the big issues for the 1.1->1.2/XMLP
move was how many design patterns it should support other than RPC,
and a lot of the confusion about its being both a dessert topping and
a floor wax comes from its being (((not (not a dessert topping)) and
(not (not a floor wax))).

-clay