| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
A J2EE application is packaged as an Enterprise ARchive (EAR) file, a standard Java JAR file with an .ear extension. The goal of this file format is to provide an application deployment unit that is assured of being portable.
A J2EE application file contains one or more J2EE modules and a J2EE application deployment descriptor. Therefore, creation of a J2EE application is a two- step process. First, the Application Component Providers create the J2EE modules: EJB, Web, and application client modules. Second, the Application Assembler packages these modules together to create the J2EE application. In this section, we will discuss the issues involved in both of these steps.
It is important to note that all J2EE modules are independently deployable units. This enables component providers to create units of functionality without having to implement full scale applications.
To assemble an application, an Application Assembler edits deployment descriptors for the J2EE modules to link dependencies between components within each archive and between components in different archives. All such dependencies must be linked before deployment. For example, in the sample application, the Web components in the WAR file need to refer to ShoppingClientController, Catalog, Account, Order, and ShoppingCart enterprise beans present in the EJB JAR file. The role of the Application Assembler is to make sure that the description of the enterprise beans in the WAR file matches with their description in the EJB JAR file.
Once the application assembly is complete, we recommend that the Application Assemblers run J2EE verifier tools (one is provided with the J2EE SDK) on the EAR file to ensure that its contents are well-formed. The verifiers perform a number of static checks to ensure that the deployment descriptor and the archive file contents are consistent with the EJB, Servlet, and J2EE specifications. While verification is not a guarantee of correct behavior at runtime, it is useful for catching some errors early on.
The following sections discuss the different types of J2EE modules and give some heuristic rules and practical tips on how best to package the different component types into modules.
An EJB module is the smallest deployable and usable unit of enterprise beans. An EJB module is packaged and deployed as an EJB JAR file, a JAR file with a .jar extension. It contains:
- Java class files for the enterprise beans and their remote and home interfaces. If the bean is an entity bean, its primary key class must also be present in the EJB module.
- Java class files for any classes and interfaces that the enterprise bean code depends on that are not included with the J2EE platform. This may include superclasses and superinterfaces and the classes and interfaces used as method parameters, results, and exceptions.
- A EJB deployment descriptor that provides both the structural and application assembly information for the enterprise beans in the EJB module. The application assembly information is optional and is typically included only with assembled applications.
An EJB JAR file differs from a standard JAR file in one key aspect: it is augmented with a deployment descriptor that contains meta-information about one or more enterprise beans.
The EJB JAR file producer can create a client JAR file to be used by the clients of the enterprise beans contained in the EJB JAR file. The client JAR file consists of all the class files that a client program needs to use to access the enterprise beans that are contained in the EJB JAR file.
A typical enterprise application will contain many enterprise beans. Some of these enterprise beans could be off-the-shelf components while others may use third-party libraries. The Application Assembler, therefore, has to choose from the following packaging options:
Because its more modular, the third option is recommended for reasonably-sized J2EE applications. It strikes the right balance between maximum reusability (option 1) and maximum simplicity (option 2). It promotes the black-box use of third-party components, which is especially important when such third-party components that are digitally signed. Another value of the third option arises when a J2EE server deploys each EJB module on a separate Java virtual machine for load balancing. In such cases, the third option is most efficient since it groups closely-coupled enterprise beans together, allowing many remote calls to be optimized to local calls. Another advantage of option 3 is that it promotes reusability at the functional level rather than at the enterprise bean level. For example, making a single Account enterprise bean reusable is more difficult than providing a reusable set of classes that provide account management functionality collectively. Logical grouping also makes sense from a tool point of view. A deployment or assembly tool may show the EJB module as a group under a single icon. The following discussions provide guidelines on grouping enterprise beans.
7.2.2.1 Grouping by Related Functionality
Once a group of enterprise beans is packaged into the same EJB module, they may not be easily separated without knowing significant implementation details of each enterprise bean. To reuse one bean from an EJB module, you would generally have to deploy all of them. So, it makes good sense to package together a group of enterprise beans only if they will be commonly deployed and used together.
The utility classes used by a bean must be packaged into the EJB module of that bean in order for the bean to function correctly at runtime. If you package related beans together, you reduce the number of copies of utility classes which would otherwise increase the virtual machine size of most J2EE servers and could cause potential conflicts during upgrades.
EJB modules will commonly be displayed in a palette of reusable components in a J2EE application assembly tool. Tools will commonly group together enterprise beans from the same EJB module in a user interface. For example, it makes sense to group server-side components related to accounting functionality or specialized database functionality in a single code library or EJB module.
7.2.2.2 Grouping Interrelated Beans
Enterprise beans can call one another at runtime, and one enterprise bean can delegate some of its functionality to another. Though some J2EE servers will support highly efficient cross-application dependencies, enterprise beans that depend on one another should be grouped together in the same JAR file for both organizational and performance reasons. Where beans call one another, the EJB module may be delivered preassembled, with all the enterprise bean cross-references resolved within the same unit. This makes the tasks of both the Assembler and the Deployer much easier. Locating an appropriate accounting bean for use by a teller bean across a number of servers may prove tedious despite the best efforts and user interface wizardry of the authors of a J2EE deployment tool. Where one bean delegates to another, many servers will partition deployed EJB modules across different process and even machine boundaries. If a bean makes frequent calls on another bean, there may be performance issues when they are run within separate address spaces.
7.2.2.3 Grouping for Circular References
When two enterprise beans refer to each other, the result is a circular dependency. Neither bean can function without the other and so neither is reusable without the other. In some cases redesign may eliminate these dependencies. When circular references are necessary, you should also package the components together in the same EJB module to ensure reusability.
7.2.2.4 Groupings with Common Security Profiles
While each EJB module allows a number of abstract security roles to be specified, enterprise beans are often written with a discrete set of users in mind. Enterprise beans that have the same security profile should be grouped together to reduce negotiation of security role names across EJB modules.
A Web module is the smallest deployable and usable unit of Web resources. A Web module is packaged and deployed as a Web ARchive (WAR) file, a JAR file with a .war extension. It contains:
The WAR file format does not conform to all the requirements of the JAR format because the classes in a WAR file are not usually loadable by a classloader if the JAR is added to a classpath.
The Web module is the smallest indivisible unit of Web resources functionality that Application Component Providers will supply to the Application Assembler. Therefore, an Application Component Provider needs to choose how to package Web tier components into Web modules. This section contains guidelines for doing so.
7.2.4.1 Cross-Dependent Servlets
Servlets may directly call each other via HTTP. The URL by which a servlet is known on the J2EE platform depends on the J2EE application in which it was deployed. For reasons of robustness, servlets that call one another should be deployed together. It is therefore recommended that you put them in the same Web module.
7.2.4.2 Cross-Linked Static Content
Since a WAR file is typically deployed under its own context root, cross-linked Web pages must be packaged in a single Web module to avoid broken links. Moreover, cross-linked HTML Web pages are typically reusable as a bundle, so it makes sense to package them together.
7.2.4.3 Logical Grouping of Functionality
A Web module that has a clearly defined purpose is easier to reuse in different scenarios than one with less well-defined overall behavior. For example, a well- designed Web module concerned purely with inventory management can be reused in many e-commerce applications that need inventory management capability. Such a module would be ideal for adding a Web-based interface for inventory management to the sample application.
Application client modules are packaged in JAR files with a .jar extension. Application client modules contain:
An application client will use a client JAR file created by the EJB JAR file producer. The client JAR file consists of all the class files that a client program needs to use to access the enterprise beans that are contained in an EJB module.
Figure 7.2 illustrates the various types of J2EE packages and how they can be deployed. Although the figure only shows an independently deployed EJB module, all three types of J2EE modules can be deployed independently.