JP2006501558A - ウェブ・アプリケーション用のウェブ・ページのセッションをユーザに表示する装置と方法 - Google Patents

Abstract

【課題】 ポータルにおいて、ビジネス規則とユーザのビジネス上の役割とに基づきユーザごとに行なうポータル・リソースの収集を実現するとともに、当該収集を実行時に動的に行ないうるようにする。
【解決手段】 本発明の実例はユーザに表示するポータル・リソース（ポートレット、ページ、およびページ・グループ）を交換可能な規則エンジンに基づいて選択する手段と、規則データベースと、規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示するポートレット・アプリケーション収集エンジンとを備えている。

Description

本発明はインターネットに関し、特にウェブ・サイトの機能を強化するためのポータルとポートレットをウェブ・アプリケーション中に作成するとともにそれらを使用する方法と装置に関する。

ワールド・ワイド・ウェブによってインターネットを介して画像情報をユーザに伝達する通信へのパラダイム・シフトが起きた。ウェブの登場によって、通信可能性（communicability:伝達性) と広帯域接続（broad connectivity）を高めることが求められ、現在でも求められている。

ポータル（the Portal) （以前はウェブ・ポータルと呼ばれていた）によって、インターネット空間にパラダイム・シフトが生じた。多数のリソースやサービス（たとえば電子メール、フォーラム、検索エンジン、データベース、または他の情報）を提示するウェブ・サイトは１つのポータル（portal）であると考えられる。最初のウェブ・ポータルはオンライン・サービス（パソコン通信サービス）であった。インターネットをサーフィンするユーザは初めて、ワールド・ワイド・ウェブ中の様々なサイトから入来する情報を用いて組み立てた後、それらの情報を提示するウェブ・ページを閲覧できるようになった。そして、その情報集積の構成はユーザにとってまだ分かりやすいものであった。しかし現在、典型的なウェブ・ブラウザを利用するユーザは密結合して表示されるウェブ・ページを見ている。閲覧中のウェブ・サイトに関連付けられていない様々なインターネット・サイトに由来する様々な部品の起点は容易には分からない。これらの部品はポートレット（Portlet)と呼ばれている。

ポートレットはエンド・ユーザが自分のポータル・ページ内で見る可視の能動コンポーネントである。ＰＣのデスクトップに表示されるウインドウと同様に、各ポートレットは自身が結果を表示する、ブラウザまたはＰＤＡ（Personal Digital Appliance) の画面の一部を「所有（own)」している。

ユーザの観点からは、ポートレットはユーザが講読し、自分の個人用のポータル・ページに付加し、パーソナライズしたコンテンツを表示するように構成する対象をなす、コンテンツ・チャネル（content channel)すなわちアプリケーションである。

コンテンツの提供者の観点からは、ポートレットは自身のコンテンツを公表するための手段である。

ポータルの管理者の観点からは、ポートレットはユーザが講読しうるように当該ポータルに登録することのできるコンテンツ・コンテナである。

ポータルの観点からは、ポートレットは当該ポータルのページ群のうちの１ページに表示すべき対象をなすコンポーネントである。

技術的な観点からは、ポートレットはポータル・サーバ上で実行されるとともに、ポータルのページ群中に埋め込むべきコンテンツを提供する一片のコードすなわち小さなアプリケーションである。最も簡単化して述べると、ポートレットはポータル内で実行されるＪａｖａ（Ｒ）サーブレットである。

（通常はワールド・ワイド・ウェブ中の様々な場所に由来する）所定のページの各部分（ポートレット）は同じページの別の部分（ポートレット）と協働して、当該ページをサーフィンする、すなわち当該ページにアクセスするユーザのためにより高度の機能を発揮することができる。したがって、ポータルは複数のユーザが複数のチャネルを経由して複数の情報源にアクセスするための単一のアクセス点になる。

ポータルは様々なビジネス・モデル（すなわちＢ２Ｃ（business to consumer) 、Ｂ２Ｂ（business to business）、Ｂ２Ｅ（business to enterprise））に適用することができる。ポータルのパラダイムに迅速に適合する鍵は既存のウェブ・アプリケーションをポータルのフレームワーク（枠組み）に切目なく統合する能力にほとんど帰着する。

しかしながら、ウェブ・アプリケーションを切目なくポータルに統合するに当たっては様々な技術上の障害がいまだに存在する。

次に示すポータルの取り決め（artifact）が既存のウェブ・アプリケーションと協働する方法に関し、従来技術には限界がある。ウェブ・アプリケーションをポータル・アーキテクチャに統合する実装方法は明確には定義されていない。これらのエンティティ（構成要素）には次に示すものが含まれる。
ポータルに対する最初のｈｔｔｐ（形式の）要求
ポータル内におけるポートレットのセッション
ポータルから関連するウェブ・アプリケーションへのｈｔｔｐ要求

異なる複数のユーザ達が１つのポータルにアクセスすると、各ユーザの最初のｈｔｔｐ要求はポータル・サーバに向けられる（ａ）。各ユーザの最初のｈｔｔｐセッションも上記ポータル・サーバが全体として「所有」している。各ポートレットはポートレット・セッションと呼ばれるそれ自身の独立したセッションを持っている。ポートレットが所定のウェブ・アプリケーションに由来する情報を表示する必要がある場合（ｂ）には通常、次に示す技術的な障害が存在する。
（ｉ）ポートレットがバックエンド・ウェブ・アプリケーションに対するｈｔｔｐ要求やｈｔｔｐ応答を生成するための既存の仕組みが存在しない。
（ｊ）起呼側のポートレット（およびポートレット・セッション）に対する複数の要求と応答を管理して、複数の要求と応答をバックエンド・ウェブ・アプリケーション（およびウェブ・アプリケーションのセッション）に正確にマッピングするための既存の仕組みが存在しない。したがって、各々（ポートレットおよびウェブ・アプリケーションの双方）はそれなりに自身のユーザ・セッションを保持している。

これが原因で複雑になるのは、複数のポートレットが同一のウェブ・アプリケーションを呼び出し、当該ウェブ・アプリケーションがこれら複数のポートレットの要求を同一のウェブ・アプリケーションのセッション内で処理するときである。

（ｋ）複数のポートレット・セッションとウェブ・アプリケーションのセッションとの間でセッション情報を中継するための既存の仕組みが存在しない。

バックエンドにある１つのウェブ・アプリケーションと対話する、同じポートレット・アプリケーション内にあるポートレット群から成る組を明確に定義すれば、参加するすべてのポートレットは正確なセッション情報を検索・取得してバックエンドにある上記ウェブ・アプリケーションに転送しうるから、当該ウェブ・アプリケーションから渡される情報が上記ポートレット群から成るポータルの情報の設定と一致するようにすることができる。そのような設定の例には、ロケール情報、当該特定のアクセスのユーザ・エージェントなどがある。たとえば、ウェブ・アプリケーションから送付される応答はそれ（当該応答）を表示している、ポータル・サーバ中のポートレットと同じロケールを使用中であるに違いない。

ポータルのユーザの資格証明書がバックエンド・ウェブ・アプリケーションによって確認（challenge)を受けずに済むようにサインオンを１回で済ますための既存の仕組みは存在しない。しかし、これは重要な要件である。これがないと、ユーザがウェブ・ページの１つの部分から同一のウェブ・ページの別の部分に移動した場合、当該ユーザの資格証明書は確認を受けることになる。というのは、各ポートレットは様々な発信（origination)と様々な識別要件を有するからである。

所定のポートレット・アプリケーションと関連するバックエンド・ウェブ・アプリケーションとの間でやり取りされる複数の要求または応答を同期させるための既存の仕組みは存在しない。

従来技術には同一のポートレット・アプリケーション内にある複数のポートレットが（同一のコンテキストを共用することにより）相互に協働するとともに、動的に統合される様々なウェブ・アプリケーションと協働しうるようにする方法が定義されていないという点に関して限界がある。

同じ「コンテキスト」を動的に共用することによって協働する複数のポートレットを含む、次に示す１つの慣習的なシナリオは上記限界を概念的に説明するのに役立つ。

１つのポータル・ウェブ・ページ上に３つのポートレットが表示されている場合において：
−−１つのポートレットは口座のリストを表示することにより口座総括表を示している
−−第２のポートレットは所定の口座の未払いの請求書を示している
−−第３のポートレットは所定の口座の注文履歴の総括表を示している

第２のポートレットと第３のポートレットは未払いの請求書（第２のポートレット）と注文履歴（第３のポートレット）を反映させることによりコンテキスト上、第１のポートレットに結び付くとともに、第１のポートレットの口座リストから選択された１つの口座と同期している。

従来技術の限界：
（ｉ）協働して動作するポートレット・アプリケーション内にあるポートレット群から成るサブグループを定義する既存の仕組みが存在しない。
（ｊ）所定のポートレット・アプリケーション内にあるポートレット群から成るこのサブグループの間で共用され（動的に変更しうる）コンテキストを定義する既存の仕組みが存在しない。ここにおけるコンテキストの例としてはポートレット１において選択する口座が挙げられる。このような口座の選択は動的に変更することができる。
（ｋ）コンテキストの変更を動的に検出する既存の仕組みが存在しない。コンテキストの変更の例としては上記例のポートレット１において１つの口座から口座リスト中の別の口座へ選択を変更することが挙げられる。
（ｌ）１つのコンテキストを共用しているポートレット群から成るサブグループ内において、参加しているポートレットごとに所定のアクション（すなわち応答）を登録する既存の仕組みが存在しない。上記アクションの例としては（ポートレット１において１つの口座から別の口座へ選択が移行することにより）コンテキストが変更されたら、未払いの請求書のリストを表示すること（ポートレット２のアクション）が挙げられる。
（ｍ）上記動的なコンテキストを関連する統合ウェブ・アプリケーションに中継する既存の仕組みが存在しない。

ポートレット・アプリケーション内のポートレット群から成るグループ用にリフレッシュの順番を定義する仕組みが従来技術には存在しない。

（ｉ）現在、ポータルの設計者が、表示中のポータル群から成る所定の組のリフレッシュの順序を指定するための手段が存在しない。

上述したシナリオでは、ポータルの設計者は第１のポートレット（口座のリスト）を最初にリフレッシュし、第２のポートレットを２番目にリフレッシュし、という具合に実行することを希望するであろう。そうすれば、第２のポートレットと第３のポートレットは正確な順番に実行される定義済みのアクション（リフレッシュ）を（当該ポートレットが使用されるときに）自動的に保持しうるようになる。

ビジネスの規則とユーザの役割を含むユーザ・プロファイル情報とに基づいて行なうポートレットの収集をサポートする明確に定義された仕組みがポータルのアーキテクチャには欠けている。

（ｉ）ビジネスの規則に基づいてポータルのリソースをユーザごとに収集することを定義するための既存の仕組みは存在しない。
例：十代のポータル・ユーザはすべて、あるグループのポートレット群を閲覧し、シニアのポータル・ユーザはすべて、別のグループのポートレット群を閲覧する。
（ｊ）実行時に動的に行なう、規則ベースであるとともにユーザ・ベースでもある、ポートレットのそのような収集のための既存の仕組みは存在しない。

ポータル・レベルのビジネス規則およびユーザ・プロファイル情報と、関連する統合されたバックエンド・ウェブ・アプリケーションとは共用されていない。

ビジネス規則またはユーザ区分情報と、統合されたウェブ・アプリケーションとが共用されていないから、これらの規則およびユーザの区分はポータルおよびその統合されたバックエンド・ウェブ・アプリケーション全体にわたって不変である（consistent：無矛盾である、一貫している）可能性がある。たとえば、十代の年齢範囲を定義する規則が存在する場合、そのような規則は不変性（consistency:無矛盾性、一貫性）ゆえに、統合されたウェブ・アプリケーションの管理下になければならず、かつ、それにとって適切なものでなければならない。

〔専門用語集〕
［ポートレット］
ポートレットとはエンド・ユーザがそのポータル・ウェブ・ページ内で見る可視の能動コンポーネントのことである。ＰＣのデスクトップに表示されるウインドウと同様に、各ポートレットはブラウザまたはＰＤＡ（Personal Digital Appliance) の画面の一部を「所有（own)」しており、そこにポートレットに固有の情報を表示する。

