Home > Articles > Programming > Java

  • Print
  • + Share This
From the author of

.NET Perspective

On the other side of the fence, Microsoft's vision for building enterprise applications in the .NET development world is twofold: developer choice and platform interoperability. The former is built into the CLR, which allows any language to use the services of the CLR, such as the forthcoming Visual Basic .NET, Visual C# .NET, JScript .NET, and Visual C++ with Managed Extensions, and do things such as use implementation inheritance across languages. In addition, Microsoft is working with more than 20 other language vendors to create compilers for the CLR.

From the J2EE perspective, there are two primary problems with this vision. First, it is claimed that organizations want to standardize the development process rather than further fragment it by introducing new versions of languages such as COBOL and Eiffel into their IT organizations. The maintenance of a multilanguage project is sure to be much more costly than a project implemented in a single well-accepted language such as Java.

Furthermore, the critics note the displeasure of developers in the VB community to the relatively minor language changes in VB.NET. This indicates that support for the CLR comes with a price that many developers won't want to pay and causes incompatibilities so great that no existing code will be capable of running without extensive rework. However, Microsoft supporters note that retraining existing developers to use Java is probably more difficult than using a somewhat modified form of a language that they're already familiar with. Secondly, from Microsoft's perspective, the idea of multilanguage projects within the same IT shop is less realistic than the need for IT shops to be capable of standardizing on any one of the 20-plus languages that support the CLR. Perhaps more importantly, the capability to create compatible components in a variety of languages means that IT shops can purchase components written in any of the CLR languages and reuse them (through implementation inheritance, if desired).

On another front, Microsoft is moving to standardize C# and the Common Language Specification by submitting them to the standards body ECMA.


Sun touts 2.5 million Java developers, while Microsoft claims more than 6 million for Visual Studio.

The second part of the vision for Microsoft is interoperability across platforms. This is clearly seen in Microsoft's fervent embrace of XML, SOAP, and WSDL for creating XML Web Services. And so Microsoft's message is essentially, "You very seldom want to port an existing application between platforms, so platform neutrality, even if achievable, is not very interesting. But you do want to interoperate between applications regardless of platform; therefore, industry standard support for Web Services is much more important." To that end, IBM is in partial agreement with Microsoft and has rapidly moved to include SOAP support in its products. In addition, BEA will support the creation of Web Services through industry-standard protocols in its WebLogic 6.1 product.

The wholehearted embrace of Web Services has led Microsoft to incorporate SOAP, XML, HTTP, WSDL, and XPath into the very heart of .NET, the .NET Framework, as well as its supporting .NET Enterprise Servers such as SQL Server, BizTalk Server, and Host Integration Server. As a result, Microsoft certainly has captured the mind share of developers when discussing XML Web Services. Sun's slow adoption of SOAP and XML has effectively meant that J2EE support for these standards either is missing in the formal specification or is not fully integrated into the various vendor's product offerings. For example, WebSphere's support for SOAP comes from an implementation that IBM produced independently and gave to Apache.

  • + Share This
  • 🔖 Save To Your Account