E4: Don’t make a fuss, just get on the bus

I sat in on the “Modeling the Workbench” breakout session at the E4 Summit.

Before I go too far, it’s worth pointing out that there is a lot of activity going on here and I’m only able to capture some small part of it. The information that I’m capturing is my perception of what’s happening and may not accurately reflect reality

There is a consensus that a consistent underlying object model is required for the workbench. Currently, at least in the Eclipse platform itself, there is a relatively good ethic of having a user interface model (a là model-view-controller pattern); the problem is that there is little consistency. Each component has a different, custom-rolled model. The notion of a DOM has been discussed heavily. The basic idea is similar to that of a browser: to change what the user sees, you change the DOM. Changes in the DOM are reflected in the user interface. This opens the door to the use of CSS to control of the workbench presentation. Of course, EMF is a great candidate for modeling the workbench. It was discussed, however, that other technologies (including databases) might be considered (or at least left open as options).

One of the more interesting things discussed (and the source of the title of this post; I’ll leave it as an exercise for the reader to find the popular culture reference) is the use of a bus in place of the bajillions of listeners currently used. It’s like a light-weight in-memory version of an Enterprise Service Bus (ESB); though I could see it being a cross-process thing. Rather than setting up many individual relationships between JavaBeans and user interface components, the selection service, part listeners, etc., a small number (possibly one) of buses can funnel changes into a single point. Today, for example, a view will register listeners on the (potentially) thousands of objects displayed in table. Imagine instead, registering a single listener on a bus that will notify you when any attribute in one of those thousands of objects changes. Rather than implementing my domain model as JavaBeans with bound properties, I instead just drop and event on the bus and let it tell everybody who cares. It makes sense. It reduces the amount of work that results from a change (especially if you have a decent filtering mechanism). It simplifies the development model which should lower the barrier for entry to everybody. To boot, by including an ESB, we have greater buzz-word compliance. I wish I’d thought of it.

Remember that these are all just ideas. You need to get involved in this conversation. The E4 page provides some useful links for getting involved including the mailing list, and the IRC channel. Of course, the E4 page is on the Eclipsepedia Wiki, so you can add your input there as well. If you want to check in on the E4 summit, you can connect to the web cam.

This entry was posted in Uncategorized. Bookmark the permalink.

8 Responses to E4: Don’t make a fuss, just get on the bus

  1. Scott Lewis says:

    Hi Wayne,

    One point about ESBs…asynchronous delivery is frequently needed for scalability as well as inter-process interactions.

    Also need to be concerned about failure/reliability (in interprocess case) and ordering requirements (especially in many-to-many cases).

    So I guess my point is that probably several/many buses will be needed, with different guarantees WRT sync/async, reliability, ordering, etc.

  2. Steven Huwig says:

    To me this looks like NeXTSTEP’s/Cocoa’s notification system, which is pretty pervasive in the architecture. Is there something more to it that I’ve missed?

  3. Tom Schindl says:

    Hi,
    I think the idea of using a bus (or different busses) which guarantee different things is the way to go. Could you clarify a bit what databases have to do with modeling? They are a way to persist things so where’s the relation to models?

  4. Wayne Beaton says:

    Scott: The cool thing about using a bus is that you should be able to play with the implementation. You could, for example, start with a really simple one that doesn’t even queue (just immediately dispatches an event). So long as you preserve API, you can easily swap that implementation out for one that’s asynchronous.

    Tom: Honestly, I don’t quite get what databases have to do with modeling the workbench either. It seems to me that EMF with persistence to a DB might be what’s meant. I’ll try to corner to person who mentioned it and find out more.

  5. Philipp Kursawe says:

    I think something like this already exists in Eclipse. Its called OSGi Event Admin. We are using it for JMS and other things.

    Its great to update multiple views without them knowing about sources of changes. They just register in a topic. For instance a table view registers for changes in the model list it is displaying: “my.model/*”
    It could also register only to specific CRU(D) actions: “my.model/DELETE” to be informed about deletion of a model. If you open an editor on a specific object this editor registers for events for this model too: “my.model/*” but with an LDAP filter applied “..&(object.id=12345)” so it will be only informed about changes in the object with this id. All this functionality is encapsulated into base ViewPart* and EditorPart* classes or injected into existing parts using embedded components. Using this approach its easy to have a status bar that constantly shows the amount of objects in the system, or an editor that closes itself when the model its editing has been deleted in the system.

    The Workbench SelectionService could make use of Event Admin by just propagating an “ISelection/UPDATE” event with the classname as a filter property and every OSGi EventHandler would be (asynchronously) informed about that. No more registering in the selection service, which makes cleaner interfaces and independent modules.

  6. jconlon@verticon.com says:

    I agree with Philipp, we already have a bus – the OSGi EventAdmin service. Not only is it the perfect (at hand) solution for intra JVM messaging within Eclipse it can easily be adapted to work with inter-network capable messaging services (aka Enterprise Service Buses) as well.

  7. Philipp Kursawe says:

    Using OSGi we also would have the freedom to exchange the implementation of the EventAdmin service if we are not happy with the current Equinox single-threaded asynchronous approach.

  8. Pingback: Eclipse hints, tips, and random musings » Blog Archive » Event Service

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