課題 1.2: API 間の概念的な相違

この課題を始める前に、『課題 1.1: リソースのインポート』を完了していなければなりません。

この課題では、2 つのポートレット API 間の概念的な相違を学習します。

概要

IBM ポートレット API は、最初は WebSphere Portal バージョン 4 用に開発されました。 JSR 168 ポートレット API のサポートは、WebSphere Portal バージョン 5.0.2 から提供されています。

JSR 168 ポートレット API は、ポータル・サーバーの主要ベンダーからの入力に基づいて、 IBM と Sun 主導の合同グループが開発した標準化 JavaTM ポートレット仕様です。 その目的は、各種ベンダーからのポータル・サーバー間のポートレットの互換性の問題を解決することにあります。 最初の仕様は、2003 年 10 月に承認されました。

WebSphere Portal は、両方の API をサポートしています。 2 つのポータル・コンテナーを提供しています: (1) IBM ポートレット API ポートレット用の既存のコンテナー (これ以降は「IBM ポートレット」と呼びます) (2) JSR 168 ポートレット API ポートレット用の標準コンテナー (これ以降は「JSR 168 ポートレット」と呼びます)。 異なるコンテナーで実行するポートレットは、同じポータル・ページに常駐させることができます。

ポータル・コンテナーは、ポートレットにランタイム環境を提供します。 これは以下の 3 フェーズで構成されたポートレットのライフ・サイクルをサポートします。

要求処理フェーズには、以下の 2 つのサブフェーズがあります:

特定コーディングの相違を理解する前に、 2 つのポートレット API 間のいくつかの基本的な相違を理解する必要があります。

ポートレット・デプロイメント記述子のソース・コードについては、下記の説明のように直接処理をする必要はありません。 ポートレットのデプロイメント記述子エディターは、 portlet.xml にグラフィカル・ユーザー・インターフェースを提供して、 ユーザーに代わってソース・コードを更新します。

IBM ポートレット API を使用するクラス・インスタンスおよびデータ

ポートレットが最初にロードされると、Web デプロイメント記述子 (web.xml) のパラメーターで初期化されます。 このパラメーターは <servlet> エレメントの <init-param> エレメントに定義されます。 これらのパラメーターは、PortletConfig オブジェクトの getInitParameter() メソッドを使用して検索できます。 結果ポートレットはアブストラクト・ポートレット です。

ポートレットを使用する前に、ポートレットのデプロイメント記述子 (portlet.xml) から、 パラメーターが PortletApplicationSettings オブジェクト、または PortletSettings オブジェクトにロードされます。 これらのパラメーターは、<concrete-portlet-app> エレメントの <context-param> エレメントに、 そして <concrete-portlet> エレメントの <config-param> エレメントに設定されます。

<concrete-portlet-app> エレメント上のパラメーターは、 ポートレット・アプリケーションのすべてのポートレットに設定されます。 これらのパラメーターは PortletSettings.getApplicationSettings() メソッドで検索できます。 getApplicationSettings() メソッドは PortletApplicationSettings オブジェクトを戻し、 PortletApplicationSettings.getAttribute() は個々のパラメーターを検索する場合に使用されます。 <concrete-portlet> エレメント上のパラメーターは、 特定ポートレットに適用されます。 これらのパラメーターは PortletSettings.getAttribute() メソッドで検索できます。

アブストラクト・ポートレットと PortletSettings オブジェクトからのデータの組み合わせは コンクリート・ポートレット と呼ばれます。

ポートレットをポータル・ページに配置するときに、PortletData オブジェクトが作成されます。 コンクリート・ポートレットと PortletData オブジェクトの組み合わせは コンクリート・ポートレット・インスタンス と呼ばれます。 PortletData オブジェクトはコンクリート・ポートレット・インスタンスの永続的データを管理します。 この値は PortletRequest.getData() と PortletData.getAttribute() メソッドを使用して検索され、 PortletData.setAttribute() と PortletData.store() メソッドを使用して保管されます。 ポータル・ページのスコープに依存しますが、データはユーザーまたはグループに範囲を絞られます。

コンクリート・ポートレット・インスタンスと PortletSession オブジェクトの組み合わせは、 ユーザー・ポートレット・インスタンス と呼ばれます。

下図はこれまでに検討したオブジェクトを示すものです。
IBM ポートレット API におけるポートレット・クラスとデータの論理表記

JSR 168 ポートレット API を使用するクラス・インスタンスおよびデータ

JSR 168 ポートレット API を使用して、初期パラメーターは <portlet-preferences> エレメントと一緒に portlet.xml に定義されます。 IBM ポートレット API 用の web.xml にある <init-param> エレメントは、 JSR 168 ポートレット API 用の portlet.xml にある <init-param> エレメントに相当します。

これらの初期パラメーターは読み取り専用に設定できますが、構成モードで実行時に変更することも可能です。 読み取り専用初期化パラメーターの変更は管理者のみが行うことができます。 ランタイムで変更する場合は、バリデーター・クラスを呼び出すことができます。 バリデーター・クラスの名前は <portlet-preferences> エレメントにも設定できます。 PortletPreferences オブジェクトは、 RenderRequest.getPreferences()、PortletPreferences.getValue()、および PortletPreferences.getValues() メソッドを介して、これらのパラメーターを使用可能にします。 <portlet-preferences> エレメントは、IBM ポートレット API における <config-param> エレメントと PortletData オブジェクトを組み合わせたものに相当します。

