Migration and integration - Enterprise OSGi in Action - page 273

OSGi framework

C++

OSGi service

Exposed
SCA
endpoint

Bundle

OSGi service

EJB

Figure 11.3 SCA bindings are exposed to OSGi applications as services, which means non-SCA-aware
OSGi applications can communicate with non-SCA-aware applications of other types by consuming normal
OSGi services.

of SCA . For example, anything that can drive a web service can communicate with an
SCA component that exposes a web services binding. They also allow an SCA compo-
nent—such as an OSG i service—to communicate transparently with external services
with no awareness either of OSG i or of SCA (see figure 11.3).

INTEGRATING WITH AN EJB
SCA allows OSG i services to interact with EJB s. Although EJB s might seem like a compo-
nent type, they're a binding. One way of thinking of this is that EJB s have a language
(or communication protocol) and the SCA EJB binding provides a translation layer
that allows things that aren't EJB s to communicate with EJB s.
Hooking an OSG i service up to an EJB is therefore as simple as replacing the web
services binding in the food-config.xml configuration file (listing 10.8) with an equiv-
alent EJB binding, as shown in the following code:

<sca:binding.ejb
name="ForeignFood"
uri="corbaname:iiop@localhost:4201#ForeignFoodFacadeBeanRemote" />
Assuming you have an EJB with the right name listening on the configured port, it will
be accessible as an OSG i service inside the OSG i framework.

INTEGRATING WITH JMS
Accessing an external JMS queue is similarly transparent. The binding for a JMS queue
called (for example) FoodQueue is as follows:

<sca:binding.jms
uri="jms:FoodQueue" />