［ポートレット・アプリケーション］
ポートレット群を集約してポートレット・アプリケーションを形成することもできる。ポートレット・アプリケーションはウェブ・アーカイブ・ファイル（ＷＡＲ）を用いて配布し配備する。ポートレットには固有の拡張子があり、ウェブ・アプリケーションを配備するための記述子を標準化している。

［ポートレット・メッセージ］
ポートレット・アクションとポートレット・メッセージを使用している２つのポートレット間の通信にはポートレット・メッセージを使用する。ポートレットを送付する際、ポートレット・アクションを生成し、当該アクションをＵＲＬにエンコードする。（たとえばユーザがタスクの実行を試みることにより）ＵＲＬをアドレス指定すると、アクション・リスナが呼び出され、必要なデータを送付するためのポートレット・メッセージを送付する。

［ポートレット・セッション］
ポートレット・インスタンスごとユーザごとにセッション情報を保持するために、ポートレット・インスタンスごとに、かつログオンしているユーザごとにポートレット・セッションを生成する。

現在のポータルにはビジネス規則とユーザのビジネス上の役割を含むユーザ・プロファイル情報とに基づきユーザごとに行なうポータル・リソースの収集をサポートする明確に定義された仕組みが存在しない。実行時に動的に行なわれる可能性のある、規則ごとかつユーザごとに行なうポータル・リソースのそのような収集のための既存の仕組みは存在しない。

本発明の様々な実例は従来技術の弱点を少なくとも１つ解消する。

本発明は規則データベース中のアクセス規則（たとえばポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則）に基づいてポータル・リソースを動的に表示する装置を提供する。

本発明の一実例は、
ユーザに表示するポータル・リソース（ポートレット、ページ、およびページ・グループ）を交換可能な規則エンジンに基づいて選択する手段と、
規則データベースと、
規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示するポートレット・アプリケーション収集エンジンとを備えている。

本発明の別の実例はユーザの役割に基づくポータル・リソースの表示を制御する規則を格納した役割データベースを用いて役割にアクセスする手段を備えている。
本発明の一実例によれば、規則に基づいてポータル・リソースを動的に表示する機能を備えた微細なレベルのパーソナライゼーションを実現することが可能になる。

本発明の一実例は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ポータルをユーザに表示する装置であり、前記ウェブ・ポータルは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している複数の関連するポートレットを表示するものである、装置であって、
前記ウェブ・アプリケーションへのアクセスを提供するウェブ・ポータルを運営するポータル・サーバと、
前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションであって、
前記ウェブ・アプリケーションへのアクセスを求めるユーザの要求に応えてポートレットを始動する手段と、
前記ポートレット用にポートレット・アプリケーション・セッション・オブジェクトを管理する手段と
を備えた
ポートレット・アプリケーションと、
ポートレットとポートレット・アプリケーション・セッション・オブジェクトとを関連付ける、ユーザの要求中のパラメータを保存するための、ポートレット・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと
を備えた
装置。

本発明の装置は関連するポートレットから受領する要求をウェブ・アプリケーションに伝達するために、ポートレット・アプリケーション・セッション・オブジェクトとウェブ・アプリケーションとの間で通信するポートレット・アプリケーション通信クライアントをポートレット・アプリケーション中に備えている。このポートレット・アプリケーションはポートレット・アプリケーション・セッション・オブジェクトに付随する各ポートレットに共通キーを割り当てる。

本発明の別の実例は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ポータルを複数のユーザに表示する装置でり、前記ウェブ・ポータルは、前記ユーザによってアクセス可能であるとともに情報を共用している複数のポートレットを表示するものである、装置であって、
ウェブ・ポータル上で動作して前記ウェブ・アプリケーションへのアクセスを提供するポータル・サーバと、
前記複数のユーザの各々用に前記ポータル・サーバ上で動作するとともに、前記複数のユーザの各々用に関連する一群のポートレットを管理するポートレット・アプリケーションであって、
前記ポートレット・アプリケーションの各々は、
前記ウェブ・アプリケーションへのアクセスを求める、前記複数のユーザのうちの１人の要求に応えてポートレットを始動する手段と、
前記ポートレット用にポートレット・アプリケーション・セッション・オブジェクトを管理する手段と
を備えている、
ポートレット・アプリケーションと、
ポートレットとポートレット・アプリケーション・セッション・オブジェクトとを関連付ける、ユーザの要求中のパラメータを保存するための、ポートレット・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと
を備えた
装置。

本発明の別の実例は次に示す装置を提供する。
複数のウェブ・アプリケーション用のウェブ・ポータルを１人のユーザに表示する装置であり、前記ウェブ・ポータルは、前記ユーザによってアクセス可能であるとともに情報を共用している関連する複数のポートレットを表示するものである、装置であって、
ウェブ・ポータル上で動作して前記ウェブ・アプリケーションへのアクセスを提供するポータル・サーバと、
前記ポータル・サーバ上で動作する、前記複数のウェブ・アプリケーションにそれぞれ関連する複数のポートレット・アプリケーションであって、
各ポートレット・アプリケーションは関連する一群のポートレットを管理しうるように適合しており、
前記ポートレット・アプリケーションの各々は、
前記複数のウェブ・アプリケーションの１つへのアクセスを求める、１人のユーザの要求に応えてポートレットを始動する手段と、
前記ポートレット用にポートレット・アプリケーション・セッション・オブジェクトを管理する手段と
を備えている、
複数のポートレット・アプリケーションと、
ポートレット・アプリケーション中のポートレットとポートレット・アプリケーション・セッションのポートレット・アプリケーション・セッション・オブジェクトとを関連付ける、ユーザの要求中のパラメータを保存するための、ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと
を備えた
装置。

本発明の装置の別の側面は複数のウェブ・アプリケーションとポートレット・アプリケーション・セッション・オブジェクトとを接続しうるように適合したユーザ・セッション情報テーブルを備えている。

本発明のさらに別の実例は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ポータルを１人のユーザに表示する装置であり、前記ウェブ・ポータルは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している関連する複数のポートレットを表示するものである、装置であって、
ウェブ・ポータル上で動作して前記ウェブ・アプリケーションへのアクセスを提供するポータル・サーバと、
前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションとを備え、
前記ポートレット・アプリケーションは、
前記ウェブ・アプリケーションへのアクセスを求める、１人のユーザの要求に応えて最初のポートレットを始動する手段と、
前記最初のポートレット用に前記ユーザ用のポートレット・アプリケーション・セッション・オブジェクトを生成する手段と、
前記ウェブ・アプリケーションへのアクセスを求める、前記ユーザの後続する要求に応えて前記最初のポートレットに付随する追加のポートを生成する手段と、
前記追加のポートレットと前記ポートレット・アプリケーション・セッション・オブジェクトとを関連付けるために保存済みのパラメータを使用する、ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと、
前記最初のポートレットおよび追加のポートレットから受領するユーザの要求を前記ウェブ・アプリケーションに伝達するために、ポートレット・アプリケーション・セッション・オブジェクトおよびウェブ・アプリケーションと通信するポートレット・アプリケーション通信クライアント（ｈｔｔｐクライアント）を生成する手段と
を備えている、
装置。

前記装置は関連するポートレットから受領するユーザの要求を前記ウェブ・アプリケーションに伝達するために、ポートレット・アプリケーション・セッション・オブジェクトとウェブ・アプリケーションとの間で通信するポートレット・アプリケーション通信クライアントを前記ポートレット・アプリケーション中に備えてもよい。

前記ポートレット・アプリケーションはポートレット・アプリケーション・セッション・オブジェクトに付随する各ポートレットに共通キーを割り当てるのが望ましい。

複数のウェブ・アプリケーションとポートレット・アプリケーション・セッション・オブジェクトとを接続しうるように適合したユーザ・セッション情報テーブルを備えるのが好都合である。

本発明の別の実例は次に示す装置を提供する。
１つのウェブ・アプリケーション用のウェブ・ポータルを１人のユーザに表示する装置であり、前記ウェブ・ポータルは、前記ユーザによってアクセス可能であるとともに情報を共用している関連する複数のポートレットを表示するものである、装置であって、
ウェブ・ポータル上で動作して前記ウェブ・アプリケーションへのアクセスを提供するポータル・サーバと、
前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションであって、
前記ウェブ・アプリケーションへのアクセスを求める、１人のユーザの要求に応えてポートレットを始動する手段と、
前記ポートレット用にポートレット・アプリケーション・セッション・オブジェクトを管理する手段と
を備えた
ポートレット・アプリケーションと、
ポートレットとポートレット・アプリケーション・セッション・オブジェクトとを関連付ける、ユーザの要求中のパラメータを保存するための、ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと
を備えた
装置。

本発明の別の側面は次に示す方法を提供する。
ウェブ・ポータル中の関連する複数のポートレットの間で情報を共用する方法であって、
前記関連する複数のポートレットの各々用にポートレット・データ・ストアに対するアクセス権を生成するステップと、
前記関連する複数のポートレットの各々に、前記ポートレット・データ・ストアにデータを書き込むこと、および前記ポートレット・データ・ストアから格納済みのデータを読み出すことを許可するステップと
を備えた
方法。

前記方法は次に示すシステムを備えるのが好都合である。
データ処理システム上で動作しうるように適合したポートレット・アプリケーションが前記関連するポートレットを管理し、
前記ポートレット・データ・ストアが、前記ポートレット・アプリケーションの前記関連するポートレットの間でデータを交換するのを可能にするために、前記データ・ストア中の関連するポートレットによるデータの読み出しおよび書き込みを制御するポートレット・アプリケーション・セッション・オブジェクトが管理するポートレット・アプリケーション記憶装置を備えた
システム。

本発明の別の側面は次に示す装置を提供する。
ウェブ・ポータル中の関連する複数のポートレットの間で情報を共用する装置であって、
前記関連する複数のポートレットを管理するポートレット・アプリケーションと、
ポートレット・アプリケーション・データ・ストアと、
前記ポートレットが相互にデータを交換しうるように、前記関連する複数のポートレットによる前記データ・ストアに対する読み出し／書き込みアクセスを保証する手段と
を備えた
装置。

本発明のさらに別の側面は次に示すポートレット（アプリケーション）サーバを提供する。
ポータル・サーバ上で動作し、ウェブ・ポータル中の関連する複数のポートレットをホストしうるポートレット（アプリケーション）サーバであって、
前記関連する複数のポートレットを管理する手段と、
ポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、
前記ポートレット・アプリケーション・セッション・オブジェクトが管理するポートレット・アプリケーション・データ・ストアとを備え、
前記ポートレット・アプリケーション・データ・ストアは当該ポートレット・アプリケーション・データ・ストアに対する読み出し／書き込みアクセスを前記関連する複数のポートレットに保証することにより、前記関連するポートレットが相互にデータを交換しうるようにしている、
ポートレット（アプリケーション）サーバ。

本発明の別の側面は次に示すポートレット（アプリケーション）サーバを提供する。
ポータル・サーバ上で動作し、ウェブ・ポータル中の関連する複数のポートレットをホストしうるポートレット（アプリケーション）サーバであって、
前記関連する複数のポートレットを管理する手段と、
ポートレット・アプリケーション・セッション・オブジェクトを生成して管理する手段と、
前記ポートレット・アプリケーション・セッション・オブジェクトが生成して管理するポートレット・アプリケーション・データ・ストアであって、前記ポートレット・アプリケーション・データ・ストアは当該ポートレット・アプリケーション・データ・ストアに対する読み出し／書き込みアクセスを前記関連する複数のポートレットに保証することにより、前記関連するポートレットが相互にデータを交換しうるようにしている、ポートレット・アプリケーション・データ・ストアと
を備えた
ポートレット（アプリケーション）サーバ。

前記ポートレット・アプリケーションはポートレット・アプリケーション・セッション・オブジェクトに付随する各ポートレットに共通キーを割り当てるのが好都合である。

本発明の別の側面は次に示すポートレット・アプリケーションを提供する。
ユーザがアクセスしうるウェブ・ポータル中の関連する複数のポートレットをホストする、ポータル・サーバ上で動作しうるポートレット・アプリケーションであって、
前記関連する複数のポートレットを管理するポートレット・アプリケーション手段と、
前記ユーザ用のポートレット・アプリケーション・セッション・オブジェクトを管理するポートレット・アプリケーション手段と、
関連するポートレットの各々に前記ポートレット・アプリケーション・オブジェクトへのアクセスを制御するキーを与えるポートレット・アプリケーション手段と
を備えた
ポートレット・アプリケーション。

