Data Bus Pattern

DataBusPattern is a way of organizing communication among objects which don't know about existence of each other. Instead of calling other objects' methods directly, objects communicate by sending events to the bus which other bus members receive. An object must register with a bus to become its member and start to receive events sent to that bus. Defining types and structure of events is up to the application developer.

Adding new functionality to the system built that way can be extremely simple - sometimes as simple as registering another member with a data bus which starts to receive bus events and do its job based on that information. Adding more members to the bus which add functionality to the existing system also doesn't break anything, as unknown events are ignored by the bus members which receive them. That way, it's possible to add new functionality step-by-step to the application.

Possibly another name for ComponentBus.

Similar concepts

DataBusPattern is most similar to the MediatorPattern. The main difference is that there's no single object which manages communication. Data bus members decide themselves if they're interested in data being published on the bus and if so, what to do with it. This approach makes task responsibility more focused - there is only one class which is involved in performing a given task.

DataBusPattern is similar to TupleSpace, BlackboardMetaphor or AssociativeMemory. The main difference from them is that DataBusPattern is a simpler, lower-level pattern dealing with data transport. One can easily add bus members to provide additional functionality, including functionality of these other patterns. One can think about DataBusPattern as a refinement of a basic concept underlying these similar concepts.

Another pattern in this family is ObserverPattern (or its cousin, EventListenerPattern?) from which DataBusPattern has evolved. Users of DataBusPattern want many-to-many communication, whereas ObserverPattern is a one-to-many relationship, but if you consider the bus itself as the observable object, then this can be viewed as a one-to-many relationship. In fact, a need for DataBusPattern can arise from more and more difficulty in managing the growing net of inter-object relationships in a system built using ObserverPattern.

DataBusPattern is related to, but not exactly the same as PublishSubscribeModel. DataBusPattern decouples the sender and receiver by adding an intermediary (the DataBus). In PublishSubscribeModel, the sender and receiver must be aware of each other.

Are we saying that the PublishSubscribeModel describes the relationship between clients of the database and the data bus itself? That the difference is that in a data bus, the relationships are PeerToPeer? What do you think of JiniTechnology?

Implementation notes

Like a hardware data bus, there are several relevant issues with the DataBusPattern:

A JavaLanguage example is available at the HUF project. Go to http://huf.sourceforge.net and look at package huf.unibus.

Arguments against DataBusPattern


EditHint: Merge with ComponentBus

EditText of this page (last edited October 8, 2007) or FindPage with title or text search