Rumble in the jungle: J2EE versus .Net, Part 2

Compare how J2EE and .Net build a working enterprise application

In Part 1 of this two-part series, we introduced Microsoft .Net and J2EE (Java 2 Platform, Enterprise Edition) from the 30,000-foot level. In this article, in contrast, we actually implement a representative Web based application—the Ice Cold Beer Boutique (ICBB)—in both J2EE and .Net. To do so, we evaluate the presentation, business, and data tiers for both technologies, looking at common services such as exception handling, caching, and configuration, as well as the technologies' tool support. We then bring it all together to implement the sample business application. We finish by discussing the future for both .Net and J2EE.

Read the whole "Rumble in the Jungle: J2EE Versus .Net" series:

Note: Download this article's sample source code from Resources.

Web application overview

For the Ice Cold Beer Boutique application, which Sheil introduced in "To EJB, or Not to EJB?" (JavaWorld, December 2001), we chose a problem interesting enough to be nontrivial, yet simple enough to ensure that we can clearly show each technologies' features and deficits. With that in mind, what should the ICBB application accomplish?

The Ice Cold Beer Boutique

ICBB, a business-to-business (B2B) company that sells premium beverages to resellers in Europe and the US, wants to reduce costs and order turnaround time by allowing resellers to create orders on a secure Website. The IT strategy calls for incrementally building up the site as demand increases.

The application's first release must:

  • Be secure by allowing only authorized visitors access the ICBB Website
  • Be easy to use; ICBB's CEO intends to test this feature himself
  • Allow resellers to view all currently stocked beverage types and prices
  • Allow an ICBB system administrator to update the details for a beverage type
  • Allow an ICBB system administrator to delete a beverage product

The second release, building on that functionality, will allow resellers to create orders and schedule them for shipment. Eventually, ICBB will integrate its Web store with its enterprise resource planning (ERP) system Sales order Processing module so sales invoices can be raised automatically and stock information updated.

Our goal: Produce an application using a technology and design that meets these immediate requirements and admits constant enhancements as the system expands.

Application structure

We implement a thin slice of the overall application, so you can see how the application layers communicate together. Figure 1 shows the distinct HTML pages planned for the system and how they hang together. All pages apart from the Welcome and Login pages are secure; only authenticated users can access them.

Figure 1. The system HTML pages in relation to each other, for both J2EE and .Net implementations. Click on thumbnail to view full-size image.

J2EE notes

Let's see how to design the ICBB application as a J2EE application, then look at the reasons behind the important J2EE-based implementation decisions. Figure 2 illustrates how the ICBB sample application looks when implemented with J2EE.

Figure 2. The ICBB schematic as implemented with J2EE. Click on thumbnail to view full-size image.

The presentation tier

Unlike .Net, with J2EE you can employ a number of free frameworks to help build an application. That's both good and bad: While I have freedom of choice, I may choose the wrong tool. For example, with Web frameworks, I can choose to build my own or choose between Struts, WebWork, Velocity, Turbine—jeez! Which one is the right one? It depends on the task at hand!

For our ICBB example, I chose the Jakarta Project's Struts Web framework as it is arguably the most deployed Web framework in the J2EE world. Such wide deployment means that more developers know Struts than any other framework, Struts boasts a large and stable developer community, all the major application servers support Struts, and documentation/support is easy to come by. In short, you can expect Struts to be a long-lived Web application framework.

When using Struts, the system JSPs (JavaServer Pages) handle only data formatting and presentation. The pages themselves remain as simple as possible by using Jakarta Project standard tag libraries. These tag libraries require JSP 1.2 specification support, contained in all J2EE 1.3-compliant servers.

With tag libraries, Java code exists away from the JSPs, making the pages much easier to read and maintain. In addition, with tag libraries you can more easily change the JSPs' look and feel.

Business and data tiers

I implement the business and data tiers as one unit using stateless session beans called the ProductManager and CategoryManager. These session beans retrieve requested products and categories from the database, delete products, and apply changes made to products by an ICBB system administrator. They also update the database using straight SQL executed as Java Database Connectivity (JDBC) code. SQL statements execute as PreparedStatement objects to allow JDBC drivers to optimize them as cacheable statements in the database wherever possible.

In a more complex system, I would split the ProductManager between session beans for business functionality and entity beans for persistence, but the business case for ICBB simply doesn't warrant that approach—yet. Looking forward, I could easily extend the ProductManager session bean to delegate persistence to a separate persistence object(s).

Further, container managed transactions provide the system with transactional capability. Each business method invoked on the ProductManager class executes with a Required transaction attribute, and the Enterprise JavaBean (EJB) container manages the in-depth transaction management details.

Common services

