IBM Lotus Expeditorプロパティー・ブローカー用のコラボレーティブ・コンポーネントの作成

コンテンツ IBM Lotus Expeditorプロパティー・ブローカーとIBM WebSphere Portalプロパティー・ブローカーの比較 コンポーネントの適切な構築 サンプル・アプリケーション アクション・ハンドラー コンポーネント内でのアクションの作成 プロパティー・ブローカーでのSWTアクションの使用 WebSphere Portal CAIとのコンポーネントの統合 プロビジョニングのためのコンポーネントのデプロイ OSGiコンソールでのデバッグ デバッグのヒント まとめ リソース 筆者について（原文のまま） ご意見ご要望をお寄せ下さい

Bob Balfe (balfe@us.ibm.com), Senior Software Engineer, IBM

レベル：中級
原文の掲載：2006年12月19日
原文はこちら(US)

IBM Lotus Expeditorプロパティー・ブローカーの概要を把握し、ブローカーによって提供される宣言型通信で動作するコンポーネントの作成方法を理解しましょう。拡張ポイント、IBM WebSphere Portalワイヤリング・ツール、およびプロパティー・ブローカーAPIを使用してコンポーネントを宣言的にワイヤーする方法について解説します。

この記事では、IBM Lotus Expeditorプロパティー・ブローカーについて紹介します。また、コンポーネントの作成方法、およびプロパティー・ブローカーが提供する宣言型通信にこれらのコンポーネントを参加させる方法についても説明します。プロパティー・ブローカーの主なタスクは、完全に分離したコンポーネント間に通信を提供することです。これらのコンポーネントは、自分自身を識別可能なプロパティーまたはアクションとしてプロパティー・ブローカーに適切に登録できる、定義済みの任意のJavaオブジェクトです。拡張ポイント、IBM WebSphere Portalワイヤリング・ツール、またはプロパティー・ブローカーAPIを使用すると、これらのコンポーネントを相互に宣言的にワイヤーすることができます。

この記事は、Lotus Expeditor（以前のIBM WebSphere Everyplace Deployment）に習熟したアプリケーション開発者を対象としています。アクション、プロパティーなどの用語を理解している前提で、説明を進めます。

IBM Lotus Expeditorプロパティー・ブローカーとIBM WebSphere Portalプロパティー・ブローカーの比較

Lotus Expeditorプロパティー・ブローカーは、WebSphere Portalプロパティー・ブローカーの機能にたいへんよく似ています。コンポジット・アプリケーションのコンテキストで使用されると、WebSphere PortalからのXMLは分離したコンポーネントのワイヤリングおよび通信を実行します。コンポジット・アプリケーション・インフラストラクチャー(CAI)は、ワイヤーの登録およびアクティブ化を管理します。CAIで使用されるよう開発されたコンポーネントの場合、最も重要なことはプロパティー変更のパブリッシュと、プロパティー変更に基づくアクションです。CAIの外部でコンポーネントを作成すると、ワイヤーの登録、アクティブ化、および非アクティブ化を独自に処理する必要があります。

EclipseプラットフォームおよびLotus Expeditorによって提供されるマルチ・ウィンドウおよびマルチタスク環境は複雑であるため、クライアント・サイドのプロパティー・ブローカーとその同類のWebSphere Portalブローカーの違いを明確にする最も大きな要因は、追加のアクション・フレームワークを拡張できる機能にあります。WebSphere Portalでは、異なる種類のポートレット間の通信が可能ですが、クライアント・プロパティー・ブローカーでは、Eclipse 拡張ポイントを使用してブローカーへの新しい拡張を作成できます。Lotus Expeditorには3つのアクション・ハンドラー拡張が含まれていて、いずれも既存のコードと互換性を保つために使用できます。Lotus Expeditorに含まれている、すぐに使用可能な3つのアクション・ハンドラーは以下のとおりです。

• Eclipseコア・コマンド
• Standard Widget Toolkit(SWT)ベースのアクション
• Abstract Windows Toolkit(AWT)コンポーネント

アクションは入力プロパティーの変更をともなって呼び出すことができるだけでなく、任意の数の出力プロパティーの変更を提供できるため、プロパティー・ブローカーは異なるタイプのメッセージング・システムでもあります。実際に、これによってプロパティー変更の応答を連鎖させることができます。図1に、実行の流れの例を示します。

