Guidelines: Assembling J2EE Modules
Topics
Introduction
This guidelines page focuses on the assembly of J2EE Modules.
Assembly a J2EE Module results in the following Implementation Elements :
- J2EE archive (WAR, EJB-JAR, and JAR files), and its
- Deployment descriptors (XML files) that describe the contents of the archive and describe how the contained components are intended to function within the deployment container
For more information on J2EE Modules, see Guidelines: J2EE Modules.
Defining the Archive
In this step, the application component provider identifies the components that are to be packaged in the module.
Multiple archives may be produced for different purposes. For example, separate archives for testing, debugging, or delivery to different "production" deployment configurations. The testing archives would contain testing classes and classes built with debug flags, while the production archives would not contain test classes and would not be built with debug flags. The intended context of the archive being assembled affects the assembly workspace that is set up.
Defining the Deployment Descriptors
The key step in assembling a J2EE Module is defining the deployment descriptor. Much of this information should have been captured in the design of each component, and so defining the deployment descriptor is largely about ensuring consistency with the design. If you are using round-trip engineering, then there may also be tool support for generating the deployment descriptor.
Each archive contains a J2EE-standard deployment descriptor, plus zero or more vendor-specific descriptors. The standard descriptors, ejb-jar.xml for EJB-JARs, and web.xml for WARs, contain sections that need to completed for testing and other "non-production" deployments, plus sections that will be prepared by the final application assembler for production deployment.
Each descriptor contains information of interest to application component providers, as well as application assemblers. For example, ejb-jar.xml contains three major sections (for the purposes of our discussion): <enterprise-beans>...</enterprise-beans>, <relationships>...</relationships>, and <assembly-descriptor>...</assembly-descriptor>. The application component provider defines the properties of the EJBs, such as CMP fields, in the <enterprise-beans>...</enterprise-beans> section. The application component provider also defines the optional relationships between EJBs in the <relationships>...</relationships> section. The <assembly-descriptor>...</assembly-descriptor> section is where transactions, security roles, method permissions, etc. are defined. Normally, only the application assembler will worry about this section. The assembler may decide to modify the contents of the other two sections, but this is less common. The situation is similar for WAR archives. For more information on application assembly, see Guidelines: Assembling J2EE Applications.
If, during design, you defined mappings between database tables in the Data Model and container-managed persistent (CMP) entity EJB's, those mappings should be reflected in the mapping directives in the vendor-specific descriptors (mapping directives are not part of the standard EJB descriptor). For more information on mapping CMP entity EJBs to database tables,, see Guidelines: Designing Entity Beans.
If multiple components are to be packaged in the same archive (see step: Defining the Archive), the application component provider must integrate their deployment descriptor information. For example, when combining EJBs into one EJB-JAR, the application component provider must harmonize information in the deployment descriptors, such as security roles, and cross-references.
Validating the Archive
It is a good idea to valid the contents of the archive before attempting deployment, as obscure errors, especially on the application server side, may result in obscure or non-existent error messages. For example, duplicate JNDI names cannot be used by any of the components packaged in the archive.
