Migration and integration - Enterprise OSGi in Action - page 283

there's almost always only one place in the code where they get created. This means that
it's often easy to replace a call to the Persistence bootstrap class with a service lookup.
Ideally, the code will already use a dependency injection model, or it can easily be
changed to do so. You saw back in listing 3.5 how you could use a Blueprint namespace
to easily inject JPA resources (in that case, it was a managed EntityManager ). When
using dependency injection, JPA resource access is a simple matter of configuring the
dependency injection container to use the appropriate mechanism for the current plat-
form. When accessing JPA in this way, client code can continue to work in OSG i and Java
SE unchanged.

JAVA EE JPA CLIENTS
Java EE has a different model for JPA usage than Java SE , and luckily it's one that fits a
little better with OSG i. Java EE modules are either injected with JPA resources or they
look them up in JNDI . As a result, some OSG i-aware containers are able to transpar-
ently request these objects from the Service Registry. This support isn't available from
all containers, and if it isn't, it's a trivial exercise to use the osgi:service JNDI scheme
to locate the resource instead. (We discussed osgi:service lookups in sections 2.4
and 3.2.1).
Now that you've seen how WAR and JPA modules can be migrated, it's time to look
at another common Java EE module type, the EJB JAR .

11.2.3 EJBs in OSGi

WAR s and JPA persistence archives both have related OSG i standards. As a result, our
advice so far has been portable across multiple environments. Unfortunately, there's
no such specification support for EJB s in OSG i. The EJB project in Apache Aries is
one of the newest, and at the time of writing Apache Aries EJB is still preparing for its
first release.
Despite the comparative lack of support for EJB s in OSG i, there are still multiple
supporting platforms. Oracle's GlassFish Server supports EJB JAR s that use OSG i meta-
data and classloading. Apache Aries approaches this from the other direction ( OSG i
bundles that contain EJB s), but there has been a significant effort to meet in the mid-
dle. As a result both Apache Aries and GlassFish use the same metadata to describe
EJB s within an OSG i bundle, meaning that although EJB bundles aren't strictly stan-
dard, they're reasonably easy to use across multiple platforms.

EJB BUNDLE PACKAGING AND METADATA
An EJB JAR has a simple structure. It has a normal JAR classpath, and it contains EJB
classes. These classes can be identified using annotations, XML , or a mixture of both.
If XML is used, then the XML file is called ejb-jar.xml and it lives in the META-INF
directory of the JAR . Just like WAB s do with WAR s, EJB bundles follow exactly the same
structure as EJB JAR s (although as bundles they can choose to have a nonstandard
internal classpath). The advantages of this approach are clear: it makes it easier to
author an EJB bundle with existing tooling and skills, and it allows a module to be a
valid EJB JAR and EJB bundle at the same time. The key difference between an EJB JAR