IBM WebSphere Application Server V6.1ポートレット・コンテナーの活用: 第4部: WebSphere Application ServerとWebSphere Portal間でのポートレットの移行

コンテンツ はじめに サンプルについて ポートレット・プログラミング・モデル 拡張プログラミング・モデル 移行時のテーマ まとめ ダウンロード リソース 筆者について（原文のまま） ご意見ご要望をお寄せ下さい

この連載記事では、IBM® WebSphere® Application Server V6.1で利用できるJSR 168ポートレット・コンテナーについて解説し、IBM WebSphere Portalとの使い方の違いを明らかにします。

第1部では、ポートレット・コンテナーについて紹介し、ポートレットのインストールおよびアクセス方法、URLアドレス可能度の使い方を説明しました。

第2部では、コンテナーの拡張機能の一部について説明しました。ウィンドウ・フレーム内でのポートレットのレンダリング、複数のポートレットの表示、デプロイされたポートレットに関する情報の取得、およびポートレットのデフォルトの動作の変更などの方法を取り上げました。

第3部では、パフォーマンス・モニターおよび測定手法を使用して、ポートレット・コンテナーでのパフォーマンスのボトルネックを分析する方法を説明しました。

第4部では、WebSphere Portalの拡張ポートレット・プログラミング・モデルとWebSphere Application Serverでのポートレットのサポートを比較し、2つの環境間でポートレットを移行する場合に、どのような変更が必要となるのかを明らかにします。サンプル・ポートレットをダウンロードし、両方のプラットフォームでデプロイおよび実行することができます。

この連載は、JavaポートレットAPIに習熟されているJava™プログラマー、ポートレット・プログラマー、およびWeb管理者の方を対象としています。これらのスキルを得るための情報については、「リソース」セクションのリンクを参照してください。

はじめに

今日では、ポータル開発者は、多彩で高度な機能をポータルで使用することに慣れています。これらのプラットフォームにおける2つの主要機能とは、ポートレット・プログラミング・モデルをサポートする拡張ポートレット・ランタイム環境と、ポートレットやページなどのポータル成果物を集約および管理する洗練されたポータル・フレームワークです。

WebSphere Portalは幅広い機能を提供します。その多くはポートレット・プログラミング・モデルをサポートし、拡張ポートレット・ランタイムを介してポートレットのエクスペリエンスの質を高めます。これに対し、WebSphere Application Server V6.1のポータル関連の機能セットはポートレット・ランタイムに重点を置き、最小限のポータル機能だけを提供します。

この記事では、2つの製品でのポートレット・ランタイムおよびポータル機能の違いを説明します。デプロイメント・ランタイムの機能を活用できるポートレットを開発するには、拡張プログラミング・モデルを理解することが必要です。各プラットフォームでモデルのどの部分がサポートされているのかを知ることにより、ランタイムでサポートされる機能セットが異なるケースで、適切に機能を低下させることが可能なポートレットを実装できます(2つのランタイム間でポートレットを移行する場合)。

上に戻る

サンプルについて

記事「Converting the WorldClock portlet from the IBM Portlet API to the JSR 168 portlet API」に含まれている世界時計のサンプル・コードは、WebSphere Portalでのみ動作するJSR 168ポートレットの良い例です。これは、標準ポートレットAPIを越える拡張ポータル・プログラミング・モデルに属するbidiタグを使用しています。詳細については、「WebSphere Portal InfoCenter」の「標準ポートレットのJSPタグ」トピックを参照してください。この拡張機能は単純な世界時計ポートレットでは必要ないため、適切な機能低下が推奨される場合の例としても用いられます。

この依存関係を削除するか、あるいは機能を適切に低下させるインテリジェントJavaクラスを追加し、ポートレットが他のプラットフォームでも動作するようにします。この連載に含まれる世界時計のサンプル・ポートレットは、どちらのプラットフォームでも動作するよう調整されています。

ポートレット・プログラミング・モデル

JSR 168ポートレット仕様をサポートするすべてのIBM製品は、同じテクノロジーに基づいています。しかし、ポータル・フレームワーク、および対応する環境によってもたらされるプラグ・ポイントに応じて、各製品は異なるテクノロジー層に組み込まれ、サポート済みの異なる拡張を提供します。

