構成マネージャー・プロキシーを使用したブローカー・ドメインへのナビゲート

始める前に

このステップの開始前に、構成マネージャー・プロキシーを使用した構成マネージャーへの接続を完了する必要があります。

構成マネージャーから制御可能な各ドメイン・オブジェクトは、構成マネージャー・プロキシー (CMP) で単一オブジェクトとして表され、これには以下のものが含まれます。
  • ブローカー
  • 実行グループ
  • デプロイ済みメッセージ・フロー
  • トピック
  • 集合
  • サブスクリプション
  • パブリッシュ/サブスクライブ・トポロジー
  • ブローカー・イベント・ログ

さらに、CMP はデプロイ済みメッセージ・セットを処理します。ただし、これらはデプロイ済み実行グループの属性として扱われます。

これらのオブジェクトは集合的に管理対象オブジェクトとして知られ、構成マネージャーへの一括のインターフェースを提供します。 また、それ自体は構成マネージャー・プロキシー API を理解するための基礎となります。

各管理対象オブジェクトは、構成マネージャー内のオブジェクトの基礎となるタイプを記述する Java クラスのインスタンスです。 考えられる Java クラスは以下のとおりです。
Java クラス クラスの機能
TopologyProxy pub/sub トポロジーを記述します。
CollectiveProxy pub/sub 集合を記述します。
BrokerProxy ブローカーを記述します。
ExecutionGroupProxy 実行グループを記述します。
MessageFlowProxy 実行グループにすでにデプロイされているメッセージ・フローを記述します。ツールキットのブローカー・アプリケーション開発パースペクティブ内のメッセージ・フローは記述しません。
TopicProxy トピックを記述します。
TopicRootProxy トピック階層のルートを記述します。
LogProxy 現行ユーザー用のブローカーのイベント・ログを記述します。
SubscriptionsProxy アクティブなサブスクリプションのサブセットを記述します。
ConfigManagerProxy 構成マネージャー自体を記述します。
各管理対象オブジェクトは、構成マネージャーから制御可能な単一オブジェクトを記述します。 例えば、ブローカー・ドメイン内のブローカーごとに、CMP アプリケーション内のブローカーを表す 1 つの BrokerProxy インスタンスがあります。

各管理対象オブジェクトでは、インスタンスが参照する基礎となる構成マネージャー・オブジェクトのプロパティーを問い合わせて取り扱うためにプログラムが使用できるパブリック・メソッドのセットが宣言されます。 例えば、ブローカー B1 を参照する BrokerProxy オブジェクトでは、ブローカーがその実行状態を明らかにするか、またはブローカーがそのすべてのメッセージ・フローなどを開始するメソッドを呼び出すことができます。

管理対象オブジェクトにアクセスして、その API を使用するには、まず、管理対象オブジェクトを論理的に所有するオブジェクトから、その管理対象オブジェクトへのハンドルを要求する必要があります。 例えば、ブローカーが実行グループを論理的に所有している場合、ブローカー B1 で実行する実行グループ EG1 へのハンドルを取得するには、アプリケーションは、B1 で表される BrokerProxy オブジェクトに依頼して、EG1 で表される ExecutionGroupProxy オブジェクトへのハンドルを取得する必要があります。

ConnectToConfigManager の例では、ConfigManagerProxy オブジェクトへのハンドルが取得されます。 ConfigManagerProxy は、論理的には管理対象オブジェクト・ツリーのルートです。つまり、構成マネージャー内のその他のオブジェクトはすべて、直接的または間接的にそこからアクセス可能です。 構成マネージャーはパブリッシュ/サブスクライブ・トポロジーを直接所有します。そのため、アプリケーションが TopologyProxy オブジェクトへのハンドルを取得するために ConfigManagerProxy から呼び出すことができるメソッドがあります。 同様に、トポロジーにはすべてのブローカーのセットが論理的に含まれているため、BrokerProxy オブジェクトにアクセスするためのメソッドを TopologyProxy オブジェクトで呼び出すことができます。 このようなアクセス関係の完全な階層は、以下に示すとおりです。


以下のプログラムでは、ConnectToConfigManager の例を開始点として使用し、管理対象オブジェクト階層を全探索して、デプロイ済みのメッセージ・フローの実行状態を見付けます。 プログラムでは、メッセージ・フロー MF1 がブローカー B1 上の EG1 にデプロイされることを前提としています。ただし、コード内のこれらの値をドメイン内で有効な値に置換することが可能です。
import com.ibm.broker.config.proxy.*;

