[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Re

• To: xml-dev@l...
• Subject: HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Replacing???)
• From: Sean McGrath <sean.mcgrath@p...>
• Date: Wed, 27 Feb 2002 09:06:57 +0000
• In-reply-to: <NCBBKFMJCLIMOBIGKFMJIEBDHEAA.ldodds@i...>
• References: <82W1YFD4208C0SQFASQEANMFE077293.3c7bcaf8@MChamp>

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 [expletive deleted].
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

• Follow-Ups:
  • RE: HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Replacing???)
    • From: Bill de hÓra <dehora@e...>
  • Re: HTTPEctomy considered bad (was RE: RE: MS thinksHTTP Needs Replacing???)
    • From: Paul Prescod <paul@p...>
  • Re: HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Replacing???)
    • From: John Cowan <cowan@m...>

• Prev by Date: RE: Namespaces best practices
• Next by Date: Re: HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Replacing???)
• Previous by thread: RE: Namespaces best practices
• Next by thread: Re: HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Replacing???)
• Index(es):
  • Date
  • Thread