Component Bus

Please see the following link for the most updated version of the ComponentBus pattern:

http://jerry.cs.uiuc.edu/~plop/plop99/proceedings/Eskelin1/ComponentInteractionPatterns.pdf

This is the PLoP'99 version of this pattern.

Also Known As

Software Bus, Coordination Model of Distribution, TupleSpace

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

1. Components need to communicate.
2. You want to achieve ContextIndependence between components
3. 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.

1. 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.
2. Implement the bus to perform its roles of the AbstractInteractions
3. 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.
4. 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.

Known Uses

The Java Infobus [1] implements a ComponentBus for JavaBeans within the same address space.

Tuple spaces, such as Linda [2] and JavaSpaces, act as a distributed ComponentBus.

Messaging middleware, such as iBus [3], can be used as a distributed ComponentBus.

Example

Related Patterns

A MultiCaster 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.

-- LionKimbro

See also: PluggableArchitecture, DataBusPattern, InformationBus.

What are the distinctions?

PluggableArchitecture 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."

ComponentBuses, 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 DataBusPattern 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.

-- LionKimbro

In ComponentBus, 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 idiom). 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. -- DavidHopwood

See also MessagePassing YouCanSolveAnyProblemWithAnotherLevelOfIndirection

This page mirrored in ComponentDesignPatterns as of April 29, 2006