I couldn't come up with any reasons last week as to why .Net would revolutionize Web services. I've heard from many defenders of .Net during the past year, and not one of them has offered a credible argument regarding a unique advantage that .Net brings to the Web services table.
In fact, most .Net fans tend to wax rhapsodic over the ability to combine multiple languages via the Common Language Runtime (CLR) and Intermediate Language (IL) and ignore the Web services angle entirely. Some even fail to see the connection between the .Net framework, Web services and HailStorm/Passport, as if Microsoft created .Lang instead of .Net.
I suspect I know why so many .Net fans suffer from language myopia: Java. Java 2 Enterprise Edition (J2EE) is currently the de facto standard for Web services. Microsoft has to convince everyone that its CLR approach to programming is superior to Java before .Net can overtake J2EE.
So, how unique are the CLR and IL compared with Java? Not very. Java byte code is the key to providing language alternatives to Java. Lo and behold, the Java byte code instruction set is documented at http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions.doc.html for anyone who's interested in making his language compiler generate Java byte code. Some folks have already accomplished this feat. You can find a couple of Ada95 compilers that produce Java byte code.
A program called Jython (www.jython.org) lets you write programs in Python and compile them into Java byte code. Kawa (www.gnu.org/software/kawa/) generates Java byte code from a language called Scheme. Fans of IBM's Rexx language can use NetRexx to generate Java byte code (www2.hursley.ibm.com/netrexx/). There's no reason why you can't create Java classes with one language and use them with another.
One might wonder why there isn't a C++ compiler that generates Java byte code. The answer is simple. First, Java syntax is enough like C++ that a C++ compiler would be redundant. More important, however, is the fact that standard C++ doesn't map well to a Java environment. C++ lets you do dangerous things that Java prevents.
C++ also doesn't map well to .Net. That's why Microsoft's "managed C++" isn't the same as standard C++. Visual Basic doesn't map well to .Net either. Microsoft had to make significant changes to Visual Basic to make VB.Net work with the CLR.
So, what advantage is there in using the .Net CLR? Speed. The claim to fame for .Net programs is that they should run faster than standard Java programs regardless of the language you use.
Strictly speaking, this is true if you run Java programs via the Java Virtual Machine, which runs byte code. Byte code programs don't run as fast as native code, even when you speed up the byte code with just-in-time compilers. But this limitation exists only because Java is designed to be platform-neutral.
If you don't mind subverting the platform neutrality of Java, there are ways to compile your Java programs into fast-running native code.
For example, TowerJ (www.towerj.com) compiles Java byte code into native code, as does a product called Jove (www.instantiations.com/jove/product/thejovesystem.htm). The free software GNU compiler GCJ also compiles Java into native code, although it's largely a work in progress.
If the proponents of .Net are correct in assuming that people are clamoring for a development environment that lets you combine multiple languages and produce native code, then there's an easy way to test that assumption. All of these features have been available for Java for quite some time. So if the features are truly the long-awaited answer to someone's prayers, we should be able to find dozens, if not hundreds, of projects that combine Java with Ada95, Kawa, Jython and NetRexx, all compiled down to native code with TowerJ or Jove.
If instead we find that most people build J2EE projects in Java with, at most, a just-in-time compiler, then I suspect that the .Net fans are suffering from glassy-eyed gee-whizitis. I also suspect they're going to get a big dose of reality halfway into their first big projects.