The latest Java 2 Enterprise Edition (J2EE) compliant technologies, represent a platform-independent, Java-centric environment originally developed by Sun Microsystems for developing, building, and deploying web-based enterprise applications on-line.
The typical J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multitiered, Web-based applications. Some of the key features and services of the platform are
- At the client side, supports for pure hypertext markup language (HTML), as well as Java applets (programs that are executable from within another application, but cannot be executed directly from the operating system). J2EE relies on Java server pages (JSP) and servlet code (a small program that runs on a server side, which is analogous to a Java applet that runs within a Web browser environment) to create HTML or other formatted data for the client.
- Enterprise JavaBeans (EJB). A Java API also developed by Sun, which defines a component architecture for multi-tier client/server systems, provide another layer where the platform's logic is stored. Accordingly, an EJB-based server provides functions such as threading, concurrency, security, and memory management, and these services are transparent to the author.
- Java database connectivity (JDBC), which is the Java equivalent to open database connectivity (ODBC). JDBC is the standard interface for Java databases.
- Java servlet API. The servlet enhances consistency for developers without requiring a graphical user interface (GUI).
.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.
J2EE Appeals to Relevant
An example of how J2EE might appeal to focused niche ERP vendors would be choice of Relevant Business Systems . In mid-2004, Relevant announced its product's technological direction for the future. It announced its decision to use J2EE environment for future product development, and the vendor believes the choice of J2EE provides an optimal fit with its product offering and more closely matches the needs of its customers across a broad range of requirements. As an ISV, Relevant's choice of J2EE over Microsoft .NET was reportedly based not only on what worked best for its internal product development but also on the needs of a diverse customer base. Like most ISV's, Relevant wanted the best overall platform for its product offering both in terms of performance and marketability, which, translated into features that meant that critical to both audiences were
- Platform independence and acceptance in the target market and in the software industry in general. Many of Relevant's customers have server standards dictating the platform that enterprise applications may be deployed on. In addition, Relevant's target customers range from small to midsize (defined by the vendor as 20 to 100 users) to large (200 to over 1000 users), whereby smaller customers often prefer the Microsoft Windows server platform, while larger multinationals gravitate towards UNIX. The availability of UNIX operating systems provides increased uptime and reliability for Relevant's customers and the applications are built to scale in order to meet the needs of Relevant's larger and rapidly growing enterprise class customers. Given .NET is restricted to Windows, on the critical criteria of acceptance in the target market, J2EE, which allows a single application to be deployed in multiple environments, was deemed far less restrictive. Thus, J2EE will supposedly allow Relevant to write a single application deployable in multiple environments. Otherwise, Relevant acknowledges that both .NET and J2EE are well accepted by the software industry.
- Scalability. Relevant's enterprise software equally addresses the requirements of sites supporting as few as thirty or as many as several thousand users. Given that the typical installed life span of an ERP system is eight to ten years, this is a key product advantage. Relevant wanted to ensure that its choice of underlying technology would preserve and enhance its product's ability to gracefully scale to growing customers' needs. While .NET is considered to have a slight advantage in smaller environments, analysts and users alike still consider J2EE to currently be the only real choice in environments with over 300 users. This has weighed heavily in Relevant's considerations, which thus concluded a choice of J2EE was definitely preferable on this measure.
- Product performance. A strong, feature-rich enterprise product is particularly critical to the project-oriented businesses Relevant serves. While .NET has the richer user interface (UI), J2EE provides the stronger back-end needed for Relevant's server side-focused development. Access to the underlying technology, the ability to handle high volume transactions and many built-in features such as session management, fail-over, load balancing, and application integration make J2EE a more robust and suitable technology for Relevant's enterprise software.
- Ease of development and robustness. With a good product specific integrated development environment (IDE) and plug-ins, Relevant believed its customer base would be able to develop easily with either .NET or J2EE. For its own development, however, Relevant found J2EE to be far stronger on the server side, where most of the development is done. In addition, J2EE afforded the additional benefit of allowing a developer access to more of the underlying technology. Although .NET's many built-ins decrease the necessity for third party tools, ample availability of tools and plug-ins for J2EE minimize this advantage. Revelant found .NET to be less robust for complex application development. In addition, the .NET platform was judged more prone to viruses and worms.
- Costs. Neither solution has significant infrastructure management costs. Resources are abundant for both platforms, although highly skilled resources might be easier to find on the J2EE platform due to its maturity, albeit .NET resources offset Java's availability superiority with a slight cost advantage.
In the end, virtually all key Relevant's stakeholders found it fairly easy to select J2EE for the overall ERP development architecture. As an ERP developer marketing to companies ranging from mid-size manufacturers to large scale multinational enterprises, platform independence, increased product portability and scalability were the key issues. By selecting J2EE, Relevant believes it has ensured that its applications would be deployable on a variety of platforms, enabling its customers to support Relevant's application on the platform that they were most familiar and comfortable with.
Before customers make any attempt at choosing products or suites of products for EAI, middleware, Web application servers or other software solutions that require seamless interoperability, they must be sure they understand the difference in the approaches used by J2EE and .NET. While one of the main goals of Web services was to make the platform choice less important, that reality is still a long way off. Despite anyone's platform preference or the roster of programmers with certain skill sets, it is therefore prudent to gather as much information as possible from both camps, as both will have their pros and cons.
Although competition typically results in both camps keeping each other on their toe tips to be more creative, it does not help users and prospects now. They should thus question vendors closely on which approach they have (or will be) taking in their current and future releases, and why. Once the choice is made, it will be difficult although not quite impossible to switch or abridge. Since application integration efforts are costly, complex, and time-consuming, the decision may come back to haunt you if you do not choose wisely. Users must recognize that making a choice for an application server should encompass the entire stack (portal, personalization, directory, etc.).