上に戻る

コンポーネントの適切な構築

良好なカプセル化と適切な分離を行うために、コンポーネントは正しいコンポーネント・モデルに従う必要があります。これは、コンポーネントをこれまでの概念にはないコンテキストで使用するよう定義し、適切なコンポーネント化の原理を設計に適用しなければならないことを意味します。

考慮すべき設計のヒントを以下に示します。

1. わかりやすくするために、ビューとアクションを同じパッケージで宣言します。この方法により、クラスは自動的に分離されますが、同じパッケージ構造で結び付いています。1つの方法として、すべてのアクション・クラスが存在するActionsという名前のビューでサブパッケージを使用します。
2. 簡潔にするために、各アクションに対して1つのWSDL(Web Services Description Library)ファイルを提供します。プロパティー・ブローカーでは1つのWSDLで複数のアクションを定義できますが、アクションが他のアクションの汎用コンテナーとして動作しない限り、この方法は推奨されません。
3. プロパティー・ブローカーをCAIとともに使用することが、最も簡単な方法です。プロパティー・ブローカーとアクションをこのフレームワークの外部で使おうとすると、アクションとワイヤーを有効および無効にするコードを提供しなければならないでしょう。また、ワイヤーを登録するコードの提供も必要です。WebSphere Portalからコンポジット・アプリケーションのXMLを使用するとき、このワイヤーはXMLで定義されます。
4. プロパティーのネームスペースは、そのネームスペース内でプロパティーが固有となるよう制限する必要があります。たとえば、2つのコンポーネントが同じネームスペースを共有している場合、一方のコンポーネントでURLという名前のプロパティーを使用し、もう一方のコンポーネントでURLという名前のプロパティーを使用することはできません。固有にするために、ビューまたはアクションによって識別できる接頭辞をプロパティー名に付加することがあります。
5. アクションがUIコンポーネントを更新する場合、ラベルまたはUIコントロールを更新する呼び出しは、UIスレッド内から行うようにしてください。テンプレートはこれを前提として、コードを提供します。

上に戻る

サンプル・アプリケーション

分離した2つのコンポーネントのデモを行うサンプル・アプリケーションは、2つのコンポーネントを作成し、WebSphere Portalを使用して相互にワイヤーする基本レベルの方法を示します。このアプリケーションには2つのコンポーネントがあります。左側がURL Selectorビューで、右側がManaged Browserビューです(図2参照)。2つのビューはそれぞれ独自のプラグインで開発され、相互にバイナリーの依存関係はありません。

Selectorビューは、ユーザーが選択できるURLのリスト・コントロールを持つ単純なビューです。このビューは、名前がURL From TreeでタイプがURLのプロパティーをパブリッシュします。Browserビューは、Embedded Browserコントロールを持つSWTビューです。このビューは、URLInという1つの入力パラメーターを受け取るloadURLという名前のアクションを登録します。

Selectorビューがプロパティーをパブリッシュすると、このプロパティーはプロパティー・ブローカーを経由してSWTアクション・ハンドラーに到達し、ManagedBrowserプラグイン内のアクションに入ります。このアクションは、SWTHelperクラスを使用してビュー・インスタンスを特定し、loadURL()メソッドをビュー・オブジェクトに呼び出します。

上に戻る

アクション・ハンドラー

プロパティー・ブローカーのアーキテクチャーを理解するには、アクション・ハンドラーが何であるのかを理解する必要があります。アクション・ハンドラー拡張ポイントが存在する基本的な理由は、既存のイベント・ベースまたはメッセージ・ベースのシステムが、宣言型のブローカー・モデルにアクションを提供できるようにするためです。前述のように、Lotus Expeditorには3つのアクション・ハンドラーが含まれています。アクション・ハンドラーの要件に基づいて、適切なアクション・インプリメンテーションを使用する必要があります。最終的に、アクションはこれらのハンドラーのいずれかによって呼び出されます。ブローカーは、アクション・オブジェクト・タイプの登録済みハンドラーにプロパティーの変更を渡します。利用できる4つのハンドラーを表1に示します。

