Hooking up remote systems with distributed OSGi - Enterprise OSGi in Action - page 263

Figure 10.22 A new special offer!

as many machines as you want. As a final proof that the remote service is behaving
properly, try making a bulk order for some more of your foreign food. This will cause
your stock to drop, and if you buy enough, should cause your foreign foods depart-
ment to select a new special offer (see figure 10.22).
We hope that you're now convinced that your remote service is not only live, but
operating on the same data as the consuming framework. One thing you haven't done
is propagate distributed transactions. This isn't always a problem—for example, your
special offer service is read-only, and it isn't a disaster if you advertise an offer that's
been changed by another user's large order. Sometimes, however, it's vitally important
that both ends of the remote call run under the same logical transaction, and this isn't
an area where CXF is strong. Although Apache CXF is probably the simplest way to
take advantage of OSG i remote services, it's not the only one.

10.6 Using SCA for remoting

The Apache Tuscany project provides an alternative remote services implementation
based on the Service Component Architecture ( SCA ). SCA is designed to enable com-
ponent-oriented programming, in which discrete components are wired together
through well-defined endpoints. These components may be co-located on the same
system or—more usefully for remote services—distributed across a network.

10.6.1 Apache Tuscany

The Apache Tuscany project is an open source implementation of the SCA specifica-
tion based on a Java-language runtime. As well as the core SCA runtime, Tuscany
includes a number of SCA component implementation types. Importantly for OSG i,
the Tuscany project hosts the reference implementation of the OSG i SCA component
type, known as <implementation.osgi/> .
Because service component architecture is all about services, and OSG i services are
one of the great features of the OSG i programming model, you may be guessing that
these two technologies are a good fit. Unsurprisingly, SCA 's OSG i component type
makes use of the OSG i Service Registry to provide and consume SCA services. An OSG i
SCA descriptor (following the typical SCA syntax) can be used to select particular OSG i
services from the Service Registry using service properties to identify particular imple-
mentations. These services are then exposed as endpoints through the SCA runtime.