This comment -- NC + XML = .NET -- made several times on day one of Forum XML could be seen as the foundation of the presentation by Microsoft's Neil Hutson on day two: XML is the enabling technology that will make Network Computing possible.

The concept of network computing appeared during the nineties, and been heralded by most IT leaders. Lou Gerstner for Business Week, Oct 95:

In the wired future, says Gerstner, companies will be able to buy computing power and applications software the way they buy electric service. "They will rent them on a per-usage basis because they will be resident in the network," predicts Gerstner. "Think about the implications of a world in which the application is on the server--all applications."

Even though the press has largely placed the spotlight on Network Computers, the final target was already Network Computing and services. Larry Ellison for Red Herring, August 97:

Because the NC appliance is so visible on the desktop, people think of the NC as the center of our strategy. It's quite the opposite. Our strategy centers on the network. The NC is the vehicle whereby you access the network.

The reason why the concept that Microsoft was previously fiercely fighting has become the center of their strategy is probably to be found amongst the language and platform neutral enabling technologies that have arisen since this date. Whereas the vehicle for Network Computing was CORBA, an architecture that Microsoft had always considered as biased toward Java, it was very clear in Hutson's presentation that XML and its late binding protocols was what made this strategic shift possible.

While many speakers at Forum XML were celebrating XML's ability to perform late bindings, it is interesting to note that this is a hot topic on the W3C XML Protocols WG xml-dist-app@w3.org list. Noah Mendelsohn tried to explain how the new XML protocols will be different from older RPC mechanisms:

A traditional application of earlier Remote Procedure Call or ORB systems might be explained informally as: "I've got these objects lying around, how can I access them remotely?" In this view, the objects and their interfaces are a given, and the detailed semantics of their correct use are wrapped up in particular programming languages (e.g. Java) or objects systems (e.g. COM or CORBA). When building an RPC system for this world, success is proving that you can remotely expose these interfaces in all their detail. If you subscribe to this view for XP (I don't), then it is clear why you would want to specify and verify language bindings.

I believe that the interesting target for XP and SOAP is modeled very differently. Let's say that I want to offer a credit card validation service on the Web using XP RPC. I advertise (using WSDL, UDDI, talking to you on the phone or whatever) an XP interface which is a single method that takes as arguments a string credit card number and a decimal amount, and returns a Boolean to indicate whether the card is valid.

Could it be that, at the end of the day, what makes web services possible is only that we get accustomed to the web and start building new applications for it, rather than adapting old ones?

The explanation is too simple and relies on confusion according to Andrew Watson from the OMG:

We do *exactly* this in ORBs using IDL. As you point out, we do not want to know "anything about the programming technology used at one end of the line or another", and we don't have to. In your example, we would advertise an IDL "interface which is a single method that takes as arguments a string credit card number and a decimal amount, and returns a Boolean to indicate whether the card is valid". I've quoted your words exactly because they apply *exactly* to the ORB case.

The distinction you are trying to make between your XP proposal and long-established ORB technology does not exist.

Here again, the only distinction appears to be XML!

Related story:

• XML and e-business integration