THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
As we are using Discovery here, there is 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. So 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.
Run the client side (controller)
| Code Block |
|---|
-> install @@@
-> start 7
-> install @@@
-> 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 else yet.
| Code Block |
|---|
Sending text to displays: some text 1
Sending text to displays: some text 2
Sending text to displays: some text 3
... |
The remote Displays
Every Display in the system registers a Display Service implementation in the local Service Registry. This happens in the Activator of the provider side of the demo. It adds the properties to make the service available remotely as well:
...
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 important. 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:
| Code Block |
|---|
-> install @@@
-> start 7
-> install @@@
-> 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:
| Code Block |
|---|
DisplayService [127.0.0.1:1816]: some text 145
DisplayService [127.0.0.1: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 store the metadata of the services that are exposed remotely in a centralized server, a ZooKeeper server. On the service 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:
| Code Block |
|---|
> bin\zkCli.cmd localhost:2181
-> ls /osgi/service_registry/org/apache/cxf/dosgi/samples/discovery/DisplayService
Processing ls
[127.0.0.1#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:
| Code Block |
|---|
get /osgi/service_registry/org/apache/cxf/dosgi/samples/discovery/DisplayService/127.0.0.1#1816##display
Processing get
#
#Tue Jun 09 14:52:39 BST 2009
osgi.remote.endpoint.location=http\://127.0.0.1\:1816/display
osgi.remote.interfaces=*
osgi.remote.configuration.pojo.address=http\://127.0.0.1\: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
|