IBM WebSphere Application Server V6.1ポートレット・コンテナーの活用: 第1部. ポートレット・コンテナーの紹介

コンテンツ はじめに Application Serverポートレット・コンテナーを使用すべき場合 サンプル・ポートレットについて ポートレット・コンテナーの機能のまとめ ポートレットのインストール ポートレットへのアクセスとアドレス指定 URLアドレス可能度について まとめ ダウンロード リソース 筆者について（原文のまま） アンケートにご協力ください

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

第1部では、ポートレット・コンテナーについて紹介します。特に、ポートレットのインストール方法、ポートレットへのアクセス方法、およびURLアドレス可能度(URLAddressability)の使用方法を取り上げます。サンプルのポートレットをダウンロードして使用することで、WebSphere Application Server V6.1ポートレット・コンテナーの特徴を知ることができます。

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

はじめに

JSR 168 Portlet APIは、ポートレット開発の標準として幅広く認知され、採用されています。JSR 168 Portlet APIをサポートするポートレット・コンテナーは、Plutoなどのオープン・ソース・プロジェクトやWebSphere Portalなどの企業向け製品で、長い間利用されてきました。JSR 168ポートレット・コンテナーはWebSphere Application Server V6.1における不可欠の要素であり、WebSphere PortalおよびWebSphere Application Server (以降Application Serverと表記します)の双方に共通するコンポーネントです。WebSphere Portalはポートレット・コンテナーを活用し、その機能を拡張しています。IBMはポートレット・コンテナーをアプリケーション・サーバーに提供することにより、Webアプリケーション用のサーバー・ユーザー・インターフェース(UI)のポートレット・プログラミング・モデルを推進しています。プログラマーは、任意のApplication Server環境を使用してポートレットを容易に作成できます。これらのポートレットは、WebSphere Portalで再利用可能です。

この記事では、Application ServerのJSR 168ポートレット・コンテナーについて紹介します。まず、コンテナーの機能の概要を示し、次に、最初のポートレットのインストールとアクセス方法を説明します。最後に、Application Serverでのポートレット・コンテナーの基盤の1つである、URLアドレス可能度(URL Addressability)と呼ばれる機能について解説します。また、これらの機能がWebSphere Portalの同様の機能とどのように対応するのかも明らかにします。

この連載記事はさまざまな読者を想定して書かれています。たとえば、Application Serverでポートレット・コンテナーを開発プラットフォームとして使用する予定で、開発用にWebSphere Portalのことをまだ知らない(または必要としない)開発者およびアーキテクトの方などです。また、すでにWebSphere Portalのスキルがあり、コンテナーをアプリケーション・サーバーに組み込むことによって、ポートレット開発がどのように容易になるかを理解したい開発者およびアーキテクトの方も対象としています。

上に戻る

Application Serverポートレット・コンテナーを使用すべき場合

Application Serverの新しいポートレット・コンテナーにより、次に示す2つのポートレット・コンテナーを使い分けることができます。

• Application Serverのポートレット・コンテナーは、JSR 168 Portlet APIなどの基本機能を提供します。
  
• WebSphere Portalのポートレット・コンテナーは、プロパティー・ブローカー・イベントやポートレット・サービス・イベントなどの機能を追加することにより、基本機能を拡張します。
  

このため、Application Server上で開発したポートレットは、WebSphere Portal上で動作します。この逆は必ずしも真ではなく、Application Serverのポートレット・コンテナーでサポートされていないWebSphere Portalの機能を使用して作成したポートレットは、Application Server上では動作しません。ただし、シームレスに機能を低下させる方法でコードを記述することはできます。

ポートレットはユーザーが直接操作するアプリケーションなので、プラットフォームで提供される機能にアプリケーションの要件が適合する場合は、Application Serverのポートレット・コンテナーを使用することが最適です。Application Serverでは、ユーザーとの接点となるコンポーネントをページ上で1つだけ表示し、多機能の集約を必要としなければ、ほとんどの場合、この方法が用いられます。一方、拡張されたプログラミング・モデルによる多機能の集約が必要な場合は、WebSphere Portalのポートレット・コンテナーを使用します。

上に戻る

サンプル・ポートレットについて

世界時計(World Clock)のサンプル・ポートレットをダウンロードし(US)、記事を読み進める際の参考にすることができます。サンプルの詳細については、記事『Converting the WorldClock portlet from the IBM Portlet API to the JSR 168 portlet API』を参照してください(「リソース」参照)。

上に戻る

ポートレット・コンテナーの機能のまとめ

