混合環境でのメッセージング・プロバイダーの選択

既存のメッセージング環境や計画されたメッセージング環境に IBM MQ および WebSphere® Application Server システムの両方が含まれている場合は、メッセージング要件、業務環境、および各メッセージング・アプリケーションのニーズを考慮して、デフォルト・メッセージング・プロバイダー、IBM MQ メッセージング・プロバイダー、またはその 2 つの混合のいずれかを選択してください。

このタスクについて

アプリケーション・サーバー間のメッセージングでは、IBM MQ システムとの対話によって、デフォルト・メッセージング・プロバイダーまたは IBM MQ プロバイダーを使用できます。いずれのプロバイダーも、必ずしも他方より優れているということはありません。プロバイダーの選択は、主として業務環境に関連した要因および予定されているその環境の変化、そしてそれぞれの JMS アプリケーションが実行すべきことに応じて異なります。さらに、これら 2 つのタイプのメッセージング・プロバイダーは相互に排他的ではありません。

  • 1 つのセル内で両方のタイプのプロバイダーを構成できます。
  • さまざまなアプリケーションが同じプロバイダーまたは異なるプロバイダーを使用できます。

業務環境に関連した要因には以下のものがあります。

  • メッセージング要件
  • 既存のスキル・セット
  • 既存のメッセージング・インフラストラクチャー
  • そのインフラストラクチャーに対して予定されている変更

1 つのプロバイダーのみを使用する場合、メッセージング・インフラストラクチャーの構成と管理はより単純です。メッセージングが主に IBM MQ 内で行われる場合は、おそらく IBM MQ メッセージング・プロバイダーを選択すべきです。同様に、メッセージングが主に WebSphere Application Server 内で行われる場合は、おそらくデフォルト・メッセージング・プロバイダーを選択すべきです。

業務環境で、1 つのプロバイダーのみを使用すべきか判断できない場合は、2 つを混用し、それぞれのアプリケーションに最も適切なメッセージング・プロバイダーを選択することを、検討する必要があります。これには、アプリケーションが使用する宛先のタイプ (サービス統合バス、または IBM MQ キューまたはトピック) を特定することが有効です。アプリケーションがバス宛先のみを使用している場合は、 通常、デフォルト・メッセージング・プロバイダーを使用します (ソリューション「DMP」)。 アプリケーションが 1 つ以上の IBM MQ 宛先と通信する必要がある場合は、業務環境、使用シナリオ、およびシステム・トポロジーに応じて、次のソリューションのいずれかを選択できます。
  • IBM MQ メッセージング・プロバイダー (ソリューション「MQP」) を使用します。
  • デフォルト・メッセージング・プロバイダーを使用して、IBM MQ サーバー (IBM MQ キュー・マネージャーまたはキュー共有グループ) をバス・メンバーとして統合します (ソリューション "DMP interop bus member")。
  • デフォルト・メッセージング・プロバイダーを使用して、IBM MQ ネットワークを外部バスとして統合します。IBM MQ リンクを使用します (ソリューション "DMP interop, foreign bus")。

これらのソリューションについて詳しくは、IBM MQ との相互協調処理: 主なフィーチャーの比較を参照してください。

これらのソリューションの選択に役立つように、以下の一部のステップには表が含まれています。表の各行が業務またはシステムの要件を示しています。また、アスタリスク (*) は、該当する要件を満たすのに最も有効である可能性の高いソリューションを示しています。 これらの表は、一般的なガイダンスを提供するために作成されており、正確にソリューションを特定することを意図したものではありません。 大部分の要件には、可能性のあるソリューションが複数あります。また、アスタリスクが表示されていない場合でも、そのソリューションを使用できないことを意味しているわけではありません。 これらの表を使用して最適なガイダンスを得るには、以下のようにします。
  • 最も重要な要件を反映している行に注目します。
  • 考慮するすべての行に対して、各ソリューションのアスタリスクの数を数えます。
アスタリスクの数が最も多いソリューションが、最も有効なソリューションである可能性が高くなります。