理解するために最も重要な部分は、表の依存関係の列です。ヘッドレス・アクション(UIの依存関係を持つことができないプラグインまたはコード)をワイヤーする場合は、アクションをインプリメントするときにorg.eclipse.core.commands.IHandlerインターフェースを使用します。コンポーネントが、SWTビューなどのグラフィックをベースとしたコンポーネントの場合は、org.eclipse.core.commands.IHandlerインターフェースをインプリメントする必要がありますが、アクションを作成するときはSWT_ACTIONタイプを指定します。SWTアクション・ハンドラーを使用すると、ページ・レベルのワイヤーの有効化または無効化を気にしなくてもよくなります。パースペクティブの表示または非表示にともない、コンポジット・アプリケーションのXMLで定義されたどのワイヤーも、適切に有効または無効にされます。

前述のように、アクション・ハンドラーは呼び出し可能なアクションとともに互換性のあるオブジェクトをインプリメントする役割を持ち、PropertyChangeEventインターフェースを提供するので、アクションはプロパティーおよびワイヤー情報を利用できます(図3参照)。ほとんどの場合、アクション・ハンドラーではなく、アクションだけを作成します。

上に戻る

コンポーネント内でのアクションの作成

このセクションでは、アクションの作成に焦点を当てます。始めるにあたり、アクションとは、あらかじめ定義されているインターフェースをインプリメントする一片のコードであることを理解する必要があります。プロパティーの値が変更され、プロパティーがアクション・コンポーネントに適切にワイヤーされるときに、そのコード内でメソッドが呼び出されます。

まず、PropertyBrokerDefinitions拡張ポイントへの拡張を作成することにより開始します。この拡張ポイントを作成するには、com.ibm.rcp.propertybrokerバンドルへの依存関係が必要です。この拡張は、入力プロパティーおよび出力プロパティーとともにアクションを適切に登録します。

Lotus Expeditor Toolkitによって提供されるいずれかのテンプレートを使用すると、すぐに始められます。プロパティー・ブローカー定義テンプレートは、拡張、WSDLファイル、およびアクションJavaクラスを作成します。選択できるテンプレートは2つあります。1つは基本的なEclipseアクション用、もう1つはSWTアクション用です(図4参照)。

このテンプレートの画面では、入力プロパティーと出力プロパティーの名前、およびそれらを宣言するネームスペースを入力します(図5参照)。テンプレートでは1つの入力プロパティーおよび1つの出力プロパティーを持つアクションしか作成できないので、テンプレートはスタート・ポイントだと考えるべきです。WSDLファイルを手動で変更することにより、いつでも出力パラメーターを追加できます。

メモ: 現在、プロパティー・ブローカーは1つの入力プロパティーのみサポートします。

次の入力画面では、入出力パラメーターをともなうアクションを作成するために、アクション・クラス、それを含めるパッケージ、およびその他の要素を定義します。

メモ: これらのすべての値は、WSDL内または生成されたアクション・コード内で直接変更できます。

これで、プロパティーの変更が発生したときにエントリー・ポイントとなるアクション・クラスを作成できました。

Eclipseの統合開発環境(IDE)および入力した情報に基づいてテンプレートによって作成された成果物を図6に示します。図内の(1)はコアEclipseコマンドまたはSWTベースのアクション用のアクションJavaファイルで、(2)は上記の入力に基づく完全な機能を持つWSDLファイルです。また、(3)は拡張ポイントで、(4)は生成されたWSDLへの関連を示します。

最後に、プロパティー・ブローカーはPropertyBrokerDefinitions拡張を処理するときに、プラグインIDを所有者IDとしてプロパティーを登録します。プロパティー・ブローカー内の所有者はその内部に固有のコンポーネントを持つ必要があるので、このことは重要です。単一の所有者は、1つの固有のプロパティーおよびアクション名を持つことができます。

上に戻る

プロパティー・ブローカーでのSWTアクションの使用

