An IT headhunter recently asked if I "knew" J2EE, and then realized something, paused, and followed up with, "What is J2EE, anyway?"

Trying to be efficient in a breathless sort of way, she never gave me a chance to give her an answer. The company she hustles for seems to work much the same way, so I politely declined the job interview. Still, so long as I don't give her my spiel, my take on J2EE, I will continue to have this nagging feeling of something left undone. I'll email her this piece when it's finished.

Overlaps with earlier writeups on the topic are unavoidable. These are my words, for better or worse.

J2EE

J2EE is a technological standard developed by Sun Microsystems, the "makers" of Java. The acronym stands for "Java 2 Enterprise Edition". Java 2 is just what they call the current maturity level of their Java product. It used to be just "Java", but over the years they've poured in so many extensions and enhancements that they decided it was time for a name change. The base product, what everybody thinks of when they hear "Java", consists of the language itself, the library, the compiler and some other tools for working with them, and is called "Java 2 Standard Edition" (J2SE).

J2EE defines a number of extensions to J2SE which Sun feels are essential to the software infrastructure used for many Java-based "Enterprise-level" IT projects. The most widespread, if not universal paradigm for enterprise-level computing is the n-tier client/server architecture. Applying Julius Caesar's "divide and conquer" principle, this approach separates IT infrastructures into three, layers, or tiers:

  1. The client layer communicates with the user, usually through a Graphical User Interface (GUI), often a Web browser.
  2. The business layer, sometimes also known as the middle layer, contains code to implement the logic of the process. Essentially, this answers the question of, "given this input, what should the results and the output be?"
  3. The data access layer, sometimes aka the Enterprise Information System(s) layer, is where the system's owning company keeps its data: Customer database, product catalog, sales transaction records and so on.
In real life, sometimes layers are split in different ways, so that the number of tiers is not always three. That's why this technology is also sometimes aka "n-tier Client/Server."

The n-tier split is helpful in partitioning problems, but often not enough. Programming the complete business layer for an application is often tremendously difficult. However, experience has shown that most applications share a set of common activities, many of which are quite difficult to program "correctly" in such a way that expectations of performance and reliability are consistently met. J2EE's solution to this problem is to provide standard implementations for many of the common activities, mostly involved with infrastructure and management, which I sometimes call "plumbing". J2EE also specifies a framework which holds the pieces together. Thus, if all goes well, the programmer needs only to code those parts of the application which are unique to the problem at hand. Again, the "divide and conquer" principle simplifies a complex task.

Specifically, J2EE provides the following:

  • JNDI: Java Naming and Directory Interface, which lets an application discover its own components and those of other applications
  • Servlets, a technology standard for creating dynamic Web pages in Java code
  • JSP: Java Server Pages allow servlets to be built into Web pages
  • JMS: Java Messaging Service for asynchronous messaging
  • JTA: Java Transaction API (API is a TLA for "Application Program Interface")
  • JavaMail for mail handling
  • ... some other, similar bits and pieces which I choose to leave out for brevity; other people may assign different priorities to the parts of J2EE but I think this list gives a good partial overview. But here are the three pieces which, in my view, are the most essential:
  • EJB: Enterprise Java Beans, a standard for "wrapping" service functional code in a way that lends itself to management and persistence
  • An EJB container for interfacing, managing and persisting EJBs
  • A J2EE Server, i.e. a body of software which embodies all or a subset of the above technologies.
EJBs, EJB containers and the J2EE server, are those parts of the standard that perhaps provide the biggest benefit in breaking an application into chunks suitable in scope for a single programmer or small group. By adhering to a set of conventions in building business services and data objects, they automatically become eligible for use in the EJB container's framework, which provides simple and automatic persistence and database access, management, security services and so on. The server, meanwhile, advertises these services and makes them available to clients and other servers.

There is a popular Open Source J2EE server implementation called JBoss. Of course, there are also many commercial offerings which claim a fuller range of implemented services, greater performance and stability and better integration with other products by the same manufacturer. Some noteworthy examples that come to my mind are IBM WebSphere and BEA WebLogic Server.