Java Reference
In-Depth Information
Although including EJBs directly inside a WAR module is a great convenience started
with the Java EE 6 spec, it's not the only way to include EJBs inside a WAR module. It's
very typical (particularly in high-use and high-availability applications) to need much more
business rules processing power than web front-end display power. Therefore, the archi-
tecture of the application is divided into a small cluster of web front-end servers running
the WAR module and a much larger cluster of back-end servers running the EJB modules.
With two separate clusters, the WAR modules on the front end talk to the EJB modules on
the back end remotely through
@Remote
EJBs.
If your application is architected like this, the Maven configuration of the maven-ejb-plugin
can include the
<generateClient>true</generateClient>
option. With this
option, Maven will package up all interfaces for the EJBs into its own JAR file. Your WAR
modules can then include this dependency, which has only the interfaces instead of the en-
tire EJB-JAR.
These are two options for building a WAR module. Now we'll look at whether deployment
descriptors are even needed.
13.3.3. XML versus annotations
An EJB deployment descriptor (ejb-jar.xml) describes the contents of an EJB module, any
resources used by it, and security transaction settings. The deployment descriptor is written
in XML, and because it's external to the Java byte code, it allows you to separate concerns
for development and deployment.
The deployment descriptor is optional and you could use annotations instead, but we don't
advise using annotations in all cases for several reasons. Annotations are great for devel-
opment but may not be well suited for deployments where settings may change frequently.
During deployment it's common in large companies for different people to be involved for
each environment (development, test, production, and so on). For instance, your applica-
tion requires such resources as DataSource or JMS objects, and the JNDI names for these
resources change between these environments. It doesn't make sense to hardcode these
names in the code using annotations. The deployment descriptor allows the deployers to
understand the contents and take appropriate action. Keep in mind that even if the deploy-
ment descriptor is optional, certain settings, such as default interceptors for an EJB-JAR
