commits@cxf.apache.org Archives

DOSGi Discovery Demo page

Page edited by David Bosschaert

Update to new properties

This page describes the demo that shows the Discovery functionality of Distributed OSGi.

It assumes that you have set up your DOSGi/ZooKeeper based Discovery system as outlined in the DOSGi Discovery page.

Demo design

This demo consists of a display controller node that writes messages on all the available display instances. Display instances are realized as remote OSGi services, which are registered with the ZooKeeper-based Discovery system. The discovery system informs the controller, which is a consumer of the DisplayServices, of any available remote instances of this service.
@@@ add an image here @@@

As with most of the other demos, the actual implementation consists of 3 bundles.

A DisplayService interface bundle.
A DisplayService implementation bundle.
A DisplayService client bundle, which takes the role of the display controller.

The Display Service interface is as follows:

public interface DisplayService {
    boolean displayText(String
text);
    String getID();
}

The Display Controller (service consumer)

Let's start with the controller, which is a consumer to the the DisplayService. It's simply using an OSGi ServiceTracker to consume all DisplayService services. It also uses a Scheduled Executor to periodically send test messages to all registered displays. Here's the Activator:

public class Activator
implements BundleActivator {
    private ServiceTracker tracker;
    private Map<DisplayService, String> displays = new
ConcurrentHashMap<DisplayService, String>();

    public void start(BundleContext bc) throws Exception {
        tracker = new ServiceTracker(bc, DisplayService.class.getName(),
null) {
            public Object
addingService(ServiceReference reference) {
                Object svc = super.addingService(reference);
                if (svc instanceof
DisplayService) {
                    DisplayService d = (DisplayService) svc;
                    System.out.println("Adding display: " + d.getID() + "
(" + d + ")");
                    displays.put(d, d.getID());
                }
                return svc;
            }

            public void removedService(ServiceReference
reference, Object service) {
                String value = displays.remove(service);
                System.out.println("Removed
display: " + value);
                super.removedService(reference,
service);
            }            
        };        
        tracker.open();
        // ... scheduler stuff that sends messages to all
registered displays ommitted
    }

    public void stop(BundleContext bc) throws Exception {
        tracker.close();
    }
}

No `remote-services.xml` file!

As we are using Discovery here, there is no static remote service metadata required. So no remote-services.xml file. Discovery will dynamically inform the DOSGi implementation of the locations of available remote services. The DOSGi implemenation will in turn register proxies for the remote services in the local service registry. As a service consumer you simply depend on the service - e.g. by using a ServiceTracker as above, or through a component framework such as Blueprint or DS.

Running the controller

-> install http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-discovery-client/1.1/cxf-dosgi-ri-samples-discovery-client-1.1.jar
-> install http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-discovery-interface/1.1/cxf-dosgi-ri-samples-discovery-interface-1.1.jar
-> start 7
-> start 8
-> ps
START LEVEL 1
   ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.8.0)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.2.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.2.0)
[   3] [Active     ] [    1] Apache Felix Bundle Repository (1.4.0)
[   4] [Resolved   ] [    1] OSGi R4 Compendium Bundle (4.1.0)
[   5] [Active     ] [    1] Distributed OSGi Distribution Software Single-Bundle Distribution
[   6] [Active     ] [    1] Distributed OSGi Zookeeper-Based Discovery Single-Bundle Distribution
[   7] [Active     ] [    1] Distributed OSGI Discovery Sample Client Bundle
[   8] [Active     ] [    1] Distributed OSGI Discovery Sample Interface Bundle

After a brief moment, you will see messages appearing on the controller side. These are the messages sent to all registered displays. Since there are none, they won't show up anywhere just yet.

Sending text to displays: some text 1
Sending text to displays: some text 2
Sending text to displays: some text 3
...

The Remote Displays (service implementation)

Every Display in the system registers a Display Service implementation in the local Service Registry. This happens in the Activator of the service implementation bundle. It adds the properties to make the service available remotely as well:

public class Activator
implements BundleActivator {
    private ServiceRegistration reg;

    public void start(BundleContext bc) throws Exception {        
        Dictionary props = new Hashtable();
        
        String host = getHostName(); // obtain the current host name
        int port = getPort();  
     // find a free port
        
        props.put("service.exported.interfaces",
"*");
        props.put("service.exported.configs",
"org.apache.cxf.ws");
        props.put("org.apache.cxf.ws.address",
"http://" + host
+ ":" + port + "/display");

        reg = bc.registerService(DisplayService.class.getName(), 
                new DisplayServiceImpl(host
+ ":" + port), props);
    }

    public void stop(BundleContext bc) throws Exception {
        reg.unregister();
    }
}

