On rumors of HTTP's death

Is Microsoft out to get HTTP?

This was the implication of a news article a few weeks back, but the story overstated matters a bit. As Microsoft's Don Box said in a conversation with me, HTTP is way too pervasive not to dominate Web services for some time now. But it's still a less than ideal protocol for much of what's planned for Web services.

Protocols are a major source of confusion these days with respect to Web services. Even security expert Bruce Schneier blew it in a recent article on his own site claiming that SOAP requires HTTP. He cites unspecified "Microsoft documentation" for this claim, but the quote he provides is actually from an article in a Microsoft developer magazine.

Schneier was spooked by the article's claim that SOAP would breeze through firewalls since everyone leaves port 80 wide open. Of course, any non-braindead corporate firewall would block incoming  HTTP, at least to most client addresses in the network. And it won't be long before firewalls are SOAP-aware and can deal with the particulars of its use and potential abuse.

That's because SOAP is protocol-independent and does not rely on HTTP. Microsoft has demonstrated SOAP using numerous transports including SMTP and SneakerNet (yes, that's floppy disks). This article, shows how to use SOAP over several other transports.

So what's the problem with HTTP? HTTP was specifically designed for Web surfing, not for general program interoperability. It's connectionless and asymmetric, and not designed for operations with long latency, such as a request that requires 5 minutes of processing at the server. Some firewall or gateway is going to disconnect the client on the assumption that something has gone wrong.

The other knock on HTTP in the news article was that it's not well-suited to peer-to-peer applications, and indeed it is miserably suited to them. Of course, I'm not a big fan of P2P and I don't see a big role for it in Web services, but this does reinforce the general point that it's not practical in the long term to shoe-horn inappropriate applications into an HTTP infrastructure.

The way HTTP works is that a client makes a request and a server responds. But what if the server needs to initiate some operation with the client? Either the client needs also to be an HTTP server (the security nightmare that Schneier feared), or you've got to play some sort of weird programming trick to get it to work, like having the clients periodically poll the servers.

As part of the GXA effort, Microsoft is working on a number of higher-order meta-protocols that address some of the protocol problems in Web services. The most relevant here is the Web Services Routing Protocol (WS-Routing). Even though SOAP specifies who the parties are in a transported message, it says nothing concrete about the routing of that message.

WS-Routing is just one of numerous SOAP-based protocols that Microsoft and others are using to make the infrastructure of the Internet more amenable to Web services. WS-Inspection defines the ability to inspect a site for available services; WS-Referral deals with configuration of nodes along a SOAP message route; WS-Security provides credential exchange, message integrity, and message confidentiality to Web services; and WS-License describes the license types in a WS-Security tag.

I find all this rather reassuring. A mad rush into Web services would probably be a bad thing, as we would all likely make serious mistakes. But it's going to be many years before we really get the knack of this Web services thing, and perhaps by then we'll have built a good infrastructure for them and worked out the numerous issues, only some of them technical, that need to be resolved before we can actually rely on them on a wide scale.

Web services are a great idea and corporations should definitely be experimenting with them, both as providers and consumers. But it's clear that it's going to be a while before they can be the main way we do business on the Internet. Go slow.

What's your take on the ultimate fate of HTTP? Speak your mind in our TalkBack forum, or send an e-mail to Larry.