本発明のさらに別の側面は次に示すポートレット・アプリケーションを提供する。
ユーザがアクセスしうるウェブ・ポータル中の関連する複数のポートレットをホストする、ポータル・サーバ上で動作しうるポートレット・アプリケーションであって、
前記関連する複数のポートレットを管理するポートレット・アプリケーション手段と、
前記ユーザ用のポートレット・アプリケーション・セッション・オブジェクトを生成して管理するポートレット・アプリケーション手段と、
関連するポートレットの各々に前記ポートレット・アプリケーション・オブジェクトへのアクセスを制御するキーを与えるポートレット・アプリケーション手段と
を備えた
ポートレット・アプリケーション。

各ユーザには１つのポートレット・アプリケーションを割り当て、各ポートレット・アプリケーションごとに、個別のポートレット・アプリケーション・オブジェクトに１つのキーを各ユーザごとに個別に割り当てるのが好都合である。

本発明の別の側面は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ポータルをユーザに表示する装置であって、
ユーザによる前記ウェブ・アプリケーションに対するアクセスを提供するためにウェブ・ポータルを運営するポータル・サーバと、
前記ポータル・サーバ上で実行されるとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
前記関連するポートレット用かつ前記ユーザ用のポートレット・アプリケーション・セッション・オブジェクトと、
前記ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと、
前記関連するポートレットから受領するユーザ要求を前記ウェブ・アプリケーションに伝達するために、前記関連するポートレットと前記ウェブ・アプリケーションとの間で通信する、前記ポートレット・アプリケーション・データ・ストアにリンクされたポートレット・アプリケーション通信クライアントとを備え、
前記通信クライアントは前記関連するポートレットが出す要求を格納するとともに同期させて前記通信クライアントが前記ウェブ・アプリケーションに対して同期するのを可能にする要求バッファを備えている、
装置。

前記ポートレット・アプリケーション通信クライアントは情報（たとえば要求）をネットワークを介してウェブ・アプリケーションに送信し、当該ウェブ・アプリケーションから情報（たとえば前記要求に対する応答）を受信するのが望ましい。

本発明の別の側面は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ポータルをユーザに表示する装置であって、
ユーザによる前記ウェブ・アプリケーションに対するアクセスを提供するためにウェブ・ポータルを運営するポータル・サーバと、
前記ポータル・サーバ上で実行されるとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
前記関連するポートレット用かつ前記ユーザ用のポートレット・アプリケーション・セッション・オブジェクトと、
前記ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと、
前記関連するポートレットから受領するユーザ要求を前記ウェブ・アプリケーションに伝達するために、前記関連するポートレットと前記ウェブ・アプリケーションとの間で通信する、前記ポートレット・アプリケーション・データ・ストアにリンクされたポートレット・アプリケーション通信クライアントとを備え、
前記通信クライアントは前記関連するポートレットが出す要求を格納するとともに直列化して前記通信クライアントが前記ウェブ・アプリケーションに対して直列化するのを可能にする要求バッファを備えている、
装置。

前記ポートレット・アプリケーション通信クライアントは情報（たとえば要求）をネットワークを介してウェブ・アプリケーションまたはウェブ・アプリケーション・サーバに送信し、当該ウェブ・アプリケーションから情報（たとえば前記要求に対する応答）を受信するのが望ましい。

本発明の別の側面は次に示すポータル・サーバを提供する。
ウェブ・アプリケーションへのアクセスを提供するためにウェブ・ポータルを運営しうるように適合したポータル・サーバであって、
前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションであって、
前記ウェブ・アプリケーションへのアクセスを求めるユーザの要求に応じてポートレットを初期化する手段と、
前記ポートレット用のポートレット・アプリケーション・セッション・オブジェクトを管理する手段と
を備えた
ポートレット・アプリケーションと、
前記ポートレットと前記ポートレット・アプリケーション・セッション・オブジェクトとを関連付ける、ユーザ要求中のパラメータを保存するための、ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアとを備え、
さらに、
前記関連するポートレットから受領するユーザ要求を前記ウェブ・アプリケーションに伝達するために、前記関連するポートレットと前記ウェブ・アプリケーションとの間で通信する、前記ポートレット・アプリケーション・データ・ストアにリンクされたポートレット・アプリケーション通信クライアント（ｈｔｔｐクライアント）を備え、
前記ポートレット・アプリケーション通信クライアントはユーザ・セッション情報（たとえば、ユーザＩＤ、ユーザの資格証明書、言語設定、セッションのタイムアウト情報、セッションＩＤなどのユーザ・セッション情報から成る組から選択した情報）を格納するとともに、前記ユーザ・セッション情報を前記ウェブ・アプリケーションの対応するセッションにマップするユーザ・セッション情報ストア（マッピング・テーブル）を備えている
ポータル・サーバ。
前記セッション・タイムアウト情報は前記ポータル・サーバおよび前記ウェブ・アプリケーションのセッション・タイムアウト情報を含んでいるのが望ましい。

本発明の別の側面は次に示すポートレット・アプリケーションを提供する。
ユーザによるウェブ・アプリケーションへのアクセスを提供するポータル・サーバ上で動作するとともに、ポータル中の一群の関連するポートレットを管理するポートレット・アプリケーションであり、前記関連するポートレットは前記ポートレットに対するユーザの要求中のデータおよび命令を格納するポートレット要求パラメータ・マップを備えている、ポートレット・アプリケーションであって、
ユーザ用かつ前記関連するポートレット用のポートレット・アプリケーション・セッション・オブジェクトと、
前記ポートレット・アプリケーション・セッション・オブジェクトが制御するポートレット・アプリケーション・セッション・データ・ストアと、
前記関連するポートレットから受信するユーザ要求を前記ウェブ・アプリケーションに伝達するために、前記関連するポートレットと前記ウェブ・アプリケーションとの間で通信する、前記ポートレット・アプリケーション・ストアにリンクされたポートレット・アプリケーション通信クライアント（ｈｔｔｐクライアント）とを備え、
前記通信クライアントは当該通信クライアントが前記ウェブ・アプリケーションのデータおよび命令を準備しうるようにするために、前記関連するポートレットのポートレット要求パラメータ・マップ中の要求を格納する要求バッファを備えている、
ポートレット・アプリケーション。

本発明の別の側面は次に示すポートレット・アプリケーション通信クライアント（ｈｔｔｐクライアント）を提供する。
関連するポートレットから受信するユーザ要求をウェブ・アプリケーションに伝達するために、前記関連するポートレットと前記ウェブ・アプリケーションとの間で通信する、ポートレット・データ・ストアにリンクされたポートレット・アプリケーション通信クライアント（ｈｔｔｐクライアント）であって、
前記ポートレット・アプリケーション通信クライアントはユーザ・セッション情報（たとえば、ユーザＩＤ、ユーザの資格証明書、言語設定、セッションのタイムアウト情報、セッションＩＤなどのユーザ・セッション情報から成る組から選択した情報）を格納するとともに、前記ユーザ・セッション情報を前記ウェブ・アプリケーションの対応するセッションにマップするユーザ・セッション情報ストア（マッピング・テーブル）を備え、
前記セッションのタイムアウト情報は前記ポータル・サーバおよび前記ウェブ・アプリケーションのセッションのタイムアウト情報を含んでいる、
ポートレット・アプリケーション通信クライアント（ｈｔｔｐクライアント）。

上述したものは前記ポータル・サーバがタイムアウトする前に前記ウェブ・アプリケーションがタイムアウトする場合には前記ユーザを再認証することにより、ポータル・サーバと前記ウェブ・アプリケーションとの間のセッションのタイムアウトを一致させる、前記ポートレット・アプリケーション通信クライアント用の同期手段を備えているが望ましい。

本発明の別の側面は次に示すポートレット・アプリケーションを提供する。
ポータル・サーバ上で動作するとともに、ユーザがアクセスしうるウェブ・アプリケーション中の複数の関連するポートレットをホストしうるポートレット・アプリケーションであって、
前記関連するポートレットが相互にメッセージを交換しうるようにするメッセージング手段と、
前記複数の関連するポートレットを管理するポートレット・アプリケーション手段であって、
各関連するポートレットはコンテキスト名を記述したポートレット記述子を備えており、
前記関連するポートレットはコンテキストの値を定義した対応するコンテキスト名を有するポートレットから成る協働グループを備えており、
前記ポートレットから成る協働グループの各々はマスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを備えており、
前記ポートレットから成るグループの各々は共通のコンテキスト名を共用している、
ポートレット・アプリケーション手段と、
マスタ・ポートレット中のコンテキスト値の変更を当該マスタ・ポートレットのスレーブ・ポートレットにブロードキャストによって通知する、前記ポータル・サーバ中の手段と、
ブロードキャストされるマスタ・ポートレットのコンテキスト値と一致するようにスレーブ・ポートレットのコンテキスト値を変更する、前記ポータル・サーバ中の手段と
を備えた
ポートレット・アプリケーション。

本発明の別の側面は次に示すポートレット・アプリケーションを提供する。
ポータル・サーバ上で動作するとともに、ユーザがアクセスしうるウェブ・アプリケーション中の複数の関連するポートレットをホストしうるポートレット・アプリケーションであり、前記ポータル・サーバはポートレットをリフレッシュする機能を備えている、ポートレット・アプリケーションであって、
前記複数の関連するポートレットを管理するポートレット・アプリケーション手段であって、
各関連するポートレットはポートレット記述子を備えており、
各ポートレット記述子はポートレット用のリフレッシュ順位の記述を備えており、
前記関連するポートレットはポートレットから成る協働グループを備えており、
ポートレットから成る前記協働グループの各々はマスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを備えている、
ポートレット・アプリケーション手段と、
ポートレット群のリフレッシュ順位から成る順序で当該ポートレット群をリフレッシュする、ポートレット・アプリケーション手段中の手段と
を備えた
ポートレット・アプリケーション。

本発明のさらに別の側面は次に示すポートレット・アプリケーションを提供する。
ポータル・サーバ上で動作するとともに、ユーザがアクセスしうるウェブ・アプリケーション中の複数の関連するポートレットをホストしうるポートレット・アプリケーションであり、前記ポータル・サーバはポートレットをリフレッシュする機能を備え、前記関連するポートレットはポートレットから成る協働グループを備えている、ポートレット・アプリケーションであって、
前記複数の関連するポートレットを管理するポートレット・アプリケーション手段であって、
各関連するポートレットはポートレット記述子を備えており、
各ポートレット記述子はポートレット用のリフレッシュ順位の記述、および、ポートレットが所属する、ポートレットから成る協働グループ用のリフレッシュ記述順位を備えており、
ポートレットから成る前記協働グループの各々はマスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを備えている、
ポートレット・アプリケーション手段と、
ポートレット群の順位から成る順序で当該ポートレット群をリフレッシュする、ポートレット・アプリケーション手段中の手段と、
ポートレット群のグループ・リフレッシュ順位から成る順序でポートレット群から成る協働グループ群をリフレッシュする、ポートレット・アプリケーション手段中の手段と
を備えた
ポートレット・アプリケーション。

マスタ・ポートレットの順位はスレーブ・ポートレットの順位よりも高い。

ポートレット・アプリケーションはまずグループ順位から成る順序でグループ群をリフレッシュし、次いで各グループ内をポートレットの順位から成る順序でリフレッシュするのが望ましい。

本発明の別の側面は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ページ・セッションをユーザに表示する装置であり、前記ウェブ・ページ・セッションは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している複数の関連する協働ポートレットを表示するものである、装置であって、
前記ウェブ・アプリケーションへのアクセスを提供するウェブ・ポータルを運営するポータル・サーバと、
前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
規則を格納するように適合した規則データベースにアクセスするためのアクセス手段であって、前記規則はポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、アクセス手段と、
ユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を、前記ユーザ（情報属性）が提供する情報に基づいて選択する選択手段と
を備えた
装置。

本発明の別の変形例では、前記選択手段は、
交換可能な規則エンジンと、
規則データベースと、
規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示するポートレット・アプリケーション収集エンジンとを備えている。

