Many argue that it's inaccurate to characterise the key companies in this battle as Microsoft and Sun. But Sun has never relinquished its control over the Java/EJB standards (even going as far as pulling them back from the ECMA standards committee). So you certainly have to be willing to place a significant amount of faith in a company that is trading at an eighth of its value from a year ago and has lost four of its key senior executives in the last six months. You also have to wonder whether Microsoft's winning streak is over after having vanquished Apple (with Windows), IBM (with Windows over OS/2), Novell (with NT) and Oracle (with SQL Server on NT/2000). Even with the significant distractions that the Department of Justice has caused Microsoft over the last three years, the corporation has continued to build both quality products and market share. Moreover, it has begun to listen to customers like never before. Witness Microsoft's recent withdrawal of its MyServices initiative and new security battles -- both based on customer feedback about concerns over security with Microsoft products and technologies. But you also have to give Sun credit for doing something Microsoft could never do: rally the industry around a single development standard. Microsoft had minor successes (with database standards such as ODBC), but it has never been able to effectively extend its desktop dominance into the data center. Sun's shepherding of the Java/EJB standard has resulted in a large marketplace for vendors hawking their wares. These include top names such as Oracle, IBM, and BEA, as well as many other second-tier EJB tools and server vendors. In theory at least, this vendor participation in a standard leads to vendor independence. But this is not turning out to be the case in practice. Vendor independence in question
The whole notion of vendor independence has become a red herring because J2EE evolves so slowly. Vendors have no choice but to exceed the specification in order to create compelling products. J2EE's slow adoption of SOAP and Web services has forced vendors to release their own proprietary extensions. For example, BEA Systems, Inc. has announced a new application framework, code-named "Cajun." Cajun is designed to make it easier for developers to build enterprise Web services, but it doesn't run on any other application server except BEA's own WebLogic. And BEA is not alone. IBM recently added proprietary extensions to its WebSphere 4.0 Java application server. Its new enterprise edition includes the ability to create new bean types specific to the IBM server and not portable to other vendors' application servers. And Oracle's own 9i Application Server has very specific ties to its database, basically eliminating the ability to use other vendors' databases efficiently. So building a robust J2EE application based on the latest technology requires you to select someone's proprietary extensions to the J2EE "standard." This isn't really a Microsoft or Sun choice; it's a Microsoft or IBM or Sun or BEA or Oracle or some combination of non-Microsoft technologies decision. It's starting to look like CORBA and OpenDoc all over again. Choice based on existing markets
Market share is always a difficult measure upon which to base your decision. On the surface, it seems simple: Java/EJB has a commanding lead in the enterprise marketplace over .Net. But given the recent release of .Net vs. the three-year lead of J2EE, this is to be expected. Microsoft advocates will argue that the .Net Framework's age -- it's three years younger than J2EE -- is an advantage. Microsoft has been able to learn from the problems encountered during development and implementation of J2EE systems. Although it's based on Microsoft technologies, in many ways .Net already includes the features you can expect from J2EE. Perhaps a more compelling comparison would be production systems based on COM vs. J2EE. Many J2EE advocates will argue that this is insignificant since enterprise architectures are moving away from the proprietary Microsoft COM standard and toward industry standards like TCP/IP, XML, and SOAP. But Microsoft designed .Net to make it easier for existing COM developers to migrate their applications toward these industry standards while preserving their investment in their existing language and tools knowledge. Given that you could make market-share arguments based on several different metrics, it begs the question: Why does market share really matter? Simply put, it's the availability of resources to develop the applications of the future. More market share normally translates to more (and therefore cheaper and higher-quality) resources. Sun has done a masterful job of getting Java entrenched in the academic community, ensuring the J2EE camp of a continuing source of new, Java-trained resources. Microsoft is attempting to do the same with C# (which was its driving reason for getting ECMA standards certification), but the jury is still out on whether the corporation will be successful convincing academia to add C# or to switch from Java. So Microsoft's key advantage here is its existing base of VB and C++ developers along with the new C# developers and Java-to-C# converts. Making your choice
If you already have a significant investment in Microsoft or J2EE technology from one of the key vendors, your simple choice is to continue betting on that technology as long as the vendor is giving you the features and performance your applications demand. If the investment is in Microsoft, you have to be willing to believe that Microsoft will solve its security problems (or that you can continue to architect around them) and be glad that your developers can make a relatively smooth transition from COM to .Net using the best toolset on the market (Visual Studio .Net) to develop Web services and other XML/SOAP-based applications. If you've invested in one of the J2EE vendors, you have to choose between using its advanced tools and sacrificing portability (and also limiting the number of available resources on that particular technology) or holding firm on using only portable J2EE features and sacrificing performance (but preserving the ability to use more generic development resources). So you see, the choice isn't really down to two options -- J2EE or .Net -- but comes down to three: .Net, J2EE-generic or J2EE-vendor specific. It's a tough time to be a CIO.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
