A software bus for messages between components. Can be synchronous or asynchronous, point-to-point or multicast, transactional. etc. [Transactions are not discussed below -- should they be?]
Please see the following link for the most updated version of the ComponentBus
This is the PLoP'99 version of this pattern.
Old version in canonical form included below.
Also Known As
Software Bus, Coordination Model of Distribution, TupleSpace
A system is constructed from components in which components are created and destroyed at runtime
. These components execute within some environment that contains other components and support services.
How can you reduce a component's dependence on the environment in which it is executed?
- Components need to communicate.
- You want to achieve ContextIndependence between components
- Components need be dynamically added to and removed from the system at runtime.
Have components communicate indirectly through a software "bus". The bus manages the routing of information between components, from components that produce information to those that consume that information. Routing of information is managed dynamically: as components are added to the bus they register their interest in the information they require. When a component places information onto the bus it is delivered to those components that have registered an interest in that information.
- Define AbstractInteractions by which components communicate with the bus. Components must announce data onto the bus, get notifications of new data from the bus and must be able to structure and type data so that they can define higher-level protocols in terms of the bus-level protocol.
- Implement the bus to perform its roles of the AbstractInteractions
- Implement components that plug into the bus by implementing the other roles of the AbstractInteractions and use the bus to implement application-level communication protocols.
- In your system, instantiate the bus and plug components into the bus. This can be done through ThirdPartyBinding, but it can also be done implicitly if the bus is part of the ComponentFramework.
The use of a bus removes the need for explicit bindings between components.
Components can be removed from and plugged into the bus without involving the other components with which they communicate.
The ability to dynamically reconfigure the components communicating through the bus makes it easier to migrate components in a distributed system; e.g. for load balancing.
In using a ComponentBus
you are really building LayeredFrameworks
. Components interacting through the bus are actually interacting via AbstractInteractions
that are defined in terms of the bus protocols. These AbstractInteractions
are not encoded as interfaces or otherwise visible in the implementation language, and so must be carefully specified elsewhere, as documentation, state charts etc.
Components have a direct dependency on the bus interfaces, but not on other component instances with which they communicate.
Because components only communicate through the bus interfaces there is no need for ComponentGlue
to adapt between incompatible interfaces.
Dynamically removing components from the bus may disrupt a stateful inter-component protocol that is implemented in terms of the bus protocol. Because components interact only through the bus, it is not obvious which components are interacting and how removing a component will affect other parts of the system. If application protocols are stateful, it might be better to use ThirdPartyBinding
to make interconnections explicit.
The architecture of the system is not easily visible from the source code or at runtime. A ComponentBus
is like a supporting scripting language: You can understand how the system works, but not how it is being used. To understand use, you need the schematics: In scripting systems, the scripts; In ComponentBus
systems, the component and bus configurations.
The Java Infobus  implements a ComponentBus
within the same address space.
Tuple spaces, such as Linda  and JavaSpaces
, act as a distributed ComponentBus
Messaging middleware, such as iBus , can be used as a distributed ComponentBus
can be used as the basis of a ComponentBus
Having worked on a number of these systems, I feel that they are not really workable unless you have some sort of 2D visualization system in place.
Linear code systems are good for relatively linear code. But these ComponentBus
systems just fly out in all directions.
Reading straight text, you have to draw a diagram on paper, in order to conceptualize the inter-relationships sensibly.
These bus systems feel much more like biology to me, than traditional programming.
I feel that they are much
more powerful, and give you the benefits of reusability that OOP was supposed
to give us.
But our UserInterface
tools are just not there yet.
See also: PluggableArchitecture
What are the distinctions?
tends to imply more specific interfaces. You might have 4 avenues of communication- say, 4 function calls, and each function call may have very specific type information for each parameter in it. Commonly, but by no mean always always, pluggable architectures do not have much communication between plugins. Rather, communication is between the system and the plugin. It is also common for the plugin to be the "recipient" of information from the system, and then return some information back to the system. The central system comes "first," and the plugin is "second."
es, on the other hand, tend to have wide open gates, where you both send and receive any sort of information. The underlying system very rarely has any concept of just what's in the information. The architecture is far more decentralized, and may even have no "center," beyond the bus system itself, which just dumbly passes messages between components, and provides a life tick to each component.
is, I believe, the exact same thing as the ComponentBus
. Just a different name. I mean, read them. It's the same thing.
I don't know enough about the InformationBus
to talk about those. We don't have much data here.
The DataBusPattern is, I believe, the exact same thing as the ComponentBus.
I would say that's not true, but rather that ComponentBus
is an application of the DataBusPattern
. The relevant distinction here is that ComponentsAreNotObjects?
, the components are entirely separate applications, and are generally not objects (though the bus adapters for the components might be objects), and messages are generally in a generic format such as plain text. The DataBusPattern
would encompass that just fine, but it could just as well encompass the system I wrote in Access last week that allows VBA class instances to subscribe and publish messages with Variant content that hold VB primitives, an arrays, or object references. In that case, there is only a single application, and the data is in a language-specific format. That system clearly implements the DataBusPattern
, but is not a ComponentBus
A Data bus is distinct from a ComponentBus in that A ComponentBus must manage the lifecycle of the component. A DataBus? is much dumber than that. Usually. But we are talking definitions so I am only one voice. For all I know people conflate the two things. Also, a component usually is an object, but an object is usually not a component. The distinguishing attribute is that components are relatively independent. Same caveats apply.
Note also the Service Bus, which probably is the same as a component bus. -- RichardHenderson
The defining features are:
Content neutral (as in EnvelopeLetter
Routes messages from source to destination.
Examples: TIBCO, MQ-Series, Oracle Queues, Sybase Messaging, JMS, JavaSpaces
. No doubt all the other vendors have their own version.
Some of these are MessageQueuingArchitectures, and some ComponentBuses. They are different, I think. -- DavidSarahHopwood
See also MessagePassing YouCanSolveAnyProblemWithAnotherLevelOfIndirection
CategoryPattern CategoryComponents ComponentDesignPatterns MessagingPatterns ComponentBusExamples