Network Deployment (Distributed operating systems), v8.0 > Applications > Service integration > Service integration configurations
Bus configurations
We can connect buses in different ways depending on our requirements. For example, we can link messaging engine 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, our 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 to WebSphere 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 appservers 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 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.
Messaging security and multiple security domains
Bootstrap members
Interconnected buses
Bus topology that links to WebSphere MQ networks
Foreign buses
Single-server bus
Multiple-server bus without clustering
Multiple-server bus with clustering
Direct and indirect routing between service integration buses
Service integration security
Bus configurations
Common issues with all bus configurations
Interconnected bus configurations
Configurations that include WebSphere MQ