WebSphere PortalとWebSphere Application Serverは、それぞれのポータル・フレームワークによって提供される機能が異なります。WebSphere Application Serverが単一のポートレットを実行するためのポートレット・ランタイムに重点を置いているのに対し、WebSphere Portalは簡潔で洗練されたページ集約およびいくつかのバックエンド・システム(永続的な保存用のデータベースなど)への統合を管理する機能を完全にサポートします。

また、WebSphere Application Serverのプログラミング・モデルはポートレット・コンポーネントの使用を可能にしますが、WebSphere Portalは複合アプリケーションの使用を可能にします。これには、ビジネス・ユーザーが、リンクされたアプリケーションを簡単に作成およびカスタマイズしたり、コンポーネントを複合アプリケーションに加工することができる優れたアプリケーション・フレームワークが含まれています。

WebSphere Portalの拡張ポートレット・プログラミング・モデルとWebSphere Application ServerのポートレットAPIプログラミング・モデルの違いを理解するために、この記事では、JSR 168ポートレットをサポートするポータル機能を比較します。

WebSphere Application ServerでのURL (Uniform Resource Locator)アドレス可能度は、ポータル・フレームワークの最も単純な形です。アドレス可能度を使用すると、ページ上で1つのポートレットをレンダリングできます。これは、たいへん簡単に使用でき、開発に最も適しています。URLアドレス可能度を活用および拡張することで、ある程度ポータル集約をカスタマイズしたり、その機能を強化できます（連載の第2部の記事を参照してください）。

WebSphere Portalは、多数の拡張を持つ機能豊富なポータル・フレームワークを提供します。すべての機能を説明することはこの記事の範囲を超えています（「WebSphere Portal InfoCenter」を参照してください）。この記事では、ポートレット・プログラミング・モデルに関連する機能を取り上げ、WebSphere Application Serverと比較します。

比較する機能を表1に示します。この表には、それぞれの環境での各機能の動作、およびランタイムまたは移行時に、実行するポートレットの動作に与える影響の違いが示されています。

URL処理によるページ集約の取り扱い

WebSphere Portalのポータル・ページ集約フレームワークを使用すると、ページ上でポートレットを簡単に構築できるだけでなく、最も複雑なページ構造さえも扱いやすいタスクとなります。WebSphere Application Serverを使用すると、簡単に1つのポートレットをページ上に表示できるので、複数のポートレットおよびページを扱うために、特別な処理は何も必要ありません。しかしながら、このセクションで解決しなければならない課題がいくつか残っています。たとえば、ナビゲーション状態については、双方の環境で概念的にはほぼ同じですが、処理方法が少し異なります。

各ポートレットは、複数のポートレットURLを、同じページ上のポートレットを参照するマークアップ内でレンダリングできます。通常、これはcreateRenderURLまたはcreateActionURLを呼び出すことによって行います。

通常、ポートレットのナビゲーション状態の一部としてレンダリング・パラメーターをポートレットURLに追加する目的は、ポートレットへの特定のビューをブックマーク可能にし、「戻る」ボタンと「進む」ボタンの動作を有効にすることです。しかし、この動作はJSR 168ポートレット仕様によって強制されるものではありません。これらのパラメーターをポートレットURLに追加することにより、ユーザーはポートレットへの特定のビューのアドレスを直接指定できます。この利点は、URLの許容最大長によって制約されます。

ブックマークおよびアドレスの直接指定を有効にするには、ナビゲーション状態に関する情報を各URLに追加することをお勧めします。これには、(少なくとも)要求されたページ上にあるすべてのポートレットのすべてのレンダリング・パラメーターも含めます。容易に想像できるように、この種の情報を含むURLは非常に長くなる可能性があります。

ページ集約によって長いURLが作成されるリスクが大幅に高まるため、WebSphere Portalは種々の高度な機能(圧縮など)および他のストレージ(HttpSessionなど)を使用して、非常に長くなるURLを管理します。このため、WebSphere Portalによって作成されたすべてのURLは有効になりますが、必ずしもブックマーク可能であるとは限りません。URL処理を詳細に構成することより、その結果を変更できます。

