The two Web services standards are now settling into their respective roles and the reasons for choosing one over the other are becoming clearer. But can they play nicely together?
IT vendors love to talk about the interesting companies that have used their technologies, but few could top the claim of Sun Microsystems, whose J2EE (Java 2 Enterprise Edition) application environment was used to program NASA's twin Opportunity and Spirit Mars rovers.
In an environment where "mission-critical" takes on a whole new meaning, the choice of J2EE is a strong testament to the resilience of a platform that has enjoyed strong support from enterprise developers. It has also, through the support of non-Microsoft independent software vendors (ISVs) like IBM, BEA, and Sun, become a centre of gravity for advocates of Linux and open source development that many argue frees them from the shackles of a single-vendor computing environment.
But does philosophical superiority really translate into business benefits? After several years in a market where J2EE competes against Microsoft's .NET application environment, the answer is becoming less clear.
Through its bundling into Microsoft's latest operating systems, .NET is rapidly becoming ubiquitous in presence, if not in actual usage; this increased footprint has put significant momentum behind the Redmond creation. Given that Windows dominates the corporate desktop and is becoming increasingly common on the server side where .NET lives, many companies already have .NET installed when they decide to experiment with it.
J2EE, however, also has a strong following, particularly amongst large companies that years ago learned their lessons about the need for open software after forking over exorbitant maintenance fees and funding costly forklift upgrades to rebuild applications originally created in obsolete technologies. Because it is supported across a number of server platforms and lies at the centre of a maelstrom of productive competition, J2EE has rapidly evolved into the platform of choice for large companies needing to build applications that can easily extend across heterogeneous computing farms.
Convenience versus technical excellence; closed design versus open: from a purely philosophical perspective, it would seem J2EE would be set to win the battle hands down. However, there are other factors: cost, development complexity, deployment expenses, and skill sets all vary widely between the two platforms, each shaping the ultimate decision as to which technology is best.
In the long term, the choice of whether to pick J2EE or .NET remains highly subjective to the requirements of each individual environment. For most companies, it's not even an either-or choice: Gartner recently reported that "more than 90 percent of medium to large organisations that develop applications for their own projects will most likely use a mixture of both Microsoft and Java technologies through 2005."
Fence-sitters rejoice: judging from Gartner's feedback, you are not alone. For many companies the challenge, then, is not which platform to deploy--but which platform to deploy, where. The choice is no longer exclusive: a variety of methods allow interconnection of application components written in the two environments. Still, determining the right approach requires a clear understanding of the requirements of both short-term applications and long-term information strategies.
Step into the ring
One of the major arguments of J2EE proponents has been the fact that J2EE's openness, broad support and links with the open-source community--particularly with the inexpensive Linux server operating system--make it a less expensive and inherently more robust solution. This may sound good to budget-challenged managers, but those managers will do well to also consider a study by Forrester Research subsidiary Giga Research that last year concluded that .NET actually offered a significantly lower cost of application development and maintenance than J2EE.
| ||||||||||||||||||||||||||||||||||||||||||||||||
The findings refute the idea that J2EE might be cheaper to develop. For the large sample company, the cost of developing, deploying and supporting the application for three years was US$2,289,041 compared with US$1,643,112 for a .NET solution. The medium-sized company application weighed in at US$881,455 for J2EE and US$661,012.
Cynics will point out that the study, sponsored by Microsoft, would not have been released if it didn't find in the company's favour. Certainly, the higher number of .NET interviewees and the making of several assumptions means that the Forrester conclusions may not necessarily reflect real-world performance.
Nonetheless, Giga's analysis did raise several valid issues. One of the main problems with the J2EE approach is the fact that database, application server, development tools, and software maintenance typically needs to be purchased from different companies--preventing companies from achieving economies of scale by ordering many components from a single vendor. A license for four BEA WebLogic Enterprise Edition application server licenses, for example, cost US$68,000 compared with zero for the .NET solution.
Microsoft, on the other hand, bundles its .NET server components into every copy of Windows Server 2003, which has become the standard platform for new Windows server deployments. Microsoft also offers a full suite of software and support options making .NET software costs lower in the long term.
Another key issue highlighted by Giga is training. Assuming 9.25 full-time equivalent staff (FTEs) taking 10 days of J2EE and BEA WebLogic training for the J2EE solution and seven days of Microsoft training, Giga concluded that getting staff up to speed for the large company application would cost US$300,000 for J2EE/Linux and around US$210,000 for the .NET solution, while the medium-sized sample organisation would spend US$70,000 training staff for a J2EE/Linux solution and US$38,500 training them for .NET.
| ||||||||||||||||||||||||||||||||||||||||||||||||
Differences in staff training costs have been a very real part of the reason Melbourne-based development house WDG has focused its efforts on .NET rather than J2EE.
"Especially in the early days, .NET developers were significantly cheaper to find," says Karl Kopp, director of IT with WDG, which has 22 developers working on a range of .NET projects. "Java developers tend to be a lot more costly, and we're trying to run a business; it was a lot more cost-effective for us to follow the Microsoft path because developers are so much cheaper."
3%
2%
