Mixture of cluster and server bus members
The cell has some appserver clusters and other non-clustered servers. Both non-clustered servers and server clusters have been added as bus members.
The benefits of this topology are:
- Cluster bus members can be configured with partitioned destinations to support workload-managed, message-consuming applications, such as message-driven beans.
- Cluster bus members can be used to make system-critical destinations highly available.
- To overcome the workload management restrictions of clients connecting to a cluster, clients outside the cell can connect to server bus members. Clients can then put messages to destinations with partitioned queue points. Messages are workload-managed between the partitions.
- To overcome the workload management restrictions of clients connecting to a cluster (JMS clients connecting into a cluster of messaging engines), clients outside the cell can connect to server bus members outside of the cluster. Clients can then put messages to partitioned destinations and the messages will be workload-managed across the partitions.
- Clients bootstrapping to servers (with a SIB service) outside the cluster can get workload management of their connections to the messaging engines within the cluster bus member.
The drawback is that these more complex messaging topologies take a little more planning and configuration than simpler topologies.
Multiple buses in a cell
It is possible to have many buses within a cell. This topology can be desirable under in the following situations:
- Separation of concerns
Applications that do not need to share messages can be isolated from each other by using their own bus.
- Test configuration
A test configuration with identical destination names can be created on a separate bus that is not used by the production system. Changing the name of the bus in the connection factories can then redirect the test application to the production bus without changing any other configuration.