それでは、ビューであるSWTベースのコンポーネントがプロパティー・ブローカー・フレームワークでどのように使用されるのかを見ていきましょう。まず、アクション・コードは、特定のビューまたはビュー・インスタンスに直接結び付けられていないことを理解する必要があります。しかし、CAIとアクションに渡されたデータの組み合わせにより、ビューの特定のインスタンスを更新できます。残念ながら、SWTアクションでこれを実行するのは簡単ではありませんが、これを補助するヘルパーAPIが用意されています。

execute()メソッド内でアクションが呼び出されるときに、いくつかのヘルパー関数を呼び出して、特定のビュー・インスタンスを更新します(それが、アクションの実行目的であった場合)。作成したサンプル・コードはリスト1のようになります。

public Object execute(ExecutionEvent event) throws ExecutionException {

  final Object eventTrigger = event.getTrigger();
        
  if (eventTrigger instanceof PropertyChangeEvent){
        final PropertyChangeEvent pce = (PropertyChangeEvent)eventTrigger;
                        
        final PropertyValue value = pce.getPropertyValue();
                        
        Display.getDefault().asyncExec(new Runnable() {
                public void run(){

                Wire def = pce.getWireDefinition();
                                        
                ViewPart view = SWTHelper.locateView(def.getTargetEntityId());
                                        
                }
        });
  }
  return null;
}

太字で強調した行に注目してください。SWTHelperクラスには、使用する特定のビュー・インスタンスの識別を補助する静的メソッドがあります。ビューIDはワイヤー定義オブジェクトに含まれています。このオブジェクトは、PropertyChangeEventに含まれています。ワイヤー定義では、ワイヤーのソース・ビューとターゲット・ビューを参照できます。CAIは、アクションが正しい情報をともなって呼び出されるように管理しています。locateView()呼び出しは、ターゲットのビュー・インスタンスであるIViewPart thatを返します。instanceOfオペレーションを実行し、それが探していたビューであることを確認する必要があります。その後、適切なビュー・クラスにそれを型キャストします。

上に戻る

WebSphere Portal CAIとのコンポーネントの統合

次のステップとして、コンポーネントをWebSphere Portalに登録して、CAIに統合します。主な成果物は、アクション拡張用に作成されたWSDLファイルです。WebSphere Portalで定義されたポートレットでは、この同じWSDLファイルを使用しなければなりません。その理由として、ポートレットはプロパティーとアクションをWebSphere Portalプロパティー・ブローカーに登録することにより、他のポートレットとワイヤーするからです(WebSphere Portalのすべてのコンポーネントは、最初はポートレットであることが必要です)。Eclipseベースのビューをランタイムとして使用するときは、WebSphere Portalで1つのポートレットを登録することだけが必要です。これにより、コンポーネントのプロパティーとアクションを登録できます。本質的にポートレットは画面上のプレースホルダーであり、クライアントではコンポーネントがそこに表示されます。

この例のために、IBM Rational Application Developerでサンプル・ポートレットを作成し、WSDLファイルをそれに添付しました。ポートレットをランタイムに使用しないので、このポートレットのコードは何もする必要がありません。このポートレットは、ポートレットの代わりにSWTビューを使用することをクライアント・サイドのCAIに指示するよう構成されています。

ポートレットを作成した後は、コラボレーティブ・ポートレットを作成するときと同じ方法で、WSDLをポートレットに追加します。portlet.xmlファイルを編集し、WARファイル内でWSDLファイルが置かれている場所を指定します(図7参照)。

メモ: わかりやすくするために、ポートレットには、Eclipseビューの名前に似た名前を付けるようにしてください。ポートレットをページに配置するときに、ポートレットの名前がSWTビューの名前に非常によく似ていると、より理解しやすくなります。

図7では、指定しなければならないポートレット設定がcom.ibm.portal.propertybroker.wsdllocationであることがわかります。所有している各ポートレットおよびWSDLファイルごとに、この設定をportlet.xmlに追加する必要があります。

次のステップでは、WARファイルをRational Application Developerからエクスポートし、「ポートレット管理」でポータル管理ツールを使用して、これをWebSphere Portalにインポートします(図8参照)。

ビューを表すポートレットを1つのWARファイルに組み込むことができます。また、WARファイルとEclipseプラグインをできるだけ多く対応させることをお勧めします。