本発明の別の側面は次に示す装置を提供する。
ウェブ・アプリケーション用のウェブ・ページ・セッションをユーザに表示する装置であり、前記ウェブ・ページ・セッションは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している複数の関連する協働ポートレットを表示する、装置であって、
前記ウェブ・アプリケーションへのアクセスを提供するウェブ・ポータルを運営するポータル・サーバと、
前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
役割データベースにアクセスするための役割アクセス手段であって、前記役割データベースはポートレット、ページ、およびページ・グループから成る組のユーザへの表示をユーザの役割に基づいて制御する規則を備えている、役割アクセス手段と、
ユーザの特定済みの役割に基づき当該ユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を選択する役割選択手段と
を備えた
装置。

本発明の他の側面は次に示す製品を提供する。
コンピュータ読み取り可能な信号担持媒体と、
上述した本発明の実例の方法を実行しうるように適合し、前記媒体に記録されたコンピュータ・プログラム・コード手段とを備えた製品。

本発明の他の側面は次に示す製品を提供する。
コンピュータ読み取り可能な信号担持媒体と、
上述した本発明の実例のうちの１つの装置を実装しうるように適合し、前記媒体に記録されたコンピュータ・プログラム・コード手段とを備えた製品。

前記媒体は磁気的データ記憶媒体、光学的データ記憶媒体、生物学的データ記憶媒体、および原子的データ記憶媒体から成る群から選択されている。

前記媒体はモジュール化された搬送信号である。

前記信号はネットワーク上を伝送されるものである。

この章では本発明の好適な実施形態を説明する。
〔Ａ．１．ポータルとウェブ・アプリケーションとの統合を可能にする〕
図２はウェブ・ポータル・サーバを用いてその使用方法を説明する、本発明の好適な実施形態を示す図である。

〔Ａ．１．１ ポートレット・アプリケーションのｈｔｔｐクライアント〕
（バックエンド・ウェブ・アプリケーションへのｈｔｔｐ要求を作成する）ポートレットはポートレット・アプリケーションｈｔｔｐクライアント２０９を使用して、バックエンド・アプリケーション・サーバ２１０で実行されているバックエンド・ウェブ・アプリケーションへのｈｔｔｐ接続を開く。バックエンド・ウェブ・アプリケーションは複数の要求と応答にまたがるセッションのサポート、クッキの処理、および単一サインオン（ＳＳＯ）の論理を実現するためにポートレット・アプリケーションｈｔｔｐクライアント２０９を必要とする。１つのポートレット・アプリケーション中のすべてのポートレットは同一のポートレット・アプリケーションｈｔｔｐクライアント・オブジェクト２０９を用いて少なくとも１つのバックエンド・ウェブ・アプリケーションに接続する。ポートレット・アプリケーション２０４ごとに１つのポートレット・アプリケーションｈｔｔｐクライアント２０９が存在する。

〔Ａ．１．２ ポートレット・アプリケーション・セッション〕
ポートレット・アプリケーション・セッション・オブジェクト２０８は所定のポートレット・アプリケーション中のすべてのポートレットが共用することのできる統合データ格納オブジェクトである。ポートレット・アプリケーション・セッション・オブジェクト２０８はインフラストラクチャを提供して、所定のポートレット・アプリケーション中の複数のポートレットが独立のユーザ・セッション（ポートレット・セッション２０４、２０５、２０６とも呼ばれる）を持つが、同じポートレット・アプリケーション・セッションを共用し、単一のウェブ・アプリケーション・セッションを用いてバックエンド・アプリケーション・サーバ２１０にあるウェブ・アプリケーションと通信しうるようにするものである。

〔Ａ．１．３ ポートレット・アプリケーション・セッション・コンテキスト〕
ポートレット・アプリケーション・セッション・コンテキストはユーザごとポートレット・アプリケーションごとの情報を提供するものである。これは次のことを意味する。すすなわちこれにより、同じポートレット・アプリケーション（２０４、２０３）中のすべてのポートレットはそれらの間で共通の情報を共用する手段を保持しうるようになる。

〔Ａ．１．４ セッション中継機構３２０〕
セッション中継機構はポータル・サーバが保持している最初のｈｔｔｐセッションに由来する情報をポートレット・アプリケーションのｈｔｔｐクライアントが生成するバックエンドのｈｔｔｐセッションに渡すことを可能にするものである。この機構は次に示すインフラストラクチャを使用する。

［クッキ・テーブル３０５とクッキ探索キー］
クッキ・テーブル３０５（ユーザ・セッション情報のテーブル）はポータル・サーバのクッキをバックエンド・ウェブ・アプリケーション・セッションのクッキへマッピングするための主要な構成要素である。ポータル・サーバへのｈｔｔｐ要求のクッキと所定の１つのウェブ・アプリケーションに属すポートレット・アプリケーションｈｔｔｐクライアントのクッキとの間のマッピング関係は一対一である。しかし、所定のポートレット・アプリケーションｈｔｔｐクライアントは様々なウェブ・アプリケーション（各ウェブ・アプリケーションは独立のセッションを保持している）に対してｈｔｔｐ要求を生成することができる。したがって、ポータル・サーバ・セッションのクッキとバックエンド・ウェブ・アプリケーションのクッキとの間のマッピングは（バックエンド・ウェブ・アプリケーション・サーバが複数個存在するために）一対多になる可能性がある。

図１３はこのマッピングを示す図である。同図には多数の項目が示されている。すなわち、
ＲＱ１：ユーザ・エージェント（ブラウザ）のｈｔｔｐ要求からポータル・サーバへのクッキ
ＲＱＡ：ポートレットｈｔｔｐアプリケーション・クライアントのｈｔｔｐ要求からウェブ・アプリケーションＡへのクッキ
ＲＱＢ：ポートレットｈｔｔｐアプリケーション・クライアントのｈｔｔｐ要求からウェブ・アプリケーションＢへのクッキ

ポートレット・アプリケーションｈｔｔｐクライアント２０９はこのテーブルを用いて、バックエンド・ウェブ・アプリケーション・サーバ２１０で実行されているバックエンド・ウェブ・アプリケーションと一致するクッキを探索する。

このクッキ・マッピング・テーブル３０５があると、ポータル・サーバ・セッションが満了したときにバックエンド・ウェブ・アプリケーション・セッションを自動的に満了させることが可能になる。

［クッキ探索キー］
ポートレット・アプリケーションｈｔｔｐクライアント２０９はポートレット・アプリケーションごとに生成する。クッキ探索キーは同じポートレット・アプリケーション中のすべてのポートレットにアクセス可能なポータル・アプリケーション・セッション・オブジェクトに格納されている。このクッキ探索キーはポータル・サーバのｈｔｔｐセッションとバックエンド・アプリケーションのｈｔｔｐセッションとを一致させる任に当たる。

クッキ探索キーを使用すると、同じｈｔｔｐクライアント・キーを共用している、所定のポートレット・アプリケーション中のすべてのポートレットが、現在ログインしているユーザ用にバックエンド・ウェブ・アプリケーションの情報の正確な組を検索・取得して転送することが可能になる。この結果、同じポートレット・アプリケーション中のすべてのポートレットが同期して動作して使用中のバックエンド・ウェブ・アプリケーションを更新しうるようになる。その結果、エンド・ユーザはバックエンド・ウェブ・アプリケーションの統合されたビューを複数のポートレットを通して見ることになる。

［ポートレット要求パラメータ・マップ］
ポートレット要求パラメータ・マップ３０８は共用アプリケーション・セッション・データストアに格納されているメモリ・オブジェクトであり、ポートレットごとポータル・サーバ・セッションごとに生成される。それは特定のポートレットに入来するユーザ要求が出すすべての要求のパラメータを格納するのに使用する。

〔Ａ．２．ポートレットの動的コンテンツの同期〕
〔Ａ．２．１ 動的コンテキスト定義テンプレート〕
図５はポータルをバックエンド・ウェブ・アプリケーションに統合する様子を示す図である。図５を参照することは次に示す点で有益である。

動的コンテキスト定義テンプレート５０３は次に示す事項を動的コンテキスト・グループごとに定義する。
−−コンテキストとその種別（上述した例では、それは口座ＩＤである）
−−定義済みコンテキストの値を変更しうるマスタ・ポートレット
−−定義済みコンテキストが変更されたときに通知されるスレーブ・ポートレット
−−コンテキスト変更の通知時におけるスレーブ・ポートレットの登録済み応答（すなわちアクション）
−−任意事項としてスレーブ・ポートレットのリフレッシュの順番を定義する（マスタは常に所定のグループ内において最初にリフレッシュされる）

１つの動的コンテキスト定義テンプレート５０３は１つまたは多数の動的コンテキスト・グループを含むことができる。しかし、各動的コンテキスト・グループは次に示すものしか含むことができない。
−−１つのマスタ・ポートレット
−−１つの定義済みコンテキスト
−−１つまたは複数のスレーブ・ポートレット

注記：所定のポートレットは複数の動的コンテキスト・グループに参加することができるが、各グループにおいて果たす役割は様々である。

〔Ａ．２．２ 動的コンテキスト・ポートレット・グループを生成するツール〕
このツール５０１は動的コンテキスト定義テンプレート５０３を読み込み、すべての動的コンテキスト・グループ用の動的コンテキスト・マスタ・ポートレットと動的コンテキスト・スレーブ・ポートレットを、指定された定義に従い、ポートレット配備記述子５０２をそれ相応に更新することにより生成する。

〔Ａ．２．３ 動的コンテキスト・グループ〕
動的コンテキスト・グループは同じコンテキストを共用するポートレット群から成るサブセットであり、１つの動的コンテキスト・グループの下にまとめられている。所定のポートレットは複数の動的コンテキスト・グループに属すことができる。

動的コンテキスト・グループ定義ドキュメント・インスタンス５０４は特定の動的コンテキスト・グループを定義するために使用する。

｛動的コンテキスト・マスタ・ポートレット｝
動的コンテキスト・マスタ・ポートレットは次に示す事項を担当する。
−−コンテキストの状態の変更を検出すること
−−すべてのスレーブ・ポートレットにコンテキストの状態の変更を通知すること

｛動的コンテキスト・スレーブ・ポートレット｝
動的コンテキスト・スレーブ・ポートレットは次に示す事項を実行する。
−−マスタ・ポートレットが通知したコンテキストの変更を支持すること
−−コンテキストの変更を通知されたときに対応するバックエンド・アプリケーションを指示する登録済みアクションを実行すること

｛動的コンテキストのモデル｝
ポートレットを相互に関連付けるために使用しうる動的コンテキストのモデルには次に示す２種類のものがある。

〔Ａ．２．４ 同期モデル〕
図１４に示す同期モデルでは、マスタ・ポートレット１０１はスレーブ１７０１〜１７０３に動的コンテキスト・マスタ・ポートレットのコンテキストの状態の変更を通知する。その結果、すべてのスレーブは事前に定義した応答に基づくアクションを実行してマスタのコンテキストの状態の変更に同期することなる。

同期モデルの図

〔Ａ．２．５ 連結モデル〕
図１に示す連結モデルでは、マスタＡ（１０１）の状態が変更されると、スレーブＡ（１０２）の応答アクションが惹起される。スレーブＡはマスタ・ポートレットＢでもあるから、コンテキストＢの状態が変更される。その結果、スレーブＢ（１０３）のコンテキストの変更の応答が惹起される。スレーブＢは動的コンテキスト・グループＣのマスタ・ポートレットでもあるから、スレーブＣの応答アクションが惹起される。

〔Ａ．２．６ ポートレット・トランザクション・マネージャ：〕
順番認識ポータル収集エンジン拡張。図１５を参照する。ポートレット・トランザクション・マネージャ１８０２はポートレットの要求、応答、およびセッションの生成を含む、ポートレットの実行時におけるリフレッシュの順番付けの管理を担当するコンポーネントである。

（１）任意のポートレット・アプリケーション用のポートレットのうちで最初にリフレッシュすることになるポートレットを、所定のユーザ用のすべてのポートレットのうちで最初にリフレッシュするポートレットとして定義する。所定のページ内にあるポートレットをリフレッシュする順番を定義する既存の仕組みは存在しない。