PortletPreferences オブジェクトとポートレットの組み合わせは、ポートレット・エンティティー として既知のものです。 ポートレット・ウィンドウ はポートレット・モード (編集、表示)、ポートレット・ウィンドウ状態 (標準、最大化、最小化)、 およびレンダリング・パラメーターの組み合わせとして定義されます。 ポータル・ページには、提供されるポートレットに対して複数のポートレット・ウィンドウを組み込むことが可能であり、 それぞれは特定モード、状態、およびレンダリング・パラメーターのセットと関連付けされます。

下図はこれまでに検討したオブジェクトを示すものです。
JSR 168 API におけるポートレット・クラスとデータの論理表記

ポートレットのライフ・サイクル

両方のポートレット API は、初期化フェーズ、要求処理フェーズ、 および消滅フェーズから成るライフ・サイクルを使用します。 要求処理フェーズはサブフェーズ (アクション処理、およびコンテンツ・レンダリング) に分割されています。 要求処理フェーズの詳細は、 「要求処理」で検討されています。 下のリストは、それぞれのフェーズで呼び出される特定メソッドです。

IBM ポートレット API ライフ・サイクル・メソッド

init(PortletConfig)
ポートレットがサービス提供状態になるときに、init() メソッドが呼び出されます。 PortletConfig パラメーターにより、PortletContext オブジェクトへのアクセスが提供されます。
initConcrete(PortletSettings)
initConcrete() メソッドは PortletSettings オブジェクトでコンクリート・ポートレットを初期化する場合に使用されます。
service(PortletRequest, PortletResponse)
service() メソッドは、ポートレットがそのコンテンツをレンダリングするために必要となったときに呼び出されます。 この service メソッドはポートレットのライフ・サイクル期間中に何回も呼び出されます。 service はポートレットのウィンドウ状態に依存して、doView() および doEdit() などのメソッドを呼び出します。 この service メソッドは、通常、ポートレット・クラスの実装時にはオーバーライドされません。
destroyConcrete(PortletSettings)
destroyConcrete() メソッドは、コンクリート・ポートレットがサービス休止になるときに呼び出されます。
destroy(PortletConfig)
destroy() メソッドは、ポートレットがサービス休止になり、 リソースのクリーンアップをしているときに呼び出されます。

JSR 168 ポートレット API ライフ・サイクル・メソッド

init(PortletConfig)
ポートレットがサービス提供状態になるときに、init() メソッドが呼び出されます。 PortletConfig パラメーターにより、PortletContext オブジェクトへのアクセスが提供されます。
render(RenderRequest, RenderResponse)
render() メソッドは、ポートレットがそのコンテンツをレンダリングするために必要となったときに呼び出されます。 このメソッドはポートレットのウィンドウ状態に依存して、doEdit() および doView() などのメソッドを呼び出します。 この render メソッドは、通常、ポートレット・クラスの実装時にはオーバーライドされません。
processAction(ActionRequest, ActionResponse)
processAction() メソッドには、パラメーターとして ActionRequest および ActionResponse オブジェクトが必要です。
destroy()
destroy() メソッドは、ポートレットがサービス休止になり、 リソースのクリーンアップをしているときに呼び出されます。

要求処理

両方のポートレット API は 2 フェーズの要求処理を使用します。 アクション (またはイベント) が最初に処理され、 次に、レンダリング・フェーズが呼び出されます。 IBM ポートレット API では、 アクション・フェーズは actionPerformed() メソッドを介して呼び出され、 レンダリング・フェーズは service() メソッドによって呼び出されます。 JSR 168 ポートレット API では、フェーズは processAction() および render() メソッドを介して呼び出されます。

2 つの API 間での大きな相違点は、JSR ポートレット API ではオブジェクト、 およびレンダリング・フェーズで異なる要求オブジェクトと応答オブジェクトを使用していますが、 一方、IBM ポートレット API は 2 つのフェーズで同じオブジェクトを使用することです。 IBM ポートレット API を使用すると、イベント処理中に要求オブジェクトと応答オブジェクトに属性を設定することが可能であり、 レンダリング・フェーズでその値を検索できます。 JSR ポートレット API を使用すると、 セッション・オブジェクト、またはレンダリング・パラメーターを使用して、属性値をパスできます。

その他の相違点としては、IBM ポートレット API の actionPerformed() メソッドは、その ActionEvent パラメーターを使用して、PortletRequest オブジェクトへのアクセスを取得しますが、JSR 168 ポートレット API の processAction() メソッドは、PortletRequest および PortletResponse インターフェースを実装するパラメーターの ActionRequest および ActionResponse を持っていることです。

これで、『課題 1.3: JavaTM クラス相違の比較』を開始する準備が完了しました。

ご利用条件 | フィードバック
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.