Microsoft’s flirtation with Java as a part of its long-term systems strategy ended in late January when Microsoft agreed to pay $20 million to settle a lawsuit with Sun. The suit claimed that Microsoft had altered Java in a way that prevents the software from fulfilling its core goal of “write once, run anywhere.”
The settlement allows Microsoft to continue using an older version of the Java technology in existing products like Visual J++ and Internet Explorer for the next seven years.
Truth be told, Microsoft has spent years preparing for this day. A couple of years ago, rumors surfaced about Microsoft’s COOL technology—its alleged Java-killer.
In fact, COOL research produced the flagship development language for Microsoft’s .NET initiative, called C#. Microsoft designed C# to combine the power of C++ with the elegance of Java. More importantly, Microsoft submitted C# to standards bodies so that an independent standard (not driven by Sun as with Java) would be allowed to develop. Now that the Microsoft and Sun positions are clearly stated, what are the implications for corporate development shops?
Best online Microsoft MCTS Training, Microsoft MCITP Training at certkingdom.com
Platform choices will drive language selection
If you decide to implement a solution on a UNIX (or UNIX-variant) platform, you can be almost certain that the solution will be implemented using Java. Sun is in an interesting position here in that they control the language standard for all UNIX implementations but have a vested interest in optimizing Java for their platform. They don’t make money selling Java—they make money selling Sun servers and operating systems.
Although Sun will continue, in the near term, selling its own Java implementations for Windows NT and Windows 2000, I believe they are providing these products primarily to keep their customers satisfied. I don’t see any strategic reason for Sun to pursue this market over the long-term.
Microsoft, on the other hand, is attempting to level the playing field using .NET. Of course, it doesn’t hurt when you own the playing field, i.e., Windows 200x and .NET.
Ostensibly, if you use .NET for your development platform, you can choose any language you’d like. Microsoft is working with other language and tools developers to port their wares to the .NET platform. By the time Visual Studio.NET is released, you should be able to use COBOL, RPG, MUMPS, Python, or any number of other languages to develop .NET applications.
In truth, the versions of these languages will have to be able to support the .NET Common Language Runtime (CLR) before real object interoperability can be achieved. This means that although developers may bring language skills with them to the .NET party, most applications will have to be rewritten to accommodate new language syntax and a common set of data types. This will be true for all languages (including Microsoft’s C++ and Visual Basic) except Microsoft’s implementation of C#.
Protocols will become more important than languages
To a great extent, industry developments have rendered Sun’s lawsuit and the settlement meaningless. During the past two years, all companies (including Microsoft and Sun) have focused on developing systems whose major feature is interoperability rather than exclusivity.
For example, most Sun/Oracle implementations use Java (and some C++) components tied together with JavaScript and Java Server Pages (JSP) as their development language. Most Microsoft Windows NT or Windows 2000 implementations use Visual Basic or C++ components tied together with VBScript/JScript and Active Server Pages (ASP).
The real issue here is not what you use to build the internal system—that’s determined by your access to technical resources. The issue is whether, once finished, the system can interact intelligently with other systems in a loosely coupled, scalable fashion.
I believe that 10 years from now, industry pundits looking back on the early 00s won’t even see this settlement on their radar screen. Instead, they will point to the decision by Microsoft, IBM, and Sun to support Simple Object Access Protocol (SOAP) as the beginning of the interoperability decade.
Doubtless, there are many more standards battles to fight. However, I think that later this year, you’ll see commercial implementations of SOAP that allow developers to use languages and platforms of choice while giving them protocols that allow those systems to interoperate.
SOAP and other associated standards allow systems to discover each other’s functions, manipulate the functions, and return results and error codes. These systems won’t be designed to work with each other but to implement their exportable functions so they can be discovered by other SOAP-compliant systems.
How do you protect yourself?
Unfortunately, the only sure way to cover all your bases is to keep using the development tools and platforms you’ve been investing in until the platform and language battle settles down. You should be getting your developers and system architects trained in XML and SOAP, if you aren’t already.
It’s also not too early to begin architecting your systems to expose themselves to other systems—even to other like systems—using protocols like SOAP instead of proprietary protocols like Microsoft COM (Component Object Model).
How do you feel about Tim Landgrave’s predictions? Start a discussion below.
