最初はブローカーを 1 つインストールするだけかもしれませんが、数年後にブローカーが組織でどのように使用されるかを考慮してください。 先を見越して計画しておくと、WebSphere Event Broker 構成の開発が容易になります。
z/OS 上に構成マネージャーを作成してブローカー・ドメインを管理することを考慮してください。WebSphere Event Broker の以前のバージョンからマイグレーションする場合、以前に Windows にあった構成マネージャーのマイグレーションを考慮してください。
セキュリティーでパブリッシュ/サブスクライブを使用している場合、ユーザー・ネーム・サーバーも必要です。 ユーザー・ネーム・サーバーは、z/OS または別のプラットフォームに配置することができます。 キュー・マネージャーは、ユーザー・ネーム・サーバーからの情報が他のキュー・マネージャー上のブローカーに配布されるように、相互接続されていなければなりません。
ブローカーには、キュー・マネージャーおよび DB2 へのアクセスが必要です。 構成マネージャーとユーザー・ネーム・サーバーに必要なのは、キュー・マネージャーへのアクセスのみです。 ブローカーは、別のブローカーとキュー・マネージャーを共用することはできませんが、構成マネージャーおよびユーザー・ネーム・サーバーとキュー・マネージャーを共用することはできます。
WebSphere MQ 共用キューを使って WebSphere Event Broker に関連したデータを SYSTEM.BROKER キューとして保持することはできませんが、共用キューをメッセージ・フロー・キューで使用することはできます。
DB2 データベース・ユーザー表および z/OS で WebSphere Event Broker が作成し、使用する WebSphere MQ キューの詳細は、トピックmqsicreatebroker コマンドにあります。
使用する計画のブローカー、ユーザー・ネーム・サーバー、および構成マネージャーの開始済みタスク手順を作成する必要があります。 これらの手順は、該当するユーザー ID を使用して、開始済みタスク表に定義する必要があります。
リカバリー戦略を決定する必要があります。 システム体系の一部として、システムが異常終了した場合に備えてそれを再始動する戦略が必要です。 一般的な解決方法は、NetView のような自動化製品または Automatic Restart Manager (ARM) 機能を使用することです。 WebSphere Event Broker を ARM を使用するように構成することができます。
また、UNIX システム・サービス、リソース・リカバリー・サービス、DB2、WebSphere MQ、および Java を含む、相互に必要な製品の計画も必要です。