처음에 브로커를 하나만 설치하는 경우에도 몇 년 후 브로커가 조직에서 어떻게 사용될 지 고려해야 합니다. 미리 계획하면 WebSphere Message Broker 구성 개발이 더 용이합니다.
브로커 도메인을 관리하려면 z/OS에서 구성 관리자 작성을 고려해야 합니다. 초기 버전의 WebSphere Message Broker에서 이주하는 경우 Windows에서 사전에 구성 관리자 이주를 고려해야 합니다.
보안이 적용된 Publish/Subscribe를 사용하는 경우 사용자 이름 서버도 필요합니다. 사용자 이름 서버는 z/OS 또는 다른 플랫폼에 있을 수 있습니다. 사용자 이름 서버의 정보가 다른 큐 관리자에 있는 브로커로 분배될 수 있도록 큐 관리자가 상호연결되어야 합니다.
브로커에는 큐 관리자 및 DB2에 대한 액세스가 필요합니다. 구성 관리자 및 사용자 이름 서버에는 큐 관리자에 대한 액세스만 필요합니다. 브로커는 다른 브로커와 큐 관리자를 공유할 수 없지만 구성 관리자 및 사용자 이름 서버와는 큐 관리자를 공유할 수 있습니다.
WebSphere Message Broker에 관련된 데이터를 보유하기 위해 WebSphere MQ 공유 큐를 SYSTEM.BROKER 큐로 사용할 수 없지만, 메시지 플로우 큐 대신 공유 큐를 사용할 수 있습니다.
DB2 데이터베이스 사용자 테이블 및 z/OS에서 WebSphere Message Broker에 의해 작성되고 사용되는 WebSphere MQ 큐에 대한 자세한 내용은 mqsicreatebroker 명령 주제에서 볼 수 있습니다.
브로커, 사용자 이름 서버, 사용할 계획이 있는 구성 관리자에 대해 시작 작업 프로시저를 작성해야 합니다. 이 프로시저는 적절한 사용자 ID를 사용하여 시작 작업 테이블에서 정의해야 합니다.
복구 전략을 결정해야 합니다. 시스템 아키텍처의 일부로, 시스템이 비정상 종료되는 경우 시스템 재시작을 위한 전략이 있어야 합니다. 공통되는 해결책은 NetView 또는 ARM(Automatic Restart Manager) 기능과 같은 자동화 제품을 사용하는 것입니다. ARM을 사용하여 WebSphere Message Broker를 구성할 수 있습니다.
UNIX 시스템 서비스, 자원 복구 서비스, DB2, WebSphere MQ 및 Java를 포함하여 공동 필수 제품에 대해서도 계획해야 합니다.
브로커의 RTLS(Runtime Library System)이 시스템의 언어 환경 디폴트 옵션에서 꺼져 있는지 확인해야 합니다. 왜냐하면, 브로커 코드는 XPLINK를 사용하여 컴파일되며 XPLINK 응용프로그램은 RTLS가 활성인 동안 시작될 수 없기 때문입니다.
z/OS의
브로커 통계도 수집해야 합니다.