public class GetMessageFlowRunState {

  public static void main(String[] args) {
        
    ConfigManagerProxy cmp = null;
    try {
      ConfigManagerConnectionParameters cmcp =
         new MQConfigManagerConnectionParameters(
           "localhost",
           1414,
           "");
      cmp = ConfigManagerProxy.getInstance(cmcp);
    } catch (ConfigManagerProxyException cmpex) {
      System.out.println("Error connecting: "+cmpex);
    }
        
    if (cmp != null) {
      System.out.println("Connected to Config Manager!");
      displayMessageFlowRunState(cmp, "B1", "EG1", "MF1");
      cmp.disconnect();
    }      
  }

  private static void displayMessageFlowRunState(
                                 ConfigManagerProxy cmp,
                                 String brokerName,
                                 String egName,
                                 String flowName) {
    try {
      TopologyProxy topology = cmp.getTopology();
            
      if (topology != null) {
        BrokerProxy b = topology.getBrokerByName(brokerName);

        if (b != null) {
          ExecutionGroupProxy eg =
            b.getExecutionGroupByName(egName);

          if (eg != null) {
            MessageFlowProxy mf =
              eg.getMessageFlowByName(flowName);

            if (mf != null) {
              boolean isRunning = mf.isRunning();
              System.out.print("Flow "+flowName+" on " +
                egName+" on "+brokerName+" is ");

              if (isRunning) {
                System.out.println("running");
              } else {
                System.out.println("stopped");
              }
            } else {
              System.err.println("No such flow "+flowName);
            }
          } else {
            System.err.println("No such exegrp "+egName+"!");
          }
        } else {
          System.err.println("No such broker "+brokerName);
        }
      } else {
        System.err.println("Topology not available!");
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
      System.err.println("Comms problem! "+ex);
    }
  }
}
作業の大部分を行うメソッドは displayMessageFlowRunState() です。 このメソッドは、以前に取得した有効な ConfigManagerProxy ハンドルを使用し、メッセージ・フローの実行状態を以下のように見付けます。
  1. ConfigManagerProxy インスタンスを使用して、TopologyProxy へのハンドルを取得します。 構成マネージャーごとに 1 つのトポロジーしかないため、getTopology() メソッドは ID で修飾することを必要としません。
  2. 有効なトポロジーが戻される場合、TopologyProxy インスタンスが、ストリング brokerName で記述された名前を持つ、その BrokerProxy オブジェクトへのハンドルを取得するために使用されます。
  3. 有効なブローカーが戻される場合、BrokerProxy インスタンスが、ストリング egName で記述された名前を持つ、その ExecutionGroupProxy オブジェクトへのハンドルを取得するために使用されます。
  4. 有効な実行グループが戻される場合、ExecutionGroupProxy インスタンスが、ストリング flowName で記述された名前を持つ、その MessageFlowProxy オブジェクトへのハンドルを取得するために使用されます。
  5. 有効なメッセージ・フローが戻される場合、MessageFlowProxy オブジェクトの実行状態が照会され、結果が表示されます。
取り扱うことを予定しているオブジェクトの名前を知っている必要はありません。 各管理対象オブジェクトには、それが論理的に所有するオブジェクトのセットを戻すメソッドが含まれています。 以下の例では、ドメイン内のすべてのブローカーの名前を検索することによって、このことを示します。
import java.util.Enumeration;
import com.ibm.broker.config.proxy.*;

public class DisplayBrokerNames {

  public static void main(String[] args) {
        
    ConfigManagerProxy cmp = null;
    try {
      ConfigManagerConnectionParameters cmcp =
         new MQConfigManagerConnectionParameters(
           "localhost",
           1414,
           "");
      cmp = ConfigManagerProxy.getInstance(cmcp);
    } catch (ConfigManagerProxyException cmpex) {
      System.out.println("Error connecting: "+cmpex);
    }
        
    if (cmp != null) {
      System.out.println("Connected to Config Manager!");
      displayBrokerNames(cmp);
      cmp.disconnect();
    }
  }

