With Sun Microsystems Java 2 Enterprise Edition enterprise computing platform and Microsoft’s .Net architecture vying for attention, developers are facing some tough choices over which road to take. We’ve compared J2EE and .Net for you.
What is J2EE?
Java represents more than just a programming language, encompassing the virtual machine (VM) technology that lets compiled Java programs run unaltered on various machine architectures; tools to compile, analyse, debug and deploy Java programs; and other components, such as browser plug-ins, rich media and more.
The Java triumvirate
- The Java 2 micro edition (J2ME), for handheld and other lower-end device
- The Java 2 standard edition (J2SE), for desktop machines
- The Java 2 enterprise edition (J2EE), for servers and doing the heavy lifting in the Java world.
J2EE is a Java-based technology stack built on top of J2SE that provides developers with the tools and runtime capabilities to build enterprise applications meeting rigorous uptime, security, scalability and maintainability requirements.
The latest version of J2EE is 1.3.1. Sun uses the J2EE platform to synchronise the technology specifications for specific releases. Here's a partial J2EE components list:
- Java server pages (JSPs): Generate dynamic content for web browsers and mobile devices. JSPs resemble HTML, especially when developers use custom tag libraries to remove Java code from the JSPs themselves, for easier maintainability.
- Servlets: Build control and navigation logic into J2EE applications, typically following a model-view-controller design pattern in conjunction with JSPs.
- Enterprise Java beans (EJBs): The two types of EJBs are the mainstay of the J2EE platform: session beans that model business logic and entity beans that model persistent data. EJBs provide transparent scaling, security framework, transaction model and container-managed life cycle.
- Java connectivity architecture (JCA): Lets Java enterprise applications interface with existing non-Java enterprise applications like SAP. Transactions and security roles can propagate, allowing for integration of legacy applications in a J2EE architecture.
- Java message service (JMS): Provides asynchronous messaging capabilities to the J2EE platform. Established message-oriented middleware (MOM) vendors like IBM (MQ Series) and Tibco (Rendezvous) provide JMS interfaces to their products.
- Java management extensions (JMX): Manages J2EE servers and applications.
- Java naming and directory interface (JNDI): A required part of the J2EE platform, JNDI provides component location transparency in a clustered J2EE environment.
- Java database connectivity (JDBC): JDBC handles all database input/output via SQL.
- The HotSpot virtual machine: The HotSpot VM has addressed most of the initial concerns about J2EE's performance.
Unlike J2EE's specification set, .Net is a suite of shipping products (with parts ratified as international standards by the European Computer Manufacturers Association).
According to Microsoft, ".Net is a set of Microsoft software technologies for connecting your world of information, people, systems and devices."
However, .Net evades easy definition because it covers so many topics. It can be defined as a development platform for building XML web services, as well as a set of enterprise servers. Both definitions are correct, although neither tells the whole story.
The .Net basic elements are:
- Smart client software for smart clients: From personal computers (Windows XP), to small-footprint devices like PDAs (Windows CE .Net), to set-top devices (Windows XP Embedded).
- XML web services: Let applications share data and consume services provided by other applications irregardless of how those applications were built, the platform or which devices access them. .Net includes implementations of the latest accepted web service standards, such as the XML Schema standard. In addition, Microsoft plans to provide many commercially available foundation services, called My Services, to serve as application building blocks.
- Enterprise servers: Among the offerings in the mix are Application Centre for deploying and managing web applications, BizTalk Server for coordinating XML-based business processes across applications and organisations and the SQL Server database.
Presentation layer: HTML generation
J2EE: JSPs and servlets generate HTML for J2EE applications. Servlet containers include features such as session state, security framework and configuration. Tag libraries allow developers to cleanly separate presentation code from control and business logic and also make JSPs readable for HTML coders. A new initiative called Java server faces aims to extend JSPs to allow developers to specify UI (user interface) components, event handling for HTML widgets, data validation and navigation. Currently, you can handle such tasks with presentation frameworks such as Struts, Webwork or wingS.
.Net: ASP.Net builds and hosts web applications under Microsoft's Internet Information Server (IIS). ASP.Net includes fault-tolerant session state, authentication and authorisation, and HTML generation. With ASP.Net, developers build ASPX pages with HTML and custom tags mapped to server-side web controls. Web controls encapsulate reusable user interface logic and provide many advanced features to ease web programming. For example, input controls (eg textboxes) automatically maintain their state from one round trip to the next, so developers can access form data on the server via control properties (eg textbox.Text).
Business logic: transactions, distributing remote objects and XML web services support
Developers code transactions to provide systems with so-called ACID properties: atomicity, consistency, isolation and durability. These properties keep your system's data coherent when things go wrong.
J2EE: Developers can either explicitly code transaction management (user defined or manual) or specify the required behaviour and hand off the management to the container (automatic mode). In most cases, developers try to delegate transaction handling to the EJB container. Manually managing transactions can introduce subtle bugs into the application; in addition, the container is usually better at transaction management than the developers.
.Net: The CLR supports both manual and automatic transactions. With manual transactions, developers begin and enlist others in the transaction, commit or abort it, and end the transaction. With automatic transactions, developers define an object's transactional behaviour by setting a transaction attribute value on an ASP.Net page, an XML web service method or a class. Once an object is marked to participate in a transaction, it will automatically execute within the transaction's scope.
Automatic transactions are easier to program, but much more expensive in performance terms than manual ones. Developers generally only use automatic transactions to manage distributed transactions.
Calling remote objects
J2EE: J2EE’s core feature, JNDI, finds server-side components such as EJBs or JMS queues, which may or may not reside in the same VM. All access to EJBs must go through interfaces. This allows the application server to implement its own load balancing across multiple nodes to optimise throughput and response time. In practical terms, most application servers attempt to keep communicating EJBs in the same VM to minimise network traffic and the associated marshalling overhead. The developer can enforce in-VM execution with local interfaces.
.Net: With .Net remoting, developers can call remote objects distributed across application domains, processes, and machine boundaries. As you'd expect from any remoting framework, .Net remoting hides the nasty remote call details, formats messages and provides underlying transport mechanisms. How you decide whether or not to use remoting in .Net is interesting. In .Net you can't automatically decide to distribute your objects as you can in J2EE, because there’s a price in network latency to pay. In the .Net world, developers employ remoting to increase security and ease maintenance, but not to improve scalability which is generally achieved by adding web servers.
XML web services
J2EE: The Java web services developer pack from java.sun.com, lets you create web services today. In the future, J2EE 1.4 will provide best-in-class web services support. With 1.4, all EJB web services can be consumers, and a stateless session bean can provide a web service. Additionally, specifications such as JSRs (Java Specification Request) 67, 93, 101 and 109 enhance the web services support in the Java platform, providing service naming, lookup, invocation, and usage functionality, respectively.
.Net: Microsoft placed XML web services at .Net's core and it contains the latest accepted XML web service standards (such as the XML Schema). Moreover, Microsoft, which groups web services-related standards as Global XML web Services, actively promotes other needed web services standards.
J2EE: Persistent data is typically modelled as entity beans. Two main types, container-managed and bean-managed persistence (CMP and BMP, respectively) let developers tap into container-provided services such as transaction management, a persistence framework with intelligent database updates and caching; also, a security framework, leveraging the container's innate characteristics such as scalability and fault tolerance. Generally, there is a Java package to access almost any corporate data source.
.Net: Developers can data sources, including XML, through .Net's ADO.Net classes. Although ADO.Net gets its name from its predecessor, ADO (ActiveX Data Objects), ADO.Net is a rewrite rather than an upgrade. ADO.Net includes data providers that let you connect to a database and execute commands. Developers can also transport data over the web using XML web services or across process boundaries using .Net remoting.
J2EE: Java source code compiles into machine-independent byte code, which the JVM interprets at runtime. The installed JVM is thus crucial to performance and scalability. Sun supplies its HotSpot VM with Java, and other JVM implementations exist, such as IBM's JVM or BEA Systems' JRockit. HotSpot looks for repeatedly executed code sections, and intensively optimises them. HotSpot also supplies the standard configurable security model for code loading and execution. Java's JVMs also leverage their host machines' strengths. For example, JVMs optimised for Solaris take advantage of special features such as thread management. Java applications running on Solaris machines can scale up to more than 100 CPUs, 10,000 threads and 100GB of RAM per virtual machine.
.Net: The CLR environment executes .Net's Microsoft intermediate language (MSIL, or just IL) code. Like JVMs, the CLR also offers support services, such as code verification, memory management via garbage collection and code security. With the extensive set of framework class libraries (FCL), you have the .Net Framework. There are several differences between the JVM and the CLR. First, Microsoft designed the CLR to support multiple languages, whereas the JVM supports only one — Java. Microsoft currently provides CLR-compliant versions of Visual Basic, C#, C++, JScript and even Java. Other vendors provide support for additional languages, such as Cobol, Fortran and Perl.
Second, in .Net, managed code always translates into native machine code rather than interpreted. The CLR, unlike the JVM, supports compilation from the start. Although all JVMs provide just-in-time (JIT) compilers or HotSpot today, the JVM was originally designed as an interpreter. Third, consider .Net's support for application domains. Application domains resemble processes; they provide the same isolation level without the overhead that comes from making cross-process calls or switching between processes, because they can run within a single process space. The ability to run multiple applications within a single process dramatically increases server scalability, something not supported by JVMs.
J2EE: J2EE offers complete cross-platform portability. If a JDK exists for your target platform, then J2EE runs on it, be it Window or mainframes.
.Net: The CLR includes a JIT compiler that translates IL into machine code running on target platforms. Currently, .Net only supports the Windows platform, but support for other platforms such as FreeBSD and Linux (through the open source Mono initiative) are in the pipeline.
J2EE: If you want to use another language than Java, you'll have to do it via an interface technology like the Java native interface (JNI) or via web services.
.Net: .Net can use any language once a mapping exists from that language to IL. Several third-party vendors have produced language compilers that target the CLR; examples include NetCobol from Fujitsu, and Visual Perl and Visual Python from ActiveState, with others on the way. Because all .Net languages share a common type system, developers can safely pass types written in one language to code written in another. They can also use the unified framework class libraries in any .Net language, saving them from having to learn how to work with many different implementations. It means companies can choose the best language for the job based their developers' skills.
J2EE: Anyone can propose a JSR for a new platform extension, and the Java community process (JCP) does a great job keeping Java technology open with input from IBM, HP, BEA Systems and others. Adding to the language itself, however, is nearly impossible. Sun is conservative about introducing changes to the Java language — a good idea, in our opinion, as it keeps the platform stable.
.Net: Microsoft been criticised for tightly controlling its technologies. However, on December 13, 2001, the ECMA general assembly ratified the C# and CLI specifications into international standards, allowing others to participate in their evolution.
J2EE: Java has a plethora of tools, which provides developer with lots of choice. But choosing the right tool for the job is tricky. There are numerous IDEs, which works better on some projects but not others. Debugging support is good via the Java platform debugging architecture (JPDA), and Ant and JUnit have given the Java community a standard build tool and unit testing framework, respectively.
.Net: Microsoft's excellent Visual Studio .Net IDE allows developers to use any .Net language. From the developer's viewpoint, applications are built using a single IDE. Visual Studio .Net boasts too many features to address here, but it's worth mentioning the new Server Explorer feature. With the Server Explorer, developers can access server resources (message queues, performance counters, data sources, and so on) without ever leaving Visual Studio .Net.
J2EE: IBM, BEA Systems, Sun Microsystems, Oracle, JBoss.org and many others offer a wide variety of J2EE products. At present, however, open source vendors cannot become J2EE-certified — a contradiction that Sun should resolve to allow open source J2EE offerings to grow.
.Net: For the foreseeable future, .Net is a Microsoft platform. On the plus side, developers need not worry about a dizzying array of choices, inconsistencies in various vendor implementations, or about standards compliance. On the other hand, .Net locks you into Microsoft. Depending on your organisation, that lock-in may or may not be an issue.
What developers think of .Net