Event Service

I blogged a while back about the potential use of a bus for delivering property change notifications in place of the very common observer pattern. A reader commented that the exact service I need to implement that sort of thing is already available in the form of the OSGi Event Service. An implementation of this service is provided by the Equinox project.

I’ve updated part of the Eclipse Expense Expense Reporting Tool example to make use of the service.

I updated my business domain objects to post events detailing their changes through the EventAdmin service. This was made relatively easy owing to the fact that I had already implemented those objects with a common superclass. I added the postEvent(…) method to that common superclass:

	void postEvent(String propertyName, Object oldValue, Object newValue) {
		EventAdmin eventAdmin = getEventAdmin();
		if (eventAdmin == null) return;

		Properties properties = new Properties();
		properties.put(SOURCE, this);
		properties.put(SOURCE_TYPE, this.getClass().getName());
		properties.put(PROPERTY_NAME, propertyName);
		if (oldValue != null) properties.put(OLD_VALUE, oldValue);
		if (newValue != null) properties.put(NEW_VALUE, newValue);

		eventAdmin.postEvent(new Event(PROPERTY_CHANGE_TOPIC, properties));
	}

It’s pretty straightforward. The first thing it tries to do is obtain the service. The getEventAdmin() method uses the bundle activator (and a ServiceTracker) to find a service that implements EventAdmin. If no such service can be found, we bail out and pretend that nothing happened. If we do find an EventAdmin, we create and post an Event instance. The postEvent method posts the event to be delivered asynchronously; the sendEvent method delivers the event to waiting handlers before returning.

The Event instance is packed with properties. The nature of these properties are application-specific. In this case, I’m including properties that tell me what has changed and in what object. The event also has a "topic". The topic is used to determine how the event is delivered; only event handlers that are listening for this particular topic will be informed of the event (there’s a little more to it than this). It’s very much like the Java Messaging Service (JMS).

This is only part of the story. Publishing events through the event service is only interesting if there are subscribers on the other side. I’ll talk about what I’ve done on that side sometime next week…

This entry was posted in Eclipse 101, Equinox, Examples. Bookmark the permalink.

4 Responses to Event Service

  1. Scott Lewis says:

    Hi Wayne. Not sure whether you knew this, but the ECF Datashare API

    http://wiki.eclipse.org/ECF_API_Docs#Datashare_API

    provides an abstraction called a IChannel, that is for asynchronous cross-process (as opposed to the Event service’s within-process-only) message delivery model.

    The use of String topics is problematic in the event service’s case, because topics as Strings are only unique within a single process. Using ECF IDs rather than String topics allows

    1) multiple or alternative protocols/implementations to be used (e.g. one of them is JMS, another is JGroups…i.e. via multicast, etc. see http://ecf1.osuosl.org).

    2) either pt-to-pt or group/pub-sub based event delivery (the default model of is of a topic/group and pt-to-pt is a degraded case…i.e. group of 2🙂.

    In fact, I believe that the asynchronous Event service can/could even be used to implement the ECF datashare API…of course with the limitation of being within-process only.

  2. Chris Aniszczyk says:

    Cool, I have an EventAdmin article coming out on dW in about 2 months🙂

  3. Wayne Beaton says:

    So… we could implement an EventHandler that posts on an IChannel, or even an implementation of EventAdmin that implements IChannel directly?

    I’ll need to take a closer look at the Datashare API.

  4. Scott Lewis says:

    >So… we could implement an EventHandler that posts on an IChannel, or even an >implementation of EventAdmin that implements IChannel directly?

    Sure…either/both will be useful. The first one for sending events (that can be serialized, of course) to other processes via existing datashare api providers (jms, jgroups, xmpp, skype, ecf generic, others). The second one for a local IChannel based upon the Event Service (useful for testing and other things).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s