  private static void displayBrokerNames(ConfigManagerProxy cmp)
  {
    try {
      TopologyProxy topology = cmp.getTopology();
            
      if (topology != null) {
        Enumeration allBrokers = topology.getBrokers(null);
        
        while (allBrokers.hasMoreElements()) {
          BrokerProxy thisBroker =
            (BrokerProxy) allBrokers.nextElement();
          System.out.println("Broker "+thisBroker.getName());
        }
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
        System.err.println("Comms problem! "+ex);
    }
  }
}
かぎとなるメソッドは TopologyProxy.getBrokers(Properties) です。 このメソッドにヌル引数が指定されると、ドメイン内のすべての BrokerProxy オブジェクトの列挙が戻されます。 プログラムはこのメソッドを使用して、それぞれの BrokerProxy を順番に調べ、その名前を表示します。

TopologyProxy.getBrokers(Properties) の Properties 引数を使用して、検索されたブローカーの特性を厳密に指定することができます。 管理対象オブジェクトを戻すメソッドの大多数でこれを行うことができます。また、これは、それらのオブジェクトをプログラムが処理する必要のある対象でフィルタリングするための有効な方法です。

オブジェクトのルックアップをフィルタリングするために使用できるそれらの特性の例には、名前や UUID などのより明白なプロパティーだけでなく、実行状態と簡略説明があります。 これを行うための論理を作成するには、管理対象オブジェクトがその情報をどのように保管するのかを理解する必要があります。

各管理対象オブジェクトのプロパティーは、ハッシュ・テーブルを使用してオブジェクトの内部に論理的に保管されます。このとき、各プロパティーは {key, value} の組で表されます。 各 key は属性の名前 (例えば、name) で、各 value は値 (例えば、BROKER1) です。

各キー名は、AttributeConstants クラスからの定数 (com.ibm.broker.config.proxy) を使用して表現する必要があります。 各管理対象オブジェクトのキーと考えられる値のセットのすべてについては、Java の資料の AttributesConstant クラスで説明されています。また、構成マネージャー・プロキシー API エクササイザーのサンプル・プログラムの「このオブジェクトのロー・プロパティー・テーブルを表示」機能を使用することもできます。 後者では、管理対象オブジェクトごとの {key, value} の対の完全なリストが表示されます。

ルックアップ・メソッドに提供されるプロパティー引数は {key, value} の対のセットで、これらは戻された列挙で管理対象オブジェクトに存在していなければなりません。 このことを示すために、以下のコード断片を考慮してください。
Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration e = executionGroup.getMessageFlows(p);
変数 executionGroup が有効な ExecutionGroupProxy オブジェクトである場合、戻される列挙には実行中の メッセージ・フロー (OBJECT_RUN_STATE_PROPERTY が OBJECT_RUNSTATE_RUNNING に等しい) だけが含まれます。
プロパティーのフィルタリングが、オブジェクトの列挙ではなく単一の管理対象オブジェクトを戻すメソッドに適用される場合、最初の結果だけが戻されます (複数の一致が該当する場合、この結果は決定的ではありません)。 これは以下のことを意味します。
Properties p = new Properties();

p.setProperty(AttributeConstants.NAME_PROPERTY,
              "shares");

TopicProxy t = topicProxy.getTopic(p);
これは以下に代わるものです。
TopicProxy t = topicProxy.getTopicByName("shares");

複数の {key, value} の対がプロパティー・フィルターに追加される場合、オブジェクトが一致するには、すべてのプロパティーが子オブジェクトの中に存在しなければなりません。 このことを行うための特定のアプリケーション・コードを作成しないで、フィルターで論理 OR、または論理 NOT を実行することはできません。

AdministeredObjects がアプリケーションで最初にインスタンス化されている場合、CMP は構成マネージャーにそのオブジェクトのプロパティーの現行セットを求めます。 これは非同期に起こります。つまり、プロパティーが最初に要求されるときに、CMP が構成マネージャーによって提供される情報を待機している間、一時停止があるかもしれないことを意味します。 一定の時間内に情報が届かない場合 (例えば、構成マネージャーが実行中ではない場合)、ConfigManagerProxyPropertyNotInitializedException がスローされます。 CMP が待機する最大時間は ConfigManagerProxy.setRetryCharacteristics() メソッドによって決定されます。

関連タスク
構成マネージャー・プロキシー・アプリケーションの開発および実行用の環境の構成
構成マネージャー・プロキシーを使用した構成マネージャーへの接続
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ae33040_