レベル: 中級 Stefan Hepper, WebSphere Portal Programming Model Architect, IBM, Software Group
Oliver Köth, Lead Developer, Portlet Container, IBM
2008年 9月 03日 新しくリリースされた IBM® WebSphere® Portal V6.1は、Java™ Portlet Specification 2.0 (JSR286) をフルに実装しています。この記事は、新機能を理解して最も適した使い方をするために役立ちます。また、新しい標準の概念、特にポートレット間通信がどのように製品に統合されているかを説明し、通信用にポートレット・イベントまたは公開レンダリング・パラメーターのどちらを使用するのかを選択するガイドラインを示します。この記事にはサンプル・ポートレットが含まれていて、ポートレット・イベント機能を試せるだけでなく、ポートレットに簡単にイベント・サポートを追加する際の参考資料としても利用できます。
この記事の前半部分では、Java Portlet Specificationの 2つ目のバージョンであるJSR286に含まれる新しいプログラミング機能を取り上げました。ポートレット・プログラマーがこれらの拡張機能を使用して新しいユース・ケースに取り組む方法を説明し、特に、別々に開発されたポートレット間の調整と、ポピュラーな AJAX 技術のサポートの改良点に焦点を当てました。
後半では、新機能が IBM WebSphere Portal V6.1 でどのように利用されているかを説明します。
イベントのサポート
最初にあげるJSR 286 機能は、ポートレット・イベントです。この記事の前半に述べたように、ポートレット・イベントは疎結合されたパブリッシュとサブスクライブの通信モデルを表します。この内部で、ポートレットはイベントを送出し、イベントは、ポータル内部で実行されているブローカー・コンポーネントによって、そのイベントに関連する他のポートレットに渡されます。
ポートレット間通信は常に重要なユース・ケースであるため、WebSphere Portal のいくつかのリリースで、非常によく似た通信メカニズムが、ポートレット間の情報交換のブローカーとして提供されてきました。これが、WebSphere Portal の連携ポートレット機能であり、プロパティー・ブローカーとも呼ばれています。JSR 286 でのポートレット・イベントのサポートにより、パブリッシュとサブスクライブのインフラストラクチャーが拡張され、標準化された新しいアプリケーション・プログラミング・インターフェース (API) がサポートされるようになりました。
ポートレットへの接続
管理者の視点からは、JSR 168 ベースの連携ポートレットへの接続と、イベント・サポートされた JSR 286 ポートレットへの接続に違いはありません。どちらもワイヤリング管理を使用して行われます。つまり、接続は、一方のポートレットでのパブリッシュ済みの情報 (パブリッシュ側イベント) から、もう一方のポートレットでの処理ロジック (処理側) のイベントへと定義されます。もちろん、ワイヤリング・ツールは、ポートレットがパブリッシュおよび受信できるイベント・タイプを知っている必要があります。このため、Java Portlet Specification で推奨されているように、ポートレットがサポートするすべてのイベントを portlet.xml デプロイメント記述子で宣言する必要があります。この宣言をしないと、WebSphere Portal V6.1 でポートレットを接続できず、ポートレット同士が通信できません。
ワイヤリング・ツールがワイヤリングのソースとターゲットをユーザー・フレンドリーな方法で表示できるように、宣言されたすべてのイベントにユーザーが読みやすい表示名を付ける必要があります。JSR 286 では、WAR ファイル内のすべてのポートレットで共有する言語固有の情報が追加されました。このため、新しい標準では、イベントの表示名などの変換可能な情報が格納されるアプリケーション・リソース・バンドルが (JSR 168 ポートレット・リソース・バンドルに加え) 定義されています。
この記事に含まれるサンプル・ポートレットでは、デプロイメント記述子でのイベントの定義方法と、コードおよびリソース・バンドルでのイベントの参照方法を示し、どのような方法でパーツ相互を正しく適合させるのかを説明します。
現在 WebSphere Portal では、ポートレットを同じページ上に配置することによるポートレット間の動的な相互接続はサポートされていません。一致するワイヤーが定義されているポートレット間でのみイベントが交換されます。一般に、ページは、ページ上のポートレット間のワイヤリングも含め、管理者によって設定されます。ページのプライベート・ビューにポートレットを追加できる権限を持つユーザーも、プライベート・ワイヤーをセットアップできます。
2 つのサンプル・ポートレットを相互にワイヤリングしているポートレット・ワイヤリング・ツールの画面キャプチャーを図 1 に示します。
図 1. ポートレット・ワイヤリング・ツール
明示的なワイヤリング・モデルにより、管理者は WebSphere Portal にデプロイされているポートレットの通信方法を完全に制御できます。特にこのモデルでは、ターゲット・イベントをグローバル (任意ページでの表示が可能) として定義し、異なるページをまたいだポートレットのワイヤーを確立できます。あるポートレットからのイベントは、同じページ上およびページ間の複数のワイヤーに伝搬できます。ページ間ワイヤーにページ切り替えフラグを追加指定でき、これを行うと、イベント処理の完了後、ブラウザーはターゲット・ページへとリダイレクトされます。
ワイヤーはページのデータ・モデルの一部であり、これは、ページの管理機能と API が内蔵のワイヤーも保持していることを意味します。XmlAccess などの構成管理ツールまたは新しいバージョン 6.1 のサイト管理ツールを使用すると、ワイヤーをページとともにエクスポートおよびインポートできます。WebSphere Portal アプリケーション・テンプレートは、ポートレット、ページ、およびビジネス・コンポーネントの特定のセットアップのインスタンスを作成するときに用いられますが、このテンプレートでは、通信しているポートレットとのワイヤーを、アプリケーション・インスタンスの一部としてセットアップできます。最後に、データ・モデル情報を読み取るパブリック・モデルのシステム・プログラミング・インターフェース (SPI) とパブリック・コントローラー SPI、およびモデル Atom フィード・インフラストラクチャー (どちらもバージョン 6.1 の新機能) は、ページのワイヤリング構造の読み取りと変更をサポートします。
イベント・ペイロードと相互運用性
JSR 286 仕様では、ポートレットが複雑な Java オブジェクトをイベント・ペイロードとして送受信することを許可しています。ただし、これらのペイロードが Java および JAXB XML シリアライズ可能でなければなりません。この許可により、たとえば、Web Services for Remote Portlets (WSRP) 2.0 プロトコルに準拠したリモート・ポートレットと通信する時など、クラス・ローダーおよびサーバーに対しても複雑なオブジェクトを転送できます。WebSphere Portal 6.1 は WSRP 2.0 をサポートし、完全な相互運用性をもたらし、ローカルおよびリモートのポートレット間でイベントを伝搬できます。
異なるクラス・ローダー間での複雑なオブジェクトの変換にも、XML シリアライゼーション・メカニズム (JAXB 2.0 ベース) は使用されます。このシリアライゼーションは、各 Web モジュールをそれ自身のクラス・ローダーにデプロイするためにカスタム・ペイロード・タイプがポートレット WAR ファイルに組み込まれているときによく使用されます。XML シリアライゼーションはパフォーマンスのオーバーヘッドをともなうことがあるため、WebSphere Portal は可能であれば直接オブジェクト参照を渡すことを試みます。この機能の利点として、たとえば、WebSphere Application Server 共有ライブラリーの概念を使用して、共有ペイロード・クラスを共通クラス・ローダーにデプロイすることにより、シリアライゼーションが必要なくなり、最適のパフォーマンスを得ることができます。
ポートレットがもともと同時に開発されたものでなくてもこの手法によって、ポートレット間接続の可能性を最大限に高めるために、一般には、単純な Java タイプ (通常は String) をイベント・ペイロードとして使用します。独立して開発されたポートレット間では、複雑なイベント・ペイロード・クラスはほとんど互換性がありません。
互換性のあるイベント名または別名を宣言することにより、ポートレットの相互運用性を高める必要があります。一般に、イベント名は交換されるデータを示すだけでなく、データを作成または要求するアクティビティーも示します。たとえば、カレンダー・ポートレットが、データを入力として受け取る特定の show_week_for_date 処理イベントに反応することがあります。他のポートレットからの入力をこのアクティビティーにワイヤーするには、そのポートレットはポートレット固有の同じネーム・スペースで show_week_for_date パブリッシング・イベントを生成する必要があります。このとき、イベント名が、たとえば、日付を生成する注文処理ポートレットであまり意味を持たない可能性があります。このため、JSR 286 はイベントの別名をサポートします。たとえば、注文処理ポートレットでは、show_week_for_date と show_month_for_date という別名を使用して order_added_for_date パブリッシング・イベントを宣言できるので、ユーザーは注文選択イベントをカレンダー内の別のアクションにワイヤーできます。
このアプローチは、両方のポートレット設計の比較的緊密な結合をまだ示唆しています。相互運用性を最大限に高めるには、期待するデータ・タイプまたは生成するデータ・タイプだけを表す別名を各イベントに宣言する必要があります。言い換えると、これが互換性のための最小限の要件です。たとえば、カレンダー・ポートレットの処理イベントをリスト 1 のように宣言できます。
リスト 1. カレンダー・ポートレットの処理イベント
<event-definition
xmlns:cal=”http://www.acme.com/portlets/calendar”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<qname>cal:show_week_for_date</qname>
<alias>xsd:date</alias>
<value-type> java.util.Date</value-type>
</event-definition>
|
別名を使用することで、接続されているポートレット同士が完全に独立して開発された場合でも、日付を生成する任意のソースによって show_week_for_date イベントを呼び出すことができます。
新しい注文が追加され、日付がカレンダーに送信されました。図 2 を参照してください。
図 2. イベントのサンプル
WebSphere Portal でのユーザー制御によるイベント伝搬
JSR 286 のイベント伝搬メカニズムは、ポートレットがイベントをパブリッシュするときに常に発生する、自動化されたポートレット間の対話を表します。ポートレットのライフ・サイクルのイベント・フェーズでは、どのような種類のユーザー対話も許可されません。WebSphere Portal は、情報の伝搬がユーザーによって明示的に制御されるポートレット間通信メカニズムを使用して、このモデルを拡張しています。このメカニズムは、Click-to-Action モデルと呼ばれています。
このアイデアは、アクション・フェーズでイベントをパブリッシュする代わりに、ポートレットが特殊な HTML 構成を使用してイベント情報をそのマークアップに埋め込み、イベント・ソースをライブ・テキストとして有効にできるというものです。このイベント・ソースは、ブラウザー内でアクティブ・ホット・スポットとして表示されます。つまり、クリックされると、イベント・ソースは一致するすべての処理ターゲットをページ上で動的に収集し、ユーザーに表示するメニューを作成します。ユーザーは、表示されたメニューリストから処理アクションを選択できます。図 3 を参照してください。
図 3. 注文ポートレットでの出荷日ライブ・テキスト用のコンテキスト・メニュー
このモデルでは、イベント・ソースを提供するメカニズムが JSR 286 とは異なりますが (Java 呼び出しの代わりにセマンティック HTML マークアップが使用されています)、JSR 286 のイベント処理は処理ターゲットとしてこのモデルに良好に適合します。このため、処理イベントを定義する JSR 286 ポートレットは、Click-to-Action のターゲットとして WebSphere Portal V6.1 で自動的に利用可能になります。JSR 286 ソース・イベントとライブ・テキスト・マークアップをポートレットに提供することにより、両方のプログラミング・モデルを簡単に結合できます。Click-to-Action は HTML マークアップにのみ基づくため、ポータル・ページでマークアップとして表されるすべての種類のコンポーネント間の通信に使用できることに注意してください。たとえば、ページに表示されるコンテンツ管理情報のイベント・ソース用にタグを追加し、この情報を同じページにある JSR 286 ポートレットに送信できます。Click-to-Action のサポートの詳細については、「WebSphere Portal V6.1 Information Center」を参照してください。
最後に、WebSphere Portal での JSR 286 のイベント・サポートは、前述した前のリリースでサポートされている連携ポートレット機能と完全に相互運用性がある点を指摘しておきます。JSR 168 の連携ポートレットは JSR 286 ポートレットによって処理イベントとして受信される情報を送信でき、JSR 286 ポートレットは連携ポートレット・モデルによって伝搬されるイベントをパブリッシュできます。この相互運用性により、調整されたポートレットを持つ既存のシステムを新しいポートレット標準に円滑に移行または拡張でき、お客様の投資が保護されます。
パブリック・レンダリング・パラメーター
ポートレット・イベントに加え、ポートレット間の調整を行う別の方法としてパブリック・レンダリング・パラメーターがあります。どちらのメカニズムもポートレット間の情報交換を可能にしますが、いくつかの観点で違いがあります。まず、パブリック・レンダリング・パラメーターの技術的な詳細および WebSphere Portal でのインプリメンテーションについて説明し、ポートレット通信に最も適した方法を選択するガイドラインを示します。
パブリック・レンダリング・パラメーターの使用
この記事の前半でも述べたように、プログラミングの観点では、パブリック・レンダリング・パラメーターは通常の (プライベート) レンダリング・パラメーターとほぼ同じように処理されます。ポートレットは、JSR 168 によってプライベート・レンダリング・パラメーター用に導入されたものと同じ API メソッドを使用して、このパラメーターの設定および読み取りができます。プログラマーから見た重要な違いは、パブリック・レンダリング・パラメーターは portlet.xml デプロイメント記述子で宣言され、それゆえにポートレットの外部インターフェースとなる点です。リスト 2 を参照してください。
リスト 2. 公開レンダリング・パラメーター
<public-render-parameter
xmlns:dm=”http://www.acme.com/portlets/doc-mgmt”>
<identifier>selected-doc</identifier>
<qname>dm:doc</qname>
</public-render-parameter>
|
この portlet.xml フラグメントでは、ポートレット・コードはポートレット固有の識別子「selected-doc」を持つレンダリング・パラメーターを使用し、このレンダリング・パラメーターは「http://www.acme.com/portlets/doc-mgmt:doc」というグローバル (および、固有) 名のもとで外部共有が可能であることが宣言されています。2 番目のポートレットがグローバル名「http://www.acme.com/portlets/doc-mgmt:doc」を持つ公開レンダリング・パラメーターを宣言すると (使用するポートレット固有の識別子にかかわらず)、このレンダリング・パラメーターの値を共有できるようになります。WebSphere Portal V6.1 は、portlet.xml で宣言されたネーム・スペースおよび QName を URL に格納するので、これらはできるだけ短くする必要があります。
WebSphere Portal V6.1 では、公開パラメーターの共有のために、2 つのポートレットをセットアップする管理タスクはまったく不要です。双方が同じグローバル名を使用するという事実だけで十分であり、2 つのポートレットを同じページに配置すると、ポートレット間で対話が開始されます。
実際には、コラボレーション機能は複数のページまたがって行われます。デフォルトでは、ポートレットによって設定されたすべての公開レンダリング・パラメーターは、グローバル・スコープに置かれます。これは、公開パラメーターを使用するポートレットと対話した後、異なるページにあり同じ公開パラメーターを使用する別のポートレットに切り替えられることを意味します。2 番目のポートレットを初めて表示するとき、そのポートレットは最初のポートレットから提供された情報を用いてただちにセットアップされます。このアプローチにより、たとえば、複数のポートレットが異なるページにあっても、顧客 ID などのグローバル・キーに関連する情報をすべてのポートレットが表示できる公開レンダリング・パラメーターは優れたツールといえます。すべてのポートレットでこのグローバル・キーを公開レンダリング・パラメーターとして扱うと、これらは自動的に調整されます。
公開レンダリング・パラメーターの共有スコープの制限
もちろん、このような種類のグローバル情報の共有が望まれないケースもあります。一般的な例としては、ナビゲーターとビューアーなど共同作業をしている2つのペアのポートレットが異なるページに存在している場合です。ページ 1 上のナビゲーターを使用して同じページ上にあるビューアーを制御しますが、他のページ上のビューアーには影響を与えたくありません。WebSphere Portal V6.1 では、公開レンダリング・パラメーターの共有スコープを 1 つのページに制限することにより、この動作を制御できます。これを行うには、そのページの「ページ・プロパティーの編集」に移動し、param.sharing.scope (「拡張オプション」-「パラメーターを設定する」にあります) を空でない値 (scope1 など) に設定します。このページに配置されたすべてのポートレットは、宣言済みのレンダリング・パラメーターに対し固有の共有値を使用するようになり、情報を共有できますが、他のページのポートレットには影響を与えません。図 4 を参照してください。
図 4. public.param.scope ページ設定
他のページのページ・プロパティーの編集で同じ値の scope1 を設定すると、そのページも同じ共有スコープの一部となります。一般に、次の条件が満たされる場合にのみ、2 つのポートレットは公開レンダリング・パラメーターの値を共有します。
- 2 つのポートレットが、portlet.xml デプロイメント記述子で同じグローバル名を持つパラメーターを宣言している
- 2 つのポートレットが、同じページ、または param.sharing.scope 設定に同じ値を持つページに配置されている。
最初に説明したグローバル共有スコープは、ページ設定が空という特殊なケースです。
公開レンダリング・パラメーターによる Web 動作のサポート
Java Portlet Specification 1.0 でのレンダリング・パラメーターの概念は、ポートレット自身の内部ナビゲーション状態に関する情報を格納できる API をポートレットに与え、ポータルはこの情報を URL に含めることができる、というものでした。この概念は、レンダリング・パラメーターによって、ポートレット内の期待されるユーザー動作をブラウザー操作 (たとえば、ブックマーク設定や「戻る」ボタンなど) 用に提供できることを意味します。ユーザー選択など、ポートレット内部のナビゲーション状態がレンダリング・パラメーターとして表されている場合は、ポータル・ページの各 URL はこの状態を正確に復元することができます。また、HTTP プロキシー・キャッシュは、URL に基づいて、同じポータル・ページの異なる状態を正しくキャッシュできます。
WebSphere Portal はバージョン 5.1 から、このような豊富な機能を持つブックマーク可能な URL をサポートしてきました。その結果、バージョン 6.1 では、公開レンダリング・パラメーターもこの URL 情報の一部となりました。たとえば、これらはポータル・ブックマークの一部として格納されます。実際に、WebSphere Portal 内の任意の URL に公開レンダリング・パラメーターを含めることができ、製品固有の URL 生成機能 (たとえば、UrlGeneration JSP タグなど) を使用して、ポートレット用の公開レンダリング・パラメーターを設定できます。
公開レンダリング・パラメーターとポートレット・イベントの比較
前述の説明からもわかるように、公開レンダリング・パラメーターはポートレット・イベントと比較して、より軽量な通信機能といえます。ユース・ケースに適したメカニズムを決める際に役立つように、それぞれの機能比較を以下のリストに示します。
公開レンダリング・パラメーターの特徴は、次のとおりです。
- 通常、明示的なコーディングは不要ですが、portlet.xml デプロイメント記述子の宣言は必要です。
- 単純なストリング値にのみ制限されています。
- セットアップするために、明示的な管理は必要ありません。
- ポートレット共有情報が増えても、パフォーマンスのオーバーヘッドは生じません。
- ブックマークへの移動など、URL の変更によって更新されます。
- ポータルのテーマとスキンでエンコードされたリンクから設定できます。
- 製品固有の API で作成され、あるポートレットから異なるページ上の別のポートレットへ移動するリンクに設定できます。
ポートレット・イベントの特徴は、次のとおりです。
- 送信および受信のために明示的なポートレット・コードが必要です。
- 複雑な情報を保持することができます。
- ポートレット間 (ページ上またはページ間、パブリックまたはプライベート) で異なる種類のワイヤーをセットアップすることで、詳細な制御が可能です。
- 異なる情報を使用したカスケードされた更新が可能です。たとえば、ポートレット A がイベント X をポートレット B に送信した後、ポートレット B が異なるイベント Y をポートレット C に送信できます。
- 通信リンク数が増えるにつれ、処理オーバーヘッドが増加します。
- 何らかの明示的なユーザー対話 (通常はポートレット内のアクション・リンクのクリック) によって開始する必要があり、ページに初めて移動するときのビューのセットアップには使用できません。
- 前のバージョンの WebSphere Portal によって提供された連携ポートレット通信機能と相互運用することができます。
どちらのメカニズムでも、データ交換とページ切り替えを結合することができます。前述のように、イベントの場合は、ページを切り替えるページ間のワイヤーを定義できます。公開レンダリング･パラメーターの場合は、あるポートレットで製品固有の API を使用して別のページ上の異なるポートレットへのリンクを生成し、そのターゲット用の公開レンダリング・パラメーターを設定できます。
もちろん、両方の手法を結合することもできます。たとえば、レンダリング・パラメーターを設定する処理イベントをポートレットで宣言し、同時にこのパラメーターをパブリックとして宣言すると、どちらの方法でもこの情報を受信できます。
上記の説明は、特定のユース・ケースに、どちらの機能がより適しているかを決める際に役立ちます。一般的なルールとしては、可能であれば公開レンダリング・パラメーターを使用し、レンダリング・パラメーターでは不十分なより複雑なケースに、ポートレット・イベントを使用します。
JSR 286 のその他の機能
これまで、JSR 286 で導入されたポートレットの調整機能について説明してきました。これは仕様における最も重要な新機能であるとともに、ポートレット間で情報を仲介する役割を持つポータル・インプリメンテーションに大きく依存する機能です。
ポートレット・フィルターなど、JSR 286 のその他のプログラミングの新機能は仕様によって詳細に定義され、特定のポータル・インプリメンテーションには依存しないため、WebSphere Portal の特定のトピックとしては説明しません。
次のセクションでは、WebSphere Portal V6.1 で JSR 286 ポートレットをプログラミングするときに役立つと思われる JSR 286 のいくつかの新機能について詳しく説明します。
リソース・サービス提供
リソース・サービス提供を使用すると、HTTP プロトコルのすべてを完全に制御できます。WebSphere Portal は、リソース応答で指定されたすべての応答プロパティーを HTTP ヘッダーとして書き出すため、提供するコンテンツの言語、コンテンツ・タイプ、その他の情報を制御できます。反面、通常のページ要求と比較して、ポータルは応答に対してデフォルトのヘッダー情報を提供しないため、リソースの提供中にすべての情報が明示的に設定されている必要があります。
WebSphere Portal は、仕様によって定義された異なるキャッシュ・レベルである PAGE、PORTLET、および FULL を実装します。前述したように、WebSphere Portal は、ページの完全なナビゲーション状態をエンコードするリッチ URL を使用します。デフォルトの PAGE キャッシュ範囲をともなうリソース URL には、ポータル内の他のコンポーネントに関する特定の情報が多数含まれていますが、多くの場合、リソース要求内ではこの情報は必要ありません。
リソース要求に HTTP キャッシュを利用したい場合は、リソース URL のキャッシュ範囲を最も高いレベル (最も少ない情報) に設定します。これは、リソース要求の処理、一貫した URL の生成、および HTTP キャッシュ範囲の改善を行うために実際に必要です。また、リソース要求をキャッシュ可能にするには、ポータルがキャッシュ・ヘッダーを生成できるように、応答にキャッシュ制御情報を明示的に設定する必要があります。通常のレンダリング要求とは異なり、portlet.xml デプロイメント記述子でのデフォルトのキャッシュ定義はリソース要求には適用されません。
Cookie の処理
JSR 286 では、Cookie プロパティーの読み取りと書き込みを行う API メソッドがポートレット要求および応答に追加されましたが、これらの Cookie の格納および処理方法は、ポータル・インプリメンテーションにゆだねられたままです。WebSphere Portal は、Cookie プロパティーを実際の HTTP Cookie に直接変換します。Cookie パスを明示的に指定しない場合、ポータルの URL コンテキストにはデフォルトが設定されるため、将来のポータル要求によってその Cookie が正しく受け取られますが、同じサーバー上にある別の Web アプリケーションによって受け取られることはありません。
Cookie はネーム・スペースに含まれないため、ポートレット間、または必要であれば他の Web アプリケーションとの間で Cookie を共有できます。このため、Cookie はポートレット間を調整する代替手法として機能させることもできます。ポートレットによって設定された新しい Cookie は、同じクライアント要求の以降のライフ・サイクル・フェーズですべてのポートレットから利用でき、クライアントが廃棄しない限り、以降の要求でも利用できます。
レンダリング・フェーズでの Cookie の設定は、現在 WebSphere Portal V6.1 ではサポートされていません。クライアント応答はレンダリング・フェーズですでにコミットされているので、これらの Cookie はクライアントには転送されず、以降の要求で失われます。
コンテナーのランタイム・オプション
コンテナーのランタイム・オプションにより、ポートレットはポータルおよびポートレット・コンテナーからの特定のランタイム動作を要求できます。WebSphere Portal V6.1 では、以下に示すコンテナーのランタイム・オプションがサポートされています。
- javax.portlet.escapeXml (JSR 286 で定義) は、JSP タグによって生成された URL のデフォルト XML エスケープを防止します。
- javax.portlet.actionScopedRequestAttributes (JSR 286 で定義) は、ポートレット要求の属性を要求境界全域にわたり保持します。
- com.ibm.portal.public.session (製品固有) は、ポートレットが正しく動作するためにセッションが必要であることを示します。このオプションは、ユーザーがログインしていない場合でも、ポートレットを含むページがアクセスされたときは常にセッション cookie を作成するようポータルに要求します。
これらのすべてのランタイム・オプションは、ポートレット仕様の概念では正しく実行されないコードのための対策ですが、WebSphere Portal ではサポートされています。後の 2 つのランタイム・オプションは、使用度の高いポータルでパフォーマンスの低下を招くおそれがあります。したがって、これらのランタイム・オプションの使用を避けるよう試み、これらを使わなくてもよい方法でコードを記述してください。
URL ストリーミングのサポート
URL 生成用の JSR 168 API では、URL オブジェクトをマークアップに書き出す前に、ポートレットは PortletURL.toString() メソッドを使用して、常に URL オブジェクトをストリングに変換する必要がありました。WebSphere Portal は機能豊富でかなりのサイズのURLになるため、このストリング変換は、多数の URL を生成するポートレットのパフォーマンスに悪影響を及ぼすことがあります。
しかし、JSR 286 では write() メソッドが追加され、URL オブジェクトを直接応答ライターにストリーミングすることが可能になり、一時的なストリング・オブジェクトが作成されなくなりました。URL の書き出しには、このメソッドを使用してください。toString() メソッドとは異なり、この write() メソッドは、XML および HTML 仕様によって求められている URL の正確な XML エスケープを自動的に提供します。同様の考え方が、JavaServer™ Pages のポートレット URL タグにも適用されます。生成した URL を一時的なストリング変数に格納するタグ構文よりも、URL を直接書き出すタグ構文の方が推奨されます。
制限
WebSphere Portal V6.1 は JSR 286 に完全に準拠した 1 つのインプリメンテーションであり、主要なすべての機能をサポートしますが、標準のオプション機能でサポートされていないものも若干あります。詳細については、WebSphere Portal の Information Center を参照してください。
リモート・ポートレットのサポート
Java Portlet API の最初のバージョンと同様に、JSR 286は、Web Services for Remote Portlets (WSRP) 標準を定義している OASIS 委員会との緊密な協力のもとで開発されました。その結果、プロトコルが異なるだけで、どちらの仕様もよく似ていて、同じプログラミング・モデルとなっています。JSR 286 では、ローカル・ポートレットが Java ベースのポータルと対話する方法が定義され、WSRP 2.0 では、リモート・ポートレットが SOAP ベースの Web サービスをサポートするポータルとの対話方法が定義されています。
WebSphere Portal V6.1 では、両方の仕様のサポートが組み合わせられています。その結果、JSR 286 の主なプログラミング機能 (特に、ポートレットの調整とリソース・サービス提供) は、リモート・ポートレットにも有効です。これにより、たとえば、JSR 286 ポートレットをあるポータル環境にデプロイし、そのポートレットを別のポータル環境から利用することが可能です。このポートレットは、あたかもローカルにインストールされているかのように動作し続けます。
まとめ
WebSphere Portal の新しいリリースは JSR 286 をサポートし、ポートレットのプログラミングをより強化する幅広い新機能を提供します。最も重要なのは、これらの新機能がポートレット間通信用に標準化されたさまざまなメカニズムをサポートしている点です。機能に対するいくつかの側面が、製品固有のインプリメンテーションを可能にするために、オープンな状態で意図的に残されています。特にポートレット間通信では、その割合が高くなっています。この仕様では、情報を交換するためのポートレットのプログラミング方法ついては明確に定義されていますが、ポータル環境でこの情報交換が実際に発生するタイミングや、情報交換を制御するためのポートレットの接続方法については定義されていません。
この記事の後半部分では、新しい標準に対する製品固有の特徴が WebSphere Portal V6.1 でどのように扱われているのか、また Click-to-Action や高度な URL の生成など、標準を凌ぐ製品機能と新たな特徴とをどのように統合するのかについて説明しました。前半部分と合わせてこの記事を読むことにより、新しいポートレット・プログラミング機能を新規ポータル・プロジェクトで活用するために必要なすべての情報が得られます。
ダウンロード | ファイル名 | サイズ | ダウンロード形式 |
|---|
| dummyOrders.war | 9KB | HTTP | | dummyCalendar.war | 11KB | HTTP |
参考文献
著者について  | | | Stefan Hepper is the responsible architect for the WebSphere Portal and Workplace programming model and public APIs. He co-led the Java Portlet Specification V1.0 (JSR 168) and is now leading the V2.0 (JSR 286) effort. Stefan received a Diploma of Computer Science from the University of Karlsruhe, Germany, and in 1998 he joined the IBM Böblingen Development Laboratory.
|
| | | Oliver Köth is the lead developer for the portlet container in WebSphere Portal and is responsible for the implementation of the Java Portlet Specification 2.0 in the product. He holds a Diplome of Computer Science from the University of Erlangen, Germany and has been working on IBM’s portal mission since 2001 in the IBM Böblingen Development Laboratory.
|
記事の評価
| 
