Web applications and web services - OSGi in Action - page 495

As you can see, this is a fairly typical BundleActivator . You're basically registering a
service with a set of properties. You may be asking yourself, “Where is the remote com-
munication?” That's the cool thing about the Remote Services specification: it shields
you from those messy details. The specification defines a set of service properties you
can attach to your services to indicate that they should be made available remotely.
The actual remote communication is handled by another bundle or set of bundles;
these types of bundles are classified as distribution provider bundles.
The key service property in listing 15.11 is service.exported.interfaces , which
tells any distribution providers that you intend for your service to be made available
remotely. The value * indicates that all interfaces specified when registering the ser-
vice should be exported remotely. You can also change this to a String array to specify
a specific set of interfaces.
NOTE This opt-in approach is reasonable, because not all services make sense
in a remote context. For example, consider the whiteboard pattern for serv-
lets that we provided earlier, in section 15.1.1. It makes little sense to register
a Java5 servlet interface remotely, because it's entirely an in-memory API .
The rest of the attributes specify either intents or configuration for the distribution
provider, which it uses to decide how to publish the remote service. We'll look at
intents and configuration in more detail a little later; for now, you can probably intui-
tively guess that you're requesting that your service be exposed using a SOAP interface
from the specified URL .
To create a remote service, you need to select a distribution provider. For this
example, we've chosen to use the Apache CXF Distributed OSG i implementation
( http://cxf.apache.org/distributed-osgi.html ), which is a Remote Services distribu-
tion provider built on top of Apache CXF . To run your remote service, go into the
chapter15/webservice/ directory of the topic's companion code. Type ant to build
the example and java -jar launcher.jar bundles/ to run it. You can test your intu-
ition by visiting http://localhost:9090/stockprovider?wsdl in a web browser. You
should see something like the following (truncated):
<wsdl:definitions name="StockProvider"
targetNamespace="http://stockprovider.foo.org/">
<wsdl:types>
<xsd:schema attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://stockprovider.foo.org/">
<xsd:complexType name="string2doubleMap">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="entry">
That's all there is to it! By deploying the StockProvider bundle into an OSG i frame-
work along with a distribution provider, you're able to make it available remotely.
Pretty neat. Before we move on to the client side of the example, let's look a little
more at intents and configuration.