Why Web services will kill HTTP--eventually

That was the implication of a news article that appeared a couple months ago, but the story overstated matters a bit. As Microsoft XML Web services architect 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 site claiming that SOAP (Simple Object Access Protocol) 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-brain-dead 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 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 shoehorn 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? Will it die? Why or why not? If so, how soon? TalkBack to me below.

Larry Seltzer is a contributing editor for ZDNet Tech Update and has been writting software and computer articles since 1983. He has worked for software companies and IT departments, and has managed test labs at National Software Testing Labs, PC Week, and PC Magazine.