.NET versus J2EE Environments

Nowadays, the only serious alternate option to J2EE environments comes from the Microsoft.NET platform that incorporates applications, a suite of tools and services, and a change in the infrastructure of Microsoft's equivalent Web strategy to erase the boundaries between applications and the Internet. Instead of interacting with an application or a single Web site, .NET aims at connecting the users to an array of computers and software services that will exchange and combine objects and data, whereby “users will have access to their information on the Internet from any device, anytime, anywhere”.
Hence, the Microsoft .NET versus J2EE platform argument often takes on the vehemence of a religious debate, but while these debates can be heated, the choice of one technology platform over the other can have even existential ramifications for independent software vendors (ISV) selling to a heterogeneous or platform-agnostic target audience. Choosing one may amount to “betting the farm”, whereas choosing neither or both typically forces unwieldy workarounds or excruciating duplicate development efforts. That is, in a great part, the case because there are significant differences when it comes to these technologies’ support for operating system (OS) platforms and languages.
While Microsoft .NET works only on its Windows OS, it offers support for over twenty programming languages as a consolation prize. J2EE proponents, with Oracle and IBM being some of the most vocal, encourage development on multiple operating systems (e.g., Windows, UNIX, Linux, and even mainframe), but use a single language, Java. Based on the above perplexing facts, and given that neither platform has fully matured, many enterprises will consequently have to delve into both approaches for some time to come.
Despite its head start in offering the framework to build Web services, Microsoft’s task of luring the developer community into its camp—especially enterprise application developers—remains an uphill battle since many large organizations have significant investment and progress with Java. Nevertheless, Microsoft .NET remains well regarded on several fronts, such as leading in desktop productivity applications, with GUI-rich OS flavors that excel in front-end development, since the comprehensive framework includes an outstanding integrated development environment (IDE) within which developers can create “rich” (“smart”) user interfaces. Tightly integrated into native Microsoft Windows OS variants, .NET gives developers significant options for user interaction, while permitting development in a multitude of languages (compiling byte code to an internal language in runtime – which means occurring while the program is executing), so there can be greater reuse of skill sets. Further, extensibility in .NET is inherent, since it was built around Web services, while overall development costs may initially be cheaper in .NET, since the application server is built into the server platform.
However, the platform’s weaknesses, in addition to its inability to run on an OS other than Windows, are its forced reliance on Microsoft for platform development and standards and the relative immaturity of the platform. Also frequent, significant changes to Microsoft’s strategy blueprint and tools (including .NET, Visual Basic.NET [VB.NET], C#, Active Server Pages [ASP], etc.) requires continuous readjustments and additional user education. Last but possibly the most significant question regarding .NET focuses on its still unproven scalability and stability. Conversely, J2EE is strong where .NET is weak, such as J2EE’s ability to run on any OS and its proven ability to scale and handle very high volume transaction applications. With many features built in for enterprise applications (e.g., session management, fail-over, load balancing, and application integration), Java has been favored for large enterprise application development for years.
The fact is that virtually every high transaction volume data transformation (e.g., extract, transform, and load [ETL]) or enterprise application integration (EAI) product developed in the past several years has been built using J2EE, including those from IBM, Hewlett-Packard (HP), Sun, BEA Systems, and Oracle. Also, the vast Java community reviews the J2EE platform specifications, and all input is reviewed, weighed and analyzed before it can become standard. Thus a large number of companies influence the make up of the platform, which ensures that no one company (including mighty IBM) can manipulate the specification to advance a specific agenda. On the downside, J2EE is more complex than .NET, and its GUI environment is much more limited.
Still, J2EE remains a platform of choice for typical diverse e-business solutions environments, as the various Java platforms have reached an indisputable level of maturity and acceptance. Java is still likely the fastest-growing language and platform for building new applications and will likely continue to be used by large global corporations, as seen in SAP’s relatively recent endorsement (see SAP Opens The 'Miss Congeniality' Contest).
Again, the only non-J2EE application server product of merit belongs to Microsoft, while all other mainstream enterprise vendors have committed to the Java juggernaut. As for Microsoft followers, they should be pleased with Microsoft's ongoing execution of its Web services strategy. It remains a good choice for Windows environments with an abundance of PC desktop-oriented activities, and that are involved in next-generation platform (e.g., .NET and Web services) development and deployment. Microsoft might not be such good a choice for complex heterogeneous organizations that need solutions for complex computing problems (a high-volume backbone enterprise resource planning (ERP) system that uses publish-and-subscribe message-oriented middleware (MOM) and multi-vendor integration projects (hardware, software, services), solutions where security is of high concern, and projects where cross-platform is a matter of course, and where most application developments are done in Java.
On the other hand, although J2EE was drafted prior to the advent and adoption of Web services, the market has responded with an enormous amount of Web services tools and applications. Consequently, at this point, applications developed with either .NET or J2EE can take advantage of service oriented architectures (SOA) and Web services, and answer the extensibility question effectively. Furthermore, Web services may motivate vendors to more tightly couple integration with development early in the life cycle of software applications. Microsoft seems to have realized this through the ability of its BizTalk Server to utilize VB.NET objects and combine them in a process-oriented manner with other application components. BEA’s WebLogic, IBM’s WebSphere, Oracle AS 10g, SAP NetWeaver, and other application server platforms have been delivered along the same lines. Hence, instead of having to wade through the complexity of integration only after applications have been implemented and are up and running, enterprises can begin executing on integration strategy concurrently with development and deployment.