Note that the port where the service is made available is dynamically set to be any free port in the system. So you can safely run any number of remote Display Services on the same machine. Because we're using Discovery here, a well-known port is not needed. Registering the service as in the previous code snippet will make it available remotely and publish it to the installed Discovery system.

Once the provider side bundles are started:

-> install http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-discovery-interface/1.1/cxf-dosgi-ri-samples-discovery-interface-1.1.jar
-> start 7
-> install http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-discovery-impl/1.1/cxf-dosgi-ri-samples-discovery-impl-1.1.jar
-> start 8
-> ps
START LEVEL 1
   ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.8.0)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.2.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.2.0)
[   3] [Active     ] [    1] Apache Felix Bundle Repository (1.4.0)
[   4] [Resolved   ] [    1] OSGi R4 Compendium Bundle (4.1.0)
[   5] [Active     ] [    1] Distributed OSGi Distribution Software Single-Bundle Distribution
(1.1.0.SNAPSHOT)
[   6] [Active     ] [    1] Distributed OSGi Zookeeper-Based Discovery Single-Bundle Distribution
(1.1.0.SNAPSHOT)
[   7] [Active     ] [    1] Distributed OSGI Discovery Sample Interface Bundle
[   8] [Active     ] [    1] Distributed OSGI Discovery Sample Implementation Bundle

You will start seeing the messages appear on the remote display:

DisplayService [myhost:1816]: some text 145
DisplayService [myhost:1816]: some text 146
...

You can add more Display Services and they will also receive the messages.

Under the hood in the ZooKeeper server

The Discovery system uses standard OSGi mechanisms to publish the metadata of the services that are exposed remotely in a centralized server, a ZooKeeper server. On the consumer side, the services are looked up in Discovery through standard OSGi mechanisms as well. These mechanisms are independent of ZooKeeper, so they will work with any Distributed OSGi standards-compliant Dicovery implementation.

ZooKeeper comes with a client program (zkCli) that allows you to look in the ZooKeeper virtual filesystem. All of the OSGi-registered services are stored in a virtual directory under the node /osgi/service_registry. The virtual directory name is based on the fully qualified name of the interface that is implemented by the remote service. So in the case of the DisplayService the remote service metadata is stored under /osgi/service_registry/org/apache/cxf/dosgi/samples/discovery/DisplayService:

$ bin/zkCli localhost:2181

-> ls /osgi/service_registry/org/apache/cxf/dosgi/samples/discovery/DisplayService
Processing ls
[myhost#1816##display]

Every instance of a remote service that implements the org.apache.cxf.dosgi.samples.discovery.DisplayService interface will get a virtual file in this location. The virtual file is only there for the lifetime of the service. If you stop the service, or kill the OSGi container that hosts it, its associated file in this directory will disappear.
You can obtain the information stored in the node, to get an idea of the metadata that's being communicated using the Discovery system:

-> get /osgi/service_registry/org/apache/cxf/dosgi/samples/discovery/DisplayService/myhost#1816##display
Processing get
#
#Tue Jun 09 14:52:39 BST 2009
osgi.remote.endpoint.location=http\://myhost\:1816/display
osgi.remote.interfaces=*
osgi.remote.configuration.pojo.address=http\://myhost\:1816/display
osgi.remote.configuration.type=pojo
osgi.remote.endpoint.id=0ffe1fbf-c029-4096-bc14-3c7d77470dfd

cZxid = 511
ctime = Tue Jun 09 14:52:39 BST 2009
mZxid = 511
mtime = Tue Jun 09 14:52:39 BST 2009
pZxid = 511
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 81563124471365634
dataLength = 338
numChildren = 0

Other Resources

Introducing Dynamic Discovery into OSGi Distributed Applications - http://blog.akquinet.de/2009/09/23/introducing-dynamic-discovery-into-osgi-distributed-applications/

Change Notification Preferences

View Online | View Change | Add Comment

Configuration property	Default	Description
zookeeper.host	no default	The host where the ZooKeeper server is running.
zookeeper.port	2181	The port of the ZooKeeper server.
zookeeper.timeout	3000	Sets the ZooKeeper tick time.

Description	File	MD5
Multi-bundle distribution (tar.gz)	cxf-dosgi-ri-multibundle-distribution-1.1.tar.gz	cxf-dosgi-ri-multibundle-distribution-1.1.tar.gz.md5
Multi-bundle distribution (zip)	cxf-dosgi-ri-multibundle-distribution-1.1.zip	cxf-dosgi-ri-multibundle-distribution-1.1.zip.md5
Single-bundle distribution	cxf-dosgi-ri-singlebundle-distribution-1.1.jar	cxf-dosgi-ri-singlebundle-distribution-1.1.jar.md5
Source distribution	cxf-dosgi-ri-source-distribution-1.1.tar.gz	cxf-dosgi-ri-source-distribution-1.1.tar.gz.md5

Description	File	MD5
Multi-bundle distribution (tar.gz)	cxf-dosgi-ri-multibundle-distribution-1.0.tar.gz	cxf-dosgi-ri-multibundle-distribution-1.0.tar.gz.md5
Multi-bundle distribution (zip)	cxf-dosgi-ri-multibundle-distribution-1.0.zip	cxf-dosgi-ri-multibundle-distribution-1.0.zip.md5
Single-bundle distribution	cxf-dosgi-ri-singlebundle-distribution-1.0.jar	cxf-dosgi-ri-singlebundle-distribution-1.0.jar.md5
Source distribution	cxf-dosgi-ri-source-distribution-1.0.tar.gz	cxf-dosgi-ri-source-distribution-1.0.tar.gz.md5

ws-security.username	The username used for UsernameToken policy assertions
ws-security.password	The password used for UsernameToken policy assertions. If not specified, the callback handler will be called.
ws-security.callback-handler	The WSS4J security CallbackHandler that will be used to retrieve passwords for keystores and UsernameTokens.
ws-security.signature.properties	The properties file/object that contains the WSS4J properties for configuring the signature keystore and crypto objects
ws-security.encryption.properties	The properties file/object that contains the WSS4J properties for configuring the encryption keystore and crypto objects
ws-security.signature.username	The username or alias for the key in the signature keystore that will be used. If not specified, it uses the the default alias set in the properties file. If that's also not set, and the keystore only contains a single key, that key will be used.
ws-security.encryption.username	The username or alias for the key in the encryption keystore that will be used. If not specified, it uses the the default alias set in the properties file. If that's also not set, and the keystore only contains a single key, that key will be used.
ws-security.signature.crypto	Instead of specifying the signature properties, this can point to the full WSS4J Crypto object. This can allow easier "programmatic" configuration of the Crypto information."
ws-security.encryption.crypto	Instead of specifying the encryption properties, this can point to the full WSS4J Crypto object. This can allow easier "programmatic" configuration of the Crypto information."

commits@cxf.apache.org Archives

svn commit: r887673 - in /cxf/branches/2.2.x-fixes: ./ systests/uncategorized/src/test/java/org/apache/cxf/systest/clustering/FailoverAddressOverrideTest.java

svn commit: r887669 - /cxf/trunk/systests/uncategorized/src/test/java/org/apache/cxf/systest/clustering/FailoverAddressOverrideTest.java

svn commit: r887389 - /cxf/branches/2.2.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/addr_wsdl/jaxwsmm/WSDLAddrPolicyAttachmentJaxwsMMProviderTest.java

svn commit: r887356 - in /cxf/branches/2.2.x-fixes: ./ rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/interceptors/ systests/ws-specs/ systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/addr_wsdl/jaxwsmm/ systests/ws-specs/src/test/resourc...

svn commit: r887353 - in /cxf/trunk: rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/interceptors/ systests/ws-specs/ systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/addr_wsdl/jaxwsmm/ systests/ws-specs/src/test/resources/wsdl_systest_ws...

svn commit: r887329 - in /cxf/branches/2.2.x-fixes: ./ distribution/src/main/release/samples/ws_security/ut_policy/ distribution/src/main/release/samples/ws_security/ut_policy/bin/ distribution/src/main/release/samples/ws_security/ut_policy/certs/ dist...

svn commit: r887328 [2/2] - in /cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy: ./ bin/ certs/ certs/demoCA/ certs/demoCA/newcerts/ src/ src/demo/ src/demo/wssec/ src/demo/wssec/client/ src/demo/wssec/resources/ src/demo/wssec/se...

svn commit: r887328 [1/2] - in /cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy: ./ bin/ certs/ certs/demoCA/ certs/demoCA/newcerts/ src/ src/demo/ src/demo/wssec/ src/demo/wssec/client/ src/demo/wssec/resources/ src/demo/wssec/se...

svn commit: r887317 - in /cxf/trunk: rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/atom/ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ rt/frontend/jaxrs/src/main/java/...

svn commit: r887310 - /cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/wadl/WadlGenerator.java

svn commit: r887271 - in /cxf/trunk: parent/pom.xml testutils/src/main/java/org/apache/cxf/testutil/common/ServerLauncher.java

[CONF] Apache CXF > DOSGi Discovery Demo page

Page edited by David Bosschaert

Demo design

The Display Controller (service consumer)

No remote-services.xml file!

Running the controller

The Remote Displays (service implementation)

Under the hood in the ZooKeeper server

Other Resources

[CONF] Apache CXF > DOSGi Discovery Demo page

Page edited by David Bosschaert

Demo design

The Display Controller (service consumer)

No remote-services.xml file!

Running the controller

The Remote Displays (service implementation)

Under the hood in the ZooKeeper server

Other Resources

[CONF] Apache CXF > DOSGi Discovery

Page edited by David Bosschaert

Introduction

Installing and run the ZooKeeper server

Installing the CXF Discovery Bundles

Single Bundle Distribution

Multi Bundle Distribution

Configuring Discovery

[CONF] Apache CXF > DOSGi DS Demo page

Page edited by David Bosschaert

Demo design

The Adder Service Implementation

The Adder Service Consumer

[CONF] Apache CXF > DOSGi DS Demo page

File attached by David Bosschaert

[CONF] Apache CXF > DOSGi Multi Bundle Setup

Page edited by David Bosschaert

Setting up the Multi Bundle Distribution of CXF Distributed OSGi

Setting up Felix

Setting up Equinox

[CONF] Apache CXF > DOSGi Spring-DM Demo page

Page edited by David Bosschaert

Demo design

The Dinner Service Provider

The Dinner Service Consumer

svn commit: r886968 [1/2] - in /cxf/branches/2.2.x-fixes: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/...

svn commit: r886968 [2/2] - in /cxf/branches/2.2.x-fixes: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/...

svn commit: r886957 [5/5] - in /cxf/trunk: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/src/main/java/c...

svn commit: r886957 [3/5] - in /cxf/trunk: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/src/main/java/c...

svn commit: r886957 [2/5] - in /cxf/trunk: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/src/main/java/c...

svn commit: r886957 [4/5] - in /cxf/trunk: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/src/main/java/c...

svn commit: r886957 [1/5] - in /cxf/trunk: api/src/test/java/org/apache/cxf/databinding/ distribution/src/main/release/samples/wsdl_first/src/main/java/com/example/customerservice/client/ distribution/src/main/release/samples/wsdl_first/src/main/java/c...

svn commit: r886953 - in /cxf/branches/2.2.x-fixes: ./ rt/core/src/main/java/org/apache/cxf/wsdl11/WSDLManagerImpl.java

svn commit: r886949 - in /cxf/branches/2.2.x-fixes: ./ rt/javascript/src/main/java/org/apache/cxf/javascript/ rt/javascript/src/main/java/org/apache/cxf/javascript/types/ rt/javascript/src/test/java/org/apache/cxf/javascript/fortest/ rt/javascript/src/...

svn commit: r886948 - in /cxf/branches/2.2.x-fixes: ./ api/src/main/java/org/apache/cxf/clustering/ rt/core/src/main/java/org/apache/cxf/clustering/ systests/uncategorized/src/test/java/org/apache/cxf/systest/clustering/

svn commit: r886947 - in /cxf/branches/2.2.x-fixes: ./ systests/wsdl_maven/codegen/ systests/wsdl_maven/codegen/src/ systests/wsdl_maven/codegen/src/main/ systests/wsdl_maven/codegen/src/main/resources/ systests/wsdl_maven/java2ws/src/main/java/org/apa...

svn commit: r886944 - in /cxf/branches/2.2.x-fixes: ./ maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/ maven-plugins/codegen-plugin/src/test/java/ maven-plugins/codegen-plugin/src/test/java/org/ maven-plugins/codegen-plugin/src/...

svn commit: r886943 - in /cxf/branches/2.2.x-fixes: ./ rt/javascript/src/main/resources/org/apache/cxf/javascript/cxf-utils.js

svn commit: r886941 - in /cxf/branches/2.2.x-fixes: ./ maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WsdlOption.java

svn commit: r886939 - in /cxf/branches/2.2.x-fixes: ./ maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/

svn commit: r886934 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/wsdl11/WSDLManagerImpl.java

[CONF] Apache CXF Documentation > Apache Camel Transport

Page edited by Daniel Kulp

[CONF] Apache CXF Documentation > Apache Camel Transport

Page edited by Daniel Kulp

[CONF] Apache CXF Documentation > Client HTTP Transport (including SSL support)

Comment removed by Daniel Kulp

[CONF] Apache CXF > DOSGi Releases

Page edited by Eoghan Glynn

Releases

No `remote-services.xml` file!

No `remote-services.xml` file!