7.1 Packaging Components

A J2EE component (such as a servlet or an enterprise bean) is an independent functional software unit that conforms to interfaces defined by a component specification, and has only explicit dependencies on its environment. A component may be a single class, but more often is a collection of classes, interfaces, and resources. The J2EE platform offers five types of components: enterprise beans, servlets and JSP pages, applets, application clients, and connectors.

The J2EE platform specification provides a way to bundle one or more components into a module, which is the smallest unit of independent deployment for any component type. A module may be deployed directly into a J2EE container, or one or more modules may be combined to form a J2EE application. For example, several enterprise bean components may be packaged into an EJB module that provides all or part of an application model, and that EJB module may be further combined with other modules to create a J2EE application.

Modules and applications for the J2EE platform are packaged and deployed as deployment units, which are compressed archive files similar to JAR files, but with a specified internal structure and file extension. There are four types of J2EE platform modules:

• EJB modules contain enterprise beans and related classes.
• Web modules contain web-tier components and resources.
• Application client modules contain application client classes.
• Resource adapter modules contain Java connectors, resource adapters, and support libraries and resources.

The deployment unit for each type of module has a structure defined by the corresponding component technology specification. For example, a Web module deployment unit is called a "Web archive," which has (among other things) a WEB-INF directory containing support files for the module. One or more J2EE platform modules can be composed into a J2EE application, which has its own type of deployment unit.

In addition to components and resources, each deployment unit contains a deployment descriptor, which is an XML file that specifies the explicit dependencies between each component and its environment. Deployment descriptors specify two kinds of information:

• Structural information--Meta-data that describes the components contained in the deployment unit, their relationships to each other, and their external dependencies. Structural information corresponds to hard-coded features that are not configurable at deployment time. Such information includes the names of enterprise bean home and remote interfaces and implementation classes, entity bean primary key classes, the persistence mechanisms used, and so on. Environment entry declarations and resource requirements are also part of structural information. A component container uses structural information to manage component instances at runtime.

Changing structural information in a deployment descriptor can cause a component to operate incorrectly or not at all, because it must be consistent with inherent hard-coded features. For example, an entity bean is an entity bean because it implements the EntityBean interface, and a deployment descriptor that says otherwise is simply wrong.

• Assembly information--This optional information describes how the contents of a deployment unit are composed with other deployment units to produce a new component. Assembly information includes enterprise bean relationship names, descriptive entries, security roles, method permissions, and the values of environment entries.

Assembly information in a deployment descriptor can be changed without breaking the corresponding component, although doing so may alter the behavior of the assembled application.

See Code Example 7.1 and the text following it for an example of structural and assembly information.

Each J2EE developer role has specific packaging and deployment responsibilities.