Packaging and Deploying J2EE Applications

The installation of a typical desktop application, such as a word processor, is usually a straightforward affair. The installation program will ask you a few questions about the functionality you require and where it should install its files. It will also examine parts of your desktop machine (such as the Windows registry) to discover whether any components that it relies on are already installed.

The installation of a desktop application is reasonably straightforward because

• The concept of word processing is well understood by most people, so they can make an appropriate judgment on whether they need particular parts of the package or not. There is little in the way of personal tailoring involved.

• All of the installation takes place on a single machine. The installation program knows where to find existing configuration information and where it should install the different parts of the application.

Compared with this, a distributed enterprise application requires a lot more information about the environment in which it is to be installed. This includes, but is not limited to, the following:

• The location of the servers on which the server-side components will be deployed.

• The appropriate level of security that must be enforced for the application. The application must carry with it information about the security roles it expects and the access each role has to the functionality of the application. These security roles must be mapped onto the underlying security principals used in the distributed environment.

• Components that access data and other resources must be configured to use appropriate local data sources.

• The names of components and resources must be checked and potentially changed to avoid clashes with existing applications or to conform to a company-wide naming standard.

• Web components must be configured so that they integrate with any existing Web sites of which they will form a part.

As you can see, this is specialist task, requiring knowledge about the application and the environment in which it is being deployed. The application must carry with it information about the requirements it has of the environment. The Application Assembler defines these requirements when the application is created. The Application Deployer must examine these requirements and map them onto the underlying environment.

J2EE Applications

A J2EE application will consist of zero or more of the following components:

• Web applications packaged as Web Archives (WAR files)

• EJB components packaged as EJB-JAR files

• Client applications packaged as JAR files

• Connectors packaged as Resource Archives (RAR files)

Naturally, there must be at least one component for there to be an application! The components that constitute an application must be packaged together so that they can be transported and then deployed. To this end, all of the components in a J2EE application are stored in a particular type of JAR file called an Enterprise Archive or EAR file.

Given the previous scenario, it should be clear that a J2EE application needs to carry with it information about how its different parts interrelate and the requirements of the environment in which it will be deployed. This information is carried in XML documents called deployment descriptors. There is an overall application deployment descriptor that defines application-level requirements. This application deployment descriptor is also stored in the EAR file.

Each individual component will have its own deployment descriptor that defines its own configuration and requirements. These component deployment descriptors are carried in the individual component archives. Figure 2.5 shows the structure of an EAR file and how the application deployment descriptor, the component archives, and the component deployment descriptors fit within this structure.

The application deployment descriptor contains application-wide deployment information and can potentially supersede information in individual component deployment descriptors.

The application is split into modules, each of which represents a component. If necessary, a module can contain an additional deployment descriptor to override some or all settings in the deployment descriptor provided in the component archive file.

As you can see from Figure 2.5, components are represented in an EAR file by component archive files. Each module will point to its associated component archive file. Each type of component archive file is a JAR-format file that contains the component's classes and resources together with a component-specific deployment descriptor.

The two most common types of component archive are EJB-JAR files and WAR files.

EJB Components

An EJB-JAR file contains all of the classes that make up an EJB. It also contains any resource files required by the EJB. The properties of the component are described in its associated deployment descriptor, called ejb-jar.xml, which is also included in the EJB-JAR file.

The deployment descriptor describes the main class files contained in the EJB-JAR file. The deployment descriptor also specifies which external resources are required by the component and information about the security and transaction settings. This resource and extra information is often referred to as metadata. Figure 2.6 shows a subset of the contents of an EJB deployment descriptor.

All of the component's metadata can be altered or replaced by the Application Assembler when they bind the component into the application. The Application Deployer can also customize some of the metadata.

EJB-JAR files and their deployment descriptors are discussed in more detail on Days 4 and 5. Other aspects of EJB deployment information, such as security and transactions, are covered later in the book.

Web Components

Servlets and JSPs can also be packaged together into a Web archive resource (WAR) file. The archive file is a JAR-format file that contains the class files, JSP files, and resources required by the Web components (including static HTML files) and a deployment descriptor (called web.xml).

Just as with the EJB deployment descriptor, the WAR deployment descriptor indicates the main classes in the WAR file and the resources required by the components. However, the WAR deployment descriptor also contains Web-specific information, such as the URL mappings for the servlets and JSPs.

WAR files and their deployment descriptors are discussed in more detail on Day 12 and Day 13, “JavaServer Pages.”

Application Components

Standalone client applications are packaged into a JAR file containing all the constituent classes and a deployment descriptor called application-client.xml. Application clients are Java applications that directly access EJBs. Application clients are described on Day 4 and Day 5.

Connector Components

Connectors provide resources that can be used by a J2EE component but are not supplied as a standard constituent of the J2EE containers. The connectors you are most likely to come across are connectors to a JMS implementation (see Day 9) and general purpose connectors for accessing external EIS and ERP systems (see Day 19, “Integrating with External Resources”).