First, in simple terms and few sentences, give me a quick summary of J2EE.
J2EE (pronounced “jay too ee eeEEEEEE!” ) stands for Java 2 Platform Enterprise Edition. J2EE is a conglomeration of standards for architectures, protocols, languages, APIs, and services that allow companies to implement and deploy web applications capable of serving many, many users. If you walk into a department store, an airport, or a bank and the clerk is relying on software with web pages, chances are that system is implemented either with J2EE or .NET. J2EE is an open source standard that is controlled and owned by Sun Microsystems and that is implemented by a number of vendors including IBM (as WebSphere Application Server), Oracle (as Oracle Application Server), BEA (as WebLogic and now owned by Oracle), Red Hat (as JBoss Application Server), and others.
What problem is J2EE intended to solve?
The grand vision of J2EE was three fold:
- First, it was supposed to make programming easier by abstracting up a number of problems that have plagued programmers since the invention of computers. For example, J2EE promised to conceal complexities pertaining to security, database access, failover, and scaling. The idea was to free programmers from such pesky programming issues and to allow them to concentrate solely on their company’s specialized competencies and business logic. Hmmmmmm.
- Second, and like so many of its predecessors, J2EE was supposed to be heavily “componentized” and encourage code reuse.
- Third, the architecture was supposed to be layered in such a way that development roles would be highly distinct and independent. The web developers would only need to know JSP and HTML, for example, while the business logic folks would specialize only in Java programming. The components would be stuck together by an “application assembler” into an application. A “deployer” would push the software into production where it would be maintained by a system administrator. No… seriously… that’s the vision.
In practice, the industry uses J2EE very differently than its creators originally envisioned, and the realization of these goals has not occurred. However, the technology provides significant value nonetheless (see the “How well does it work?” section in the book).
J2EE has a lot of parts. How do those look when they are finally deployed on real computers?
Almost all books on J2EE show the same J2EE architecture diagram from the official J2EE specification, and it’s utterly useless for people who are trying to understand the technology from scratch . Instead of refering to that diagram, let’s show a different utterly useless diagram:
The J2EE Four Tier Architecture
On the left, the standard J2EE architecture tiers are shown. In the middle, you can see the key software pieces that reside in each tier. On the right, each layer’s corresponding physical incarnation is shown. Note how the “Web Tier” really spans two machines – the HTTP Server, and half of the application server (or “app server”). J2EE is a server-side architecture, so critical business functions are performed in a secure, controlled computer room, as opposed to a client-side application that performs critical tasks on the PC. Seriously, the diagram above really does help to understand what happens where and why.
Give me a few short words on "application servers" and "containers".
The most important machine in the diagram is the application server. The app server machine runs application server software (like IBM’s WebSphere Application Server, or Oracle’s Application Server). The application server software is really just a giant Java program that has at least two key parts to it – a “Web Container” and an “EJB Container”. Those “containers” are responsible for running custom software in a very controlled fashion. So the application server is a Java program that runs other Java programs. The web container runs servlets (a kind of Java program) and JSPs (which are ultimately just servlets too). The EJB Container runs session and entity beans, which are really just Java classes designed to be called by the container program. Everything that runs in the application server is Java-based, which is a key difference between J2EE and .NET.
In J2EE, what happens from the time a user clicks on a button?
It helps to understand what happens when a user clicks on a web page. The request travels across the network to the HTTP Server. The HTTP stores simple images (.gif or .jpg, for example) and simple unchanging text (.html files, for example) and if it can, will service the request by itself, without asking the app server for help. However, if the request is for something more complicated that requires calculations or a database hit, the HTTP Server passes the request on to the App Server. (Sometimes you can tell if this is happening if you see a “.jsp” embedded somewhere in the URL.)
When the application server receives a request from the HTTP Server, it passes the information to its web container, which runs a “servlet” to calculate what HTML should be generated and returned. Rather than hitting the database directly (as would be done in, say, PHP), the servlets are SUPPOSED to pass the request on to session beans, which perform business logic and that reside in the EJB contain. Those session beans are SUPPOSED to use entity beans to perform create, update, retrieve, and delete actions to the database. Entity beans provide support for organizing the information in the database into classes so information that potentially resides across multiple tables can be dealt with as a unit. Moreover, entity beans shield the programmer from having to worry about two users changing the same data at the same time or from having to cache data for performance, or from a number of other well known database interaction problems. Entity beans also ensure that data are accessed in consistent naming and access patterns, and that multiple data source vendors (like Oracle or DB2) can be “transparently” swapped. The entity bean packages up the information from the database and returns it to the session bean, which completes its business logic calculations. The EJB container then passes this information back to the web container which passes the information back to the HTTP Server who passes it back to the browser.
Give me 5 sentences or less on the "web" and "EJB" containers.
Technically, the J2EE specification does not require that the web container and the EJB container be unified in a single program but this is how the application server vendors all seem to implement the application server – as a single Java Program running in one Java Virtual Machine (or “JVM”). You may hear administrators refer to the app server program simply as a “JVM”. Since J2EE provides nice vertical scaling support, you can run multiple app servers programs (or “JVMs”) on the same app server machine. The term “app server” usually refers either to a single instance of the application server program or it refers to the machine (or set of machines) that run these app server programs.
So what's the benefit of J2EE?
Although a container is really just a portion of a single “app server” program running in a JVM, J2EE is better thought of as an operating system for the JVM “hardware”. JVMs by themselves do not provide operating system-like mechanisms to manage applications running inside of them nor do they provide support to manage their shared resources (like memory and database connections). Running a Java application directly inside of a JVM is akin to writing assembly language and running it directly in a chip with no operating system. J2EE is a technology that fills this operating system gap and the app server containers act as the operating system for the JVM. This has emerged as the most important purpose of J2EE and it has considerable value. (.NET does not offer a similar benefit since there is no virtual machine in .NET that’s missing an operating system, although it offers different benefits.)
What's all this WAR and EAR file stuff I keep hearing about?
J2EE programmers develop servlets and package them in WAR files that run in the web container. That is, the web container in the app server knows how to unpack the contents of a WAR file and prepare to respond to requests for the servlets inside of the WAR file (or JSPs, which are also servlets). Requests for those servlets will come from the HTTP Server. On the business tier side, session and entity beans are bundled into JAR files that run within the EJB container. The EJB container knows how to unpack the contents of the jar files and prepare for requests for those beans from the web container. WAR files are bundled together with the JAR files into a larger EAR file and frequently “deployed” to the app server as a whole – as an enterprise application. The EAR file has both the servlets and the enterprise beans. So in the end, the enterprise application runs inside of the web and EJB containers (virtual operating systems), which run inside a JVM (virtual hardware), which run on top of an operating system like UNIX (a traditional operating system), which runs on a physical computer (real hardware).
Wrap it up, I'm out of time.
So J2EE provides the operating system for a JVM, which allows you to run multiple processes inside of the virtual machine and manage the machine’s resources just like you might run programs inside of UNIX or Windows O/S. But J2EE does something very important even beyond that. J2EE not only provides an operating system for a single JVM, it provides an interface to act as a distributed operating system across multiple machines. That is, J2EE has the ability to make multiple JVMs appear as though you were dealing with a single computer. You can deploy an application across all the machines at the same time with a single operation. J2EE can be used to control multiple machines with separate JVMs as though they were one machine. It’s the operating-system like capabilities of J2EE that provide its true value.
But how well does J2EE really work out in industry?
So how well does J2EE work in practice? J2EE is not at all used in industry how it was originally intended to be used. Remarkably though, it still can provide enormous value. It's essential to understand why J2EE doesn’t get used in the way it was intended and why industry uses it another way in order to avoid the very common pitfalls of the technology. These topics are covered in detail in the book you can order below. To get that next big raise (or to keep your job), you need to ensure your company is successful with J2EE. Avoid the utter disasters that so many J2EE projects seem to turn into. Leverage off the experience of people who have pushed many J2EE projects into production. Don't just settle for the book excerpt you've read above - click the “Buy Now” button below to get the whole picture. It’s a business expense, it's an easy read, and you're likely to be surprised at some of the common mistakes revealed for other technologies as well.