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 Component Bus pattern:
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, Tuple Space
Context
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.
Problem
How can you reduce a component's dependence on the environment in which it is executed?
Forces
Components need to communicate.
You want to achieve Context Independence between components
Components need be dynamically added to and removed from the system at runtime.
Solution
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 Abstract Interactions 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 Abstract Interactions
Implement components that plug into the bus by implementing the other roles of the Abstract Interactions 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 Third Party Binding, but it can also be done implicitly if the bus is part of the Component Framework.
Resulting Context
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 Component Bus you are really building Layered Frameworks. Components interacting through the bus are actually interacting via Abstract Interactions that are defined in terms of the bus protocols. These Abstract Interactions 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 Component Glue 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 Third Party Binding to make interconnections explicit.
The architecture of the system is not easily visible from the source code or at runtime. A Component Bus 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 Component Bus systems, the component and bus configurations.
Known Uses
The Java Infobus [1] implements a Component Bus for Java Beans within the same address space.
Tuple spaces, such as Linda [2] and Java Spaces, act as a distributed Component Bus.
Messaging middleware, such as iBus [3], can be used as a distributed Component Bus.
Example
Related Patterns
A Multi Caster can be used as the basis of a Component Bus.
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 Component Bus 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 User Interface tools are just not there yet.
-- Lion Kimbro
See also: Pluggable Architecture, Data Bus Pattern, Information Bus.
What are the distinctions?
Pluggable Architecture 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."
Component Buses, 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.
The Data Bus Pattern is, I believe, the exact same thing as the Component Bus. Just a different name. I mean, read them. It's the same thing.
I don't know enough about the Information Bus to talk about those. We don't have much data here.
-- Lion Kimbro
The Data Bus Pattern is, I believe, the exact same thing as the Component Bus. I would say that's not true, but rather that Component Bus is an application of the Data Bus Pattern. The relevant distinction here is that Components Are Not Objects.
In Component Bus, 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 Data Bus Pattern 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 Data Bus Pattern, but is not a Component Bus.
A Data bus is distinct from a Component Bus in that A Component Bus must manage the lifecycle of the component. A Data Bus 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. -- Richard Henderson
The defining features are:
Content neutral (as in Envelope Letter idiom). Routes messages from source to destination.
Examples: TIBCO, MQ-Series, Oracle Queues, Sybase Messaging, JMS, Java Spaces. No doubt all the other vendors have their own version.
Some of these are Message Queuing Architectures, and some Component Buses. They are different, I think. -- David Sarah Hopwood
Category Pattern Category Components Component Design Patterns Messaging Patterns Component Bus Examples
See original on c2.com 