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

Web browser JVM2

Stock-watcher bundle

HTTP

Stock-watcher
servlet

Blah, blah, bl ah,
blah, blah, blah,
blah, blah

StockProvider

SOAP

JVM1 StockProvider

StockProviderImpl

Figure 15.6 The Google
stock-watcher application
running in an OSGi context

Stock-provider bundle

to import remote services (provided over any protocol, such as SOAP , RMI , or JMS )
into the OSG i service registry and symmetrically export services from the OSG i service
registry so they can be accessed by other processes external to the JVM .
To see how this works in practice, let's look at the stock-watcher application you
built in the last section. It has a three-tier architecture, consisting of a web browser
connected to a back-end servlet engine that talks to an in-process StockProvider ser-
vice. A logical step in this section of the topic is to split the StockProvider service into
a separate JVM process and communicate with it using an over-the-wire protocol, such
as SOAP . The new architecture is shown in figure 15.6. Let's look into how you can
realize this design using the Remote Services specification.

15.2.1 Providing a web service

The first step in making a distributed OSG i application is to create the remote imple-
mentation of the StockProvider service. To do this, create the BundleActivator
shown in the following listing.

Listing 15.11 Reading stock prices from the StockProvider service

public class Activator implements BundleActivator {

public void start(BundleContext ctx) throws Exception {
Dictionary props = new Hashtable();

props.put("service.exported.interfaces", "*");
props.put("service.exported.intents", "SOAP");
props.put("service.exported.configs", "org.apache.cxf.ws");
props.put("org.apache.cxf.ws.address",
"http://localhost:9090/stockprovider");

ctx.registerService(StockProvider.class.getName(),
new StockProviderImpl(), props);
}

public void stop(BundleContext ctx) throws Exception {
}
}