したがって、実行時にマスタ・ポートレットを動的に特定できる何らかの論理が求められている。本発明では、単純なスクラッチボードを使用し、各ポートレットはリフレッシュされるたびにそれにマークを付ける。あるポートレットがこのスクラッチボードに初めてマークを付けると、当該ポートレットは自分が最初のポートレットすなわちマスタ・ポートレットであることが分かる。このリストに次にマークを付けるポートレットはそれに他のポートレットがすでにマークを付けているのを知ることができるから、自分がマスタ・ポートレットではないことがわかる、等々。次にポータル・ページをリフレッシュするときにも、最初のポートレットがこのリストに二重のマークを付ければ、それがマスタ・ポートレットになる。次いで、このマスタ・ポートレットは他のすべてのポートレットのマークを除去するとともに自身の二重のマークのうちの１つをも除去することにより、このリストを初期化して次の要求に備える。このアルゴリズムにより、ポートレットのポータル・サーバから要求が入来するたびにマスタ・ポートレットを動的に検出することが可能になる。

最初のポートレットをリフレッシュしたら、トランザクション・マネージャは動的コンポーネント・グループのマスタ・ポートレットとスレーブ・ポートレットをマッピングする際に事前に定義した順番で他のポートレット群をリフレッシュする。

（２）順番ソータ：順番ソータ・モジュール１８０４はポートレット群をそれらのリフレッシュの順番順にソートするために使用する。それはポートレット配備記述子を使用して各ポートレットのリフレッシュの順番を特定した後、それらをソートして要求ディスパッチ・エンジンの用に供する。

（３）順番認識要求ディスパッチ・エンジンの拡張：このエンジン１８０５はポートレットに対する要求をディスパッチするために使用する。このエンジン１８０５はポータル収集エンジンに優先する（override) 。その任務は適切なポートレット要求オブジェクトと応答オブジェクトを構築することである。さらに、商用のポータルに適用した場合には、すべてのポートレット用にポートレット・セッションを構築することである。次いで、トランザクション・マネージャがポートレットを実際にリフレッシュするためにそれを使用する。

（４）トランザクション・マネージャ・キャッシング・ユニット：トランザクション・マネージャ・キャッシング・ユニット１８０６はポートレットが生成した応答を要求ディスパッチ・エンジンがリフレッシュしたときに、当該応答をトランザクション・マネージャ１８０２がキャッシュするために使用する。これが必要なのは、ポータル収集エンジンがポートレットのリフレッシュを要求したときに、トランザクション・マネージャがこれらキャッシュ済みの応答をそれに返送しうるよにするためである。これにより、入来するポータル要求ごとにリフレッシュが二重に発生する問題を防止することが可能になる。

〔Ａ．３．規則ベース収集と役割ベース収集〕
図１１は本発明の好適な実施形態の規則ベースの動的収集コンポーネントの構造マップを示す図である。図示した実施形態のコンポーネントおよびそれらの動作の説明は以下の通りである。

［ポータル・リソース変換モジュール］
ポータル・リソース変換モジュール１０１５はポートレット、ページ、およびページ・グループを含むポータル・リソースの組を、外部規則エンジン１０２２が構文解析して処理しうる形態に変換する任に当たる。

［規則データベース］
規則データベース１００１にはポータル収集エンジン１００６用に企業の管理者が定義した規則が保持されている。

［ユーザ・リソース変換モジュール］
ユーザ・リソース変換モジュール１０１３はユーザ・リソースおよび様々なユーザ属性を、外部の規則エンジンが構文解析して処理しうる形態に変換する任に当たる。

［交換可能な規則エンジン］
規則エンジン１０２２は（本発明のこの実施形態では）外部の交換可能なエンジン、たとえばｗｅｂｓｐｈｅｒｅ（ＴＭ）パーソナライゼーション・エンジンである。規則エンジン１０２２は規則の動的な構文解析と実行のために使用する。このエンジンを実行すると、ユーザが見るはずのポータル・リソースの組が、ビジネス・ユーザが定義したビジネス規則と現在のユーザのユーザ属性とに基づいて生成される。

［ポータル役割ベース・パーソナライゼーション・エンジン］
ポータル役割ベース・パーソナライゼーション・エンジン１００８はあるユーザがアクセスするのを許可されているポータル・リソースのリストと当該ユーザがアクセスするのを許可されていないポータル・リソースのリストとを当該ユーザの組織構成員資格に基づいて抽出する、役割を基準にリソースを選択するモジュールである。

役割ベース・エンジン１００８はまず役割データベース１００７にアクセスすることによりユーザの組織を調査する。ユーザの組織を特定したら、当該ユーザの役割は当該組織の役割と同じものであるとみなす。この後、役割ベース・パーソナライゼーション・エンジン１００８はビジネス・ユーザがこの組織についてアクセス可およびアクセス不可と定義しておいたリソースのリストを抽出する。このリストの導出が済んだら、このモジュールはそれをポータル収集エンジンの収集済みリソース変換サブシステムに転送して後続する処理の用に供する。

［役割ＤＢ］
役割ＤＢ１００７はポータル・サーバ用に組織のデータを保持している。それは様々なユーザの組織構成員資格に関する情報を保持している。また、それは組織の構成員がその役割に基づいてアクセスできるポータル・リソースのリストとアクセスできないポータル・リソースのリストも保持している。

［ポータル収集エンジン収集済みリソース変換サブシステム］
このモジュール１００４は現在のユーザが閲覧するのを許可されているポータル・リソース（これにはポートレット、ページ、およびページ・グループが含まれる）のマスタ・リストを、規則ベース・パーソナライゼーション・エンジンと役割ベース・パーソナライゼーション・エンジンの出力に基づいてを生成する任に当たる。また、このモジュールは実際のポータル収集エンジン用のアダプタでもある。その任務にはこのマスタ・リストを生成することだけでなく、それを実際のポータル収集エンジンがアクセスしうる形態に変換し、エンド・ユーザ用に最終のウェブ・サイトを生成する用に供することも含まれる。

〔パートＢ：動作の説明〕
〔Ｂ．１ ポータルとウェブ・アプリケーションとの統合を可能にすることの説明〕
〔Ｂ．１．１ 全般的な統合構造とフローチャート〕
図２はウェブ・アプリケーションとポータルとを統合する様子を示す図である。図３は統合の構造の示す図である。図４は統合のフローチャートを示す図である。

〔Ｂ．１．２ 詳細な説明〕
図２を参照する。
バックエンド・ウェブ・アプリケーションとポータル・サーバとを統合すると、バックエンド・ウェブ・アプリケーション２２１はポータル・サーバ２０１からポートレットを経由して要求を受領する。そして、バックエンド・ウェブ・アプリケーション２２１は当該要求の生成元のポートレットに応答を返送する。

ウェブ・アプリケーション２２１が出した応答はポータル・サーバ２０１のポートレットを介して、ポートレットにアクセスしているユーザに表示する。

ポータル・アプリケーションｈｔｔｐクライアント２０９が実装されていると、バックエンド・ウェブ・アプリケーションに対する要求と応答を、当該バックエンド・ウェブ・アプリケーションは密結合したセッションとして認識する。ポータル・アプリケーションｈｔｔｐクライアント２０９はバックエンド・ウェブ・アプリケーションに対するｈｔｔｐ通信接続を開くために使用する。バックエンド・ウェブ・アプリケーションはセッション・サポート機能、クッキ処理機能、および単一サインオン（ＳＳＯ）機能を備えるためにポータル・アプリケーションｈｔｔｐクライアント２０９を必要とする。ポータル・アプリケーションｈｔｔｐクライアント２０９が機能していると、ポートレットはウェブ・アプリケーションと効率的に通信することができる。ポートレット・アプリケーション（たとえばポートレット・アプリケーション２０５）中のすべてのポートレットはバックエンド・アプリケーション２２１の１つのポートレット・アプリケーション・セッション・オブジェクト２１１に対するアクセス権を有している必要がある。すなわち、同じポータル・アプリケーション中のすべてのポートレットがポータル・アプリケーションｈｔｔｐクライアント２０９を共用している必要がある。

本発明者らが確認したところによると、このような共用を可能にするには、所定のポータル・アプリケーション中のすべてのポートレットが共用しうる統合セッション・オブジェクトが必要である。そのようなオブジェクトを実現するために、本発明はここではポートレット・アプリケーション・セッション・オブジェクト２０８を備えている。ポートレット・アプリケーション・セッション・オブジェクト２０８は商用のポートレット・アプリケーションが生成するオブジェクトである。ポートレット・アプリケーション・セッション・オブジェクト２０８は所定のポートレット・アプリケーション中のすべてのポートレット（たとえばポートレット・アプリケーション１、２０７中のポートレット２０４、２０５、２０６）がアクセスすることができる。ポートレット・アプリケーション・セッション・オブジェクト２０８がないと、所定のポータル・アプリケーション中の複数のポートレットはすべて独立のユーザ・セッションを持つようになるから、セッション関連の情報を共用できなくなる。

ポートレット・アプリケーション・セッション２０８にはポートレット・アプリケーションｈｔｔｐクライアント２０９が格納されているから、同じポートレット・アプリケーション中のポートレット群の間でそれを共用することが可能になる。このポートレット・アプリケーション・セッションがないと、上記ポートレット群はバックエンドにあるたった１つのウェブ・アプリケーション・セッションとも通信することができなくなる。

ポータル・アプリケーション・セッション・オブジェクト２０８に格納されているすべてのデータはポータル・アプリケーション・セッションのコンテキストを表しており、ユーザごとポータル・アプリケーションごとに存在する。

ポートレット・アプリケーションｈｔｔｐクライアント２０９はバックエンド・ウェブ・アプリケーション２２１用のセッション情報をすべて保持しているから、図３に示すセッション中継機構３２０用の基盤としてそれを使用する。

セッションを中継することにより、すべてのポータル・サーバ２０１に特有のセッション情報（たとえば言語情報、ユーザ・エージェント情報など）をバックエンド・ウェブ・アプリケーション２２１のセッション情報に中継することが可能になる。これは次のことを意味する。すなわち、バックエンド・ウェブ・アプリケーション２２１はユーザがポータル・サーバに送付した最初の要求に含まれているすべての要件に適合するデータ表記を伝達することができる。

たとえば、ユーザが、デフォルトの言語ロケールが「フランス語」に設定された、ＷＡＰ（wireless application protocol)対応の移動装置を使用してポータルにアクセスする場合、ポータル・サーバ２０１に対する最初のｈｔｔｐ要求のＩＴＳ言語パラメータは「フランス語」に設定され、そのＨＴＴＰヘッダのユーザ・エージェント・フィールドは「ＷＡＰ」に設定されることになる。セッション中継機構３２０はこの情報をウェブ・アプリケーション２２１に中継する。そして、当該ウェブ・アプリケーションは上記ユーザの移動装置にフランス語で表示するのに適した応答をフランス語で返す。もしセッションの中継がなければ、ウェブ・アプリケーションはデフォルトの装置（たとえばインターネット・ブラウザ）に適したデフォルトの言語（たとえば英語）で上記情報を返すことになるだろう。その場合、検索・取得した情報は上記ユーザの移動装置に適合していないだろうから、上記ユーザはそれを見ることができないだろう。

次に、図３に示す構造図中の構成要素群を参照するが、図４のプロセス・ステップ群は列挙型ステップ群によって示すことにする。

〈ステップ４０１〉ユーザがウェブ・ポータル上でポートレットと対話する。とえば、当該ユーザのウェブ・ブラウザ上にあるポートレットに表示されているリンクまたはオブジェクトをコンピュータのマウスを用いてクリックすることにより対話する。各ポートレットはそれ自身のポートレット・セッション３１０を持っている（ポートレット・セッションは従来技術の一部である）。ユーザの対話の一部として、遠隔要求３０６をバックエンド・ウェブ・アプリケーション３０７に行ない続ける。

（２）〈ステップ４０３〉ポートレット・セッションにおけるすべてのパラメータをバックエンド・ウェブ・アプリケーションに正確に渡すために、各ポートレット要求のパラメータのリストをポートレット要求パラメータ・マップ（＃８）３０８に格納する。そして、これらのパラメータを遠隔のバックエンド要求に渡す。