WebSphere Application Serverは、WebSphere Portalとは異なり、URL処理を構成する高度な機能は提供しません。WebSphere Application Serverは、URLが非常に長くなる場合でも、すべてのレンダリング・パラメーターをポートレットURLに追加します。このため、WebSphere Application Serverに基づくポートレットによって作成されたすべてのURLはブックマーク可能ですが、その副作用として、長いまたは多数のレンダリング・パラメーターを使用するポートレットのURLが無効になるおそれがあります。しかし、このリスクは、ページごとに複数のポートレットを含む通常のポータル・フレームワークよりは低くなります。

一般に、無効なURLとなるリスクを低下させるために、ポートレットでのレンダリング・パラメーターの数とサイズをできるだけ最小限にするようお勧めします。パラメーターの取り扱いに違いがあるため、URLが非常に長くなる場合、WebSphere Portalで正しく機能するポートレットが、WebSphere Application Serverでは失敗するようなリスクもあります。

WebSphere Application Serverでは、ポートレットがブラウザーの制限に抵触し、長過ぎるURLによってエラーが発生する可能性があります。たとえば、ポートレットURLの長さが80,000文字の場合、Mozilla Firefoxではレンダリングされますが、Microsoft® Internet Explorerはこのような長いURLを参照するリンクには応答しません。

セキュリティー面でのユーザー管理

WebSphere Portalは、ユーザー管理および拡張されたセキュリティー概念を完全にサポートします。ポータルにログインするユーザーは、必要なアクセス権を持っているポートレットだけを表示および使用できます。ポートレットは、JSR168ポートレット仕様(PLT17)で定義されているユーザー情報プログラミング・モデルに従って、現在のユーザーに関する情報を取得できます。

WebSphere Portalのユーザー管理は、サード・パーティー製のユーザー管理システムを容易に統合できるWebSphere Member Manager (WMM)に基づいています。緊密なWMM統合により、ポートレットは次のようなデータに基づいて、ユーザーに関する詳細情報を要求できます。

• このバックエンドのユーザー管理システムで利用できる。
• ポートレットで利用できるユーザー情報属性名(JSR 168ポートレット仕様1.0、PLT.D)の1つにマッピングされている。
• さらに、JSR 168ポートレット仕様1.0に従って、ポートレット・デプロイメント記述子内で特定のポートレット用に構成されている。

WebSphere Application Serverは、Virtual Member Manager(VMM)と呼ばれるユーザー管理システムを提供します。この種の複雑な機能はポータル・フレームワーク全体に提供されることが必要なため、現在は、ポートレット・コンテナーとVMMは統合されていません。

ポートレットは、ユーザー情報を参照して、各ユーザーの特性に反応することができます。WebSphere Application Server内のポートレット・コンテナーは高度なユーザー管理にはアクセスできませんが、どちらのプラットフォームでも、ポートレットはPortletRequestでのgetRemoteUser()またはgetUserPrincipal()を介してユーザー情報を利用できます。ポートレットは、JSR168ポートレット仕様(PLT.11.1.6)で定義されているように、ポートレット・デプロイメント記述子内でのユーザーと役割のマッピングに従って、セキュリティー属性isUserInRoleにアクセスできます。

ポートレットおよびページ固有のアクセス制御管理に関し、WebSphere Portalはユーザー・アクションの制御を可能にする、わかりやすいセキュリティー管理を提供します。たとえば、十分なアクセス権を持つユーザーだけがポートレットの編集モードを使用して、ポートレット・プリファレンスをカスタマイズできます。

ポートレットは、サーブレットと同様にURLアドレス可能度を介してアドレスを指定できるので、WebSphere Application Server内でのポートレットのセキュリティー・モデルは、サーブレットのセキュリティー・モデルに準じます。サーブレットのセキュリティー・モデルは集約のシナリオを許容していないため、WebSphere Application Server内のポートレット・ランタイムはポートレットまたはページを扱うユーザー管理、つまりアクセス制御管理を提供しません。

