Packaging Components Into EJB Modules

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:

1. Package each enterprise bean for an application in its own EJB module. In this approach, each enterprise bean has its own deployment descriptor and is pack- aged in one EJB module along with its dependent classes. One advantage of this approach is the maximum reusability of each enterprise bean, by leaving the Application Assembler free to pick and choose among these EJB modules to compose additional J2EE applications. This option is recommended if your enterprise beans are each highly reusable. In such a case, the Application As- semblers will be able to reuse precisely those enterprise beans that they wish to, and no more.

2. Package all enterprise beans for an application in one EJB module. In this ap- proach all enterprise beans and their dependent classes are packaged together in one EJB module. This approach is the simplest to implement. The Applica- tion Assembler does not have to specify references to the enterprise beans present in this EJB module as unresolved. This makes the job of Application Assemblers easier in the case when they wish to use all the enterprise beans. Application Assemblers who only wish to use a subset of the enterprise beans in the EJB module will still be able to do so, but may end up with a bloated application. The Deployer in this case may have to deploy superfluous enter- prise beans.

3. Package all related (closely-coupled) enterprise beans for an application in one EJB module. In this approach, all off-the-shelf components are used as is (that is, in their own EJB modules). All in-house enterprise beans are grouped based on their functional nature and put in one EJB module. For example, all enter- prise beans related to account management can be put in one EJB module.

PACKAGING J2EE APPLICATIONS 171

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 com- ponents 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 singleAccountenterprise 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 dis- cussions 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 enter- prise 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 enter- prise 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 spe- cialized 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 dele- gate 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 deliv- ered 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 wiz- ardry 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 ref- erences 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 nego- tiation of security role names across EJB modules.