（３）〈ステップ４０４〉商用のポートレットではｈｔｔｐクライアント・キー３０１を使用して既存のポートレット・アプリケーション・セッション・オブジェクト２０８およびポートレット・アプリケーションｈｔｔｐクライアント３０３が存在するか否かを判断するが、その判断はポートレット・アプリケーション・データ・ストア（＃４）３０２にアクセスすることにより行なう。〈ステップ４０５〉ポートレット・アプリケーション・セッション・オブジェクト２０８およびポートレット・アプリケーションｈｔｔｐクライアント３０３の一方のものが存在しない場合、同じポートレット・アプリケーション内のすべてのポートレット用に、当該ものを新たに生成る。（〈ステップ４０７〉上記一方のものが存在する場合には、既存の当該ものを使用する。）

（４）〈ステップ４０６〉最初のポートレット・セッションが発行した各ユーザの資格証明書をクッキ・テーブル３０５に保存する。

（５）〈ステップ４０８〉クッキ・テーブル３０５に由来するユーザの資格証明書とポートレット要求パラメータ・マップ３０８に事前に保存しておいたパラメータとを用いてバックエンド・ウェブ・アプリケーションに対する新たなｈｔｔｐ要求を構築する。

（６）〈ステップ４０９〉遠隔ウェブ・アプリケーション３０７に対する呼び出しを行なう。

（７）〈ステップ４１０〉遠隔ウェブ・アプリケーション３０７は上記呼び出しに応答してポートレットに表示を行なわせる。

〔Ｂ．２ ポートレットの動的コンテキストの同期〕
〔Ｂ．２．１ 開発時の説明〕
図５を参照する。図５はポータルにバックエンド・ウェブ・アプリケーションを統合する様子を示す構造図である。図５から、ポータルの開発者は動的コンテキスト・ポートレット・グループ化ツール５０１を用いて動的グループ定義インスタンス５０４の各々を新たに生成しうることが分かる。このインスタンスは関連するポートレット群から成るグループであり、どのポートレットがスレーブであり、どのポートレットがそれらスレーブのマスタであるのかを定義する。動的グループ定義の必要な構成要素は動的コンテキスト・グループ定義テンプレート５０３に指定されている。

ユーザは同じツール５０１を用いて既存の動的コンテキスト・グループの定義を更新する。

ユーザが最新の動的コンテキスト・グループの定義を行なったら、動的コンテキスト・ポートレット・グループ化ツール５０１は適切なポートレット・アプリケーション配備記述子５０２を更新してグループで定義されている関係を反映させる。

図６を参照する。図６はポータルの統合を示すフローチャートを示す図である。図６では上述したプロセスのステップ群がより明瞭に視覚化されている。

ユーザが動的コンテキスト・グループを生成（６０８）または更新（６０９）する必要がある場合、当該ユーザはグループ化ツール５０１を使用することができる（図５）。

〈６０１〉動的コンテキスト・グループ化ツールは動的コンテキスト・グループ定義テンプレート５０３で指定されているものに基づいてユーザの入力を促すが、動的コンテキスト・グループ化ツールを更新する場合には既存の動的コンテキスト・グループ・インスタンスを読み込み、それを動的コンテキスト・グループ定義テンプレート５０３を用いて検査する。

〈６０３〉ユーザは動的コンテキスト・グループを定義または更新するのに必要な情報を指定する。

〈６０５〉動的コンテキスト・グループ・インスタンス５０４を生成する。

〈６０６〉関連するすべてのポートレットの配備記述子を更新する。

（動的コンテキスト・グループ）
図７はポートレット用の動的コンテキストを示す図である。動的グループ７０１はマスタ・ポートレット７０４、スレーブ・ポートレット７０５、およびスレーブ・ポートレット７０７から成る。

グループ７０３はマスタ・ポートレット７０５、スレーブ・ポートレット７０６、およびスレーブ・ポートレット７０７から成る。

動的グループ７０２はマスタ・ポートレット７０４およびスレーブ・ポートレット７０８から成る。

ポートレット・アプリケーション中のポートレット群によって表されるデータがバックエンド・アプリケーションのレベルで同期している場合、当該ポートレット群はウェブ・アプリケーションから当該データを検索・取得することにより、当該データの調整済みのビューを配信する。しかし、ポートレットの対話がすべてバックエンド・ウェブ・アプリケーションの変更を伴うわけではない。動的コンテキストは「ポータル上でユーザが（at the glass）」同期をとるものとして機能する。それが最も効率的なのは、コンテキストの変更が別のクエリを必要とする場合である。たとえば、口座リストから別の口座を選択するには、選択対象の口座を用いてリフレッシュした請求書の情報を表示する必要がある。

従来技術のシステムでは、ポートレットは通常、互いに無関係であった。本発明はポートレット・アプリケーションを開発して構成する時に、ポートレット相互間の関係をマップするとともに、それらの相互依存関係を明確にする方法と装置を提供する。ポートレット自体は変更する必要がない。

ポートレット間の依存関係はマスタ−スレーブ関係が定義してある動的コンテキスト関係テンプレート５０３中に定義することができる。

動的コンテキスト関係テンプレート５０３は次に示す事項を定義した、ＸＭＬ準拠のデータ表記としてエンコードするのが望ましい。すなわち、
−−動的コンテキスト・グループを構成するポートレットから成るサブセット
−−動的コンテキスト・グループのマスタ・ポートレット
−−この動的コンテキスト・グループのスレーブ・ポートレット
−−コンテキストの状態が変更されたときにスレーブが実行する必要のあるスレーブ・アクション
−−この動的コンテキスト・グループのすべての構成員が共用するコンテキスト

動的コンテキスト・グループ定義インスタンスの例を以下に示す。

<DynamicContextGroup>
<DynamicContextGroupName>OrderRelatedPortletGroup
</DynamicContextGroupName>
<DynamicContextMasterPortlet>
OrderItems
</DynamicContextMasterPortlet>
<DynamicContext>itemName
</DynamicContext>
<DynamicContextSlavePortlet>
<DynamicContextSlavePortletName>UPSTracking
</DynamicContextSlavePortletName>
<SlavePortletAction>
http://inventoryserver.com/inStock/
</SlavePortletAction>
</DynamicContextSlavePortlet> </DynamicContextGroup>

<DynamicContextGroup>
<DynamicContextGroupName>StockInventoryPortletGroup
</DynamicContextGroupName>
<DynamicContextMasterPortlet>
InStockInventory
</DynamicContextMasterPortlet>
<DynamicContext>itemSKUnumber
</DynamicContext>
<DynamicContextSlavePortlet>
<DynamicContextSlavePortletName>OrderedItems
</DynamicContextSlavePortletName>
<SlavePortletAction>
http://myserver.com/lastOrdered/
</SlavePortletAction>
</DynamicContextSlavePortlet> </DynamicContextGroup>

動的コンテキスト・グループ定義インスタンスの注釈：１つの動的コンテキスト・グループ定義は１つのインスタンスである。しかし、複数の動的コンテキスト・グループ定義を複数のインスタンスを定義する１つのファイルに統合してもよい。上述した例では、３つのポートレットから成るポートレット・アプリケーションにおいて２つのポートレットの組を定義している。

第１の動的コンテキスト・グループでは、ポートレット間で共用される動的コンテキストはitemNameである。OrderedItemsなる名前のポートレットは動的コンテキスト・マスタ・ポートレットとして機能する。ポートレットUPSTracking およびポートレットInStockInventoryは動的コンテキスト・スレーブ・ポートレットとして機能する。

第２の動的コンテキスト・グループでは、ポートレット間で共用される動的コンテキストはitemSkuNumber である。InStockInventoryなる名前のポートレットは動的コンテキスト・マスタ・ポートレットとして機能する。ポートレットOrderedItemsは動的コンテキスト・スレーブ・ポートレットとして機能する。

各動的コンテキスト・マスタ・ポートレットはユーザのＨＴＴＰ要求を監視し、動的コンテキストを探索する。上記要求中に動的コンテキストを発見したら、当該動的コンテキスト・マスタ・ポートレットはスレーブ・ポートレットに動的コンテキスト（これはｈｔｔｐ要求中の名前と値の対パラメータである）を送付する。

たとえば、ポートレットOrderedItemsは「Pentium(R)IV」にセットされた属性itemNameを有するＨＴＴＰ要求を受信すると、その動的コンテキストをポートレットUPSTracking とポートレットInStockInventoryに送付し、動的コンテキストには値「Pentium(R)IV」を有するコンテキストitemNameが受信時にセットされていたことを通知する。

各動的コンテキスト・スレーブ・ポートレットは同じ動的コンテキスト・グループのすべてのスレーブ・ポートレットに宛てたマスタの通知を監視（listen to)している。マスタの通知を受信したら、対応するスレーブのアクションを呼び出す。それは属性「SlavePortletAction」の下に動的コンテキスト・グループ定義インスタンス中で定義されているアクションＵＲＬに上記動的コンテキストを付加することにより行なう。

たとえば、ポートレットinStockInventoryが、動的コンテキスト型「itemName」と値「Pentium(R)IV」を備えた動的コンテキストをポートレットOrderedItemsから受領した場合、それは次に示すＵＲＬからデータを検索・取得する。
http://inventoryserver.com/inStock/itemName=PentiumIV

動的コンテキスト・グループ定義テンプレート用のコーディングの例を次に示す。

<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:cep="http://www.ibm.com/WebsphereCommerceEnabledPortal/DynamicContextGroupDefinitionSchema">

<annotation>
<documentation xml:lang="en">
Schema for Websphere Commerce Enabled Portal Dynamic Context
Group Definition
Copyright 2002 IBM Corporation
<documentation>
</annotation>

<!-Dynamic Context Group Instance -->
<xsd:element name="DynamicContextGroup"
type="DynamicContextGroupDefinitionTemplate",
minOccurs="1"/>

<!-Dynamic Context Group Definition Schema＿<xsd:complexType name="DynamicContextGroupDefinitionTemplate">
<xsd:sequence>
<xsd:element name="DynamicContextGroupName" type="xsd:string"/>

<xsd:element name="DynamicContextMasterPortlet" type="PortletName"/>
<!- only one dynamic context per dynamic context group ->
<xsd:element name="DynamicContext" type="ContextParameter"maxOccurs="1"/>
<xsd:element name="DynamicContextSlavePortlet" type="SlavePortlet", minOccurs="1"/>
</xsd:sequence> </xsd:complexType>

<xsd:complexType name="SlavePortler">
<xsd:sequence>
<xsd:element name="DynamicContextSlavePOrtlet" type="PortletName"/>
<xsd:element name="SlavePortletAction" type="xsd:string"/>
<xsd:element name="SlavePortletTrfreshPriority" type="xsd:decimal", minOccurs="0"/>
<!- master's context is in the slave url if slave param map is absent -->
<xsd:element name="SlaveParamMapToContext" type="ContextParameter" minOccurs="0"/>
</xsd::sequence>
</xsd:complexType>

<xsd:simpleType name="PortletName">
<xsd:string>
</xsd:simpleType>

<!- name of the parameter in master's request url -->
<xsd:simpleType name="ContextParameter">
<xsd:string>
</xsd:simpleType>

</xsd:schema>

〔Ｂ．２．２ 実行時〕
この章は図８と図９を参照することにより最もよく理解しうるようになる。図８は定義インスタンス中で指定されている動的コンテキスト用にポートレット・アプリケーションを初期化する様子を示す図である。図９は動的コンテキスト・ポートレット・グループの実行時フローである。

動的コンテキストの実行時の側面を扱う主要なコンポーネントには２つのものがある。
（１）DynamicContextActionListner （９０４）（ポートレット・アクション・リスナ）−−これはマスタ・ポートレット中の動的コンテキストの変更を監視（listen for）する。すべての動的コンテキスト・ポートレット・グループ中のマスタ・ポートレットにはDynamicContextActionListner が付加されている。
（２）DynamicContextMessageListner（９０６）（ポートレット・メッセージ・リスナ）−−このメッセージ・リスナは特定の動的コンテキストが定義されているグループのマスタ・ポートレットが出す通知を監視する。動的コンテキスト・ポートレット・グループ中のすべてのスレーブ・ポートレットにはDynamicContextMessageListnerが付加されている。

［実行時フローの逐次的説明：］
ポートレットを初期化する時に（図８：８０１）、すべてのマスタ・ポートレットは定義済みの動的コンテキストをポートレット記述子に基づいて（８０２、８０５）マスタ・ポートレットのアクション・リスナに付加する（８０６）。すべてのスレーブ・ポートレットについて、動的コンテキストの型、アクションのｕｒｌ、パラメータのマッピング、およびリフレッシュの順番をポートレット記述子から検索・取得して（８０２、８０９）スレーブのポートレット・メッセージ・リスナに付加する（８１０）。