Any serious enterprise computing platform must do the simple things well. In this section, we examine the most common bread and butter tasks in enterprise application development and how the J2EE-based ICBB sample application meets the following needs:

  • Exception handling: ICBBException indicates when an unexpected error occurs. ICBBExceptions are logged at the source to aid finding and fixing the underlying cause.

    In the presentation tier, JSPs provide specific error-handling support through the <%@ page isErrorPage="true" %> attribute in the page directive. JSPs with that tag act as error handlers for other JSPs for use in application-wide error reporting and handling. See ExceptionHandler.jsp for a concrete example.

  • Logging: The code base uses the log4j logging library in conjunction with the Logger wrapper class to provide a library-independent logging system view. Log4j supports multiple destinations for logging information, including flat file, XML output, console and socket output, and even the Windows Event logger. In contrast to .Net, no explicit distinction exists between logging and trace output in J2EE, although your chosen server vendor may employ nonstandard features to provide trace information. Like .Net, the logging level can vary dynamically to aid debugging production systems while minimizing the overall impact on performance.
  • Configuration: Server-side components such as servlets and EJBs can also store configuration information outside code via the web.xml and ejb-jar.xml files. The ServletConfig for servlets and the "java:comp/env" JNDI (Java Naming and Directory Interface) naming context for EJBs enable access to that configuration information.
  • Authentication: The servlet container's built-in capabilities handle user authentication based on users' established roles. By simply setting up protected resources in a declarative fashion, we can hand off the authorization and authentication responsibilities to the servlet container. See the etc/web.xml file for more details on this functionality (specifically the <security-role>, <login-config>, and <security-constraint> tags).
  • Authorization: The J2EE specification strongly supports both declarative and programmatic security through APIs and XML configuration files. The ICBB application includes two roles: reseller and admin. J2EE's declarative security features prevent nonadmin users from editing products, while its programmatic features control what a user sees on a particular JSP based on his or her current role.
  • Session management: The servlet/JSP specifications' session management support lets developers create sessions and track users either through cookies or URL rewriting, while both JSPs and servlets can access the HttpSession object. The servlet container can invalidate these HTTP sessions automatically after a specified time-out period or programmatically (by calling the session.invalidate() method).

J2EE tools

As with application servers, J2EE developers can choose among a wide range of free and commercial tools to enhance their productivity. My favorites include:

  • Ant (free): The standard build tool for compiling, packaging, and deploying Java-based software.
  • JUnit (free): A simple, easy-to-use unit testing framework for Java.
  • xdoclet (free): Use custom Javadoc tags to generate code, XML, and so on from Java source code. I used xdoclet to generate some of the code and deployment descriptors for ICBB J2EE solution.
  • Eclipse (free): A good Java IDE (integrated development environment). Achieves native code performance in Java! Supports debugging via the Java Platform Debugging Architecture (JPDA), including debugging server-side components, plus productivity features such as smart coding help, Ant and JUnit integration, some source-code management integration, refactoring, and more.
  • IntelliJ (commercial): Another good Java IDE. Also provides debugging support through the JPDA, plus useful productivity features such as smart coding help, Ant and JUnit integration, source-code management integration, and refactoring.

(For more information on the most popular Java-based development tools at present, read Jennifer Orr's "Java's Top Guns," (JavaWorld, March 2002) which honors the leading Java technologies in the JavaWorld 2002 Editors' Choice Awards.)

Build and test the application

For detailed instructions on how to set up the J2EE-based ICBB application, read the INSTALL.txt file included with the download pack.

Application server selection and portability

I chose IronFlare's Orion application server to run the J2EE-based ICBB application. Orion boasts a small download size, supports the standard J2EE specifications, and is easy to set up and develop on. Orion also supports application hot deployment and is 100% Pure Java, so it runs on any platform with a JDK.

You can choose from numerous alternatives, such as JBoss, BEA WebLogic, or IBM WebSphere. For me, Orion's ease of use, size, and speed make it a good choice for this project. If you want to deploy the application on other application servers, feel free. I used xdoclet to generate the server-specific pieces, such as the deployment descriptors, easing the porting process. In addition, I used no proprietary Orion features to build the sample application.

Data validation

Since the J2EE-based ICBB implementation uses Struts, I can hand off most of the data validation work to Strut's behind-the-scenes code. For each HTML form from which I want to update the system, I define a class that extends ActionForm, such as EditForm. Then I implement the validate method to handle whatever necessary validation before the associated Struts Action fires. Note that the data validation is server-side; to enforce client-side validation of particular fields, I would have used the Jakarta Project's Validate tag.

Caching strategies

For Web applications, caching refers to the storing and reuse of previously constructed HTML fragments or retrieved objects to reduce the overall response time to users. The resulting performance gain can mean the difference between a successful application and a slow application that frustrates its user base. So, then, how do we handle caching in the J2EE-based ICBB application?

  • Page caching: Unlike .Net, in J2EE caching generated HTML does not typically fall under the J2EE developer/administrator's control. Rather, the JSP/servlet container controls page caching under the covers as it sees fit. That lets JSP developers focus on constructing the JSP without worrying about explicitly managing caching policies or enforcing them.

    However, in the spirit of flexibility, an open source JSP tag library from OpenSymphony lets JSP developers control JSP caching. In addition, vendors such as BEA also support JSP caching, albeit in a proprietary fashion.

  • Data caching: J2EE's data-caching strategy depends on the data access strategy in use. EJB 2.0-compliant containers provide advanced caching strategies. Vendors, moreover, compete on the strength of their implementation/interpretation of the baseline EJB 2.0 specification. With more mature J2EE offerings, developers can use transactions directly against a cache, safe in the knowledge that the cache provider ensures the database remains consistent.

.Net notes

Now that Sheil has explained how he proposes to implement the ICBB application with J2EE, let's see how Monteiro will build the same application with .Net.

Figure 3 illustrates how the ICBB sample application looks when implemented on .Net.

1 2 3 Page 1
Page 1 of 3