使用するノードの決定

始める前に:

メッセージ・フロー・ノードに関する概念トピックに目を通しておきます。

WebSphere Event Broker には、メッセージ・フロー内で使用できるメッセージ処理ノードが多数あります。 ユーザー、または他のベンダーおよび会社によって作成され提供されたユーザー定義ノードから選択することもできます。

どのノードを使用するかは、メッセージに対して実行する処理によって異なります。 組み込みノードは、いくつかのカテゴリーに分けることができ、それらのカテゴリーに ワークベンチ グループ化されて表示されます (ただし、このグループ化は操作には影響しません)。 また、同じ方法で、ユーザー定義ノードもカテゴリー化できます。 次のようなカテゴリーがあります

入出力
入出力ノードは、クライアントがメッセージ・フローの中のどのポイントへメッセージを送信するか (MQInput などの入力ノード)、どのポイントからメッセージを受信するか (MQOutput などの出力ノード) を定義します。 クライアント・アプリケーションは、ノードがメッセージの送信元または宛先として指定した I/O リソースとの間でメッセージの書き込みと読み取りを行うことにより、これらのノードと相互作用します。 メッセージ・フローには最低 1 つの入力ノードが必要ですが、出力ノードはなくてもかまいません。
  • ブローカーにデプロイしたいメッセージ・フローを作成する場合、メッセージを受け取る入力ノードを少なくとも 1 つ組み込む必要があります。 選択する入力ノードは、入力メッセージの送信元、およびメッセージを受け取りたいフロー内の場所によって異なります。
    MQInput
    メッセージが WebSphere MQ キューのブローカーに到達し、ノードがメッセージ・フローの先頭になる場合。

    変更の始まりMQeInput ノードを含むメッセージ・フローを WebSphere Event Broker バージョン 6.0 で使用することは推奨されていません。 メッセージ・フローを再設計して、MQe ノードを除去し、独自の仕様に構成され MQe ゲートウェイ構成で調整された MQ ノードに置き換えてください。 詳細については、WebSphere MQ Everyplace ノードを含むメッセージ・フローのマイグレーションを参照してください。変更の終わり

    MQGet
    メッセージが WebSphere MQ キューのブローカーに到達し、ノードがメッセージ・フローの先頭にならない場合。
    SCADAInput
    メッセージが telemetry 装置によって送信される場合。
    Real-timeInput または Real-timeOptimizedFlow
    変更の始まりメッセージが JMS またはマルチキャスト・アプリケーションによって送信される場合。Real-timeInput ノードは入力ノードであり、Real-timeOptimizedFlow ノードは高性能のパブリッシュ/サブスクライブ・メッセージ・フローを提供する完全なメッセージ・フローです。変更の終わり
    変更の始まりJMSInput変更の終わり
    変更の始まりメッセージが JMS アプリケーションによって送信される場合。変更の終わり
    ユーザー定義入力ノード
    メッセージ送信元が、異なるプロトコルまたはトランスポートを使用するクライアントまたはアプリケーションである場合。
    Input ノード
    スタンドアロン・メッセージ・フローとしてデプロイしない、別のメッセージ・フローに埋め込みたいメッセージ・フロー (サブフロー) を作成している場合、メッセージを受け取る少なくとも 1 つの入力ノードを、そのサブフローに組み込む必要があります。

    入力ノードのインスタンスは in ターミナルを表します。 例えば、入力ノードのインスタンスを 1 つ組み込んだ場合、サブフローのアイコンは、1 つの in ターミナルを表示します。 これを、他のノードに接続するのと同じ仕方で、メイン・フロー内の他のノードに接続することができます。

    デプロイできるのは、最低 1 つの入力ノードがあるメッセージ・フローだけです。 メッセージ・フローに入力ノードが含まれていない場合には、それをブローカー・アーカイブ・ファイルに追加することはできません。 入力ノードはメイン・フロー、またはメイン・フローに組み込まれたメッセージ・フローに置くことができます。

    メッセージ・フローでは、複数の入力ノードを使用できます。 詳しくは、複数の入力ノードの使用を参照してください。

  • メッセージ・フローが作成したメッセージをターゲット・アプリケーションに送信したい場合、1 つ以上の出力ノードを含めることができます。 選択される出力ノードは、ターゲット・アプリケーションが予期する、これらのメッセージを受け取る際のトランスポートに依存しています。
    Publication
    サポートされるすべてのプロトコルを介してブローカーにサブスクライブするアプリケーションに、パブリッシュ/サブスクライブ・ネットワークを使用して、メッセージを配布する場合。 Publication ノードは出力ノードであり、それが使用する出力宛先は、現在のメッセージの特性とサブスクリプションが一致するサブスクライバーによって識別されます。
    MQOutput
    ターゲット・アプリケーションが、WebSphere MQ キュー、または入力メッセージ MQMD で指定される WebSphere MQ 応答先キューで、メッセージを受け取ることを予期する場合。

    変更の始まりMQeOutput ノードを含むメッセージ・フローを WebSphere Event Broker バージョン 6.0 で使用することは推奨されていません。 メッセージ・フローを再設計して、MQe ノードを除去し、独自の仕様に構成され MQe ゲートウェイ構成で調整された MQ ノードに置き換えてください。 詳細については、WebSphere MQ Everyplace ノードを含むメッセージ・フローのマイグレーションを参照してください。変更の終わり

    MQReply
    ターゲット・アプリケーションが、入力メッセージ MQMD で指定される WebSphere MQ 応答先キューで、メッセージを受け取ることを予期する場合。
    SCADAOutput
    telemetry 装置が出力メッセージのターゲットであり、Publication ノードが適切でない場合。
    Real-timeOptimizedFlow
    ターゲット・アプリケーションが JMS またはマルチキャスト・アプリケーションである場合。
    変更の始まりJMSOutput変更の終わり
    変更の始まりメッセージが JMS 宛先に対するものである場合。変更の終わり
    ユーザー定義出力ノード
    ターゲットが、異なるプロトコルまたはトランスポートを使用するクライアントまたはアプリケーションである場合。
    Output ノード
    スタンドアロン・メッセージ・フローとしてデプロイしない、別のメッセージ・フローに埋め込みたいメッセージ・フロー (サブフロー) を作成する場合、接続する後続のノードにメッセージを伝搬する少なくとも 1 つの出力ノードを、サブフローに組み込む必要があります。

    出力ノードのインスタンスは out ターミナルを表します。 例えば、出力ノードのインスタンスを 2 つ組み込んだ場合、サブフローのアイコンは、2 つの out ターミナルを表示します。 これを、他のノードに接続するのと同じ仕方で、メイン・フロー内の他のノードに接続することができます。

関連概念
メッセージ・フローの概要
エンド・ユーザー・アプリケーションのサポート
関連タスク
DB2 のセットアップ
メッセージ・フローの設計
メッセージ・フローの作成
メッセージ・フローの内容の定義
デプロイ
関連資料
組み込みノード
エンド・ユーザー・アプリケーションのサポート
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac00330_