HTTPEctomy considered bad (was RE: RE: [xml-dev] MS thinks HTTP Needs Replacing???)

[Sean McGrath <sean.mcgrath@propylon.com>]

Here is one possible reading of the tea leaves of the HTTPectomy meme.

1) Vendors want you to think that SOAP solves all your problems. It 
doesn't. The layers
above SOAP solve your problems and you have to *buy* them. Like Dowty 
Trailblazer
modems in the Eighties, uber-SOAP stacks will work best talking to another
copy of themselves. There is a viral business model there.

2) SOAP will be transport independent. Doesn't that sound really appealing?
This mantra is already gathering pace. The fact that most developers trust deep
magic to make RPC work over both HTTP and SMTP without
thinking about the fundamentally different transport model of each is testimony
to how powerful that mantra is.

3) Developers will be urged to write to the SOAP "API"s exclusively in order
to insulate their  systems from transport dependencies. This will be
marketed as something all conscientious developers should do.

4) Vendors will build proprietary plug-in replacements for the HTTP transport
in their SOAP stacks. If you have stuck to the SOAP APIs, your code is 
safe, phew!

It is not that smart people working for the software vendors don't realize 
that RPC sucks.
They do. But many ordinary developers, short on time or inclination to 
think about the
future of the systems they are building, are easily enthralled by the 
surface simplicity
of RPC, and are the guys who buy stuff from vendors.

As the problems emerge with their RPC based designs, vendors will step in with
their plug-replaceable transport substrates to provide incremental improvements
for a fee.

Vendors will point to HTTP and say "it just couldn't cut it for reliable 
SOAP because
of X, Y and Z".

By the time they are doing that, I fear the world will have forgotten that REST
presented an alternative, and I would argue significantly more powerful,
data-flow based approach to building systems.

Sadly,
Sean