ポートレットは、ポートレット・デプロイメント記述子で定義されたセキュリティー役割参照に基づいていない限り、両方のプラットフォームで動作します。現在、これらのセキュリティー役割参照は、WebSphere Application Serverでのみサポートされています。

まとめると、プログラミング・モデルの類似性により、ユーザー情報に基づいてどちらのプラットフォームでも動作するポートレットを作成できます。また、WebSphere Portalは、ユーザーによるポートレット呼び出しを管理する、ポートレットおよびページの洗練されたアクセス制御管理機能を提供します。

ポートレットのプリファレンスおよびモード

次に、ポートレットのプリファレンスとモードについて見ていきましょう。

プリファレンスは、ポートレットのモードに基づいて変更可能なレイヤーに保持されています。たとえば、ポートレット・デプロイメント記述子によって定義されたデフォルト・プリファレンスのレイヤーが1つあります。このレイヤーは、WebSphere PortalによってサポートされるCONFIGモード内で変更できます。WebSphere Application Serverでは、ポートレット・デプロイメント記述子の値は読み取り専用です。

WebSphere Portalには、ポータル管理者がポートレット・ウィンドウごとに異なるデフォルト値を指定できるもう1つのプリファレンス・レイヤーがあります。この機能はポートレット・モードEDIT_DEFAULTSを介してサポートされ、同じポートレット・ウィンドウを使用するすべてのユーザーに適用されます。WebSphere Application Serverには、このようなプリファレンス・レイヤーはありません。

どちらの製品も、標準モードであるVIEW、EDIT、およびHELPをサポートします。いずれかの標準モードにあるページでポートレットをカスタマイズするとき、ユーザーはユーザー個人のポートレット・プリファレンスを変更できます。ページ単位またはポートレット単位のデフォルト・プリファレンスは、どの標準モードでも設定できません。代わりに、カスタム・ポートレット・モードを使用する必要があります。

WebSphere Application Serverでは、エンド・ユーザーは任意のカスタム・ポートレット・モードでポートレットのメソッドを呼び出すことができます。カスタマイズされた集約フレームワークが動作を変更しない限り、標準ポートレット・モードだけが、JSR 168ポートレット仕様(PLT.A)による定義に従って、期待どおりに動作します。言い換えると、カスタム・モード内でポートレットを呼び出すときは、標準モード(VIEW、EDIT、およびHELP)と同じスコープですべてのプリファレンスが保存されます。このため、ポートレットはCONFIGモードまたはEDIT_DEFAULTSモード内で呼び出せますが、ポートレット・モードはプリファレンス・レイヤーでは効力を持ちません。したがって、デフォルトのどのプリファレンス値も変更できません。

まとめると、すべての標準ポートレット・モードは両方の製品でサポートされています。ページ単位またはポートレット単位のスコープでデフォルトのプリファレンス値を変更できるポートレット・モードEDIT_DEFAULTSおよびCONFIGは、IBM WebSphere Portalによってのみ完全にサポートされています。

ポートレット・フラグメントのキャッシュ

ポートレット・フラグメントのキャッシュは、WebSphere Application Serverの動的キャッシュ機能に基づいています。このため、WebSphere Application Serverで実行されているポートレットのキャッシュ・キーは、cachespec.xmlを使用して詳細に構成できます。詳細については、「WebSphere Application Server InfoCenter」のトピック「cachespec.xmlファイルによるキャッシュ可能オブジェクトの構成」(US)を参照してください。

一方、WebSphere Portalでは、ibm-portlet-portal-ext.xmiファイルを使用して制限付きの構成が可能です。現在、cachespec.xmlは、WebSphere Portalで実行されているポートレットには効力を持ちません。

WebSphere Portalでは、キャッシュ・コンテンツのスコープはデフォルトでユーザー単位となります。すべてのユーザーがリバース・プロキシーを使用して同じポートレット出力を共有するには、remote-cache-scope設定を共有するよう構成します。

<portlet href="RemoteCacheSettingsTestPortlet">
   …
    <remote-cache-scope>SHARED</remote-cache-scope>
   …
</portlet>

