Microsoft has been successful in the desktop operating systems and applications market for many years but has yet to achieve similar success in the areas of large-scale enterprise and Internet systems, highly distributed systems, and devices. The .NET initiative is Microsoft’s attempt to make greater inroads into these markets.
Microsoft .NET is an ambitious initiative with the goal of providing an integrated platform for the creation, distribution, and execution of applications. While Microsoft .NET is a general-purpose development platform, it has been designed from inception to use many open Internet standards and offers strong support for highly scalable distributed applications, in particular XML Web services.
Comparisons of Java and .NET are common. Although it is undeniable that the Java platform provides the foundation for the primary competition .NET will face, the scope of the .NET initiative is much greater. Not only does .NET provide a framework in which applications can be developed and run, it also encompasses the development tools and a broad range of server products used by the applications.
The XML standard was not formalized when Java was first released; nonetheless, Java has been able to offer XML support through third-party solutions for many years. However, it is only with the JAX series of APIs that broad Java support for XML is being standardized; the first component, JAXP, is now part of the standard distribution as of Java 2 Standard Edition (J2SE) version 1.4.
Microsoft recognizes the importance of XML and has built strong XML support deeply into the .NET platform. The use of XML and related technologies is critical to the .NET strategy for systems integration and realizing Microsoft’s vision of .NET being the platform of choice for the development and delivery of XML Web services.
Java has always been platform neutral and has embraced the slogan write once, run anywhere. Implementations of the Java Virtual Machine (JVM) and the Java 2 software development kit (J2SDK) are available for most existing platforms, and it’s common for developers to write applications on one platform and deploy to another—for example, developing on low-cost Microsoft Windows or Linux machines but deploying to higher-cost server farms and clusters running a variant of UNIX.
Unfortunately, the consistency that the Java platform provides can also be a limitation; Java programmers are often unable to take advantage of specialized hardware and operating system features without making use of the clumsy Java Native Interface (JNI). As an example, features such as asynchronous I/O have become available to Java programmers only with J2SE version 1.4 but have been available in mainstream operating systems for many years.
These limitations aside, the ability to target a range of platforms has been incredibly successful and is one of the reasons behind the widespread adoption of Java. Sun Microsystems has made significant marketing mileage from this ability, and rightly so, since the advantages to developers and companies alike are obvious and immediate.
Microsoft has taken a different approach to platform support. The .NET Framework is built around the features of the Windows operating system and relies on many of the features of the Win32 API.
However, Microsoft has defined the platform adaptation layer (PAL), which defines the Win32 API calls that are used by the .NET Framework, and a shared source implementation (known as Rotor) of the European Computer Manufacturers Association (ECMA) common language infrastructure (CLI), which is built on the PAL. In principle, porting the PAL to a new platform (that is, mapping the Win32 API calls to native calls) should allow Rotor to run on the new platform.
The catch is that the ECMA CLI standard contains a subset of the .NET Framework features and excludes key elements such as database access (ADO.NET), GUI toolkits (Windows Forms), and server-side applications (ASP.NET). The Rotor implementation is available for noncommercial use and cannot be used to build competing products. Rotor is not based on the source code behind the commercial .NET Framework and is currently available for Windows and FreeBSD.
The Java language specification is at the heart of the Java platform. Attempts have been made to port other languages to the platform—most notably Jython, a version of the Python language that generates Java byte code for execution in a JVM—but there has been little adoption of these alternatives to this point, and for the most part applications that run on the Java platform are written in the Java language.
Microsoft has stated that the .NET platform is language-neutral and that .NET applications and components can be written in any language. Like a lot of marketing information, there is an element of truth in this statement, but it’s not entirely correct.
.NET does support multiple languages, but it isn’t the case that any arbitrary language can be used. Only languages that conform to the common type system (CTS) are supported, and, as a result, .NET-supported languages tend to have slightly modified syntax. For example, Microsoft Visual Basic and Visual Basic .NET are not the same language. Likewise, an experienced C++ programmer will have to understand the changes in Managed Extensions to C++ before being able to write a .NET application. The .NET Framework is biased toward object-oriented languages, so procedural languages such as C are unlikely to be introduced, and if they are, they will still be subject to syntax changes.
Although not a stated goal of .NET, it is very much in the interests of Microsoft and its customers for many of Microsoft’s overlapping and competing products and technologies to be rationalized and consolidated. The .NET platform presents the ideal scenario for such an exercise, making it more palatable to the user community because the new technology will offer greater integration with the .NET platform.