In the last chapter we introduced you to web applications, but the web tier is just one part of the J2EE spectrum. In this chapter, we’ll expand the JAW application from a simple WAR file into a full-fledged EAR.
We’ll explore the different parts of an EAR file. We’ll build a Common JAR containing classes that can be shared across all tiers of the application. Finally, we’ll play with various Ant and XDoclet tasks to create our EAR and dynamically generate the deployment descriptors JBoss needs.
WARs Versus EARs
The WAR file is a convenient way to bundle up all pieces of a web application. All servlet containers know how to deploy a WAR file—they expand the bundle, look for the WEB-INF directory, and read the web.xml found there for further deployment instructions.
The EAR file provides the same type of functionality for a full-fledged J2EE application. JBoss expands the EAR, finds the required deployment descriptors, and proceeds from there.
An EAR is like a carton of eggs—it keeps everything organized. While the carton doesn’t add any direct value to your omelet, it makes getting the eggs home from the store so easy that you wouldn’t think about transporting eggs any other way.
Each egg in your EAR carton is a specific piece of the J2EE puzzle. These eggs (or JARs) come in three basic varieties called “modules”:
Web module A WAR file containing presentation tier components
EJB module An EJB JAR file containing the middle-tier components (EJBs, MDBs, etc.)
Java module A regular JAR file containing classes and libraries that are shared across the entire application. An application client JAR and a common JAR are two examples of Java modules.
An EAR can contain at least one of any of these modules. By the same token, any of them can be safely omitted if they aren’t needed. Figure 3-1 shows the structure of an EAR file.
Web Authoring 
/ 12 
Completing an EAR
