|
Hi
Guys
What could be best approach in Packaging Components Into EJB
Modules .The SUn's Site gave these approaches.Of these which could be the
best
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:
- 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
packaged 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
Assemblers will be able to reuse precisely those enterprise beans that they
wish to, and no more.
- Package all enterprise beans for an application in one EJB module. In this
approach all enterprise beans and their dependent classes are packaged
together in one EJB module. This approach is the simplest to implement. The
Application 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 enterprise beans.
- 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 enterprise beans related to account management can be put in one
EJB module.
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.
|
