Migration and integration - Enterprise OSGi in Action - page 284

and an EJB bundle is rather unsurprising: an EJB bundle must declare OSG i metadata
in its manifest.
EJB bundles have to define standard OSG i metadata in exactly the same way that
WAB s, persistence bundles, and normal OSG i bundles do. We imagine that you're
comfortable with symbolic names, versions, and package imports by now, so we'll skip
the boring example and suggest that your import package statement is likely to need
to contain an import for javax.ejb at version [3,4) or [3.1,4) depending on which
version of the EJB specification you're using.
The important piece of information that distinguishes a bundle as an EJB bundle is
the Export-EJB header. The presence of this header allows the bundle to be recognized
and loaded by an OSG i-aware EJB runtime. In many ways, this header behaves like Web-
ContextPath does for WAB s, but its value does something rather different. We'll discuss
exactly how the Export-EJB header can be used shortly, but it's useful to know that your
EJB s will be loaded and run, even if the header has no corresponding value.
EJBs in WAR files
Starting with EJB 3.1, it's possible to define EJBs in a web module. This can be ex-
tremely useful if the EJB contains relatively little code, or if it's only used by the WAR
file. With WARs and WABs so similar, the EJB support in Apache Aries also allows
EJBs to be defined in WABs. You don't have to do anything special to make use of
this function—the EJB runtime automatically scans any WABs for EJBs. The WABs
don't even need to specify the Export-EJB header, although if they do, then it will
be processed.
One important thing to note about defining EJBs in WABs is that the ejb-jar.xml de-
scriptor must be placed in WEB-INF, not META-INF. This is the same location used by
the EJB specification when EJBs are defined in WAR files.
INTEGRATING EJBS AND OSGI
At the time of writing, the EJB integration in Apache Aries provides support for ver-
sions up to and including the latest release, EJB 3.1. Combined with the reasonably
simple structure of an EJB JAR , this means that it's usually easy to convert an existing
EJB JAR into an EJB bundle. When running in an OSG i framework, however, accessing
the EJB s might not feel particularly natural. Normally, EJB s are accessed through JNDI ,
and although this is still possible in Aries, it isn't how OSG i bundles normally do
things. Where possible, OSG i bundles use the OSG i Service Registry to integrate, and
this is exactly what you can do with certain types of EJB s.
A number of different types of EJB s exist, but the most commonly used are Session
Beans. Session Beans have a further set of distinct types; of these, the Stateless and Sin-
gleton Session Bean types behave a lot like OSG i services. They're looked up, poten-
tially by multiple clients, used for a period, and possibly cached in the meantime. It
would be ideal if this usage pattern could integrate easily with other OSG i technolo-
gies such as Blueprint, and the Service Registry is an excellent place to do that. As a