（１）ユーザが動的コンテキスト・ポートレット・グループのマスタ・ポートレットと対話すると、動的コンテキストが変更される（９０１）。
（２）マスタのポートレットDynamicContextActionListner がユーザのアクションを検出する（９０２）。
（３）DynamicContextActionListner がマスタ・ポートレットの要求オブジェクト中の動的コンテキストに対応する名前／値対をセットする（９０４）。
（４）マスタ・ポートレットが動的コンテキストの値を取得し、同じ動的ポートレット・グループ内のすべてのスレーブ・ポートレットにそれを通知する（９０５）。
（５）所定のマスタ用のスレーブ・ポートレットに付随するDynamicContextMessageListnerが上記通知（動的コンテキストの値）を受領する（９０６）。
（６）DynamicContextMessageListnerがスレーブ・ポートレットのポートレット要求オブジェクト中のDynamicContextの値をセットする（９０７）。
（７）スレーブ・ポートレットが動的コンテキストの値を取得する（１００８。）
（８）コンテキストと何らかのパラメータとがマッピングされている場合、スレーブ・ポートレットは所定のスレーブ・ポートレット用に定義されたアクションを変更する（１００９）。
（９）マッピングが指定されていない場合、動的コンテキストの名前／値対をスレーブのポートレット・アクションに付加する。
（１０）スレーブ・ポートレットが動的コンテキスト・グループ・インスタンス定義中に定義されているアクションを実行する（１０１１、１０１２）。

〔Ｂ．３ 規則ベースの動的収集と役割ベースの動的収集〕
この章では図１１〜図１５を含む多数の図を参照する。図１１は役割ベースの動的収集のコンポーネントの構造マップを示す図である。図１２は規則ベースの動的収集のコンポーネントの構造マップを示す図である。図１３は規則ベースの動的収集のフローチャートを示す図である。図１４は規則ベースの動的収集のフローチャートを示す図である。図１５は規則ベースの動的収集のフローチャートを示す図である。

ポートレット・サーバ用の役割ベース動的収集のコンポーネントおよび規則ベース動的収集のコンポーネントは規則データベースおよび役割データベースならびに各役割および各規則用のコンテンツ・グループの概念に基づいている。

規則用のコンテンツ・グループは図１１に示す規則ＤＢコンポーネント１００１中に保持する。同様に、役割用のコンテンツ・グループは図１１に示す役割ＤＢコンポーネント１００７中に保持する。各コンテンツ・グループは当該特定の役割または規則の範囲内に入るものと評価済みのユーザが有するアクセス権の対象をなす１組のポータル・サーバ・リソースから成る。

このスキーム（枠組み）中の別の主要なコンポーネントは交換可能規則エンジン１０２２である。このエンジンの仕事は変換済みのユーザ属性を読み込むこと、および、それらのユーザ属性に基づいて、事前に定義済みのあるユーザ・グループの構成員資格を有するユーザから成る組を実行時に動的に決定することである。また、このエンジンはこれら動的なユーザ・グループの組を役割ＤＢと規則ＤＢ中に定義済みのコンテンツ・グループの組にマップすることも行なう。この交換可能規則エンジンはこれらの仕事を管理するためのＧＵＩを備えているのが望ましい。図１９に示すスクリーン・ショットはＷｅｂＳｐｈｅｒｅ（Ｒ）パーソナライゼーション・サーバ・エンジンを用いてこれらの仕事を管理する方法を示している。

たとえば、図１９は「MaleTeen」と呼ばれる動的グループを定義し、１６歳〜１９歳のすべての男子ユーザをこのグループに割り当てる方法を示している。

図２０に示すように、その属性に基づいてティーンエイジャの男子のであると動的に評価されたすべてのユーザは自分達のために「maleteenaction」コマンドを実行されることになる。この「maleteenaction」コマンドは動的規則・役割ベース・ポータル収集エンジン１０２２に役割ＤＢ１００７から十代の男子のグループ用のコンテンツ・リソースを選定するように命じるコマンドである。

開発時には、１組のポータル・リソース（たとえばページ、ポートレットなど）を役割ＤＢと規則ＤＢ中の特定のコンテンツ・グループに割り当てることは会社の管理職の仕事である。これは現在、規則ＤＢと役割ＤＢを直接にロードするＳＱＬスクリプトを用いて行なっている。

〔Ｂ．３．１ 実行時における規則ベースの動的収集と役割ベースの動的収集を可能にすることの説明〕
実行時にポータル・ユーザ用に最初に実行するコマンドは規則ベース・エンジン用のラッパ・コマンドである。実際、このコマンドはプロキシ（代理人）であり、実際の交換可能規則エンジンが行なうユーザ属性の評価を始動させるものである。

次のステップでは、規則エンジンはユーザの属性を当該ユーザの格納済みプロファイルから読み込む。その際、ユーザ・リソース変換モジュールを用いてユーザ・リソースを自分が理解しうる形態に変換する。

図２１は「MaleteenAction」と呼ぶ新たなアクションを生成する様子を示す図である。「MaleteenAction」は規則ＤＢ中で「maleteengrp 」と呼ばれているコンテンツ・グループ中で定義済みのすべてのポータル・リソースを選択するアクションである。

図２０は動的ユーザ属性に基づいて「MaleTeens 」に分類するための事前に生成済みの規則の範囲に入るすべてのユーザについて「maleteengrp 」のコンテンツを選択するように動的収集モジュールに命じる動的収集モジュールのコマンドを生成する様子を示す図である。

図２０は所定のビジネス規則（たとえば十代の男子（maleteen）グループを構成するものを定義しているビジネス規則）が、所定のユーザについて当該ユーザのある属性を用いて収集すべきコンテンツのうちそのような分類に適合するものを決定する際に効果を表す（たとえばMaleteenActionを実行させる）様子を示す図である。

ユーザの属性を読み込んだら、交換可能規則エンジンはこのユーザの動的グループ構成員資格を、図２１に示す様々な動的グループ用に定義された規則に基づいて評価する。

このユーザ用の動的グループの組が確定したら、規則エンジンは図２１に示すこの動的グループ用に定義されたコンテンツ選択アクションを実行することにより、当該ユーザ用に適切なポータル・コンテンツを選択する。これらのアクションは実行されると、規則ＤＢ中に自分用の定義を有する、コンテンツ・グループに由来するポータル・リソースの組を返す。

次の実行ステップはこのユーザに割り当てられた役割を役割エンジンが評価することである。役割エンジンは（ユーザ・プロファイル属性から抽出した）組織構成員資格を用いて当該ユーザの役割用のコンテンツ・リソースの組を役割ＤＢから抽出する。次いで、これらのリソースを先行する組において生成した規則ベース・ポータル・リソースのすでに存在するリストに付加する。

次いで、このリストを動的ポータル収集エンジンに転送して実行の用に供する。次いで、動的ポータル収集エンジンはこのリストが特定しているポータル・リソースを選択してこの現在のユーザ用にデフォルトのポータル・ビューを構築する。

〔まとめ〕
（１）共通のバックエンド・ウェブ・アプリケーションを統合して実装している
ポートレット・アプリケーションｈｔｔｐクライアントとポートレット・アプリケーション・セッションとを使用すると、共通のバックエンド・ウェブ・アプリケーションを統合するモデルが得られる。これを使用すると、同じポートレット・アプリケーション中の複数のポートレットが同じバックエンド・ウェブ・アプリケーションと通信することが可能になる。

本発明のこの実装によって、次に示す事項が可能になる。
（ｉ）ネイティブ（固有）のポートレットの統合を実現して、ブラウザを別々に立ち上げる必要をなくすとともに、同じバックエンド・ウェブ・アプリケーションにアクセスするのにユーザＩＤとパスワードを求めるプロンプトを複数個提示する必要をなくすこと、および、
（ｉｉ）セッションを管理することにより、バックエンド・アプリケーションに対して複数の要求を行なうとともに、それから複数の応答を受領すること。

（２）共通のシステムを単純化することにより、ツーリングを単純化している
本発明はバックエンド・サーバで動作している既存のウェブ・アプリケーションを用いてポートレット・アプリケーション群を統合する容易かつ迅速な方法を提供する。しかも必要なのは上記ポートレット・アプリケーション群の配備記述子に、関連するバックエンド・ウェブ・アプリケーションのｕｒｌを記載することだけである。これにより、統合に共通する仕事を利用するツーリングを構築することが可能になる。

（３）ポートレット・アプリケーション中のポートレット群が共通のセッションと共通のセッション・データとを共用している
ポートレット・アプリケーション・セッション・オブジェクトを実装すると、同じポートレット・アプリケーションのポートレット群が、ポートレット・アプリケーション中で一意であるとともにポータル・サーバの最初のｈｔｔｐセッションのそれとは異なる共通のデータを当該ポートレット群間で共用することが可能になる。これにより、同じポートレット・アプリケーション中のポートレット群間で一意のデータを共用することが可能になる。

（４）ポートレット・セッションとバックエンド・セッションが共通のセッション・データを共用している
セッションの中継を実装すると、ポータル・サーバとそのバックエンド・ウェブ・アプリケーションとの間で共通のセッション・データを共用することが可能になる。これにより、バックエンド・ウェブ・アプリケーションがポータル・サーバから情報を受領することが可能になる。その結果、ウェブ・アプリケーションのビジネス論理はポートレット・サーバから渡されるこの情報を利用することが可能になる。

たとえば、現在のポートレットの状態が当該ポートレットの最大化ビューを表示することである場合、バックエンド・ウェブ・アプリケーションはポートレットの通常のビューの場合とは対照的に、詳細なビジネス情報を返送することにより、この部分（最大化ビュー）の情報を受領し、それを利用することができる。
通常のビューの場合には、バックエンド・ウェブ・アプリケーションは上記情報の簡略版を送付するだけである。

（５）密結合のバックエンド・ウェブ・アプリケーションのセッションをポータル・サーバから峻別している
ポートレット・アプリケーション・セッション、ポートレット・アプリケーション・セッション・オブジェクト、ポートレットｈｔｔｐクライアント、およびセッション中継機構を設けたから、バックエンド・ウェブ・アプリケーションは自分自身のセッションをポータル・サーバのセッションから峻別しておくことができるが、ポータル・サーバのセッションとの間におけるクッキの共用は続けている。これにより、バックエンド・ウェブ・アプリケーションは独立かつ正確に動作しうるようになるから、１つの仮想クライアントとして、ポータル中の様々なポートレットからポートレット要求を受領しうるようになる。その結果、バックエンド・ウェブ・アプリケーションとの密結合のセッションが可能になる。

（６）ポータル・サーバとバックエンド・ウェブ・アプリケーションをまたいだ単一サインオンを実現している
セッションの中継を組み込むと、単一サインオン機能を実現することができる。その結果、ユーザはポータル・サーバに１度ログオンすれば、関連するバックエンド・ウェブ・アプリケーションにログオンするためにユーザ資格証明書を再提出する必要がなくなる。これを可能にしているのはポータルへのｈｔｔｐセッションと、ポートレットｈｔｔｐクライアントからバックエンド・ウェブ・アプリケーションへのｈｔｔｐセッションとの間の一対一マッピングを備えたクッキ・テーブルである。

（７）バックエンド・ウェブ・アプリケーションの振る舞いとポータル・サーバの振る舞いとが同期されている
セッションの中継を組み込むと、切れ目のない統合を実現することが可能になる。それはバックエンド・ウェブ・アプリケーションの振る舞いを同期させることにより行なう。この同期はポータルのセッションからバックエンド・ウェブ・アプリケーションのセッションへセッション情報を中継することにより行なう。

以下、いくつかの例を示す。
あるポータル・サーバにおける言語とロケールの設定をそのバックエンド・ウェブ・アプリケーションに渡すことが可能になるから、当該バックエンド・ウェブ・アプリケーションは当該ポータル・サーバの（ロケール＋言語）の設定に基づいて応答メッセージを作成することが可能になる。

