Stephan Hesmer , Performance Chief Developer, IBMBirga Rick , Portlet Runtime Technical Lead, IBM原文はこちら
この連載記事では、IBM® WebSphere® Application Server V6.1で利用できるJSR 168ポートレット・コンテナーについて解説し、IBM WebSphere Portalとの使い方の違いを明らかにします。
第1部 では、ポートレット・コンテナーについて紹介し、ポートレットのインストールおよびアクセス方法、URLアドレス可能度(URLAddressability)の使い方を説明しました。
第2部 では、コンテナーの拡張機能の一部について説明しました。ウィンドウ・フレーム内でのポートレットのレンダリング、複数のポートレットの表示、デプロイされたポートレットに関する情報の取得、およびポートレットのデフォルトの動作の変更などの方法を取り上げました。
この第3部では、WebSphere Application ServerでJSR 168ポートレット・コンテナーを管理する方法を説明します。また、ポートレットのキャッシュ機能の構成と使用方法、パフォーマンス・メトリック、および拡張デプロイメント記述子についても説明します。WebSphere Application Server V6.1ポートレット・コンテナーの多数の機能を含み、連載の内容にも即したサンプル・コードをダウンロード できます。
この連載は、Java Portlet APIに習熟されているJava™ プログラマー、ポートレット・プログラマー、およびWeb管理者の方を対象としています。これらのスキルを得るための情報については、「リソース 」セクションのリンクを参照してください。
はじめに
IBM WebSphere Application Server V6.1は、スクリプト・インターフェース(wsadmin)、MBean 、パフォーマンス・メトリックなどをサポートし、豊富な機能を持つシステム管理用のフレームワークを提供します。WebSphere Application Serverのポートレット・コンテナーはこのフレームワーク内に組み込まれていて、他のWebSphereコンポーネントに用いるのと同じ標準的な手法で管理できます。
この記事では、ポートレット・コンテナーおよびインストールされたポートレットの管理方法について解説します。まず、拡張ポートレット・デプロイメント記述子の機能について調べ、スクリプト・インターフェースを使用してこれを変更する方法を説明します。次に、ポートレット・コンテナーおよび個々のポートレットのキャッシュ機能に進みます。ここでは、cachespec.xmlなどを使用してポートレット固有のキャッシュ値を構成する方法も取り上げます。最後に、パフォーマンスに関する手法と、それを有効にして使用する方法を説明します。この記事全体を通じて、説明した各機能をWebSphere Portalの同様の機能と比較し、その違いを明らかにするとともに、双方の製品で同じ結果を得るための方法を示します。
この記事は、WebSphere Application Serverでポートレット・コンテナーを開発プラットフォームとして使用したいが、WebSphere Portalについては知らない開発者およびアーキテクトの方を対象としています。また、すでにWebSphere Portalのスキルがあり、コンテナーを利用することで、ポートレット開発がどのように容易になるかを理解したい開発者およびアーキテクトの方も対象としています。
サンプルについて
世界時計サンプルのサンプル・コードをダウンロード すると、記事を読み進める際の参考になります。
キャッシュ
キャッシュは、システムのパフォーマンスを向上させる重要な手法です。WebSphere Application ServerでのポートレットおよびWebコンテナーは、どちらもサーバーサイド・キャッシュをサポートします。サーバーサイド・キャッシュを使用すると、サーブレットまたはポートレットのコンテンツはサーバー上のローカル・キャッシュに保存され、以降の要求でサーブレットまたはポートレットを実行する必要がありません。
ポートレットのフラグメントにはページ全体を指し示すリンクが含まれているので、ポートレットのキャッシュはサーブレットのキャッシュよりも複雑になります。しかし、キャッシュ可能なフラグメントにするには、スコープがフラグメント内の成果物だけをフラグメントに含める必要があります。ポータル・フレームワークの課題は、フラグメント外の成果物に依存しないでフラグメントのみをキャッシュすることです。
WebSphere Portalでは、その集約フレームワークを使用して、フラグメントは後で組み立てられます。WebSphere Application Serverのポートレット・コンテナーも、このような複雑さを処理します。つまり、フラグメントとは異なるスコープを持つコンテンツを除外し、キャッシュされたコンテンツが再び要求されたときに、完全なコンテンツを再組み立てします。
このセクションでは、管理コンソールまたはスクリプト・インターフェースを使用して、ポートレット・フラグメントのキャッシュをオンにする方法について説明します。また、このセクションの後半では、キャッシュ・インフラストラクチャーのデモンストレーションとして、サンプル・ポートレットを使用して、WebSphere Application Serverのキャッシュ・モニターの使い方を説明します。
管理コンソールの使用
WebSphere管理コンソールを開きます。たとえば、サーバーがローカルの場合は、ブラウザーで「http://localhost:9060/ibm/console」と入力して開きます。
ログインし、使用するサーバー(たとえば、server1 )、「ポートレット・コンテナー」の順に選択します。
図1に示すように、ポートレット・フラグメントのキャッシュを有効にするチェック・ボックスを選択します。
キャッシュを有効にするために、サーバーを再起動します。
図1. 管理コンソールでのポートレット・フラグメントのキャッシュの有効化 スクリプト・インターフェースの使用
もう1つの方法として、スクリプト・インターフェースのwsadminを使用して、ポートレット・フラグメントのキャッシュを有効にできます。
まず、wsadminを開始してサーバーに接続します。次のメッセージが表示されます。
コマンド・プロンプトで、ポートレット・フラグメントのキャッシュを有効にする次のコマンドを入力します。重要 ： Windowsシステムであっても、常にスラッシュを使用してください。
wsadmin>set server [$AdminConfig getid /Server:server1/]
構成を保存します。 キャッシュを有効にするために、サーバーを再起動します。
キャッシュ・モニターの使用
WebSphere Application Serverは、キャッシュ・モニター・アプリケーションをバイナリーとともに提供しています。このアプリケーションを使用すると、システム管理者および開発者は、システム内で使用されているキャッシュをより詳細に調べることができます。キャッシュ・サイズ、使用済みエントリー、キャッシュ・ヒット、キャッシュ・ミスなど多くの統計によって、使用パターンの概要を明確に把握できます。
前のセクションでは、ポートレット・フラグメントのキャッシュを有効にする方法を説明しました。これがどのように機能するのかを知るために、以降の例で使用する2つのアプリケーションをインストールします。インストールするのは次の2つです。
StdWorldClockCache.warは、この記事でダウンロード できます。
<WAS-HOME>/installableAppsディレクトリーにあるCacheMonitor.earをインストールします。
サンプル・アプリケーションのStdWorldClockCache.warは、一般的なポートレット・アプリケーションとは異なります。このポートレットには、portlet.xmlに追加要素が含まれるとともに、cachespec.xmlファイルも含まれています。
portlet.xml内では、オプションの要素expiration-cacheがパフォーマンスの改善を支援します。expiration-cache要素は、キャッシュがポートレット・フラグメントを「新鮮」であるとみなす期間(秒)を指定します。フラグメントが新鮮とみなされる間は、フラグメントはキャッシュから返されます。それ以外の場合は、ポートレットを再び呼び出し、新しいフラグメントを取得します。
次のスニペットは、expiration-cache要素およびportlet.xmlでのその記述場所を示します。
<portlet-name>StdWorldClock</portlet-name>
<portlet-class>com.ibm.wps.portlets.worldclock.WorldClockController</portlet-class>
<expiration-cache>130</expiration-cache>
<supports>
2番目のキャッシュ・コンポーネントはcachespec.xmlです。これは、WebSphere Application Serverに特有のファイルで、WebSphere Portalでは使用されません。WebSphere Application Serverのバージョン6.1では、キャッシュを有効にするために、このファイルをWEB-INFディレクトリーに配置する必要があります。このファイルが利用できないと、ポートレット・フラグメントはキャッシュされません。
portlet.xmlでのキャッシュ期間の指定に加え、cachespec.xmlファイルを使用すると、指定されたポートレットに追加のキャッシュ設定(たとえば、ポートレット・モードによるキャッシュなど)を定義できます。詳細については、「WebSphere Application Server Information Center 」を参照してください。
次のスニペットは、簡単なcachespec.xmlを示します。このxmlファイルで使用される特定の要素の詳細については、「WebSphere Application Server Information Center 」を参照してください。
<cache>
<cache-entry>
<class>portlet</class>
<name>StdWorldClock</name>
<property name="consume-subfragments">true</property>
<cache-id/>
</cache-entry></cache>
2つのアプリケーションを正しくインストールし、起動した後は、キャッシュ・モニターを使用して、世界時計ポートレットの統計を見ることができます。
キャッシュ・モニターのWebインターフェースを開きます。たとえば、サーバーがローカルの場合は、ブラウザーで「http://localhost:9060/cachmonitor」と入力して開きます。
左側で「キャッシュ統計 」を選択します。図2に示すウィンドウが表示されます。図2. 選択されたキャッシュのキャッシュ統計を表示するキャッシュ・モニター・アプリケーション
次に、ブラウザーで「http://localhost:9080/worldclock/StdWorldClock」というURLを開くことにより、世界時計ポートレットにアクセスします。 結果の画面表示のクリップを図3に示します。スクリーン・ショットに表示されている時刻を記録してください。後で別のデータと比較するときに、この時刻が必要になります。図3. 現在の時刻を表示する世界時計ポートレットのクリップ
キャッシュ・モニターに切り替えます。図4に示すように、新しいキャッシュ統計が表示されます。ポートレットには1度しかアクセスしていないので、「キャッシュ・ミス」となります。これで、フラグメントがキャッシュに取り込まれ、以降の要求に応える準備が整いました。図4. ポートレットに最初にアクセスした後の新しいキャッシュ統計
それでは、世界時計ポートレットに戻り、ブラウザー・ウィンドウで「再ロード 」をクリックします。この操作は130秒以内に行う必要があります。この秒数を超えると、キャッシュが期限切れとなります。キャッシュが機能したかどうかを調べるために、マークアップに表示されているタイム・スタンプを見ます。この時刻は、前に表示された時刻と同じはずです。
もう一度、キャッシュ・モニターに切り替えます。図5に示すように、新しいキャッシュ統計が表示されます。130秒以内にポートレットにアクセスしたので、システムは有効なキャッシュ・エントリー(キャッシュ・ヒット)を維持していて、ポートレットのフラグメントをキャッシュから取り出して提供します。図5. ポートレットに2回目にアクセスした後の新しいキャッシュ統計 図6. 130秒以内に2回ポートレットにアクセスしたときの新しいキャッシュ統計
130秒経過した後で、世界時計ポートレットに戻り、ブラウザー・ウィンドウで「再ロード 」をクリックします。今回、キャッシュはすでに新鮮な状態でないため、ポートレットを再びレンダリングしなければなりません。図7に示すように、新しいタイム・スタンプがレンダリングされます。また、図8に示すように、新しい「キャッシュ・ミス」が表示されます。図7. 新たな現在の時刻を表示する世界時計ポートレットのクリップ 図8.130秒経過後に複数回ポートレットにアクセスしたときの新しいキャッシュ統計
WebSphere Portalとの比較
WebSphere Application ServerおよびWebSphere Portalのどちらにも、ポートレット・フラグメントのキャッシュ機能があります。どちらの環境も、通常は複数のポートレットが1つのページに集約される事実を考慮し、上記で説明した特殊な対策を講じています。WebSphere Application Serverでのcachespec.xmlを介した拡張キャッシュID生成は、WebSphere Portalではまだ利用できません。WebSphere Portalに組み込まれているキャッシュID生成は、現状では、開発者またはポートレットによって変更することはできません。一方、WebSphere Portalは、豊富な機能を持つ、ページ・レベルのキャッシュ機能をサポートします。この機能では、集約フレームワークはページ上の各フラグメントのキャッシュ設定(たとえば、有効期間など)を考慮し、この情報をページ・キャッシュ設定として集約します。この結果、ページをリバース・プロキシーにキャッシュすることができ、ブラウザーは可能な限り長い時間キャッシュします。
トピック WebSphere Application Server WebSphere Portal
ポートレット・フラグメントのキャッシュ
可能。
可能。
キャッシュIDの生成
開発者によってカスタマイズ可能。
カスタマイズできません。
ページ・レベルのキャッシュ
利用できません。ポートレット・コンテナー上で開発できます。
デフォルトで利用可能です。
Performance Monitoring Infrastructure
システムのパフォーマンスの問題は、解決するのが非常に困難なことがしばしばあります。多くの場合、システムの測定値(たとえば、応答時間や潜在的なエラーなど)を解析することでのみソリューションを得られます。Performance Monitoring Infrastructure (PMI)は、まさにこのような状況で役に立つ、WebSphere Application Server内のたいへん便利なツールです。このツールを使用すると、さまざまなパフォーマンス・メトリックを取得し、長期間の監視によってパフォーマンスの問題点を発見できます。
ポートレット・コンテナーでは、サーブレット・メトリックにたいへんよく似た追加のパフォーマンス・メトリックがいくつか提供されます。これには次のものがあります。
ポートレット要求の数
カレントのポートレット要求の数
ポートレットのレンダリング要求の応答時間
ポートレットのアクション要求の応答時間
ポートレット・エラーの数
メトリックとその意味については、「WebSphere Application Server Information Center 」を参照してください。
管理コンソールまたはスクリプト・インターフェースを使用することにより、PMIを有効にし、活用することができます。サンプル・ポートレットを使用して、PMIの使い方を見ていきましょう。
管理コンソールの使用
WebSphere管理コンソールを開きます。たとえば、サーバーがローカルの場合は、ブラウザーで「http://localhost:9060/ibm/console」と入力して開きます。 ログインし、「モニターおよびチューニング 」->「Performance Monitoring Infrastructure (PMI) 」を選択し、使用するサーバーを選択します。この例では、server1 を選択します。.
次に、「Performance Monitoring Infrastructure (PMI)を使用可能にする」のチェック・ボックスがまだ選択されていない場合はこれを選択し、サーバーを再起動してPMIを有効にします。
PMIを有効にした後で、ポートレット・メトリックを有効にできます。ここでは、図9に示すように、「ランタイム」タブでその操作をします。つまり、情報は永続的には保存されておらず、サーバーの再起動後に失われることを意味します。これは、今後のサービス・リリースで修正される予定です。図9. 「ランタイム」タブでのみ実行可能な管理コンソールでのポートレット・メトリックの有効化
「ランタイム 」タブで、より詳細に制御するために「カスタム 」を選択します。これにより、有効にする統計を個別に選択できます。
「カスタム・モニター・レベル 」ページで、有効にするメトリックを選択します。「状況 」列に、メトリックが有効かどうかが示されます。ポートレットのすべてのメトリックを有効にした状態を図10に示します。図10. 有効になっているすべてのポートレット・メトリック
これで、Performance Viewerを使用できるようになりました。「モニターおよびチューニング 」->「Performance Viewer 」->「現在のアクティビティー 」を選択し、使用するサーバー(たとえば、server1 )を選択します。
2つのフレームを持つウィンドウが表示されます。左側のツリーでは、別のレポートおよびモジュールに移動できます。ポートレット・メトリックを測定および監視するには、最初に、どのポートレットに関心があるのかをPMIに伝える必要があります。したがって、ツリーで「パフォーマンス・モジュール 」->「Webアプリケーション 」を選択します。「Webアプリケーション 」の下に、ポートレットを含むインストール済みのWebアプリケーションが表示されます。モニターする任意のポートレットを選択します。図11に示したサンプルでは、世界時計ポートレットがモニターされるよう選択されています。図11. 標準の世界時計ポートレットのために有効にされたパフォーマンス・モジュール
Performance Viewerで表示されたメトリックを見ることができます。(表示されていない場合は、画面一番上の「モジュールの表示 」をクリックします。)図12に示すように、Performance Viewerの右側のフレームに、グラフと表が表示されます。実際の値を表示するには、別のブラウザー・ウィンドウを開き、モニターされたポートレットを操作します。図12. ポートレット・メトリックの現在の測定値を表示するPerformance Viewer
WebSphere Portalとの比較
ポータルのセットアップおよび環境は非常に複雑であるため、WebSphere Portalはパフォーマンスのモニター、レポート、および診断を IBM Tivoli Composite Application Management (ITCAM) for WebSphere など他の製品に依存しています。これには、WebSphere Application ServerおよびWebSphere Portalの特定のモニター機能も含まれます。
単純かつ簡単で、すぐに使用できるモニター・インフラストラクチャーを提供するWebSphere Application Serverに比較し、Tivoli Composite Application Managementは高度な機能を持ち、より多くのパフォーマンス・メトリック、レポート、およびシステムの診断方法をサポートします。
要求メトリック
要求メトリック(Request Metrics)は、WebSphere Application ServerのPerformance Monitoring Infrastructure (PMI)と類似する測定および診断ツールです。このツールは、アプリケーション応答測定(ARM)に基づき、単一の要求を詳細に分析することを支援します。PMIを使用すると、異なるシステム・エンティティー(たとえば、サーブレットまたはポートレット)を診断およびモニターすることができます。要求メトリック・ツールは、単一の要求の詳細なデータを提供し、その要求がシステム内の関連するコンポーネントをどのように経由してきたのかを示します。要求がシステム内を移動するのにともない、要求メトリック・ツールは、各コンポーネントの応答時間と特定の属性を記録します。これにより、要求の間に、特定のコンポーネントが行った処理および経過時間の概要を明確に把握できます。メトリックとその意味の詳細については、「WebSphere Application Server Information Center 」を参照してください。
それでは、管理コンソールおよびスクリプト・インターフェースを使用して、要求メトリック・ツールを有効にし、活用する方法を見ていきましょう。ここでは、サンプル・ポートレットを使用して、要求メトリックの使い方を説明します。
管理コンソールの使用
WebSphere管理コンソールを開きます。
ログインし、「モニターおよびチューニング 」->「要求メトリック(PMI) 」を選択します。
「要求メトリックを使用可能にする」のチェック・ボックスがオンになっていない場合はこれを選択し、サーバーを再起動して要求メトリック・ツールを有効にします。
要求メトリックを有効にした後、ポートレット・メトリックを有効にするために、「カスタム 」->「ポートレット 」を選択します。「要求メトリックの宛先」で「標準ログ 」を選択し、メトリックを簡単に見られるようにします。
図13. 管理コンソールでのポートレット・メトリックの有効化 標準ログでいくつかの要求メトリックを見るために、もう一度世界時計ポートレットを使用します。次のリストは、世界時計ポートレットのポートレットactionメソッドとrenderメソッドを実行した後の要求メトリック・ログの該当する部分を示します。
SRVE0180I: [StdWorldClock_war#StdWorldClock.war] [/worldclock] [Servlet.LOG]:
WorldClockController(processAction): entering processAction()...
SRVE0180I: [StdWorldClock_war#StdWorldClock.war] [/worldclock] [Servlet.LOG]:
WorldClockController(processAction): saving changes ...
PMRM0003I: parent:ver=1,ip=192.168.0.102,time=1148825019859,pid=2084,reqid=8211,event=1
- current:ver=1,ip=192.168.0.102,time=1148825019859,pid=2084,reqid=8211,event=1
type=Portlet detail=action elapsed=60
SRVE0180I: [StdWorldClock_war#StdWorldClock.war] [/worldclock] [Servlet.LOG]:
WorldClockController(doView): entering doView()...
PMRM0003I: parent:ver=1,ip=192.168.0.102,time=1148825019859,pid=2084,reqid=8214,event=1
- current:ver=1,ip=192.168.0.102,time=1148825019859,pid=2084,reqid=8214,event=1
type=Portlet detail=render elapsed=50
各要求メトリックのメッセージには、IPアドレス、タイム・スタンプ、プロセスID、要求ID、エントリー・タイプ、経過時間が含まれています。上記のリストでは、ポートレットに関連するデータは太字 で示されています。これは、メソッドのタイプ(detail)とミリ秒単位で示された経過時間で構成されます。特定のメソッドで経過時間がかなり長くかかる場合は、潜在的なパフォーマンスの問題として、そのポートレットと状況に注目してください。
スクリプト・インターフェース(wsadmin)の使用
もう1つの方法として、スクリプト・インターフェースのwsadminを使用してポートレットをインストールできます。
まず、wsadminを開始してサーバーに接続します。次のメッセージが表示されます。
コマンド・プロンプトで、ポートレットをインストールする次のコマンドを入力します。
重要 ： Windowsシステムであっても、常にスラッシュを使用してください。
wsadmin>set pmi [$AdminConfig list PMIRequestMetrics]
wsadmin>$AdminConfig modify $pmi {{enabledComponents {}}}
構成を保存します。
wsadmin> $AdminConfig save
構成を保存した後、ポートレット・メトリックを使用する前に、サーバーの再起動が必要な場合もあります。これで、前のセクションで示したように、要求メトリック・ログを生成する世界時計ポートレットにアクセスできます。
WebSphere Portalとの比較
ポータルのセットアップと環境の複雑さにより、WebSphere Portalは応答の測定、レポート、および診断を、より多機能な製品(たとえば、ITCAM など)に依存しています。
単純かつ簡単で、すぐに使用できる測定インフラストラクチャーを提供するWebSphere Application Serverに比較し、ITCAMは高度な機能を持ち、より多くのパフォーマンス・メトリック、レポート、およびシステムの診断方法をサポートします。
拡張デプロイメント記述子
この連載記事の第1部 では、URLアドレス可能度と、ポートレットをブラウザーに直接提供するその機能について説明しました。状況によっては、この機能をオフにすることもあります。たとえば、セキュリティー上の理由で、Integrated System Console (ISC)およびWebSphere Portalなどのポータル・フレームワークを介してのみ、ポートレットへのアクセスを許可する場合です。
URLアドレス可能度をオフにするには、新しいファイルibm-portlet-ext.xmiをWEB-INFディレクトリーに配置し、ポートレット・アプリケーションを再デプロイしなければなりません。このファイルの内容を次のスニペットに示します。ポートレットの提供をオフにするには、portletServingEnabled属性をfalseに設定してください。
<?xml version="1.0" encoding="UTF-8"?>
<portletappext:PortletApplicationExtension xmi:version="1.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:portletappext="portletapplicationext.xmi"
xmlns:portletapplication="portletapplication.xmi"
xmi:id="PortletApp_ID_Ext"
portletServingEnabled="false">
<portletappext:portletApplication href="WEB-INF/portlet.xml#worldclock_app_id"/>
</portletappext:PortletApplicationExtension>
WebSphere Portalとの比較
拡張デプロイメント記述子は、標準または既存のデプロイメント記述子を拡張するために、さまざまな製品で使用されています。WebSphere Portalは、WebSphere Application Serverと同様の方法で、ポートレット・デプロイメント記述子へのさまざまな拡張を定義します。拡張はWEB-INFディレクトリー内のibm-portal-portlet-ext.xmiファイルで定義され、WebSphere Portalのポートレットに関する動作を制御する方法を提供します。WebSphere PortalおよびWebSphere Application Serverからのどちらのファイルも、名前と機能が競合しないため、同時に存在することができます。
トピック WebSphere Application Server WebSphere Portal
ファイル名
ibm-portlet-ext.xmi
ibm-portal-portlet-ext.xmi
機能
URLアドレス可能度のオン/オフ
拡張キャッシュ、共有キャッシュ匿名セッションのオン/オフ
まとめ
連載の第3部では、WebSphere Application Serverでポートレット・コンテナーを使用するときのパフォーマンスに関するトピックを解説してきました。まず、ポートレット・キャッシュの詳細、およびポートレット・キャッシュを活用してポートレットに適用する方法を説明しました。次に、パフォーマンスのモニターおよび測定手法を使用して、パフォーマンスのボトルネックをより明らかにする方法を説明しました。さらに、管理コンソールまたはスクリプト・インターフェースを使用してこれらを構成する方法を説明しました。
次の第4部では、WebSphere Portalの拡張ポートレット・プログラミング・モデルとWebSphere Application Serverを比較します。サンプルを使用して、両方のプラットフォームにデプロイし実行できるのはどのポートレットか、また一方のプラットフォームでのみ実行できるのはどのポートレットかを示します
ダウンロード
説明
ファイル名
サイズ
ダウンロード方法
World clock portlet
StdWorldClock.war
75 KB
HTTP
リソース
筆者について（原文のまま）
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.
原文はこちら (US)
