Bus or Broker?
You may not be aware of it, but when you’ve built your integration solution, you’ve made a choice between a broker model and a bus model. Or you mixed the two.
This article looks at both models and identifies the repercussions of this choice.
Why do I even care: the one-sentence intro to EAI
The key feature of modern integration approaches (EAI, SOI) is the reduction of integration complexity by replacing the point-to-point ad-hoc integration (Figure 1) with systematic integration through an integration platform (ever heard the integrate once, recompose many times mantra? It does not work all that well, but the idea is on Figure 2).
Figure 1 Ad-hoc integration. Mess. If you integrate <3 applications, go for it.
Two common models of implementing systematic integration approach are bus model and broker model.
Figure 2 Systematic integration. Better. Look here to see why.
Bus
In bus model (Figure 3) the transport (MQ, JMS, or other MOM) is the ‘integration universe’. Any cross-system interaction involves the messaging bus. The applications are connected to the bus by adapters. Cross-system transformation and coordination of tasks is enacted by one or more integration brokers.
Figure 3: Bus Model
Broker
In broker model (Figure 4) the broker is the ‘integration universe’. Every cross-system interaction involves broker but there is no requirement for a common transport. Conceivably, you can even implement robust integration solution without message-oriented middleware.
Figure 4: Broker Model
Do I have a choice?
First, you may have very little choice. To a large extent, the choice is imposed upon you by your integration tool vendor. Therefore, consider the model you looking for at the vendor selection time.
Most of the early EAI solutions were transport add-ons, effectively leading to a bus model. Examples include the archaic TIBCO’s Message Broker or the still-alive IBM’s MQSI. However, with the recent popularity of the Enterprise Service Bus (ESB), from vendors such as Sonic, the bus architectures are all but fogotten.
The more recent offerings of EAI vendors tend to implement the broker model. Examples include TIBCO’s Business Works, IBM’s Crossworlds / ICS, or Microsoft’s BizTalk.
Characteristics and consequences
Let’s dicuss the key consequences of the bus-broker choice:
- Interoperability Vendor lock-in
Using broker, you are more likely to develop a strong dependency on the broker vendor.
The bus forces you to think about messages, and if messaging is done right and is standard-based, it is broker-agnostic. You can easily mix multiple broker in a single architecture. You can easily add transport adapters from multiple vendors and have them interoperate.
The broker model is not that flexible. Adapters need to be broker-specific. Exchanged data format are likely to be broker-specific as well.
- Asynchrony and temporal coupling
I feel strongly about the asynchronous messaging as a foundation for integration. The bus model implies asynchrony. The broker model may lead you to the dark side of RPC. Fortunately, some integration brokers are inherently asynchronous.
- Performance
Transport-based solution requires few extra hops for each interactions. Theoretically then, it should be slower. In practice, the brokers tend to be the bottleneck and not messaging. So, no clear winner here.
- Up front design cost
The bus model is likely to cost you significantly more up-front design. Bus model requires some structure for message addressing and routing. Broker can rely on addressing/routing implied by orchestrations.
- Testing
Bus is easier to test. You can send stimuli to any component using a single transport. It is easy to intercept intermediate messages from a single transport to monitor / evaluate test progress. You can use generic or open-source/free JMS/MQ/TIBCO testing tools for doing so.
- Operations & Management
- Complexity
The Broker model is easier to monitor. It is a single component from a single vendor.
Components of bus are inherently distributed. You need a monitoring / operations support tool that can handle a distributed environment, such as TIBCO’s Hawk or BMC Patrol.
The broker solution is simpler. It includes less components. The bus solution not only includes more components, and not only are the components distributed, but it also requires more design work (messaging approach /envelope/, addressing, routing, etc).
What do I chose?
The broker model is a good solution for small-to-midsize integration problems. It is simpler, cheaper, requires little up-front design. Use it to solve small enterprise or single-or-few-departments integration problems. When you do so, make sure that you keep your solution asynchronous in nature.
As your solution grows, it is likely to evolve into bus model. You are likely to find connectivity requirements that require adapters from ISVs. Or get another broker because of extra transformation requirements (or just because it came bundled with a J2EE app server and developers think its cool). The larger the solution, the less likely that a single broker will suffice; plus there is value in having a portfolio of brokers, if not for having some leverage over vendors, then to protect yourself from consequences of some product going off the market. Such portfolio should interoperate using a standard-based messages and a common bus.
Therefore, rely on a bus for large scale integration solutions.