Bus configurations
We can connect buses in different ways depending on the requirements. For example, we can link messaging engines to distribute message workload, and to provide availability if there is a system failure.
A configuration that only has a single messaging engine might be adequate for some applications however, deploying more than one messaging engine and linking them together provides the following advantages:
- Messaging workload is distributed across multiple servers.
- Message processing is positioned close to the application that is using it, and reduces network traffic. For example, if both sending and receiving applications are running in the same server process, it is inefficient to route all the messages that flow between the two applications through a messaging engine running in a remote server.
- Availability is improved in the event of system or link failure. For example, the bus topology can remove a single point of failure, and allow store and forward between two servers.
- Options for scalability improve.
- Firewalls, or other network restrictions that limit the ability of network hosts to connect to a single messaging engine, can be accommodated.
- A bus configuration can contain links toWebSphere MQ networks. This allows messages to flow between applications connected to a WebSphere MQ queue manager and applications attached to a service integration bus.
The application servers or clusters that host a messaging engine in the service integration bus are called bus members. A WebSphere MQ server is the WebSphere MQ equivalent of a messaging engine. We can make a WebSphere MQ server a member of a bus, which becomes a messaging engine which is not hosted by an application server.
A bus configuration can include one or more bootstrap members. When an application needs a connection to the bus, it connects to the bootstrap member, which authenticates the request, and then directs the connection request to a suitable bus member. A bootstrap member responds only to bootstrap requests and does not always host a messaging engine.
If a bus configuration uses multiple security domains, we can isolate buses and the applications that use them by configuring the bootstrap members so that only a subset of servers or clusters can access a bus.
Subtopics
- Single-server bus
The simplest configuration is a bus consisting of a single server. Use this configuration if there is a low volume of message throughput and scalability is not essential.
- Multiple-server bus without clustering
A bus that consists of multiple servers provides advantages of scalability, the ability to handle more client connections, and greater message throughput. A multiple-server bus includes multiple messaging engines that can share the work of storing and distributing the messages.
- Multiple-server bus with clustering
We can have a bus consisting of multiple servers, some or all of which are members of a cluster. When a server is a member of a cluster, it allows servers to run common applications on different machines. Installing an application on a cluster that has multiple servers on different machines provides high availability. If one machine fails, the other servers in the cluster do not fail.
- Common issues with all bus configurations
There are planning issues and design decisions that apply to all types of service integration bus configuration.
- Configurations that include WebSphere MQ
There are additional points to consider when planning a bus configuration that includes WebSphere MQ.
- Application server cluster with single ME bus
This configuration features a single messaging engine hosted in one application server of a cluster.
- Multiple application server cluster with single messaging engine bus
This configuration features multiple application server clusters with only a single messaging engine bus member. This allows further scaling of applications where necessary, but keeps a simple messaging configuration.
- Multiple bus member bus
Multiple bus members should be considered for the bus configuration where messaging traffic is high and can be suitably divided, for example, per application or queue.
- Interconnected bus configurations
There are specific issues that you must take into account when we are planning an interconnected service integration bus configuration.
- Interconnected buses
A service integration bus topology can contain many interconnected service integration buses to form a large messaging network. The bus that an application connects to is called its local bus. There can be connections from that local bus to other service integration buses, which are called foreign buses. Buses can also be linked to WebSphere MQ resources, for example WebSphere MQ queue managers. WebSphere MQ resources are also regarded as foreign buses.
Related concepts
Messaging security and multiple security domains Bootstrap members Single-server bus Interconnected buses Multiple-server bus without clustering Multiple-server bus with clustering Foreign buses Service integration security Direct and indirect routing between service integration buses Bus topology that links to WebSphere MQ networks