このセクションでは、JSR 168ポートレット・コンテナーによって提供される機能を、3つの主なトピックであるアドレス可能度、管理性、および拡張性(より良いアクセシビリティーのため)に分類してまとめます。表1に、これらの説明と関連情報が記載されている連載記事の番号を示します。

上に戻る

ポートレットのインストール

JSR 168 Javaポートレット仕様は、ポートレット・アプリケーション・デプロイメント・パッケージをWebアプリケーションの1つの拡張として定義しています。これはWeb ARchive (WAR)ファイルとしてパッケージ化されているため、ユーザーの観点からは、ポートレットのインストールはサーブレットのインストールと同じことになります。

ポートレットは、管理コンソールまたはwsadminというスクリプト・インターフェースを使用してインストールできます。次のセクションで、world clockポートレットを例に取り、この2つの方法を説明します。

WebSphere管理コンソールの使用

1. WebSphere管理コンソールを開きます。たとえば、サーバーがローカルの場合は、ブラウザーで次のように入力して開きます。

   http://localhost:9060/ibm/console

   
   
2. ログインし、「Install New Application」セクションにアクセスします。
3. 図1に示すように、world clockポートレットへのパス名を入力します。
   
   図1. 管理コンソールの「Install New Application」セクション」
   
   
   
4. 「Install」ボタンのあるページが表示されるまで、各ページの「Next」ボタンをクリックします。
5. 「Install」ボタンをクリックします。サーブレットと同様に、デプロイメントは正常に進み、成功を示すメッセージが表示されて終了します。
6. 変更内容を保存します。
7. ブラウザーで次のように開いて、アプリケーションを起動します。

   http://localhost:9080/worldclock/StdWorldClock

   図2のようにポートレットが表示されます。
   
   図2. 表示モードのworld clockポートレット
   
   

ポートレットをデプロイするときの考慮事項

ポートレット・アプリケーションのWARファイルをデプロイするときは、次の点を考慮する必要があります。

• ポートレットとサーブレットは、同じ名前にすることはできません。これを避ける方法については、リスト1を参照してください。
  
  リスト1. 同じ名前を持つポートレットとサーブレット
  

  <servlet> <servlet-name>BookmarkPortlet</servlet-name> ... </servlet> <portlet> <portlet-name>BookmarkPortlet</portlet-name> ... </portlet>

  
  