次に、ポートレットをページに配置し(図9参照)、「リッチ・クライアント」タブでその設定を編集します。このタブは、システム管理者がNetwork Clientインストーラー(NCI)をWebSphere Portalにインストールするときにインストールされます。

ポートレットを画面上に配置した後は、ポートレット・インスタンスの設定を編集できます(図10参照)。

「リッチ・クライアント」タブは、ポートレット設定のセットに内在する複雑さを処理します。コードは、com.ibm.rcp.viewIdという設定に、EclipseのビューIDフィールドで入力したテキストをセットします。これは、SWTコンポーネントの1次ビューIDです。CAIがパースペクティブを作成し、ビューを登録するとき、ポートレットIDはビューの2次IDとなります。

コンポーネントを構成してページに配置した後は、「ワイヤー」タブにあるポータル・ワイヤリング・ツールを使用して、互換性のあるプロパティーおよびアクションをワイヤーすることができます。Managed BrowserポートレットにワイヤーされたURLSelectorポートレットを図11に示します。

上に戻る

プロビジョニングのためのコンポーネントのデプロイ

WebSphere Portalからコンポジット・アプリケーションの一部としてコンポーネントを配布するには、コンポーネントのプラグインをHTTPサーバーにデプロイし、コンポーネントがそのサーバーを示すよう設定する必要があります。これを行うには、ポートレット設定エディターの「リッチ・クライアント」タブでEclipse更新サイトURLを指定します。

まず、プラグインをEclipseのフィーチャーにバンドルし、そのフィーチャーを更新サイトにデプロイします。更新サイトの作成後、クライアントが接続できるリモートHTTPサーバーにサイトをコピーします。

URLおよびポートレットの「リッチ・クライアント」タブで指定された要件を図12に示します。取得先のURLとともに、フィーチャーID、バージョン、および一致ルールを指定することに注意してください。

ポートレット設定でフィーチャーを指定することは、アプリケーションの起動前にこれらのフィーチャーをダウンロードするようCAIに指示することになります。これにより、画面の起動前に、フィーチャーのダウンロード、インストール、およびアクティブ化が行われます。

上に戻る

OSGiコンソールでのデバッグ

-consoleスイッチを用いてLotus ExpeditorまたはEclipseプラットフォームを起動すると、コンソール・レベルのコマンドを使用してプロパティー・ブローカーを調べることができます。これらのコマンドは、デバッグ目的でのみ使用されます。宣言型のシステムは本質的に非常に複雑であるため、プロパティー・ブローカーによってどのコンポーネントが呼び出されているのかを判断するときに(そのようなコンポーネントがある場合)、これらのコマンドが役立ちます。

プロパティー・ブローカーは、デバッグおよびテストを支援するために発行できる一連のOSGi(Open Service Gateway initiative)コンソール・コマンドを持っています。これらのコマンドは、- console コマンドを使用してプラットフォームを起動した場合にのみ提供され、コンソールで「help」と入力することにより、コマンドのリストにアクセスできます。現在、プロパティー・ブローカーによってサポートされているコマンドのリストを以下に示します(どのコマンドもpbで始まっています)。

---Property Broker Commands---
        pbsh a - Show all Actions
        pbsh aa - Show all Active Actions
        pbsh p - Show all properties by owner
        pbsh p <owner> - Show all properties for this owner (string owners only)
        pbsh w - Show all enabled wires
        pbsh aw - Show all wires
        pbsh ns - Show registered name spaces
        pbt <Property> - Trace the path for the specified property
        pbut <Property> - UnTrace the specified property, removes the trace
        pblt - Show a list of the currently traced Properties

前述のように、アクションおよびプロパティーの所有者はデフォルト設定ではプラグインIDであり、そこで拡張を作成します。ワイヤーの場合は、CAI で使用する際の所有者はパースペクティブ ID です。 CAI がワイヤーを登録する際には、パースペクティブ ID をワイヤー所有者として自動的に指定します。 パースペクティブにスイッチが入ると、 CAI は適切にワイヤーを自動的に有効および無効にします。API もしくは Extension Point を用いてワイヤーを手動で登録する場合には、ワイヤーを有効および無効にしたり、また登録から外したりするのは手動で行わなければなりません。

上に戻る

デバッグのヒント

