OSGi declares an EventAdmin service that is responsible for distributing events to listeners registered via the (org.osgi.service.event.EventHandler). It's possible to create distributed implementations of such services using JMS and/or other messaging frameworks for distributing messages to other OSGi frameworks.

+

{{:EIG:Introduction to Distributed EventAdmin}}

−

+

−

[[Image:Distributedeventadmin.png]]

+

−

+

−

ECF's provider architecture allows the creation of a distributed EventAdmin implementation that can use a variety of wire protocols. For example, ActiveMQ/JMS 5.2 as above, or ECF generic, XMPP, JavaGroups, commercial/proprietary messaging buses, or any others that can implement the ECF Shared Object API.

+

−

+

−

==Using the Distributed EventAdmin Service==

+

−

+

−

First, get ECF 3.0. [http://www.eclipse.org/ecf/downloads.php Here is the download page].

+

−

+

−

Then get the two projects that implement the event admin. [[Media:Example.eventadmin.psf | Here is a project set file]] for them.

Introduction to Distributed EventAdmin

OSGi declares an EventAdmin service that is responsible for distributing events to listeners registered via the (org.osgi.service.event.EventHandler). It's possible to create distributed implementations of such services using JMS and/or other messaging frameworks for distributing messages to other OSGi frameworks.

ECF's provider architecture allows the creation of a distributed EventAdmin implementation that can use a variety of wire protocols. For example, ActiveMQ/JMS 5.2 as above, or ECF generic, XMPP, JavaGroups, commercial/proprietary messaging buses, or any others that can implement the ECF Shared Object API.

Getting the Distributed EventAdmin Service

First, install ECF. Instructions on how to do that are on the Download page.

This indicates that the EventAdmin service is being accessed to send test messages every 2 seconds. Here's the code (in org.eclipse.ecf.examples.internal.eventadmin.app.TestSender class) that is making the EventAdmin.postEvent call:

What this does is create an Event instance with values for a couple of properties (i.e. "message", and "sender"), and then call eventAdmin.postEvent(Event) to have the eventAdmin implementation deliver the message to EventHandlers.

The test event handler implementation is this (in org.eclipse.ecf.examples.internal.eventadmin.app.TestEventHandler class):

The TestEventHandler class is registered as an instance of EventHandler upon application startup (in org.eclipse.ecf.examples.internal.eventadmin.app.EventAdminManagerApplication)

Dictionary dictionary =newHashtable();
dictionary.put(EventConstants.EVENT_TOPIC,"*");// Needed, otherwise you don't see any events at all
testEventHandlerRegistration = bundleContext.registerService(
EventHandler.class.getName(), new TestEventHandler(), dictionary);

If a EventAdmin Generic Server.product and 1 or more EventAdmin Generic Client.products are started then both the clients and the server will act as both message senders and EventHandlers (receivers), and the output will appear something like this

You can see that the 'sender' is different for the server (i.e. ecftcp://localhost:3787/server) than for the client(s) (i.e. 9POAn/uwLgZyU5krxfjDhhhAuMU=). This indicates that both the server and the client are sending messages, and receiving them (delivered to the EventHandler's that have been registered).

See the following two classes for info on how the test server and client are structured