Designing a broker domain

When you plan a new WebSphere Event Broker domain, you must first have considered your resource naming conventions, the design of the WebSphere MQ infrastructure, and any performance issues. The following topics describe these considerations:

When you are designing a broker domain consider the following elements.

  1. Brokers: The number of brokers that you need in your domain depends on the following factors:
    1. Performance: What is the required message throughput? (Refer to Optimizing message flow throughput). What is the size of the messages that are being processed? Larger messages take longer to process. A small number of brokers handling many messages might impact the broker domain's performance. Refer to Considering performance in the domain.
    2. Do you need to isolate applications from each other? You might want to separate applications that serve different functions, for example personnel and finance.
    3. Do the brokers need to handle publish/subscribe? Refer to Developing publish/subscribe applications.
  2. User Name Server: Consider the following if you have a User Name Server in your broker domain:
    1. Performance: If you have a large number of brokers in your broker domain, the requests that they send the User Name Server can be handled more quickly if there is more than one User Name Server. More than one User Name Server might also be beneficial (in terms of network traffic) if your broker domain is complex.
    2. Resilience: Although no standby mechanism is provided by WebSphere Event Broker, you might want to be able to redirect requests to a second User Name Server if a system error occurs on the system of your first User Name Server.
  3. Configuration Manager: This acts as an interface between the configuration repository and the set of brokers in the domain and the workbench. It uses WebSphere MQ messages to communicate with the brokers, and thus a large number of brokers in a broker domain (if poorly designed) can cause congestion at the Configuration Manager. To solve this, consider dividing the brokers into more than one domain where related brokers are kept together. You can then establish connections with each domain (refer to Creating a domain connection).
Related concepts
Brokers
Broker domains
Configuration Manager
User Name Server
Related tasks
Developing publish/subscribe applications
Configuring a broker domain in the workbench
Configuring broker domain components