これは、sessionidをキーの一部として保持せず、cachespec.xml内でキャッシュ・キーを指定することに相当します。sessionidをキャッシュ・キーの一部として定義すると、ポートレットのコンテンツはユーザー単位でキャッシュされます。ポートレート・キャッシュのコンテンツを共有することは、WebSphere Application Serverで実行されているポートレットのデフォルトの動作なので、キャッシュされたコンテンツのスコープをユーザー単位にしたい場合、ポートレット開発者は明示的に指定する必要があります。

最初にWebSphere Portal(コンテンツはユーザー単位でキャッシュされます)で作成されたポートレットをApplication Serverに移行するケースを考えます。ユーザー・スコープのキャッシュをサポートするために、Application Serverの管理者はcachespec.xml内のキャッシュ・キーがsessionidを使用するよう指定する必要があります。

<cache-entry>
   <class>portlet</class>
    <name>/CacheTestPortlet</name>     
    <property name="consume-subfragments">true</property>
    <cache-id>
       <component id="" type="sessionId"/>
       <timeout>0</timeout>
    </cache-id>
</cache-entry>

共有キャッシュに対し、ポートレット・デプロイメント記述子で指定された期限付きキャッシュは、環境にかかわらず、キャッシュされたポートレット出力の有効期限を同じように構成します。

WebSphere Portalでは、Java Server Page(JSP)など、ポートレットに含まれるサブフラグメントは、ポートレットのコンテンツとしてキャッシュされます。これは、WebSphere Application Serverで実行されているポートレットに対し設定できます。サブフラグメントのキャッシュを有効にするには、cachespec.xmlでconsume-subfragmentsプロパティーをtrueに設定します。WebSphere Application Serverは、デフォルトではサブフラグメントをキャッシュしません。

<property name="consume-subfragments">true</property>

ポートレットのプログラミングの観点から、ポートレットはポートレット仕様(PLT.18.1)での定義に従ってキャッシュを構成できます。ポートレット・デプロイメント記述子では、期限付きキャッシュを定義できるとともに、あらかじめ定義されている応答プロパティーjavax.portlet.PortletResponse.EXPIRATION_CACHEを実行時に設定することで、ポートレットがプログラマチックにこの構成を変更できます。

どちらの環境でもポートレット・フラグメントのキャッシュを詳細に構成できますが、これらの拡張はポータルに固有のもので、WebSphere PortalとWebSphere Application Serverでは異なります。このため、キャッシュの構成では、環境に依存した個別の設定が部分的に必要となります。

まとめると、どちらの環境でも、ポートレット・デプロイメント記述子内でキャッシュ設定を指定できます。拡張キャッシュ設定はポータル固有です。これらの構成は、WebSphere Portalではibm-portlet-portal-ext.xmiファイルで行い、WebSphere Application Serverで実行されるポートレットについてはcachespec.xmlで行います。

上に戻る

拡張プログラミング・モデル

前のセクションでは、JSR 168ポートレット仕様を実装するポートレット環境での違いを説明しました。このセクションでは、JSR168ポートレット仕様に加えて提供されたすべての機能を内包する拡張プログラミング・モデルについて説明します。

WebSphere PortalとWebSphere Application Serverは、提供されたポートレット・ランタイムを取り巻く環境が異なっています。この環境は、ポータル・フレームワークまたはポータル・エンジンと呼ばれています。WebSphere PortalとWebSphere Application Serverの拡張プログラミング・モデルの違いを理解するために、それぞれのプラグ・ポイントおよびポートレット仕様ではカバーされていないポータル機能を比較してみましょう。

WebSphere Application Serverのプログラミング・モデル

この連載記事では、主に、WebSphere Application Server上で実行されているポートレットに提供されるプログラミング・モデルおよび拡張について説明してきました。ポートレットに提供されるWebSphere Application Serverの拡張機能の一部(Performance Monitoring Infrastructureや要求メトリックなど)については、第3部で取り上げました。

WebSphere Application Serverの他の機能は、ポートレット特有のニーズをサポートするために拡張されています。たとえば、URLアドレス指定が可能なポートレットに、リモート要求ディスパッチャーを使用することもできます。これは、ポートレットは異なるJVMで実行でき、リモート呼び出しを使用してインクルードできることを意味します。

