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. Normally, such an installation takes in the order of a few minutes—half an hour at most.
The installation of a distributed enterprise application is unlike that of a packaged desktop application. 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 will require 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 Web and business components for an application could be distributed across multiple servers.
The appropriate level of security 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 currently a far more 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 the following:
Zero or more Web components packaged as Web Archives (WAR files)
Zero or more EJB components packaged as EJB-JAR files
Zero or more client components packaged as JAR files
Zero or more 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 Application Archive or EAR.
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 its requirements of the environment in which it will be deployed. This information is carried in a series of 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 described in the “Breaking Modules Down into Components” section of today's lesson. Figure 2.14 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.
Figure 2.14. Structure of an Enterprise Archive (EAR).
The application deployment descriptor contains application-wide deployment information and can potentially supersede information in individual component deployment descriptors.
Note
The EAR file can also contain a container-specific deployment descriptor that holds information that is useful to the container but falls outside the scope of the J2EE application deployment descriptor.
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.
Breaking Modules down into Components
As you can see from Figure 2.14, 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 Component
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 described the main class files contained in the EJB-JAR file. The deployment descriptor specifies which external resources are required by the component. It also contains extra information about the security and transaction settings. This resource and extra information is often referred to as metadata. Figure 2.15 shows a subset of the contents of an EJB deployment descriptor.
Figure 2.15. An EJB deployment descriptor indicates the main classes in the EJB-JAR file together with the component's metadata.
All of the component's metadata can be altered or replaced by the application assembler as they bind the component into the application. The application Deployer can also customize some of the metadata.
Note
An EJB-JAR file can contain more than one EJB.
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.
Web Component
Servlets and JSPs can also be packaged together into a component archive file. The archive file is a JAR-format file that contains the class files, JSP files, and resources required by the Web component. In this case, the resources can include static HTML files that form part of the application. This Web Archive (WAR) file also contains a deployment descriptor that indicates the Web components contained in the WAR.
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 URLs onto which servlets and JSPs should be mapped, and which is the front page of the application.
WAR files and their deployment descriptors are discussed in more detail on Day 12, “Servlets,” and Day 13. Other aspects of WAR deployment information, such as security, are covered later.