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 Data''''''Bus). 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:

* Events sent to the bus must have clearly defined structure so that other members can understand them. The exact format of such events is up to the developer, but simple messages are probably the best solution, as they help to keep the communication contract simple and concise. 
* DataBusPattern makes debugging a lot easier, because monitoring data bus traffic usually provides enough information to pin down problems almost immediately.
* To make DataBusPattern work well, the system must be partitioned into appropriately-sized modules that communicate using a bus. Make modules too small and bus traffic will impose too much overhead. Make them too large and we lose the flexibility that the bus can give.
* There is no acknowledgement of "one-way" transfers, or flow control. Providing reception acknowledgements is left up to the bus clients. The bus itself is not concerned with it.
* DataBusPattern allows for an arbitrary number of responses, from an arbitrary number of listeners (including zero).
* "Bus snooping" is allowed, and encouraged.
* There can be multiple bus masters - each bus has a name and members can obtain the bus master from the super-master.

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

'''Arguments against DataBusPattern'''

* DataBusPattern makes component interaction ad-hoc. This can be viewed as a big step backward from statically checked interfaces. DataBusPattern still has interfaces just like other communication patterns, but here they are never written down explicitly in a form the computer can validate.
* A Data''''''Bus is usually global. This can lead to some of the structuring problems described in GlobalVariablesAreBad and SingletonGlobalProblems (specifically "Non-locality" and "No Access Control or Constraint Checking", although not so much the other problems).

----
EditHint: Merge with ComponentBus