以前のバージョンおよび他の製品との共存は、WebSphere Message Broker バージョン 6.0 を同じコンピューター上で以前のバージョンの製品と共存させる方法、およびバージョン 6.0 コンポーネントを以前のバージョンのコンポーネントと共に機能させる方法について説明します。
ユーザー定義の拡張機能およびマッピング・ファイルを除き、メッセージ・フロー・ファイル、メッセージ・セット定義ファイル、ESQL ファイル、XML スキーマ・ファイル、およびブローカー・アーカイブ・ファイルなどの開発リソースおよびデプロイメント・リソースをマイグレーションするためのタスクを実行する必要はありません。これらのリソースはそのまま WebSphere Message Broker バージョン 6.0 で使用を開始できます。
すべてのバージョン 5.0 およびバージョン 5.1 のユーザー定義ノード・プロジェクトは、バージョン 6.0 Message Brokers Toolkit と連動するためにアップグレードされなければなりません。 プロジェクトを消去する (「プロジェクト」 > 「消去」をクリックする) ことによってアップグレードします。 プロジェクトを消去すると、バージョン 6.0 がユーザー定義拡張機能に含まれる ESQL ファイルをコンパイルするのに必要とされる拡張ポイントが、プロジェクト plugin.xml ファイルに作成されます。
mqsimigratemfmaps コマンドを使用して、バージョン 5.0 マッピング・ファイル (.mfmap) を バージョン 6.0 マッピング・ファイル (.msgmap) にマイグレーションした後、これらのファイルを バージョン 6.0 Message Brokers Toolkit で編集します。ESQL から呼び出されるマッピングをマイグレーションするためのマイグレーション・ツールはありません。
バージョン 6.0 Message Brokers Toolkit で現在のリソースの使用を開始した後、バージョン 5.0 またはバージョン 5.1 Message Brokers Toolkit でこれらの同じリソースを再使用することについては制約があります。 詳しくは、以前のバージョンの Message Brokers Toolkit でのマイグレーション済みリソースの使用の条件を参照してください。
マイグレーションのテストの目的は、マイグレーション中に発生する可能性のある問題を識別することです。 例えば、問題が発生すれば、マイグレーション済みの一部のリソースを、マイグレーションを開始する前にバックアップしたバージョン 5.0 のレベルにリストアしなければならなくなる可能性があり、そうなると、マイグレーション後にこれらのリソースに対して加えた変更はすべて失われることになります。 実動ドメインをマイグレーションする前に開発ドメインおよびテスト・ドメインをマイグレーションすることによって、こうした問題を識別し、さらに問題が生じた場合にそれに対処するための戦略を開発することができます。
マイグレーションを計画したら、リソースをバックアップします。