別の例を挙げる。
ポータル・サーバが出すセッション満了情報をバックエンド・ウェブ・アプリケーションに渡すことが可能になるから、バックエンド・ウェブ・アプリケーションのセッションを、ポータルのセッションがタイムアウトするのと同時にタイムアウトさせることが可能になる。バックエンド・ウェブ・アプリケーションはポータル・サーバから中継される、ポータルの状態とイベントに応答しうるようになる。

（８）同じポータル・ページ内にあるコンテンツが同期している
動的コンテンツ・ポートレットをグループ化することにより、同じ動的コンテンツ・グループ内にあるポートレット間の協働が可能になるから、ビジネスのプロセスと情報を統合し同期させることが可能になる。

各ポートレットは複数の動的コンテキスト・グループに参加することが許されている。これにより、ポータルの管理者がポートレット群を動的コンテンツ・ポートレット・グループにグループ化するための開放的かつ単純なプログラミング・モデルが実現する。

動的コンテキスト定義の構造が単純だから、動的コンテキスト・マスタ・ポートレットと動的コンテキスト・スレーブ・ポートレットをグループごとに自動的に生成するツーリングを単純にすることが可能になる。動的コンテキスト定義の実装、動的コンテキスト・グループ、マスタ・ポートレット、および（スレーブ・タスク、スレーブ・コンテキスト・マップを含む）スレーブ・ポートレットの実装は本発明の利点を実現する際に役立つ。

（９）ポートレットをリフレッシュする順番を定義できる
トランザクション・マネージャはポートレットをリフレッシュする順番を最初に定義する能力を備えている。ポートレットをリフレッシュする順番を定義できると、ポータル／ポートレット・アーキテクチャを用いてシーケンシャルなビジネス論理を適切に実装することが可能になる。トランザクション・マネージャ、リソース・ソータ、リソースのキャッシングは本発明の利点を実現する際に役立つ。

（１０）規則ベースかつ役割ベースで収集を行なっている
現在、ポータルのパーソナライゼーションを微細なレベルで行なうには動的収集によるしかない。この動的収集は通常のウェブ・アプリケーションの従来技術による実装とはまったく異なる。従来技術の実装には本発明に適用しうるポートレット、ページ、およびページ・グループの公式な概念がいずれも存在しない。ポータル市場が離陸し、販売促進目標（campaign teargeting)を微細化することを求めるユーザの要求などが現れるのにつれ、微細なレベルのパーソナライゼーションはますます重要になる。

本発明の実施形態によれば、多数の利点が得られる。それらを以下に列挙する。
（１）本発明の手法によって達成しうるパーソナライゼーションのレベルは現在のポータル・サーバが備えているポートレットの管理機能よりもその粒度がはるかに細かい。現在のポータル・サーバが備えているポートレットの管理機能は元来、手動である。いったん構成したら、それは静的であり、実行時に変更できない。本発明はポータル・リソースを規則に基づいて表示する動的機能を備えている。

（２）ポータル収集モジュールは動的なエンティティであるから、それに規則エンジンと役割エンジンを結び付けることにより、人手による関与を必要としないリアルタイムの動的収集機能を実現することができる。

（３）粒度の粗いポータル・リソース（たとえばページやページ・グループなど）をパーソナライゼーションすることにより、レイアウトを動的に行なうことができる。

（４）販売促進や契約などをはるかに効率的に行うことができる。これはｅコマース（電子商取引）小売りの組織化およびＢ２Ｂ（企業間取引）の組織化の双方にとってきわめて重要である。

（５）本発明によれば、通常のコンテンツのパーソナライゼーションよりもはるかに高度のパーソナライゼーションを実現することができる。たとえば、ウェブページを構成する全区画群を規則に基づいて無効にすることができる。これは通常のパーソナライゼーションではできない。また、動的収集はコンテンツには関係するがリソースには関係しない、通常のパーソナライゼーションの領域には適用しない。

動的コンテキスト連結モデルを示す図である。 ウェブ・アプリケーションとポータルを統合する様子を示す図である。 統合の構造を示す図である。 統合のフローチャートを示す図である。 ポータルとウェブ・アプリケーションを統合するための構造を示す図である。 統合するためのフローチャートを示す図である。 ポートレット用の動的コンテキスト・グループの一例を示す図である。 定義インスタンス中で指定されている動的コンテキスト用にポートレット・アプリケーションを初期化する様子を示す図である。 動的コンテキスト・ポートレット・グループき実行時フローを示す図である。 動的コンテキスト・ポートレット・グループき実行時フローを示す図である。 役割ベース動的収集コンポーネントの構造マップを示す図である。 規則ベース動的収集コンポーネントのフローチャートを示す図である。 役割ベース動的収集のフローチャートを示す図である。 役割ベース動的収集のフローチャートを示す図である。 役割ベース動的収集のフローチャートを示す図である。 ウェブ・アプリケーションへのポートレット要求を処理する様子を示す図である。 同期モデルを示す図である。 順番認識ポータル収集エンジン用のフローチャートを示す図である。 「MaleTeen」と呼ぶ動的グループを定義し、ユーザを当該グループに割り当てる様子を示す図である。 規則データベースのコンテンツ・グループを選択するアクションを動的ユーザ・グループに割り当てる様子を示す図である。 「maleTeenAction」と呼ぶ新たなアクションを生成する様子を示す図である。

符号の説明

１０１ マスタＡ
１０２ スレーブＡ
１０３ スレーブＢ
１０４ スレーブＣ
２０１ ポータル・サーバ
２０３ ポートレット・アプリケーション
２０４ ポートレット・アプリケーション
２０４ ポートレット
２０５ ポートレット
２０６ ポートレット
２０７ ポートレット・アプリケーション
２０８ ポートレット・アプリケーション・セッション・オブジェクト
２０９ ポートレット・アプリケーションｈｔｔｐクライアント
２１０ バックエンド・アプリケーション・サーバ
２２１ バックエンド・ウェブ・アプリケーション
３０１ ｈｔｔｐクライアント・キー
３０２ ポートレット・アプリケーション・データ・ストア（＃４）
３０３ ポートレット・アプリケーションｈｔｔｐクライアント
３０５ クッキ・テーブル
３０６ 遠隔要求
３０７ バックエンド・ウェブ・アプリケーション
３０８ ポートレット要求パラメータ・マップ（＃８）
５０１ 動的コンテキスト・ポートレット・グループ化ツール
５０２ ポートレット・アプリケーション配備記述子
５０３ 動的コンテキスト・グループ定義テンプレート
５０４ 動的コンテキスト・グループ・インスタンス
７０１ 動的グループ
７０２ 動的グループ
７０３ 動的グループ
７０４ ポートレット
７０５ ポートレット
７０６ ポートレット
７０７ ポートレット
７０８ ポートレット
１００１ 規則ＤＢコンポーネント
１００７ 役割ＤＢコンポーネント

Claims (16)

1. ウェブ・アプリケーション用のウェブ・ページ・セッションをユーザに表示する装置であり、前記ウェブ・ページ・セッションは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している複数の関連する協働ポートレットを表示するものである、装置であって、
   前記ウェブ・アプリケーションへのアクセスを提供するウェブ・ポータルを運営するポータル・サーバと、
   前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
   規則を格納しうるように適合した規則データベースにアクセスするためのアクセス手段であって、前記規則はポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、アクセス手段と、
   ユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を、前記ユーザが提供する情報に基づいて選択する選択手段と
   を備えた
   装置。
2. 前記選択手段が交換可能な規則エンジンと、前記規則データベースから規則を選択し、規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループを必要に応じてユーザに表示するポートレット・アプリケーション収集エンジンとを備えている、
   請求項１に記載の装置。
3. ウェブ・アプリケーション用のウェブ・ページ・セッションをユーザに表示する装置であり、前記ウェブ・ページ・セッションは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している複数の関連する協働ポートレットを表示するものである、装置であって、
   前記ウェブ・アプリケーションへのアクセスを提供するウェブ・ポータルを運営するポータル・サーバと、
   前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
   役割データベースにアクセスするための役割アクセス手段であって、前記役割データベースはポートレット、ページ、およびページ・グループから成る組のユーザへの表示をユーザの役割に基づいて制御する規則を備えている、役割アクセス手段と、
   ユーザの特定済みの役割に基づき必要に応じて当該ユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を選択する役割選択手段と
   を備えた
   装置。
4. ポータル上で動作している一群の関連するポートレット用にビジネス規則に基づいて行うユーザ用のポータル・リソースの選択を支援する装置であって、
   表示規則を格納する規則データベースと、
   前記規則データベースにアクセスするためのアクセス手段であって、前記規則はポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、アクセス手段と、
   必要に応じてユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を、前記ユーザが提供する情報に基づいて選択する選択手段と
   を備えた
   装置。
5. 前記選択手段が、前記規則データベース中の規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示する規則エンジンを備えている、
   請求項４に記載の装置。
6. 前記選択手段が、規則エンジンと、前記規則データベース中の規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示するポートレット・アプリケーション収集エンジンとを備えている、
   請求項５に記載の装置。
7. 前記選択手段が、交換可能な規則エンジンと、前記規則データベース中の規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示するポートレット・アプリケーション収集エンジンとを備えている、
   請求項３に記載の装置。
8. ポータル上で動作している一群の関連するポートレット用にビジネス規則に基づいて行うユーザ用のポータル・リソースの選択を支援する装置であって、
   前記ポータル・サーバ上で動作するとともに、関連する一群のポートレットを管理するポートレット・アプリケーションと、
   役割データベースであって、前記役割データベースはポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、役割データベースと、
   前記役割データベースにアクセスするための役割アクセス手段と、
   ユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を前記ユーザの特定済みの役割に基づいて選択する役割選択手段とを備えた装置。
9. ウェブ・アプリケーション用のウェブ・ページ・セッションをユーザに表示する方法であり、前記ウェブ・ページ・セッションは、前記ユーザによってアクセス可能であるとともに相互に情報を共用している複数の関連する協働ポートレットを表示するものである、方法であって、
   前記ウェブ・アプリケーションへのアクセスを提供するウェブ・ポータルすなわちポータル・サーバを運営するステップと、
   前記ポータル・サーバ上で動作するとともに、ポートレット・アプリケーションに関連付けられた一群のポートレットを管理するステップと、
   規則を格納する規則データベースにアクセスするステップであって、前記規則はポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、ステップと、
   必要に応じてユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を、前記ユーザが提供する情報に基づいて選択するステップと
   を備えた
   方法。
10. ポータル上で動作している一群の関連するポートレット用にビジネス規則に基づいて行う、ユーザ用のポータル・リソースの選択を支援する方法であって、
    表示規則を格納する規則データベースを準備するステップであって、前記規則はポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、ステップと、
    前記規則データベースにアクセスするステップと、
    必要に応じてユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を、前記ユーザが提供する情報に基づいて選択するステップと
    を備えた
    方法。
11. 前記規則データベース中の規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示するために規則エンジンを使用する、
    請求項１０に記載の方法。
12. 前記規則エンジンおよびポートレット・アプリケーション収集エンジンが、前記規則データベース中の前記規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示する、
    請求項１１に記載の方法。
13. 交換可能な規則エンジンおよびポートレット・アプリケーション収集エンジンが、前記規則データベース中の前記規則を適用してポートレット、ページ、およびページ・グループを選択し、選択したポートレット、ページ、およびページ・グループをユーザに表示する、
    請求項９に記載の方法。
14. ポータル上で動作している一群の関連するポートレット用にビジネス規則に基づいて行う、ユーザ用のポータル・リソースの選択を支援する方法であって、
    役割データベースを準備するステップであって、前記役割データベースはポートレット、ページ、およびページ・グループから成る組のユーザへの表示を制御する規則を備えている、ステップと、
    前記役割データベースにアクセスするステップと、
    ユーザに表示すべきポートレット、ページ、およびページ・グループから成る組を前記ユーザの特定済みの役割に基づいて選択するステップと
    を備えた
    方法。
15. コンピュータ読み取り可能な信号担持媒体と、
    請求項１０〜１３のうちの１項に記載の方法を実行しうるように適合し、前記媒体に記録されたコンピュータ・プログラム・コード手段とを備えた製品。
16. コンピュータ読み取り可能な信号担持媒体と、
    請求項１〜８のうちの１項に記載の装置を実装しうるように適合し、前記媒体に記録されたコンピュータ・プログラム・コード手段とを備えた製品。

Images