...
The Greeter Service implementation bundle provides a trivial implementation of the GreeterService interface. Additionally, it has an Activator:
Code Block | ||||
---|---|---|---|---|
| ||||
public class Activator implements BundleActivator { private ServiceRegistration registration; public void start(BundleContext bc) throws Exception { Dictionary props = new Hashtable(); props.put("osgiservice.remoteexported.interfaces", "*"); props.put("osgiservice.remoteexported.configuration.typeconfigs", "pojoorg.apache.cxf.ws"); props.put("osgiorg.remoteapache.configurationcxf.pojows.address", "http://localhost:9090/greeter"); registration = bc.registerService(GreeterService.class.getName(), new GreeterServiceImpl(), props); } public void stop(BundleContext bc) throws Exception { registration.unregister(); } } |
...
So the remote service is simply looked up the normal way, via the OSGi Service Registry.
How does it get there? The fact that a lookup on a service is done internally triggers a Service Registry Hook. This will go out to any registered Distributed OSGi Discovery implementations and query them for any matching services.
However, in our setup we haven't yet registered a Discovery implementation. There is an alternative, more static way to provide discovery type information, in case this info is not available via discovery. It can be specified in a OSGI-INF/remote-service/*.xml
file. This the content of the Greeter Service Consumer remote-services.xml file:
Code Block |
---|
<service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0"> <service-description> <provide interface="org.apache.cxf.dosgi.samples.greeter.GreeterService" /> <property name="osgiservice.remoteexported.interfaces">*</property> <property name="osgi.remote.configuration.type">pojo<"service.exported.configs">org.apache.cxf.ws</property> <property name="osgiorg.remoteapache.configurationcxf.pojows.address">http://localhost:9090/greeter</property> </service-description> </service-descriptions> |
...