• サーブレット・マッピングのURLパターンは、「 /<portlet-name>/* 」 または 「 /portlet/<portlet-name>/*. 」と同じにすることはできません。これを避ける方法については、リスト2を参照してください。
  
  リスト2. 同じマッピングを持つポートレットとサーブレット
  

  <servlet-mapping> <servlet-name>BookmarkPortlet</servlet-name> <url-pattern>/BookmarkPortlet/*</url-pattern> </servlet-mapping> <portlet> <portlet-name>BookmarkPortlet</portlet-name> ... </portlet>

  
  

スクリプト・インターフェース(wsadmin)の使用

もう1つの方法として、スクリプト・インターフェースのwsadminを使用してポートレットをインストールできます。

1. まず、wsadminを開始してサーバーに接続します。リスト3に示すメッセージが表示されます。
   
   リスト3. サーバーへの接続後に表示されるメッセージ
   

   C:\WebSphere\bin>wsadmin WASX7209I: Connected to process "server1" on node HESMERT40Node02 using SOAP connector; The type of process is: UnManagedProcess

   
   
2. コマンド・プロンプトで、リスト4に示すように、ポートレットをインストールするコマンドを入力します。
   重要： Windowsシステムであっても、常にスラッシュを使用してください。
   
   リスト4. ポートレットのインストール
   

   wsadmin> $AdminApp installInteractive D:/portlets/StdWorldClock.war {-contextroot /worldclock} ... ADMA5013I: Application StdWorldClock.war10af6ae88f7 installed successfully.

   
   
3. リスト5に示すように、構成を保存します。
   
   リスト5. 構成の保存
   

   wsadmin> $AdminConfig save

   
   ポートレットを表示するために、次のURLを使用してブラウザーでアプリケーションを開きます。
   http://localhost:9080/worldclock/StdWorldClock
   
   図2 のようにポートレットが表示されます。
   
   

ポートレット・コンテナーとWebSphere Portalの比較

WebSphere Portalでは、WebSphere Portal管理インターフェースまたはXMLAccessというスクリプト・インターフェースを使用して、同様の方法でポートレットをインストールできます。

管理インターフェースは、ポータルのさまざまなエリアに応じて、いくつかのセクションに分割されています。ポートレット・エリアを使用すると、ポートレットのあらゆるアスペクトを管理できます。これには、ポートレットのインストールに使用するManage WebModulesポートレットも含まれます。この機能を使用するには、WebSphere Portalで、「管理」->「ポートレット」->「Webモジュールの管理」を開きます。Application Serverとは異なり、ポータルの管理インターフェースはWARファイルのみ受け入れます。EARファイルは受け入れません。

また、スクリプト・インターフェースのXMLAccessを使用しても、ポートレットをWebSphere Portalにインストールできます。詳細については、「リソース」に掲載した「WebSphere Portal Information Center」を参照してください。XMLAccessを使用すると、デプロイ済みのEARファイルおよびWARファイルをインストールできます。

ポートレットをインストールした後は、ブラウザーを使用してポートレットにアクセスします。この方法は、ポートレットのインストールで非常に単純なURLを使用した例としてすでに説明しました。次のセクションでは、ポートレットのアドレス指定(addressing)について詳しく説明します。編集モードなど、ポートレットの特殊な機能についても取り上げます。

上に戻る

ポートレットへのアクセスとアドレス指定

JSR 168 Javaポートレット仕様では、サーブレット仕様にたいへんよく似た、対応するデプロイメント記述子を使用してJava APIが定義されています。サーブレット仕様では、URLマッピングとコンテキスト・ルートを使用してブラウザーからサーブレットにアクセスする方法が定義されています。これによって、ユーザーはサーブレットを表示することができます。

一方、ポートレットは集約された形式で実行され、応答またはビュー全体を消費しないように設計されています。つまり、ポートレットは常に他のポートレットと同じページを共有しています。これが、JSR 168 Javaポートレット仕様にポートレットへの直接アクセス(URLを使用する方法など)が含まれていない理由の1つです。その代わりとして、アクセスはポータル・アプリケーションとその集約フレームワークに任せられます。

Application Serverは、リソースへの簡単かつ直接のアクセスを提供し、迅速な開発を可能にする開発者プラットフォームです。ブラウザー内で直接ポートレットのアドレスを指定する新しい機能が導入されました。この機能をURLアドレス可能度と呼びます。

URLアドレス可能度は、JSR 168 Javaポートレット仕様で定義されたポートレットの概念を拡張し、ポートレットのURLマッピングという概念を追加します。

URLアドレス可能度がどのように機能するのかを詳しく調べるために、上記の例を考えてみましょう。ブラウザーのアドレス・バーに次の行を入力することにより、world clockポートレットにアクセスできます。

http://localhost:9080/worldclock/StdWorldClock

これは、ホスト名、ポート、コンテキスト・ルート、およびパスを持つ標準的なURLです。ポートレットはWARファイルにパッケージ化されているため、他のサーブレットのWARファイルと同様のコンテキスト・ルート(この場合は/worldclock)を使用してデプロイしました。URLのパスは、ポートレット・デプロイメント記述子(portlet.xmlファイル)で定義されたポートレット名をベースとしています。この例では、ポートレット名はStdWorldClockです。リスト6に、対応するportlet.xmlの一部を示します。

<portlet>
	<portlet-name>StdWorldClock</portlet-name>
	...
</portlet>

これがどのように機能するのかを具体的な例で確認したので、システムにインストールされた各ポートレットにアクセスできる汎用パターンを見ることにします。

次のURLパターンは、ポートレットを表示モードでレンダリングする最も基本的なURLアドレス可能度の定義です。

WebSphere Portalとの比較

現在、ポートレットのアドレス指定は、WebSphere PortalとApplication Serverの間で大きく異なっています。

WebSphere Portalでは、URLを介してポートレットに直接アクセスすることはできません。最初に、ポートレットをページ上に配置する必要があります。デプロイメント後、ページ・カスタマイザーを使用して、既存のページまたは新規作成したページにポートレットを配置しなければなりません。これにより、Portlet State APIなどのプログラマチックな方法を介して、ポートレットに直接アクセスできるようになります。

Application Serverでは、URLアドレス可能度を使用することで、より簡単にポートレットのアドレスを指定できます。ポートレットは、インストールの直後から利用できます。その反面、集約機能は不足しています。WebSphere Portalでは、ページ・レイアウトの動的変更、詳細なアクセス制御、ルールに基づく集約など、より多くの集約機能をポートレットに適用できます。

ポートレットのアドレス指定の基本がわかったので、URLアドレス可能度の詳細を見ることにしましょう。異なるポートレット・モードまたはウィンドウ状態でポートレットを呼び出す方法、およびこの状況で、ポートレットのプリファレンスがどこに保存されているのかを説明します。

上に戻る

URLアドレス可能度について

URLアドレス可能度は、既存のHTTPおよびサーブレット機能へのポートレット機能のマッピングと考えられます。ウィンドウ識別子、アクション・フラグ、ポートレット・モード、ウィンドウ状態、およびレンダリング・パラメーターはURLパターンを介して定義されます。ポートレットのプリファレンスは、ブラウザーのCookieにマッピングされます。このセクションでは、この2つを詳細に説明します。

まず、URLアドレス可能度のすべての機能セットを取り上げます。これは、汎用URLパターンです。

http://<host>:<port>/<context>/<portlet-name> 
   [/portletwindow[/ver [/action] [/mode] [/state] [rparam]]]

ここでは、読者がすでに基本的なアドレス指定(パターンの最初の部分)に習熟しているものとして説明します。

• 複数のポートレットが1つのページに表示された直後から有効になるportletwindow識別子を指定できます。portletwindowには任意の文字列を含められます。
• 現在はバージョン1.0のみサポートされているので、versionは常に1となります(ver=1.0)。
• actionフラグは、ポートレット・アクションをトリガーするかどうかを定義します。これは、追加パラメーターなしでURL内に表示されます。たとえば、次のようなURLになります。 http://localhost:9080/somecontext/MyPortletName/MyWindowIdentifier/ver=1.0/action
• modeおよびstateは、アドレス指定されたポートレットのポートレット・モードとウィンドウ状態をそれぞれ定義します。どちらのパラメーターも、mode=<mode>またはstate=<state>という書式で記述します。
• レンダリング・パラメーター(rparam)は、URL内でrparam=<name>=<value>として表されます。rparamは必要な数だけコーディングできます(/rparam=hello=world/rparam=hello2=world2)。
• パラメーターの順番は上記に示したURLパターンで定義されており、変更することはできません。
  

前のセクションでは、表示モードでworld clockポートレットにアクセスする方法を見てきました。

上記で説明した構文に沿ったURLを使用して、編集モードでアクセスしたポートレットを図3に示します。

編集モードでは、ポートレットのプリファレンスを使用してポートレットをパーソナライズすることができます。URLアドレス可能度は、ウィンドウ識別子に基づくスコープを持つCookieにポートレットのプリファレンスを格納するため、Cookieをサポートする任意のHTTPクライアントを使用してプリファレンスを保存できます。プリファレンスCookieの詳細については、「WebSphere Application Server Information Center」を参照してください(「リソース」参照)。

ユーザーが表示モードに戻ると、world clockポートレットは図4のようになります。

上に戻る

まとめ

連載の第1部では、Application Serverでのポートレット・コンテナーの概要を簡単に紹介しました。ポートレット・コンテナーで利用できる機能セットをまとめ、各機能がどの記事に記載されているかを示しました。また、ポートレットをインストールする2つの方法と、Application Server内のポートレットにアクセスする方法を説明しました。さらに、WebSphere Portalで同様のタスクを実行する方法にも触れました。最後に、URLアドレス可能度について詳しく解説しました。Application ServerでURLアドレス可能度を使用すると、URLを介してポートレットのアドレス指定ができます。URLアドレス可能度のデモンストレーションによって、たいへん簡単な方法でポートレットをレンダリングおよび開発できることがおわかりいただけたと思います。

第2部では、Application ServerでのJSR 168ポートレット・コンテナーの高度な機能について解説します。複数のポートレットを1つのページ上に集約する方法、過去にデプロイされたポートレットに関する情報を取得する方法、ポートレットのデフォルトの動作を変更する方法などを取り上げます。

上に戻る

ダウンロード

説明	ファイル名	サイズ	ダウンロード方法
World clock portlet	StdWorldClock.war	75 KB	FTP(US)|HTTP(US)

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

上に戻る

リソース

• Participate in the discussion forum (US) : ディスカッションフォーラムにご参加ください。
  
  
• 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の仕様の違いについてご覧いただけます。
  
  
• Converting the WorldClock portlet from the IBM Portlet API to the JSR 168 portlet API (US) : IBM portletを標準のportlet APIに変換する例をご覧いただけます。
  
  
• Java Portlet Specification V 1.0, JSR 168 : ポートレットAPIのための Java Community Processプロジェクトの定義をご覧いただけます。
  

  Java Portlet Specification V 1.0, JSR 168 (US)

  
  
• Pluto : Apache Pluto projectの情報
  

  Pluto (US)

  
  
• Portlet development guide(US) : WebSphere Portal製品ドキュメント、WebSphere Portalの全てのリリースのInfoCenter、リリース・ノート、Readmeを含めた最新の製品ドキュメントへのアクセスを提供しています。
  
  
• 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) : ポータルとポートレットの開発に役立つ、幅広く多様な技術リソースを提供しています。

上に戻る

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

		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.

		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.

上に戻る

上に戻る