Migration and integration - Enterprise OSGi in Action - page 285

result, the Apache Aries runtime can be configured to register OSG i services for any
Singleton or Stateless Session Beans inside an EJB Bundle.
SELECTING EJBS TO EXPOSE IN THE SERVICE REGISTRY
Getting the Aries EJB runtime to expose your EJB s as OSG i services is remarkably easy,
and it relates to the value of the Export-EJB header. The value of this header defines
a comma-separated list of EJB names. This list is a simple whitelist that's used to select
the EJB s that should be exposed as OSG i services. As we mentioned earlier, this header
can only cause Singleton and Stateless Session EJB s to be registered, but because these
are the most commonly used types of Session EJB s (and you shouldn't be trying to call
a Message Driven Bean directly), this covers the majority of EJB applications.
You might wonder why the Export-EJB header works differently from some of the
other Java EE integration headers that you've seen, and also why it's a whitelist rather
than a blacklist. This is an interesting discussion, and bears a little thought. In many
ways, EJB s are similar to Blueprint beans or other managed objects. They can be wired
together using dependency injection, and they can be exposed externally. We hope that
we've convinced you by now that one of the most important aspects of a well-architected
OSG i bundle is that it hides as much as possible. This is equally true of managed objects
inside the bundles. You wouldn't normally expose every bean in a Blueprint file as a ser-
vice; some are used internally by the other beans. Exactly the same is true of EJB s. You
should be making a decision to expose the beans, not hoping that nobody starts calling
them. This is why, by default, no EJB services get exported. To help in those times that
you do want to export everything, or when you want to be extra explicit that nothing
should be registered, there are two special values that you can associate with the
Export-EJB header. These are ALL and NONE , and their behavior is self-explanatory.
When an EJB has been exposed as a service, the Aries EJB container will register
one OSG i service per client view of the EJB . This can be a local interface, a remote
interface, or the no-interface view of the EJB . The services will be registered with some
special properties: ejb.name gives the name of the EJB , and ejb.type gives the type of
the EJB (either Singleton or Stateless). These services can then be used like any other
OSG i service; they can be easily consumed using Blueprint, or the OSG i API , or in any
other way that you fancy.
Remote EJBs and remote services
The EJB programming model includes comprehensive support for incoming requests
from remote clients. This is supported through the use of remote EJB interfaces.
Back in section 10.2, we showed that OSGi services can support remote call seman-
tics as well. Given that remote EJB interfaces are designed to be remotely accessible,
it's only natural that they should be easy to expose as remote OSGi services. The
Aries EJB container works to help you out here. All EJB services that correspond to
remote interfaces have the service.exported.interfaces property set automati-
cally by the Aries EJB container. This means that remote EJB services automatically
integrate with a Remote Services Distribution Provider.