[CONF] Apache CXF: Distributed OSGi Greeter Demo Walkthrough (page edited)

[confluence]

Page Edited : CXF : Distributed OSGi Greeter Demo Walkthrough Distributed OSGi Greeter Demo Walkthrough has been edited by David Bosschaert (Jan 16, 2009). (View changes) Content: This is a walkthrough of the Distributed OSGi Greeter Demo. It should help users of the Distributed OSGi get started with it. The greeter demo can be found in the samples/greeter directory and implements a simple OSGi Greeter Service and a consumer to that service with a trivial UI. The Greeter demo design The demo is composed of 3 bundles: The Greeter Interface bundle The Greeter Service Implementation bundle The Greeter Service Consumer bundle The Greeter Interface bundle exports the GreeterService interface which both other bundles depend on. This is the interface: public interface GreeterService { Map<GreetingPhrase, String> greetMe(String name) throws GreeterException; } The GreetingPhase and GreeterException classes are also defined by this bundle. In this walkthrough, the following setup will be used: The client side bundles will be running in Equinox, invoking on a Distributed OSGi Service running in Felix. Note that the choice of containers is completely trivial. Any OSGi container that implements the Service Registry Hooks (a new feature in OSGi 4.2) can be used on either side. The Server Side The Greeter Service bundle provides a trivial implementation of the GreeterService interface. Additionally, it has an Activator: public class Activator implements BundleActivator { private ServiceRegistration registration; public void start(BundleContext bc) throws Exception { Dictionary props = new Hashtable(); props.put("osgi.remote.interfaces", "*"); props.put("osgi.remote.configuration.type", "pojo"); props.put("osgi.remote.configuration.pojo.address", "http://localhost:9090/greeter"); registration = bc.registerService(GreeterService.class.getName(), new GreeterServiceImpl(), props); } public void stop(BundleContext bc) throws Exception { registration.unregister(); } } Besides creating the service instance, the activator sets the additional properties on the service that are required to make it available remotely: The osgi.remote.interfaces property is set to '*', which means that all the interfaces passes to registerService are good for remoting. In this case it's just the GreeterService interface. The osgi.remote.configuration.type is set to pojo, which is a CXF specific configuration type that can be used to set the URL at which the service is to be exposed. This is done via the osgi.remote.configuration.pojo.address property. Let's run the server in Felix 1.4.1. As a prerequisite it requires some of the OSGi Compendium Specification interfaces. These don't come with the Felix download but are built as part of the Felix build. When building a distribution, the Felix bundle with these interfaces is pulled in via Maven and put in the target/deps directory. To set up my Felix environment, I'm running the following commands: C:\felix-1.4.1>java -jar bin\felix.jar Welcome to Felix. ================= -> ps START LEVEL 1 ID State Level Name [ 0] [Active ] [ 0] System Bundle (1.4.1) [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) [ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.2.1) -> start file:/<dosgi-root>/distribution/single-bundle/target/deps/org.osgi.compendium-1.2.0.jar -> start file:/<dosgi-root>/distribution/single-bundle/target/cxf-dosgi-ri-singlebundle-distribution-1.0-SNAPSHOT.jar Some log meesages may come up now. Note that instead of manually adding these bundles to the Felix container, you can also append the target/felix.config.properties.append file to the <felix-root>/conf/config.properties file. This will automatically load these two bundles when Felix starts up. Now let's start up the server-side greeter bundles. -> start file:/<dosgi-root>/samples/greeter/interface/target/cxf-dosgi-ri-samples-greeter-interface-1.0-SNAPSHOT.jar -> start file:/<dosgi-root>/samples/greeter/impl/target/cxf-dosgi-ri-samples-greeter-impl-1.0-SNAPSHOT.jar -> ps START LEVEL 1 ID State Level Name [ 0] [Active ] [ 0] System Bundle (1.4.1) [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) [ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.2.1) [ 4] [Active ] [ 1] OSGi R4 Compendium Bundle (4.1.0) [ 5] [Active ] [ 1] Distributed OSGi Distribution Software Single-Bundle Distribution [ 8] [Active ] [ 1] CXF Distributed OSGi Greeter Demo Interface Bundle [ 9] [Active ] [ 1] CXF Distributed OSGi Greeter Demo Service Implementation Bundle Some more log messages come up. When it says INFO: Remote org.apache.cxf.dosgi.samples.greeter.GreeterService endpoint has been published into Discovery service you know that the service is exposed remotely, and you can verify this by requesting the WSDL: The Service Consumer side. The Service Consumer Java code contains no specific Distribution-related elements. It's simply an Activator that creates a ServiceTracker listening for services that implement the GreeterService interface. When the service becomes available it opens a little GUI window that asks you for an argument that can be sent to the Greete service. See here for the actual code Note that in many cases using an OSGi Component Framework such as Spring-DM, iPojo or OSGi DS is highly recommeded when writing OSGi Service Consumers. OSGi Services are highly dynamic in nature. They can come and go. Using a component framework will generally save you from writing ServiceTracker code as the framework will generally provide the service consumer with a reference to the service via injection. 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: <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="osgi.remote.interfaces">*</property> <property name="osgi.remote.configuration.type">pojo</property> <property name="osgi.remote.configuration.pojo.address">http://localhost:9090/greeter</property> </service-description> </service-descriptions> The's run the consumer in Equinox, so that we have a bundle running in Equinox talking to a remoted service running in Felix! As with Felix, we will have to load the bundle with the OSGi compendium interfaces. There's one that ships with Equinox. java -jar plugins/org.eclipse.osgi_3.5.0.v20081201-1815.jar -configuration conf -console osgi> install file:plugins/org.eclipse.osgi.services_3.2.0.v20081205-1800.jar Bundle id is 1 osgi> start 1 osgi> install file:/<dosgi-root>/distribution/single-bundle/target/cxf-dosgi-ri-singlebundle-distribution-1.0-SNAPSHOT.jar Bundle id is 2 osgi> start 2 Some logging messages may appear. You can also automatically load the DOSGi bundles by appending the target/equinox.config.ini.append to you equinox config.ini file. osgi> install file:/O:/samples/greeter/interface/target/cxf-dosgi-ri-samples-greeter-interface-1.0-SNAPSHOT.jar Bundle id is 3 osgi> install file:/O:/samples/greeter/client/target/cxf-dosgi-ri-samples-greeter-client-1.0-SNAPSHOT.jar Bundle id is 4 osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.5.0.v20081201-1815 1 ACTIVE org.eclipse.osgi.services_3.2.0.v20081205-1800 2 ACTIVE cxf-dosgi-ri-singlebundle-distribution_1.0.0.SNAPSHOT 3 INSTALLED cxf-dosgi-ri-samples-greeter-interface_1.0.0.SNAPSHOT 4 INSTALLED cxf-dosgi-ri-samples-greeter-client_1.0.0.SNAPSHOT osgi> start 4 After a few moments the following window appears: This means that the ServiceTracker in the consumer has received a callback that the GreeterService has been found. The value entered will used to invoke the (remote) OSGi service, with a call like this: Map<GreetingPhrase, String> result = greeter.greetMe("foobar"); I can see that the invocation has been received by the service implementation as in the Felix window the following appears. -> Invoking: greetMe(foobar) In the Equinox window I can see the response: osgi> greetMe("foobar") returns: Hola foobar Bonjour foobar Hoi foobar Hello foobar

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences