Site icon akquinet AG – Blog

Introducing Dynamic Discovery into OSGi distributed applications

This post is the second post of the dynamokos series. It improves the application made in the first post by adding dynamic remote service discovery.

In this post

The former post ends with an issue. The application behave strangely when the oracle is stopped. In this post, we start to fix the issue. To achieve that, I describe how to use a discovery protocol in order to avoid to statically import the service. We will see:


The dynamokos series aims to build a dynamic distributed web application on the top of OSGi.

The first version relies on Apache CXF DOSGi to distribute OSGi services as web services. The first framework hosts an Oracle. The Prediction Service (provided by the Oracle) is published as a web service using CXF.
The second framework imports this service, and a web application uses it.

Current architecture of the dynamokos application

The main issue in this application is the ad-hoc importation. The importer indicates to DOSGi the location of the Prediction service. But nobody checks the availability of the service. So, despite a potential unavailable Prediction Web Service, the web page tries to use it.

Dynamokos Web View


New architecture of the system

This version reuses the same technologies as the one from the first post. It just introduces discovery:

What’s a Discovery Protocol?

A discovery protocol is a way to notify other platforms of the availability of services (remotely accessible). There are a lot of technologies usable as discovery protocol:

Some rely on centralized registries (like in Jini), some just on network events.

The OSGi Distributed Service specification defines how the Distributed Service implementation (in our case DOSGi) deals with Discovery Services without imposing any discovery protocol. That’s pretty nice as we can use a lot of different discovery protocols (depending of the use case).

Apache Hadoop Zookeeper

In Dynamokos, I decided to use (at least for the time being) Apache Hadoop Zookeeper as discovery protocol. The good news is that DOSGi supports it.

Zookeeper is a high-performance coordination service for distributed applications. It exposes common services – such as naming, configuration management, synchronization, and grouping.

Zookeeper will be used as a global registry publishing services exported remotely. But before being able to use it, we need to launch it.

To this end, download the dynamokos-runtime archive from here. Then unzip it and go (with a terminal) into the runtime folder.

From there launch one of the following commands depending if your using Linux/Mac OS or windows:

#Linux : 
sh ./zookeeper/bin/ start
zookeeper\bin\zkServer.cmd start

Note: Zookeeper requires Java 6.

Those commands start a preconfigured Zookeeper server (on port 2181). You should see:

JMX enabled by default
Using config: /Users/clement/workspaces/dynamokos/ 
Starting zookeeper ... 

Publishing the Prediction service in Zookeeper

Let’s now try to publish our Prediction Web Service into Zookeeper. No code required!

The only requirement is to deploy the Zookeeper discovery service and to configure it correctly.

Configuring the Zookeeper discovery service relies on the OSGi Configuration Admin. Don’t panic. The only things to do is to create the org.apache.cxf.dosgi.discovery.zookeeper.cfg file in the oracle-dosgi-zookeeper directory with: =

This org.apache.cxf.dosgi.discovery.zookeeper.cfg file will be read by Apache Felix File Install and pushed to the OSGi Configuration Admin. Then the configuration admin pushed this configuration to the Zookeeper discovery service. Once received, this service is able to contact the Zookeeper server to register the Prediction service.

Let’s check that.

From the runtime folder, now launch the Oracle platform with:

java \ \
        file:./conf/ \
    -jar bin/felix.jar cache/oracle-dosgi-zookeeper \

This launches the Oracle platform with everything configured (Zookeeper is already configured). You should read something like:

INFO: Creating ZooKeeper node: 

Discovering the Prediction Service

It’s time to configure the client platform to discover the remote Prediction service.
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 DOSGi of the locations of available remote services. The DOSGi implementation will in turn register proxies for the remote services in the local service registry. So, this completely avoids the static import.

Let’s try that.

Go back to the runtime folder and execute the following command:

java \ \
    file:./conf/ \
   -jar bin/felix.jar cache/client-dosgi-zookeeper

This launches the client platform with the zookeeper discovery service (configured with the same configuration). Note, that there is no more the oracle importer bundle, as the static configuration is no more required.
You should see something like:

INFO: Notified - AVAILABLE: [....Prediction] 
    endpoint id: eb461f59-5250-4dd7-8e09-b17544ca4e9b

Open your browser to: http://localhost:8080/dynamokos/index.html
You should see:

Dynamokos Web View

Now, you can ask metaphysical questions to the oracle.

Let’s play with the dynamism

Ok, that’s nice but we haven’t even seen the really interesting stuff.

On the oracle platform, stop the oracle:

   ID   State         Level  Name
[   0] [Active] [    0] System Bundle (2.0.0)
[   1] [Active] [    1] Distributed OSGi Distribution ...
[   2] [Active] [    1] Apache Felix Bundle Repository (1.4.1)
[   3] [Active] [    1] Apache Felix Configuration Admin Service (1.0.10)
[   4] [Active] [    1] Apache Felix File Install (1.2.0)
[   5] [Active] [    1] Apache Felix iPOJO (1.4.0)
[   6] [Active] [    1] Apache Felix iPOJO Arch Command (1.4.0)
[   7] [Active] [    1] Apache Felix Shell Service (1.4.0)
[   8] [Active] [    1] Apache Felix Shell TUI (1.4.0)
[   9] [Active] [    1] OSGi R4 Compendium Bundle (4.1.0)
[  10] [Active] [    1] Apache Log4J (1.2.15)
[  11] [Active] [    1] Oracle (0.0.1.SNAPSHOT)
[  12] [Active] [    1] CXF Zookeeper-based ...
[  13] [Active] [    1] Prediction Service Interface (0.0.1.SNAPSHOT)
[  14] [Active] [    1] ZooKeeper wrapper bundle (1.1.0.SNAPSHOT)
-: stop 11

You should see:

INFO: Removing ZooKeeper 
    node: /...Prediction/

Go back to your browser and update the page … 404!

No web page when the oracle is out of his office

What happened is very simple:

  1. The Prediction service is withdrawn from Zookeeper.
  2. Zookeeper notifies the client Zookeeper discovery service of this departure
  3. The discovery service propagates this info to DOSGi
  4. DOSGi deletes the created proxy, and un-registers the Prediction service from the OSGi service registry
  5. The web application is invalidated and the web page is unregistered from the HTTP Server

Now if you restart the oracle:

start 11

And then, refresh the page… our oracle is back!

The Oracle is back

Issues and conclusion

Well, this version fixed the oracle availability issue, but the result is not great (maybe worse) as the user now just gets a 404. What would be uber-cool is if we would be able to handle the dynamism inside the web app itself…

That’s the content of the next post. Stay tuned!

If you have questions, feel free to post a comment on this post or to contact us.

Exit mobile version