First, let's get the J2EE terminology straight. Figure 2-1 depicts the assembly model for
J2EE applications. J2EE applications are composed of one or more components. A
component is a functional element of an application that runs within a container and
makes use of the runtime services provided by the container. These runtime services might
be security management services, transaction management services, lifecycle services, or
others, depending on the type of component and the type of container. A component
consists of one or more Java classes that implement the component, along with any
component-specific resources like properties files, images, and the like. J2EE components
(and their containers ) come in five flavors: application clients , applets , web, EJB, and
resource adapters .[*] Each type of container is capable of providing a specific set of APIs
and runtime services to its corresponding components.
It's important to note that most references on this subject distinguish resource adapters as a different category of "component" in the J2EE model: a lower-level
component that represents a resource to be used by the other, higher-order components, without a formal container model like the others. But for the sake of consistency
of the assembly and deployment model, they are included here among the other J2EE component types, since at a general level, they are handled much the same as
the other components.
J2EE components are grouped together and deployed in modules , which are collections
of components of the same type, to be run inside the corresponding container type. A
module contains all of the component-specific classes, plus any
Figure 2-1. J2EE assembly model (conceptual)
class libraries needed by the components and other cross-component resources, such as
datafiles, HTML documents (for web components), and image files. Each module also
contains a standard XMLdeployment descriptor that provides descriptive information,
external resource references, and configuration details about each component it contains.
If required, a module can also contain application server-specific details, such as
configuration files, classes, and resources that are required by a particular application
server. Most application servers, for example, allow you to specify additional configuration
parameters, not included in the standard J2EE deployment descriptors , in separate
configuration files. The application server vendor dictates the format for these files and
where they should be included in the module archive. Modules are packaged in the form
of jar files, with the deployment descriptor, classes, class libraries, and other resources
placed in specific locations in the jar file.
An enterprise application archive, or ear file, is a set of one or more modules, and these
modules collectively contain all of the components of an application. An application
archive also contains a deployment descriptor, which specifies the modules that it contains
and several other application-wide configuration details. Like components, application
archives are packaged into jar files with a particular layout, containing the deployment
descriptor for the application, the module jar files, and any other application resources,
such as documentation for the application.
In the remainder of this section, we'll talk about the general steps and concepts involved
in assembling and deploying J2EE applications. Following this, we'll discuss component
modules and application assemblies in more detail, using an example application as a
guide.
