If you've picked up any books on Java recently (including my own--I'm as guilty as the rest), you've almost certainly been inundated with terms such as "enterprise applications" or "Java 2 Enterprise Edition" and its acronym, J2EE. It seems everyone's talking about J2EE and how it is revolutionizing their enterprise applications. Additionally, there is an implicit pairing going on in the Java world. Many people think enterprise applications, defined generally as distributed applications, have become dependent on the J2EE platform, the set of APIs and implementation guidelines created and maintained by Sun Microsystems.
As an employee of Lutris Technologies, the sponsor of Lutris Enhydra, an open source Java application server, I know this firsthand. At least once a day, we hear: "When will Enhydra's J2EE implementation be out?" or "Will the next version of Enhydra be J2EE-compliant?" Unfortunately, people seem to think their application simply will not run without J2EE. They think the marriage between enterprise applications and the J2EE platform is a perfect and enduring union. Let me be the first to tell you, the honeymoon isn't going so well.
Perhaps the most difficult problem in building enterprise applications today is the blurring of the line between what is wanted and what is needed. All too often, people go overboard with their applications. In geek talk, this is called "buzzmania." Buzzmania is the tendency to buy more, get more, and use more, simply because more "buzzwords" are in a product. This is a large part of the J2EE problem. With the J2EE product descriptions and specifications reading like a meeting of exotic 12-step programs--JSP, XML, JMS, EJB, CMP, BMP, OR, JDBC--it's no wonder managers' eyes light up at sales presentations.
However, the reality is few companies, and few industries, need all these services. I'd estimate 50% to 70% of the companies that have purchased or are purchasing J2EE solutions could easily get by with a simple servlet and a JDBC-based solution. Presentation logic housed in the servlet coupled with database access through JDBC would suffice for most types of applications, including many e-commerce solutions. Adding JSP, or another presentation technology, such as Enhydra XMLC, makes this an even more robust option.
There is, however, no glamour in this approach. What would the neighbors think (Granted, these are neighbors like Sprint, Cisco, and eBay.) if you only had a feeble servlet-based solution, instead of a burly EJB and XML-based one? Probably not much. Then again, what will the neighbors think when your projects come in on time and under budget? The tables could turn at that point. Imagine needing only to hire servlet and JDBC developers and not also needing to search for EJB, XML, and JMS experts.
So why aren't companies flocking to this approach? Because many companies don't distinguish their real needs from their imagined ones. For a small- to medium-size company with less than a million-dollar weekly revenue, an EJB server and container are massive overkill. They provide transactions and security for high-volume, high-money sites, which many companies will never need.
In fact, running these services for small-volume sites can actually decrease performance. As for the guaranteed messaging that JMS provides? Most developers, and their companies, have no idea what pub/sub (publisher/subscriber) and point-to-point messaging services mean, let alone where they should be used. And XML? Although it has literally hundreds of uses, XML is a large and slow format for many types of communication. While it excels at providing a standard means of data exchange across applications, many companies are using XML for communicating, for example, from a servlet to an EJB container on the same physical hardware! Simple Java serialization could yield great performance increases.
So what does this all mean? Again, when developing enterprise applications, it's critical to to be clear about business and technology needs as opposed to wants. If a system truly requires cross-platform communication via HTTP, guaranteed delivery of messages, support for millions of transactions (all monetary), and the ability to run on 50 different servers, I will be the first to point developers and managers to a J2EE solution. However, in several years of enterprise application consulting in Java, I can count on my hands the number of times this has been the case.
It's far too common to find managers and developers in the boardroom listening to sales pitches for technologies they don't understand and their companies don't need--and then purchasing the product that had the most impressive list of acronyms. So let's begin to weed out what we want from what we need. J2EE solutions rarely fit in the latter category.
Once you cut through the hype and the lengthy list of letters running together in almost meaningless ways, you get the impression that J2EE offers one-stop shopping. In other words, a J2EE solution seems to provide everything you need for an enterprise application in one neat package. Many who claim they are "planning for the future" when they bring in a J2EE solution are assuming this. But we all know what happens when we assume.
While J2EE is a terrific first step at a unified platform and set of APIs for developing enterprise applications, it is still just a first step. The activity unrelated to J2EE at Sun Microsystems should help emphasize this point. Visit java.sun.com and you'll see how many XML-related specifications and APIs are being developed--all intended for enterprise application use.
None of these developments are in the latest version of J2EE (1.2), and don't be surprised when they make it into the next revision. What does this writing on the wall mean? J2EE isn't anywhere close to complete, or fully-featured.
In addition to gaps in XML, the platform has some other significant holes. There is no concept of time in J2EE. If this seems a trivial item to you, it shouldn't. Imagine two servers interacting to place an online order for 100,000 shares of a stock. If these two machines are just 30 seconds apart in their perception of the time the order was placed, millions of dollars could be lost. Multiply this problem over a set of 30 servers assisting millions of users, and disaster becomes imminent.
Handling time services over a distributed set of systems is crucial. Because of the lack of timing, task schedulers (Are you still using cron jobs?) are also conspicuously absent from the J2EE specification. The entire model is still based on simple request- and response-driven events. While some hacks can be made using JMS, they are hardly API-worthy.
Management is another glaring problem with J2EE. While JMX, the Java Management Extensions, are a welcome addition to the Java language, they are not currently part of the J2EE specification. Try and sell your boss on a costly J2EE solution, then be prepared to duck (for fear of a flying stapler) when you mention that management of the system requires another product. And while JMX is making strides, it is still in an early form, even earlier than J2EE itself. What you end up with is an immature platform managed by an even more immature set of APIs--a cause for concern, at the least.
Without going into a tirade, you begin to see that there are serious gaps in the J2EE platform. Licensing, versioning of components, security, a standard mechanism for logging, and metadata are just a few of the other major issues left unresolved in the current specification. While the idea of obtaining a platform for enterprise computing is an appealing one, do not be fooled into thinking J2EE, at least today's version, is a complete solution.
So what does all this mean? Am I saying that using J2EE is a waste of time? Certainly not! In fact, I work for an application server company that soon will have a J2EE offering. I don't think, however, that misinformation should be used to sell software. And, although many people understand that the decision to use a J2EE solution is a big decision, many claim J2EE is the perfect solution, the magic bullet. If it were, there would be no need for projects like Enhydra XMLC, Apache Cocoon, SOAP, and other non-J2EE technologies.
Should you go J2EE? Perhaps; perhaps not. Again, first you consider your business needs. If you are serving 100 pages per day to 1,000 customers, you are wasting time and resources trying to marshal the J2EE platform for your needs. Pick up Java Servlet Programming, by Jason Hunter, and save yourself a headache. It is an altogether different proposition if you are running the world's largest online financial bank. In that case, buckle down, read up on EJB and XML, and get ready for a bumpy ride: Even when J2EE is needed, it won't always work as you expect. And don't think a whirl around the block with Sun's "Pet Store" application is going to teach you everything you need to know about J2EE.
So open your eyes (very wide) to the prospect that:
Knowledge of these simple equations could save you hundreds of thousands of dollars in software and development costs. Be aware of the cons as well as the pros, and most of all, use what you need, not what you want. While the union of J2EE and enterprise applications may succeed, there are some real problems that need to be worked out before we can talk about the happy marriage.enterprise application != J2EE and thatJ2EE != solution-to-all-your-problems . 1
1In case you're wondering if your browser is suddenly acting up, the notation != is programmer speak for "does not equal."
Brett McLaughlin works as an Enterprise Java consultant at Lutris Technologies and specializes in distributed systems architecture. He is the author of Java and XML (O'Reilly), as well as an upcoming O'Reilly book, Java Web Architecture. He is involved in technologies such as Java servlets, Enterprise JavaBeans, XML, and business-to-business applications. He is an active developer on the Apache Cocoon project, EJBoss EJB server, and a cofounder of the Apache Turbine project.
O'Reilly & Associates recently released Brett McLaughlin's Java and XML.
Copyright © 2007 O'Reilly Media, Inc.