手順

  1. IBM MQWebSphere Application Server の経験があまりない場合に、自分のメッセージング・ニーズに一番合う製品を決めるには、WebSphere Application Server と IBM MQ メッセージングの比較を参照してください。
    注: どの製品をメッセージングの中心に選んでも、デフォルト・メッセージング・プロバイダーまたは IBM MQ プロバイダーのいずれかを、製品間の相互運用のために使用できます。
  2. 1 つのプロバイダーだけを使用できるかどうかを調べるには、業務環境を考慮してください。
    使用するプロバイダーを決定する場合は、以下の制約を考慮してください。
    • 現在および未来のメッセージング要件
    • 既存のメッセージング・インフラストラクチャー
    • 組織内にあるスキル・セット

    メッセージングの大半が現在 IBM MQ で実行されている場合は、そのアプローチを継続し、IBM MQ を外部 JMS プロバイダーとして (つまり、IBM MQ メッセージング・プロバイダーを使用する) WebSphere Application Server で構成します。WebSphere Application Server アプリケーションの JMS 要件が限定されている場合は、それらのアプリケーションについてサービス統合バスを使用することが十分に有利であるかどうかは、異論があるところです。

    ご使用の IBM MQ ネットワークと相互運用する必要のないメッセージング・アプリケーションが WebSphere Application Server にある場合は、デフォルト・メッセージング・プロバイダー (サービス統合バス) を使用します。WebSphere Application Server メッセージング要件が、WebSphere Application Server とのより緊密な相互運用を必要とする場合、サービス統合バスには次の利点があります。

    • 統合管理
    • WebSphere Application Server の高可用性機能
    • WebSphere Application Server のスケーラビリティー

    サービス統合と IBM MQ 間の相互運用をするためにデフォルト・メッセージング・プロバイダーの使用を選択する場合は、サービス統合フォーマットと IBM MQ フォーマット間のメッセージ変換に関わる追加コストが発生することに気をつけてください。

    以下のメッセージングのシナリオも検討してください。

    • IBM MQ キュー・マネージャーのインストール済みの大規模バックボーン (恐らく、メッセージ・ブローカー製品あり)。

      WebSphere Application Server を使用して、新規に導入されたメッセージング・アプリケーションを実行する場合は、IBM MQ キューまたはトピックを使用する既存のアプリケーションとメッセージを交換する WebSphere Application Server (JMS) メッセージング・アプリケーションをデプロイできます。

    • WebSphere Application Server のインストール済み環境で、おそらく既存の Web アプリケーションおよびエンタープライズ・アプリケーションはあるが、WebSphere Application Server メッセージング・アプリケーションはない場合。

      既存のメッセージング・インフラストラクチャーがない場合、WebSphere Application Server (JMS) メッセージング・アプリケーションをデプロイして、サービス統合バス宛先を使用する既存の WebSphere Application Server メッセージング・アプリケーションとメッセージを交換できます。

    • WebSphere Application Server メッセージング・アプリケーションに接続するために WebSphere Application Server を使用するインフラストラクチャー。

      WebSphere Application Server アプリケーションのペアの間で、WebSphere Application Server (JMS) メッセージングを導入します。

    • IBM MQ とサービス統合バスの両方を含むインフラストラクチャー。これは、マージャーが原因である可能性があります。 また、メッセージ・トラフィックが WebSphere Application Server から WebSphere Application Server に対して、または IBM MQ から IBM MQ に対するものとなる傾向があり、通常、WebSphere Application ServerIBM MQ の間ではないことも原因として考えられます。

      WebSphere Application Server (JMS) メッセージング・アプリケーションをデプロイして、IBM MQ キューまたはトピックを使用するアプリケーションと、メッセージを交換します。

  3. 業務環境で、1 つのメッセージング・プロバイダーのみを使用すべきか判断できない場合は、2 つを混用し、アプリケーションが使用する宛先タイプに基づいて、それぞれのアプリケーションに最も適切なプロバイダーを選択します。

    アプリケーションは、1 つ以上の既知のタイプの既知の宛先を使用する、既存のパートナー・アプリケーションまたはサービスとメッセージを交換する必要がある場合があります。 あるいは、パートナー・アプリケーションまたはサービスがまだデプロイされておらず、宛先タイプの選択がまだオープンである場合があります。その場合、ソリューション設計者は、アプリケーションやサービスを同時に接続する最適な方法を決定する必要があります。

    アプリケーションで複数の宛先が使用されている場合は、次の 4 つの結果となる可能性があります。

    注: アプリケーションがバス宛先ではなく IBM MQ 宛先を使用し、パートナー・アプリケーションも WebSphere Application Server JMS アプリケーションであることの、明確な業務理由または技術的理由がない場合は、既存の宛先をサービス統合にマイグレーションして、アプリケーションがバス宛先のみを使用するようにすることを検討してください。
  4. アプリケーションがバス宛先のみを使用する場合は、デフォルト・メッセージング・プロバイダーを使用するように、アプリケーションとその JMS リソースを構成します。
  5. アプリケーションが IBM MQ 宛先 (キューまたはトピック) のみを使用する場合は、次のチェックリストを使用して、使用するプロバイダー・ソリューションを決定します。
    表 1. IBM MQ 宛先のみを使用するアプリケーションのための、プロバイダーのチェックリスト. 以下の表の最初の列には、IBM MQ 宛先のみを使用するアプリケーションのビジネス要件またはシステム要件に関するチェックリストの質問を示します。2 番目の列には、IBM MQ メッセージング・プロバイダー (MQP) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。3 番目の列には、デフォルト・メッセージング・プロバイダーのバス・メンバー (DMP interop, bus member) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。4 番目の列には、デフォルト・メッセージング・プロバイダーの外部バス (DMP interop, foreign bus) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。2 番目から 4 番目の列には、その列に示すソリューションでは満たされない要件が、アスタリスク・マークなしで示されます。
    質問: MQP DMP interop, bus member DMP interop, foreign bus
    パフォーマンスは重要ですか?

    (そうである場合は、メッセージ変換を実行するよりも、IBM MQ を直接使用します。)

    *
    このアプリケーションでは、大規模メッセージ (500K を超えるメッセージ) の送受信が必要ですか? *
    アプリケーションのプログラミングとデプロイメントの簡素化に、ロケーションの透過性が必要ですか? * *
    アプリケーションは、IBM MQ キュー (キューの構成は固定) から消費する必要がありますか?

    (キューがサービス統合に移動することができず、バス宛先へのメッセージの送信にプッシュ・スタイルの IBM MQ アプリケーションをデプロイしたくない場合。)

    * *
    パートナー・アプリケーションは、バスまたは IBM MQ クライアントとして、WebSphere Application Server 以外で実行される JMS アプリケーションですか?

    (サービス統合と IBM MQ は、必要でない限り混用しないでください。IBM MQ またはサービス統合だけのソリューションは、より単純であり、サービス統合フォーマットと IBM MQ フォーマット間のメッセージ変換のコストを回避できます。)

    *
    パートナー・アプリケーションは非 JMS (WebSphere Application Server 以外の) アプリケーションですか?

    (可能な限り、IBM MQ またはサービス統合だけのソリューションを選択してください。ご使用の API 設定に応じて、MQI IBM MQ クライアント、または XMS IBM MQ クライアント、または XMS バス・クライアントを使用してください。)

    *
    IBM MQ ネットワークと WebSphere Application Server アプリケーション間を通過するトラフィックを、単一の長期的に実行されている接続に流すようにしたいですか? *
    WebSphere Application Server の高可用性フィーチャーを使用したいですか? *
    アプリケーションと IBM MQ キュー共有グループの間に XA 2 フェーズ・コミット (2PC) が必要ですか? * 1 を参照 * 2 を参照
    アプリケーションと IBM MQ クラスターの間に XA 2 フェーズ・コミット (2PC) が必要ですか? *
    IBM MQ キューからのメッセージを仲介するため、またはメッセージを配信するために、WebSphere Enterprise Service Bus を使用していますか?

    (例えば、WebSphere Business Integration アダプターを使用、または、CICS® などのサービス・プロバイダーに接続。)

    *
    アプリケーションは、IBM MQ キュー (キューの構成は固定) から消費する必要がありますか?

    (このキューはサービス統合に移動することができず、バス宛先へのメッセージの送信にプッシュ・スタイルの IBM MQ アプリケーションをデプロイしたくない場合。)

    * *  
    注:
    • 1 IBM MQ バージョン 7.0.1 が使用されていることが前提です。
    • 2 XA 2 フェーズ・コミットを IBM MQ リンクで使用できますが、対象となるのは IBM MQ リンクへのメッセージの送信のみです。 ストア・アンド・フォワードを使用する、IBM MQ リンクから IBM MQ キュー・マネージャーへの後続のメッセージ送信は対象となりません。
  6. 例えば、サービス統合から消費し、IBM MQ へ送信するように、アプリケーションがバス宛先と IBM MQ 宛先を混用している場合は、単一の接続ファクトリーまたはアクティベーション・スペックを使用して、デフォルト・メッセージング・プロバイダー相互運用モデルのいずれかがこれをサポートできます。以下のチェックリストを使用すれば、バス・メンバー・ソリューションと外部バス・ソリューションのいずれかに決定する際に役立ちます。
    表 2. バス宛先と IBM MQ 宛先を混用するアプリケーションのための、プロバイダーのチェックリスト. 以下の表の最初の列には、バス宛先と IBM MQ 宛先を混用するアプリケーションのビジネス要件またはシステム要件に関するチェックリストの質問を示します。2 番目の列には、デフォルト・メッセージング・プロバイダーのバス・メンバー (DMP interop, bus member) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。3 番目の列には、デフォルト・メッセージング・プロバイダーの外部バス (DMP interop, foreign bus) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。2 および 3 番目の列には、その列に示すソリューションでは満たされない要件が、アスタリスク・マークなしで示されます。
    質問: DMP interop, bus member DMP interop, foreign bus
    アプリケーションは IBM MQ 共有キューから消費する必要がありますか? *
    IBM MQ ネットワークと WebSphere Application Server アプリケーション間を通過するトラフィックを、単一の長期的に実行されている接続に流すようにしたいですか? *
    WebSphere Application Server バージョン 7 および IBM MQ バージョン 7 よりも前のバージョンの分散 IBM MQ が必要ですか? *
    IBM MQ キュー・マネージャーが使用できないときに、アプリケーションがメッセージ送信を続行できるように、ストア・アンド・フォワード機能が必要ですか? *
    サーバー接続チャネルの構成をしないようにしますか?

    (構成によりポートが開かれ、セキュリティー・リスクと見なされる可能性があるため。)

    * 1 を参照
    送信側および受信側チャネルのペアではなく、1 つのサーバー接続チャネルを定義しますか? *
    バインディング接続を使用するだけですか? *  
    注:
    • 1 これは、IBM MQ リンクを介して IBM MQ からメッセージをサービス統合バスに送信する場合にのみ適用されます。ただし、ご使用のアプリケーション・サーバーへのポートを開く必要があります。メッセージを IBM MQ リンク経由でサービス統合バスから IBM MQ に送信するには、ファイアウォール経由でキュー・マネージャーに対してポートを開く必要があります。
  7. 宛先タイプがまだわかっていない場合は、既知の問題の相対的優先順位を決めてから、次のチェックリストを使用して、可能なプロバイダー・ソリューションでそれぞれの宛先をどれほどうまく処理できるかを評価します。

    基本的な選択事項は、このアプリケーションでどの宛先タイプを使用するかです。宛先タイプはまだ決まっていないので、4 つのソリューションのいずれも可能ですが、原則として、ソリューション「DMP」または「MQP」を目指すべきです。これは、IBM MQ またはサービス統合だけのソリューションは、より単純であり、サービス統合フォーマットと IBM MQ フォーマット間のメッセージ変換コストを回避できるからです。

    表 3. 宛先タイプがまだ不明なアプリケーションのプロバイダー・チェックリスト. 以下の表の最初の列には、宛先タイプがまだ不明なアプリケーションのビジネス要件またはシステム要件に関するチェックリストの質問を示します。2 番目の列には、デフォルト・メッセージング・プロバイダー (DMP) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。3 番目の列には、IBM MQ メッセージング・プロバイダー (MQP) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。4 番目の列には、デフォルト・メッセージング・プロバイダーのバス・メンバー (DMP interop, bus member) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。5 番目の列には、デフォルト・メッセージング・プロバイダーの外部バス (DMP interop, foreign bus) ソリューションによって満たされる要件が、アスタリスク・マーク付きで示されます。2 から 5 番目の列には、その列に示すソリューションでは満たされない要件が、アスタリスク・マークなしで示されます。
    質問: DMP MQP DMP interop, bus member DMP interop, foreign bus
    IBM MQ を管理する強力な既存のスキル・ベースがありますか? * * *
    すべてのメッセージングの管理を IBM MQ チームで処理しますか? *
    管理者は、WebSphere Application Server に対するスキルはあるが、IBM MQ に対するスキルはありませんか? *
    大規模なインストール済みベース (参照を含む) および幅広い ISV ツールの選択肢を持つメッセージング製品を使用したいですか? *
    WebSphere Application Server に加えて、ライセンス交付を受けた製品を別に購入することは控えたいですか? *
    WebSphere Application Server に加えて、別の製品をインストールし、管理することは控えたいですか? *
    IBM Integration Bus (旧リリースでは WebSphere Message Broker) を既に使用していますか?

    (その場合は、いずれにしても IBM MQ が必要です。)

    * * *
    このアプリケーションでは、大規模メッセージ (500K を超えるメッセージ) の送受信が必要ですか? *
    アプリケーションのプログラミングとデプロイメントの簡素化に、ロケーションの透過性が必要ですか? * * *
    スループット要件では、複数の並列チャネルまたは経路が必要ですか? * * *
    パートナー・アプリケーションが、WebSphere Application Server 上でも実行される JMS アプリケーションですか?

    (サービス統合は WebSphere Application Server アプリケーション・サーバーで実行されます。分散プラットフォームでは、これはプロセス内であることを意味します。[z/OS]z/OS® プラットフォームでは、他の領域にあります。このため、デフォルト・メッセージング・プロバイダーを使用することで、分散プラットフォームではパフォーマンスが向上しますが、z/OS プラットフォームでは向上しません。)

    *
    パートナー・アプリケーションは、バスまたは IBM MQ クライアントとして、WebSphere Application Server 以外で実行される JMS アプリケーションですか?

    (サービス統合と IBM MQ は、必要でない限り混用しないでください。IBM MQ またはサービス統合だけのソリューションは、より単純であり、サービス統合フォーマットと IBM MQ フォーマット間のメッセージ変換のコストを回避できます。)

    * *
    パートナー・アプリケーションは非 JMS (WebSphere Application Server 以外の) アプリケーションですか?

    (可能な限り、IBM MQ またはサービス統合だけのソリューションを選択してください。ご使用の API 設定に応じて、MQI IBM MQ クライアント、または XMS IBM MQ クライアント、または XMS バス・クライアントを使用してください。)

    * *
    メッセージの順番を厳密に維持することが重要ですか? *
    アプリケーションに IBM MQ クラスターの柔軟性と便宜性が必要ですか?

    (IBM MQ クラスタリングによって管理はより単純になり、クラスター化キューの選択的並列処理が提供されます。つまり、クラスター化キューのインスタンスを、IBM MQ クラスター内の任意のキュー・マネージャー上で作成できます (しかし、必ずしもすべてのキュー・マネージャー上で作成する必要はありません)。クラスター化キューに送信されたメッセージは、キューの特定のインスタンス宛てに送信することも、ワークロード管理統計に基づいて動的にインスタンスを選択することもできます。WebSphere Application Server クラスタリングは、こうした柔軟性をある程度備えていますが、ユーザーがクラスター・バス・メンバーでメッセージング・エンジンのサブセットにバス宛先のパーティションを作成することはできません。)

    * * *
    アプリケーションには、IBM MQ for z/OS 共有キューにより提供される高可用性レベルが必要ですか? * * *
    WebSphere Application Server クラスタリングの高可用性フィーチャーまたはスケーラビリティー・フィーチャーを使用したいですか? * * *

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tmj_jmsp_mixed
ファイル名:tmj_jmsp_mixed.html