このため、WebSphere Application Serverのプログラミング・モデルは、JSR168ポートレット仕様のすべての必須部分、およびこの連載で説明したプログラミング・モデル拡張によって成り立っています。

WebSpere Portalのプログラミング・モデル

WebSphere Portalは、ポートレットの標準化プログラミング・モデルに多数の拡張を提供しますが、このセクションではそのほんの一部だけを取り上げます。すべてを分析することは、この記事の範囲ではありません。

WebSphere Portalは、クリデンシャル・ボールトやコンテンツ・アクセス・サービスなどの機能を追加する、重要なポートレット・サービス群を提供します。ポートレット・サービスの概念により、ポートレットへのカスタムAPI拡張を使用して、ポートレット・プログラミング・モデルを拡張できます。また、ポートレット・プログラミング・モデルに機能を追加することもできます。

さらに、WebSphere Portalはポートレット・フレームワークのサポートも提供します。WebSphere Portalの完全な集約プラットフォームにより、複数のポートレット・フレームワークを1つのページ上に集約することが可能です。このため、ポートレット・フレームワークがサポートされ、モデル・ビュー・コントローラーによる適切な設計などのベスト・プラクティスに従うことができます。サポートされているポートレット・フレームワークの例として、Java Server Faces(JSF)フレームワークおよびStrutsがあります。

WebSphere Portalによって提供された、必須のJSR168ポートレット仕様を拡張する追加機能を表2、3、および4に示します。

これらのポータル拡張のいずれかを使用する場合は、機能が利用できない状況では適切に機能を低下させるようにしてください。ポートレット開発者がこのガイドラインに従っていれば、これらの拡張が利用できない場合でも、ポートレットをWebSphere Application Serverでも実行することができます。WebSphere Portalのポートレット・サービス拡張を使用する例を次のコード・スニペットに示します。

// check for extension availability
Object obj = null;
javax.naming.Context ctx = 
new javax.naming.InitialContext();
try {  
  obj = (Object) ctx.lookup("portletservice/com.mycomp.CalcService");
  } catch(javax.naming.NameNotFoundException nnfe) {
 ... error handling ...
 }
// service usage (best to move in own class)
if ( obj != null ) {
  PortletServiceHome psh = (PortletServiceHome) obj;
  CalcService service = (CalcService) psh.getService(CalcService.class);  
  service.calculate();
}

複数のポータル・プラットフォームで実行することを目的としたポートレットに提供される機能の範囲を広げるために、IBMはJavaポートレット仕様標準JSR 286の定義に貢献しています。WebSphere Portalにすでに存在する多数の有益な拡張は、より一般的な形で標準化される予定です。たとえば、ポートレットAPI 2.0のプロポーザルでは、ポートレット間通信およびポートレット・フィルター拡張を標準化します。

上に戻る

移行時のテーマ

WebSphere PortalとWebSphere Application Serverのポートレット・プログラミング・モデルおよび拡張を比較することにより、その違いと、移行時に予想される問題が明らかになりました。

一般に、ポートレット開発者は、ポータル固有の拡張に依存せずに開発する限り、そのポートレットはどちらのプラットフォームでも動作することに留意してください。この記事で取り上げた移行時のテーマを表5に示します。

上に戻る

まとめ

この第4部は、IBM WebSphere Application Serverでのポートレット・コンテナーに関する連載のまとめとなる記事です。

第4部では、IBM WebSphere Portal と IBM WebSphere Application Server間のポートレット・ランタイムの違いを説明しました。ポートレット・コンテナーは同じテクノロジーに基づいていますが、それぞれのポータル・フレームワークは目的および拡張の点で異なっています。

IBM WebSphere Portal と IBM WebSphere Application Serverの違いを理解することは、ポートレット・アプリケーションの移行の問題を解決するために役立ちます。双方のプログラミング・モデルの説明および比較を通じて、どちらの環境でも容易に使用できる機能について解説しました。拡張機能について理解すると、利用可能なプログラミング・モデル拡張に応じて実行方法を変更するポートレット・アプリケーションを実装できます。

