Although you might be installing only one broker initially, you should consider how it will be used in your organization in a few years' time. Planning ahead makes developing your WebSphere Business Integration Message Broker configuration easier.
If you are using Publish/Subscribe with security, you also need a User Name Server. The User Name Server can be on z/OS or on another platform. The queue managers need to be interconnected so that information from the User Name Server can be distributed to the brokers on other queue managers.
A broker requires access to a queue manager and to DB2. A User Name Server requires access to a queue manager only. A broker cannot share its queue manager with another broker, but a broker can share a queue manager with a User Name Server.
You cannot use WebSphere MQ shared queues to hold data related to WebSphere Business Integration Message Broker as SYSTEM.BROKER queues, but you can use shared queues for your message flow queues.
You can find details of the DB2 database user tables and the WebSphere MQ queues created and used by WebSphere Business Integration Message Broker on z/OS in the topic mqsicreatebroker command
You need to decide on your recovery strategy. As part of your systems architecture, you should have a strategy for restarting systems if they end abnormally. Common solutions are to use automation products like NetView or the Automatic Restart Manager (ARM) facility. You can configure WebSphere Business Integration Message Broker to use ARM.
You must also plan for corequisite products, including UNIX System Services, Resource Recovery Services, DB2, WebSphere MQ, and Java.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ae22100_ |