問題となる可能性があるエリアおよびそのデバッグ方法のヒントを以下に示します。

• プロパティーのトレース
  なぜコンポーネントがプロパティーの変更を受け取らないか不明な場合は、プロパティー・ブローカーのトレース・コマンド「pbt」を使用して、そのプロパティーをトレースすることができます。このコマンドは、変更されたプロパティーのパスを基本的にトレースし、デバッグ情報をコンソールおよびログに出力します。出力が表示されない場合は、プロパティー名を誤って入力したか、ソース・コンポーネントがプロパティーをまったくパブリッシュしていないことが考えられます。例を示します。
  
  osgi> pbt mypropery
osgi> pbt "my property with spaces"
  
  
• ワイヤーが機能しない
  コンポーネントが機能しない、またはプロパティーの変更を受け取っていないように見える場合は、ワイヤーおよびアクションが有効になっているか確認します。「pbsh w」コマンドを使用すると、アクティブなすべてのワイヤーが表示され、「pbsh aa」コマンドを使用すると、アクティブなすべてのアクションが表示されます。
  
  
• WSDLの登録
  基本の「show」コマンドをプロパティーおよびアクションに使用して、WSDLファイルがプロパティー・ブローカーに適切に登録されているか確認します。「pbsh p」コマンドおよび「pbsh p <owner>」コマンドを使用すると、登録されているすべてのプロパティーが表示されます。アクションの場合は、「pbsh a」コマンドを使用すると、登録されているすべてのアクションのリストが得られます。

多数のWebSphere Portalアプリケーションがある場合、これらのアプリケーションの中には、多数のページを持ち、ページ内に多数のコンポーネントが存在するものがあります。クライアント・サイドのトポロジー・マネージャーは、コンポジット・アプリケーションのXMLをWebSphere Portalから取り出し、パースペクティブ、そのレイアウト、およびビューをEclipse用に動的に作成します。また、トポロジー・ハンドラーはパースペクティブおよびビュー用のデータ・モデルを提供し、Eclipseアクティビティーをページに関連付けます。

デバッグ目的で使用できるOSGiコマンドのリストを以下に示します(OSGiコンソールで「help」と入力すると、このリストを表示できます)。

---Topology Handler UI Commands---
thuish desc - Show all Perspective Descriptors
thuish del <perspective id> - Delete a Perspective Descriptor
thuish lp Show all Launcher Item IDs
thuish cd Show Current Perspective Descriptor
thuish ea Show Current Enabled Activities
thuish a <activity id> Show Activity State


---Topology Handler Commands---
thsh n - Show all navigation elements
thsh p - Show all Pages
thsh l - Show all Labels
thsh f - Show all topology files
thsh apps - Show all application GUIDs
thsh e <namespace> - Show all registered extensions under the given namespace
thsh dp - Show all dirty pages
thsh nattr <navigation id> - Show all navigation preferences

上に戻る

まとめ

コンポジット・アプリケーションは強力な概念です。ランタイム・アーキテクチャーのオープンな特性により、異なるコンポーネントおよびテクノロジーをシームレスかつ一貫性のある方法で統合することに、多くの可能性が得られます。この記事では、コンポジット・アプリケーションを構築し、それらを1つのユーザー・インターフェースに集約する方法を基本的なレベルで解説しました。

上に戻る

リソース

• developerWorksのLotus Expeditorのページ(US)
  
  
• developerWorks Lotusの記事 「IBM Lotus ExpeditorのWebサービスとしてOSGiサービスを開発する」
  
  
• developerWorks Lotusの記事 「IBM Lotus Expeditorでの簡単なWeb Services Resourceの構築とデプロイ」
  
  

• ディスカッション・フォーラム(US) にご参加ください。
  
  
• developerWorks Composite Applications ブログ(US)

上に戻る

筆者について（原文のまま）

		Bob Balfe is a Senior Software Engineer on the Lotus Expeditor team. He is the architect for the Portal Administered client and is responsible for a consistent programming model between WebSphere Portal and the Expeditor client. Bob was previously on the Lotus Notes and Domino core development team, serving as the team leader for the Automation Development team. His more than 17 years of software engineering experience include roles as an IT professional and a commercial software developer.

上に戻る

上に戻る