この記事で説明した2つの製品を十分に理解することで、各製品を正しく使用し、デフォルトの状態でどちらのプラットフォームでも機能するポートレット・アプリケーションを作成できます。また、提供されている機能を十分に活用したり、機能を利用できない特定のランタイムでは、適切に機能を低下させることも可能です。

上に戻る

ダウンロード

	ダウンロード方法について(US)			Adobe® Reader®が必要

上に戻る

リソース

• Participate in the discussion forum(US) : ディスカッションフォーラムにご参加ください。
  
  
• All aritlces in this series(US) : WebSphereの技術資料はこちらからご覧いただけます。
  
  
• An early look at Java Portlet Specification V2.0 (JSR 286) (US) : Java Portlet Specification V2.0について、いち早くご覧いただけます。
  
  
• Best practices: Developing portlets using JSR 168 and WebSphere Portal V5.02(US) : JSR-168標準に適合したポートレットを設計・開発し、JSR 168のIBM WebSphere Portalインフラストラクチャーを活用するためのガイドです。
  
  
• Comparing the Java Portlet Specification JSR 168 with the IBM Portlet API (US) : Java Portlet Specification(JSR168)の基本や特徴についてと、Java™Standardization RequestとIBM Portlet APIの仕様の違いについてご覧いただけます。
  
  
• Configuring cacheable objects with the cachespec.xml file topic in the WebSphere Application Server InfoCenter(US) : WebSphere Application Server InfoCenterのトピック 「cachespec.xml ファイルによるキャッシュ可能オブジェクトの構成」 を参照してください。
  
  
• Converting the WorldClock portlet from the IBM Portlet API to the JSR 168 portlet API (US) : IBM portletを標準のportlet APIに変換する例をご覧いただけます。
  
  
• Exploiting the WebSphere Portal V5.1.0.1 programming model (US) : WebSphere Portal V5.1.0.1プログラミング・モデルをご活用いただけます。
  
  
• Java Portlet Specification V 1.0, JSR 168 : ポートレットAPIのための Java Community Processプロジェクトの定義をご覧いただけます。
  

  Java Portlet Specification V 1.0, JSR 168 (US)

  
  
• JSP tags for standard portlets topic in the WebSphere Portal InfoCenter.(US) : WebSphere Portal InfoCenterのトピック 「標準ポートレットのJSPタグ」についてご覧いただけます。
  
  
• Portlet development Workbook(US) : このワークブックは、Java標準ポートレットAPI (JSR168) を使用してポートレットを開発する方法を学ぶことができます。
  
  
• WebSphere Application Server Information Center(US)をご覧ください。
  
  
• WebSphere Application Server Zone(US)をご覧ください。
  
  
• WebSphere Portal product documentation, including the Information Center(US) : WebSphere PortalのInfoCenter、リリース・ノート、およびreadmeを含む現在あるすべての製品資料をご参照いただけます。
  
  
• WebSphere Portal zone(US) : ポータルとポートレットの開発に役立つ、幅広く多様な技術リソースを提供しています。
  
  
• What’s new in WebSphere Portal Version 6? (US) : IBM WebSphere Portal V6.0の新機能について説明しています。
  

上に戻る

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

		Birga Rick is Technical Lead for WebSphere Application Server Portlet Runtime at the IBM Boeblingen Lab in Germany. In 2003, she was part of the team implementing the JSR168 Reference Implementation, Pluto. Following her work on JSR 168 within the WebSphere Portal development team, she integrated the Portlet Runtime into WebSphere Portal and WebSphere Application Server.

		Stephan Hesmer is currently working as Performance Chief Developer. In his previous role he worked as Portlet Runtime architect in WebSphere Portal and WebSphere Application Server. He is responsible for integrating the JSR 168 portlet container into WebSphere Application Server. Stephan worked on the JSR 168 Java™ Portlet Specification, and designed and implemented the initial version of the JSR 168 Reference Implementation, Pluto. Stephan received a Diploma of Information Technology from the University of Cooperative Education Stuttgart, Germany, in 2000. After graduating, he joined the IBM Boblingen Development Laboratory to work in the WebSphere Portal Team.

上に戻る

上に戻る