(57)【特許請求の範囲】
【請求項１】
ユーザがアクセス可能なウェブ・ポータル内の複数の関連するポートレットをグループ化する、ポータル・サーバ上で動作することができるポートレット・アプリケーションであって、
各ポートレットは、コンテキスト名を記述するポートレット記述子を有し、
複数の関連するポートレットのグループは、マスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを含み、かつコンテキスト名を共通に共有し、
前記ポートレット・アプリケーションは、前記ポータル・サーバに、
マスタ・ポートレットのコンテキスト値の変化を前記マスタのスレーブ・ポートレットに同報通信するステップと、
前記スレーブ・ポートレットのコンテキスト値を変更して、同報通信した前記マスタ・ポートレットのコンテキスト値に合致させるステップと
を実行させるポートレット・アプリケーション。
【請求項２】
前記ポートレット記述子は、前記ポートレットに関するリフレッシュの優先順位の記述を含み、
前記ポートレット・アプリケーションは、前記ポータル・サーバに、前記ポートレットを前記ポートレットのリフレッシュの優先順位でリフレッシュするステップを更に実行させる、請求項１に記載のポートレット・アプリケーション。
【請求項３】
前記マスタ・ポートレットが、前記スレーブ・ポートレットよりも高い優先順位を有する、請求項２に記載のポートレット・アプリケーション。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はインターネットに関し、より詳細には、ウェブ・アプリケーションでポータルおよびポートレットを生成および使用して、ウェブ・サイトに関する機能を向上する方法および装置に関する。
【背景技術】
【０００２】
ワールド・ワイド・ウェブは、ユーザにグラフィカル情報を搬送する、インターネットを介する通信への大きなパラダイム・シフトをもたらした。ウェブの出現と共に、通信性および高域接続性が依然としてますます求められている。
【０００３】
ポータル（以前はウェブ・ポータルと呼ばれていた）は、インターネット空間においてパラダイム・シフトをもたらした。Ｅメール、フォーラム、検索エンジン、データベース、その他の情報などの多数の資源またはサービスを提供するウェブ・サイトはポータルとみなすことができる。最初のウェブ・ポータルはオンライン・サービスであった。最初は、インターネットをサーフィンするユーザが、ワールド・ワイド・ウェブの様々なサイトから来る情報を集めて提供するウェブ・ページを見ることができたが、集合の構成はユーザに透過的であった。典型的なウェブ・ブラウザを利用するユーザは、表示される結合ウェブ・ページを見る。閲覧しているウェブ・サイトに関連しない、様々なインターネット・サイトからのページの様々な部分の起源は容易には識別できない。こうした部分はポートレットと呼ばれる。
【０００４】
ポートレットは、エンド・ユーザがそのポータル・ページ内に見る、目に見えるアクティブな構成要素である。ＰＣデスクトップ内のウィンドウと同様に、各ポートレットは、結果をそこに表示する、ブラウザまたは携帯情報端末の一部を「所有」する。
【０００５】
ユーザの観点からは、ポートレットは、ユーザがそれに加入し、ユーザの個人ポータル・ページにそれを追加し、パーソナライズしたコンテンツを表示するようにそれを構成するコンテンツ・チャネルまたはアプリケーションである。
【０００６】
コンテンツ・プロバイダの観点からは、ポートレットは、コンテンツ・プロバイダのコンテンツを利用できるようにする手段である。
【０００７】
ポータル管理者の観点からは、ポートレットは、ポータルに登録することのできるコンテンツ・コンテナであり、それによってユーザはそれに加入することができる。
【０００８】
ポータルの観点からは、ポートレットは、ポータルのページの１つにレンダリングされる構成要素である。
【０００９】
技術的観点からは、ポートレットはポータル・サーバ上で動作し、ポータル・ページに埋め込むべきコンテンツを提供する１つのコードまたは小規模アプリケーションである。最も単純な言い方として、ポートレットは、ポータル内部で動作するＪａｖａ（Ｒ）サーブレットでよい。
【００１０】
（通常はワールド・ワイド・ウェブ中の様々な場所を源とする）所与のページの各部分（ポートレット）は、同じページの別の部分（ポートレット）と協働して、ページにサーフィンまたはアクセスするユーザに対してより高い機能を達成することができる。したがって、ポータルは、複数のユーザにとって、複数のチャネルを介する複数の情報源への単一アクセス・ポイントとなる。
【００１１】
ポータルは様々なビジネス・モデル、すなわちＢ２Ｃ、Ｂ２Ｂ、またはＢ２Ｅに応用することができる。ポータル・パラダイムの急速な採用の鍵は、既存のウェブ・アプリケーション・データをシームレスにポータル・フレームワークに統合できることに強く結びついている。
【００１２】
しかし、そのようなシームレスなウェブ・アプリケーションのポータルへの統合に関して様々な技術的障害が依然として存在している。
【００１３】
従来技術では、以下のポータル・アーチファクトがどのように既存のウェブ・アプリケーションと一緒に働くかに関して制限がある。ウェブ・アプリケーションのポータル・アーキテクチャへの統合の実施は明確ではない。こうしたエンティティには以下のものが含まれる。
ポータルに対する元のｈｔｔｐ要求
ポータル内のポートレット・セッション
ポータルから関係するウェブ・アプリケーションへのｈｔｔｐ要求
【００１４】
異なるユーザがポータル・ページにアクセスするとき、各ユーザについての元のｈｔｔｐ要求が、ポータル・サーバ（ａ）に向けて送られる。各ユーザについての元のｈｔｔｐセッションもまた、ポータル・サーバによって完全に「所有される」。各ポートレットは、ポートレット・セッションと呼ばれるそれ自体の独立セッションを有する。ポートレットが所与のウェブ・アプリケーションから来る情報をレンダリングする必要があるとき（ｂ）、一般には以下の技術的障害が存在する。
ｉ．ポートレットが、バックエンド・ウェブ・アプリケーションへの、およびバックエンド・ウェブ・アプリケーションからのｈｔｔｐ要求および応答を生成する既存の機構が存在しない。
ｊ．バックエンド・ウェブ・アプリケーション（およびウェブ・アプリケーションのセッション）への複数の要求および応答と正確にマッピングする呼出し側ポートレット（およびポートレット・セッション）への複数の要求および応答を管理する既存の機構が存在しない。それぞれ（ポートレットとウェブ・アプリケーションの両方）がそのユーザ・セッションをそれに応じて維持する。
【００１５】
これにより、複数のポートレットが同一のウェブ・アプリケーションを呼び出すときに複雑になり、ウェブ・アプリケーションは、これらの複数のポートレット要求を同一のウェブ・アプリケーション・セッション内で処理する。
ｋ．複数のポートレット・セッションとウェブ・アプリケーションのセッションとの間でセッション情報を中継する既存の機構が存在しない。
【００１６】
同一のポートレット・アプリケーション内の明確な１組のポートレットがバックエンドで１つのウェブ・アプリケーションと対話するとき、関与するすべてのポートレットが、ウェブ・アプリケーションからレンダリングされる情報がポートレットのポータルの情報の設定と整合するように、バックエンドで正確なセッション情報を取り出してウェブ・アプリケーションに転送できなければならない。このような設定の例には、ロケール情報、その特定のアクセスのユーザ・エージェントなどが含まれる。例えば、ウェブ・アプリケーションから送られる応答は、それを表示するポータル・サーバ内のポートレットと同じロケールを使用していなければならない。
【００１７】
ポータル・ユーザの証明書がバックエンド・ウェブ・アプリケーションによってチャレンジされないような単一サインオンのための既存の機構は存在しない。これは重要な要件である。この欠如の結果として、ユーザがウェブ・ページの一部分から同一のウェブ・ページの異なる部分に移動するときに、ユーザの証明書がチャレンジされることになる。ポートレットが異なる起源および識別要件を有するからである。
【００１８】
所与のポートレット・アプリケーションのポートレットと関係するウェブ・アプリケーション・バックエンドとの間で複数の要求または応答を同期する既存の機構は存在しない。
【００１９】
従来技術は、同一のポートレット・アプリケーション内の複数のポートレットがどのように（同一のコンテキストを共有して）互いに、ならびに様々な統合ウェブ・アプリケーションと動的に協働することができるかが定義されないことに関して制限を有する。
【００２０】
同一の「コンテキスト」を動的に共有することによって協働する複数のポートレットに関する１つの使用法のシナリオは、この制限を概念的に例示するのに役立つ。
【００２１】
同一のポータル・ウェブ・ページ上に３つのポートレットが表示されている場合、
第１のポートレットが、取引先のリストを表示することによって取引先一覧を示す
第２のポートレットが、所与の取引先の未払いのインボイスのリストを示す
第３のポートレットが、所与の取引先の注文履歴一覧を示す
【００２２】
第２ポートレットおよび第３ポートレットは、コンテキスト的に第１ポートレットに動的にバインドされ、未払いのインボイス（第２ポートレット）および注文履歴（第３ポートレット）を反映し、第１ポートレットの取引先リストから選択された取引先と同期される。
【００２３】
従来技術の制限
ｉ．協働的に働くポートレット・アプリケーション内のポートレットのサブグループ分けを定義する機構が存在しない。
ｊ．所与のポートレット・アプリケーション内のこのポートレットのサブグループ間で共有されるコンテキスト（動的に変更することができる）を定義する機構が存在しない。ここでのコンテキストの例は、ポートレット１内の選択した取引先であり、そのような取引先の選択は動的に変更することができる。
ｋ．コンテキストの変化を動的に検出する機構が存在しない。変更の例は、上記の例のポートレット１内の取引先リストのある取引先から別の取引先への変更である。
ｌ．同一のコンテキストを共有するポートレットのサブグループ内の関与する各ポートレットについて事前定義されたアクション（または応答）を登録する機構が存在しない。例は、コンテキストが（ある取引先選択からポートレット１内の別の取引先に）変化したときに未払いのインボイスのリストを表示する（ポートレット２でのアクション）ことである。
ｍ．その動的コンテキストを関係する統合ウェブ・アプリケーションに中継する機構が存在しない。
【００２４】
ポートレット・アプリケーション内の１群のポートレットについてリフレッシュ・シーケンスを定義する機構が従来技術には存在しない。
ｉ．ポータル設計者が表示される所与の１組のポートレットのリフレッシュ順序を指定
するための備えが今日存在しない。
【００２５】
上記のシナリオでは、ポータル設計者は、第１ポートレット（アカウント・リスト）をまずリフレッシュし、第２ポートレットを２番目にリフレッシュし、以下同様であり、その結果、第２ポートレットおよび第３ポートレットが自動的に正しいシーケンスで行われるアクションを（ポートレットが配置されるとき）定義していることを望む。
【００２６】
ビジネス規則とユーザの役割を含むユーザ・プロファイリング情報とに基づいてポートレットの集合をサポートする明確な機構がポータル・アーキテクチャで欠如している。
ｉ．ビジネス規則に基づいてユーザごとのポータル資源の集合を定義する既存の機構が存在しない。例：ティーンエージャのすべてのポータル・ユーザがポートレットのあるグループを見、年長のポータル・ユーザがポートレットの別のグループを見る。
ｊ．実行時に動的に実行されるそのような規則ベースおよびユーザ・ベースのポートレットの集合のための既存の機構が存在しない。
【００２７】
関係する統合バックエンド・ウェブ・アプリケーションとのポータル・レベル・ビジネ
ス規則およびユーザ・プロファイル情報の共有が存在しない。
【００２８】
規則およびユーザ・セグメント化をポータルおよびその統合バックエンド・ウェブ・アプリケーションにわたって整合させることができるような、統合ウェブ・アプリケーションとのこうしたビジネス規則またはユーザ・セグメント化情報の共有は存在しない。例えば、ティーンエージャの範囲の年齢を定義する規則が存在する場合、そのような規則は、整合性のために、統合ウェブ・アプリケーションにとって可視であり、かつ統合ウェブ・アプリケーションに対して適用可能であるべきである。
【００２９】
用語
ポートレット
ポートレットは、エンド・ユーザがそのポータル・ウェブ・ページ内に見る、目に見えるアクティブな構成要素である。ＰＣデスクトップ内のウィンドウと同様に、各ポートレットは、ポートレット特有の情報をそこに表示する、ブラウザまたはＰＤＡ（Personal Digital Appliance）の一部を「所有」する。
【００３０】
ポートレット・アプリケーション
ポートレットはまた、ポートレット・アプリケーションでグループ化することができる。ポートレット・アプリケーションは、ウェブ・アーカイブ・ファイル（ＷＡＲ）を使用して配布および配置される。標準ウェブ・アプリケーション配置記述子に対するポートレット特有の拡張が存在する。
【００３１】
ポートレット・メッセージ
ポートレット・アクションおよびポートレット・メッセージを使用する２つのポートレット間の通信のためにポートレット・メッセージが使用される。送信側ポートレットはポートレット・アクションを作成し、アクションをＵＲＬに符号化する。例えばタスクを実施することを試みるユーザにより、ＵＲＬがアドレス指定されたとき、アクション・リスナが呼び出され、必要なデータを送信するためにポートレット・メッセージを送信する。
【００３２】
ポートレット・セッション
ログオンする各ユーザについての各ポートレット・インスタンスについてポートレット・セッションが作成され、各ユーザのポートレット・インスタンスごとにセッション情報が維持される。
【００３３】
所与のポートレット・アプリケーションのポートレットは今日、同一のポートレット・アプリケーション内の複数のポートレットがどのように同一のコンテキストを共有して互いに協働することができ、それによって統合ウェブ・アプリケーションからの応答をレンダリングするこうしたポートレットがコンテキストに関して動的にコンテンツをレンダリングすることができるかに関して制限を有する。
【００３４】
今日、関与するポートレットのコード変更が不要となるように協働的に働くポートレット・アプリケーション内のポートレットのサブグループを定義する機構も存在しない。コンテキストの変化を動的に検出する機構も存在せず、今日、関与するポートレットについて事前定義されたアクションを登録する機構も、その動的コンテキストを関連する統合ウェブ・アプリケーションに中継する機構を含めて存在しない。
【発明の開示】
【発明が解決しようとする課題】
【００３５】
本明細書の発明の様々な実施形態および態様は、従来技術の１つまたは複数の欠点に対処する。
【課題を解決するための手段】
【００３６】
本発明による方法は、同一の動的コンテキスト・ポートレット・グループ内のポートレット間の協働を可能してビジネス・プロセスおよび情報統合および同期を達成する動的コンテキスト・ポートレット・グループを利用する。
【００３７】
本発明の別の実施形態は、コンテキスト値を定義するコンテキスト名を記述するポートレット記述子をそれぞれ有する複数の関連するポートレットを管理する方法を提供する。ポートレットの各グループは、マスタ・ポートレットと少なくとも１つのスレーブ・ポートレットとを含み、ポートレットの各グループはコンテキスト名を共通に共有する。
【００３８】
本発明の別の実施形態は、マスタ・ポートレットのコンテキスト値の変化をスレーブ・ポートレットに同報通信するポータル・サーバ内の手段を含む。各ポートレット記述子は、ポートレットのリフレッシュ優先順位記述を含む。マスタ・ポートレットは、スレーブ・ポートレットよりも高い優先順位を有する。
【００３９】
本発明の実施形態により、情報統合およびビジネス・プロセス統合の同期が可能となる。動的コンテキスト・グループの単純な構造により、ポートレットの実装変更を必要としない配置を介するコンテキスト・グループ化が可能となり、本発明の利点が提供される。
【００４０】
本発明の一実施形態は、ウェブ・アプリケーションに関するウェブ・ポータルをユーザに表示する装置において、ウェブ・ポータルが、互いに情報を共有し、ユーザがアクセス可能な複数の関連するポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションとを含み、ポートレット・アプリケーションが、ウェブ・アプリケーションにアクセスすることをユーザが要求したときにポートレットを開始する手段と、ポートレットに関するポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって制御され、ポートレットをポートレット・アプリケーション・セッション・オブジェクトと関連付けるユーザ要求からのパラメータを保存するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアとを含む装置を提供する。
【００４１】
本発明の装置は、ポートレット・アプリケーション・セッション・オブジェクトと前記ウェブ・アプリケーションとの間で通信して、関連するポートレットから受信したユーザ要求をウェブ・アプリケーションに搬送するためのポートレット・アプリケーション内のポートレット・アプリケーション通信クライアントを含むことができる。ポートレット・アプリケーションは、ポートレット・アプリケーション・セッション・オブジェクトに関連する各ポートレットに共通鍵を割り当てることができる。
【００４２】
本発明の別の実施形態は、ウェブ・アプリケーションに関するウェブ・ポータルを複数のユーザに表示する装置において、ウェブ・ポータルが、情報を共有し、ユーザがアクセス可能な複数の関連するポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、複数の各ユーザについてのポータル・サーバ上で動作し、複数の各ユーザについて関連するポートレットの集合を管理するポートレット・アプリケーションとを含み、各ポートレット・アプリケーションが、ウェブ・アプリケーションにアクセスすることを複数のユーザのうちの１人が要求したときにポートレットを開始する手段と、ポートレットに関するポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって制御され、ポートレットをポートレット・アプリケーション・セッション・オブジェクトと関連付けるユーザ要求からのパラメータを保存するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアとを含む装置を提供する。
【００４３】
本発明の別の実施形態は、複数のウェブ・アプリケーションに関するウェブ・ポータルをユーザに表示する装置において、ウェブ・ポータルが、互いに情報を共有し、ユーザがアクセス可能な複数の関連するポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作する複数のウェブ・アプリケーションにそれぞれ関係する複数のポートレット・アプリケーションであって、関連するポートレットの集合を管理するようにそれぞれ適合されたポートレット・アプリケーションとを含み、各ポートレット・アプリケーションが、複数のウェブ・アプリケーションの１つにアクセスすることをユーザが要求したときにポートレットを開始する手段と、ポートレットに関するポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって制御され、ポートレット・アプリケーションのポートレットをポートレット・アプリケーションのポートレット・アプリケーション・セッション・オブジェクトと関連付けるユーザ要求からのパラメータを保存するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアとを含む装置を提供する。
【００４４】
本発明の装置の別の態様は、ポートレット・アプリケーション・セッション・オブジェクトを有する複数のウェブ・アプリケーションに接続するように適合されたユーザ・セッション情報テーブルを含む。
【００４５】
本発明のさらに別の実施形態は、ウェブ・アプリケーションに関するウェブ・ポータルをユーザに表示する装置において、ウェブ・ポータルが、互いに情報を共有し、ユーザがアクセス可能な複数の関連するポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションとを含み、ポートレット・アプリケーションが、ウェブ・アプリケーションにアクセスすることをユーザが要求したときに第１ポートレットを開始する手段と、ユーザに対して第１ポートレットに関するポートレット・アプリケーション・セッション・オブジェクトを作成する手段と、要求からのパラメータを保存する手段と、ウェブ・アプリケーションにアクセスすることをユーザがさらに要求したときに第１ポートレットに関連する追加のポートレットを生成する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって制御され、追加のポートレットをポートレット・アプリケーション・セッション・オブジェクトと関連付ける保存パラメータを使用するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと、ポートレット・アプリケーション・セッション・オブジェクトおよびウェブ・アプリケーションと通信して、第１ポートレットおよび追加のポートレットから受信したユーザ要求をウェブ・アプリケーションに搬送するポートレット・アプリケーション通信クライアント（httpClient）を作成する手段とを含む装置を提供する。
【００４６】
この装置は、ポートレット・アプリケーション・セッション・オブジェクトと前記ウェブ・アプリケーションとの間で通信して、関連するポートレットから受信したユーザ要求をウェブ・アプリケーションに搬送するためのポートレット・アプリケーション内のポートレット・アプリケーション通信クライアントを含むことができる。
【００４７】
ポートレット・アプリケーションが、ポートレット・アプリケーション・セッション・オブジェクトに関連する各ポートレットに共通鍵を割り当てることが好ましい。
【００４８】
有利には、ポートレット・アプリケーション・セッション・オブジェクトを有する複数のウェブ・アプリケーションに接続するように適合されたユーザ・セッション情報テーブルを設けることができる。
【００４９】
本発明の別の実施形態は、ウェブ・アプリケーションに関するウェブ・ポータルをユーザに表示する装置において、ウェブ・ポータルが、互いに情報を共有し、ユーザがアクセス可能な複数の関連するポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションとを含み、ポートレット・アプリケーションが、ウェブ・アプリケーションにアクセスすることをユーザが要求したときにポートレットを開始する手段と、ポートレットに関するポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって制御され、ポートレットをポートレット・アプリケーション・セッション・オブジェクトと関連付けるユーザ要求からのパラメータを保存するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアとを含む装置を提供する。
【００５０】
本発明の別の態様は、ウェブ・ポータル内の複数の関連するポートレット間で情報を共有する方法であって、複数の関連する各ポートレットについてポートレット・データ・ストアへのアクセスを付与するステップと、複数の関連する各ポートレットがポートレット・データ・ストアにデータを書き込み、ポートレット・データ・ストアから格納されたデータを読み取ることを許可するステップとを含む方法を提供する。
【００５１】
有利には、上記の方法は、関連するポートレットが、データ処理システム上で動作するように適合されたポートレット・アプリケーションによって管理され、ポートレット・データ・ストアが、データ・ストア内の関連するポートレットによるデータの読取りおよび書込みを制御し、ポートレット・アプリケーションの関連するポートレット間でデータの交換を可能にするポートレット・アプリケーション・セッション・オブジェクトによって管理されるポートレット・アプリケーション・ストレージを含むシステムを提供することができる。
【００５２】
本発明の別の態様は、ウェブ・ポータル内の複数の関連するポートレット間で情報を共有する装置であって、複数の関連するポートレットを管理するポートレット・アプリケーションと、ポートレット・アプリケーション・データ・ストアと、複数の関連するポートレットによるデータ・ストアへの読取り／書込みアクセスを付与して、ポートレットが互いにデータを交換することを可能にする手段とを含む装置を提供する。
【００５３】
本発明のさらに別の態様は、ウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット（アプリケーション）サーバであって、複数の関連するポートレットを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって管理され、複数の関連するポートレットに対するデータ・ストアへの読取り／書込みアクセスを付与して、ポートレットが互いにデータを交換することを可能にするポートレット・アプリケーション・データ・ストアとを含むポートレット（アプリケーション）サーバを提供する。
【００５４】
本発明の別の態様は、ウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット（アプリケーション）サーバであって、複数の関連するポートレットを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトを作成および管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって作成および管理され、複数の関連するポートレットに対するデータ・ストアへの読取り／書込みアクセスを付与して、ポートレットが互いにデータを交換することを可能にするポートレット・アプリケーション・データ・ストアとを含むポートレット（アプリケーション）サーバを提供する。
【００５５】
有利には、ポートレット・アプリケーションが、ポートレット・アプリケーション・セッション・オブジェクトに関連する各ポートレットに共通鍵を割り当てる。
【００５６】
本発明の別の態様は、ユーザがアクセス可能なウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット・アプリケーションであって、複数の関連するポートレットを管理するポートレット・アプリケーション手段と、ユーザに関するポートレット・アプリケーション・セッション・オブジェクトを管理するポートレット・アプリケーション手段と、ポートレット・アプリケーション・オブジェクトへのアクセスを制御するためにこの鍵を関連する各ポートレットに付与するポートレット・アプリケーション手段とを含むポートレット・アプリケーションを提供する。
【００５７】
本発明のさらに別の態様は、ユーザがアクセス可能なウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット・アプリケーションであって、複数の関連するポートレットを管理するポートレット・アプリケーション手段と、ユーザに関するポートレット・アプリケーション・セッション・オブジェクトを作成および管理するポートレット・アプリケーション手段と、ユーザに対してポートレット・アプリケーション・セッション・オブジェクトに関する鍵を作成および管理するポートレット・アプリケーション手段と、ポートレット・アプリケーション・オブジェクトへのアクセスを制御するためにこの鍵を関連する各ポートレットに付与するポートレット・アプリケーション手段とを含むポートレット・アプリケーションを提供する。
【００５８】
有利には、各ユーザに１つのポートレット・アプリケーションが割り当てられ、各ユーザについて、各ポートレット・アプリケーションに関するポートレット・アプリケーション・オブジェクトにそれぞれ１つの鍵が割り当てられる。
【００５９】
本発明の別の態様は、ウェブ・アプリケーションに関するウェブ・ポータルをユーザに表示する装置において、ウェブ・ポータルを操作してユーザによるウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションと、ユーザに関する、関連するポートレットに関するポートレット・アプリケーション・セッション・オブジェクトと、ポートレット・アプリケーション・セッション・オブジェクトによって制御されるポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと、ポートレット・アプリケーション・データ・ストアにリンクされ、関連するポートレットとウェブ・アプリケーションとの間で通信して、関連するポートレットから受信されたユーザ要求をウェブ・アプリケーションに搬送するポートレット・アプリケーション通信クライアントと、関連するポートレットからの要求を格納および同期し、通信クライアントがウェブ・アプリケーションに対する同期要求を生成する要求バッファを有する通信クライアントとを含む装置を提供する。
【００６０】
ポートレット・アプリケーション通信クライアントが、要求を含む情報をネットワークを介してウェブ・アプリケーションに送信し、要求に対する応答を含む情報をウェブ・アプリケーションから受信するように適合されることが好ましい。
【００６１】
本発明の別の態様は、ウェブ・アプリケーションに関するウェブ・ポータルをユーザに表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションと、ユーザに関する、関連するポートレットに関するポートレット・アプリケーション・セッション・オブジェクトと、ポートレット・アプリケーション・セッション・オブジェクトによって制御されるポートレット・アプリケーション・セッション・オブジェクト・データ・ストアと、関連するポートレットとウェブ・アプリケーションとの間で通信して、関連するポートレットから受信されたユーザ要求をウェブ・アプリケーションに搬送するポートレット・アプリケーション通信クライアントと、関連するポートレットからの要求を格納および同期し、通信クライアントがウェブ・アプリケーションに対する直列化要求を生成する要求バッファを有する通信クライアントとを含む装置を提供する。
【００６２】
ポートレット・アプリケーション通信クライアントが、要求を含む情報をネットワークを介してウェブ・アプリケーションに送信し、要求に対する応答を含む情報をウェブ・アプリケーションから受信するように適合されることが好ましい。
【００６３】
本発明の別の態様は、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するように適合されたポータル・サーバであって、ポータル・サーバ上で動作して、関連するポートレットの集合を管理するポートレット・アプリケーションを有し、ポートレット・アプリケーションが、ウェブ・アプリケーションにアクセスすることをユーザが要求したときにポートレットを開始する手段と、ポートレットに関するポートレット・アプリケーション・セッション・オブジェクトを管理する手段と、ポートレット・アプリケーション・セッション・オブジェクトによって制御され、ポートレットをポートレット・アプリケーション・セッション・オブジェクトと関連付けるユーザ要求からのパラメータを保存するポートレット・アプリケーション・セッション・オブジェクト・データ・ストアとを含み、ポートレット・アプリケーション・データ・ストアにリンクされ、関連するポートレットとウェブ・アプリケーションとの間を通信して、関連するポートレットから受信したユーザ要求をウェブ・アプリケーションに搬送するポートレット・アプリケーション通信クライアント（httpClient）と、ユーザＩＤ、ユーザ証明書、言語プリファレンス、セッション・タイムアウト情報、セッションｉｄなどのユーザ・セッション情報の組から選択される情報を含むユーザ・セッション情報を格納してユーザ・セッション情報をウェブ・アプリケーションの対応するセッションにマッピングするユーザ・セッション情報ストア（マッピング・テーブル）を有するポートレット・アプリケーション通信クライアントとを含む装置を提供する。
【００６４】
セッション・タイムアウト情報が、ポータル・サーバおよびウェブ・アプリケーションのセッション・タイムアウト情報を含むことが好ましい。
【００６５】
本発明の別の態様は、ポータル内の関連するポートレットの集合を管理し、サーバ上で動作してユーザによるウェブ・アプリケーションへのアクセスを実現するポートレット・アプリケーションであって、関連するポートレットが、ポートレットに対するユーザ要求からのデータおよび命令を格納するポートレット要求パラメータ・マップと、ユーザに関する、関連するポートレットに関するポートレット・アプリケーション・セッション・オブジェクトと、ポートレット・アプリケーション・セッション・オブジェクトによって制御されるポートレット・アプリケーション・セッション・データ・ストアと、ポートレット・アプリケーション・データ・ストアにリンクされ、関連するポートレットとウェブ・アプリケーションとの間で通信して、関連するポートレットから受信されたユーザ要求をウェブ・アプリケーションに搬送するポートレット・アプリケーション通信クライアント（httpClient）とを有し、通信クライアントが、関連するポートレットのポートレット要求パラメータ・マップからの要求を格納して、通信クライアントがウェブ・アプリケーションに関するデータおよび命令を提供することを可能にする要求バッファを有するポートレット・アプリケーションを提供する。
【００６６】
本発明の別の態様は、ポートレット・アプリケーション・データ・ストアにリンクされ、関連するポートレットとウェブ・アプリケーションとの間で通信して、関連するポートレットから受信されたユーザ要求をウェブ・アプリケーションに搬送するポートレット・アプリケーション通信クライアント（httpClient）であって、ユーザＩＤ、ユーザ証明書、言語プリファレンス、セッション・タイムアウト情報、セッションｉｄなどのユーザ・セッション情報の組から選択される情報を含むユーザ・セッション情報を格納してユーザ・セッション情報をウェブ・アプリケーションの対応するセッションにマッピングするユーザ・セッション情報ストア（マッピング・テーブル）と、ポータル・サーバおよびウェブ・アプリケーションのセッション・タイムアウト情報を含むセッション・タイムアウト情報とを有するポートレット・アプリケーション通信クライアント（httpClient）を提供する。
【００６７】
上記が、ウェブ・アプリケーションがポータル・サーバの前にタイムアウトする場合に、ユーザを再認証することによってポータル・サーバとウェブ・アプリケーションの間のセッション・タイムアウトを合致させるポートレット・アプリケーション通信クライアント用の同期手段を含むことが好ましい。
【００６８】
本発明の別の態様は、ユーザがアクセス可能なウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット・アプリケーションにおいて、ポータル・サーバが、関連するポートレットが互いにメッセージすることを可能にするメッセージ交換手段を提供するポートレット・アプリケーションであって、複数の関連するポートレットを管理するポートレット・アプリケーション手段であって、関連する各ポートレットが、コンテキスト名を記述するポートレット記述子をそれぞれ有し、関連するポートレットが、コンテキスト値を定義する対応するコンテキスト名を有するポートレットの協働グループを含み、ポートレットの各グループが、マスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを含み、ポートレットの各グループが、共通にコンテキスト名を共有するポートレット・アプリケーション手段と、マスタ・ポートレットのコンテキスト値の変化をマスタ・ポートレットのスレーブ・ポートレットに同報通信するポータル・サーバ内の手段と、同報通信時にマスタ・ポートレットのコンテキスト値と合致するようにスレーブ・ポートレットのコンテキスト値を変更するポータル・サーバ内の手段とを含むポートレット・アプリケーションを提供する。
【００６９】
本発明の別の態様は、ユーザがアクセス可能なウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット・アプリケーションにおいて、ポータル・サーバがポートレット・リフレッシュ機能を有するポートレット・アプリケーションであって、複数の関連するポートレットを管理するポートレット・アプリケーション手段であって、関連する各ポートレットがポートレット記述子を有し、各ポートレット記述子が、ポートレットに関するリフレッシュ優先順位記述を含み、関連するポートレットがポートレットの協働グループを含み、ポートレットの各グループが、マスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを含むポートレット・アプリケーション手段と、ポートレットをそのリフレッシュ優先順位の順序でリフレッシュするポートレット・アプリケーション手段内の手段とを含むポートレット・アプリケーションを提供する。
【００７０】
本発明のさらに別の態様は、ユーザがアクセス可能なウェブ・ポータル内の複数の関連するポートレットをホストするポータル・サーバ上で動作することができるポートレット・アプリケーションにおいて、ポータル・サーバがポートレット・リフレッシュ機能を有し、関連するポートレットが、ポートレットの協働グループを含むポートレット・アプリケーションであって、複数の関連するポートレットを管理するポートレット・アプリケーション手段であって、関連する各ポートレットがポートレット記述子を有し、各ポートレット記述子が、ポートレットに関するリフレッシュ優先順位記述と、ポートレットがメンバであるポートレットのグループに関するリフレッシュ記述優先順位とを含み、ポートレットの各グループが、マスタ・ポートレットおよび少なくとも１つのスレーブ・ポートレットを含むポートレット・アプリケーション手段と、ポートレットをそのリフレッシュ優先順位の順序でリフレッシュするポートレット・アプリケーション手段内の手段と、ポートレットの協働グループをそのグループ・リフレッシュ優先順位の順序でリフレッシュするポートレット・アプリケーション手段内の手段とを含むポートレット・アプリケーションを提供する。
【００７１】
マスタ・ポートレットは、スレーブ・ポートレットよりも高い優先順位を有する。
【００７２】
ポートレット・アプリケーションが、まずグループ優先順位順でグループをリフレッシュし、次いで各グループ内で優先順位順にリフレッシュすることが好ましい。
【００７３】
本発明の別の態様は、ウェブ・アプリケーションに関するウェブ・ページ・セッションをユーザに表示する装置において、ウェブ・ページ・セッションが、情報を互いに共有する、ユーザがアクセス可能な複数の関連する協働ポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションと、規則データベースにアクセスするアクセス手段であって、規則が、ユーザに対するポートレット、ページ、ページ・グループの組の表示を制御する規則を含む手段と、ユーザが与える情報（情報プロパティ）に基づいて、ユーザに表示すべき１組のポートレット、ページ、およびページ・グループを選択する選択手段とを含む装置を提供する。
【００７４】
本発明の別の変形形態では、選択手段は、プラグ可能規則エンジンと、規則データベースと、規則を適用して、選択したポートレット、ページ、およびページ・グループを選択し、ユーザに表示するポートレット・アプリケーション集約エンジンとを含む。
【００７５】
本発明の別の態様は、ウェブ・アプリケーションに関するウェブ・ページ・セッションをユーザに表示する装置において、ウェブ・ページ・セッションが、情報を互いに共有する、ユーザがアクセス可能な複数の関連する協働ポートレットを表示する装置であって、ウェブ・ポータルを操作してウェブ・アプリケーションへのアクセスを実現するポータル・サーバと、ポータル・サーバ上で動作し、関連するポートレットの集合を管理するポートレット・アプリケーションと、役割データベースにアクセスする役割アクセス手段と、ユーザ役割に基づいて、ユーザに対するポートレット、ページ、ページ・グループの組の表示を制御する規則を含む役割データベースと、ユーザの識別される役割に基づいて、ユーザに表示すべき１組のポートレット、ページ、およびページ・グループを選択する役割選択手段とを含む装置を提供する。
【００７６】
本発明の他の態様は、コンピュータ可読信号運搬媒体と、上述の本発明の実施形態の方法を実施するように適合された、媒体上に記録されたコンピュータ・プログラム・コード手段とを含む物品を提供する。
【００７７】
本発明の他の態様は、コンピュータ可読信号運搬媒体と、上述の本発明の実施形態のいずれかの装置を実装するように適合された、媒体上に記録されたコンピュータ・プログラム・コード手段とを含む物品を提供する。この媒体は、磁気データ記憶媒体、光データ記憶媒体、生物的データ記憶媒体、および原子データ記憶媒体から適宜選択することができる。
【００７８】
この媒体は被変調搬送波信号でよい。
【００７９】
この信号は、ネットワークを介して伝送することができる。
【００８０】
添付の図面を参照しながら、単に例示によって本発明の実施形態を説明する。
【発明を実施するための最良の形態】
【００８１】
Ａ．１．ポータル／ウェブ・アプリケーション統合使用可能性
図２に、ウェブ・ポータル・サーバと共に使用することを示す、本発明の好ましい実施形態を示す。
【００８２】
Ａ．１．１  ポートレット・アプリケーションｈｔｔｐクライアント
（バックエンド・ウェブ・アプリケーションに対するｈｔｔｐ要求を作成する）ポートレットが、バックエンド・アプリケーション・サーバ２１０上で動作するバックエンド・ウェブ・アプリケーションへのｈｔｔｐ接続をオープンするのに使用されるポートレット・アプリケーションｈｔｔｐクライアント２０９を使用する。バックエンド・ウェブ・アプリケーションは、ポートレット・アプリケーションｈｔｔｐクライアント２０９に、複数の要求および応答、クッキー処理および単一サインオン（ＳＳＯ）ロジックを介してセッション・サポートを提供するように要求する。同一のポートレット・アプリケーション内のすべてのポートレットは、同一のポートレット・アプリケーションｈｔｔｐクライアント・オブジェクト２０９を使用して１つまたは複数のバックエンド・ウェブ・アプリケーションに接続する。ポートレット・アプリケーション２０４ごとに１つのポートレット・アプリケーションｈｔｔｐクライアント２０９が存在する。
【００８３】
Ａ．１．２  ポートレット・アプリケーション・セッション
ポートレット・アプリケーション・セッション・オブジェクト２０８は、所与のポートレット・アプリケーション内のすべてのポートレットによって共有することのできる統一データ・ストア・オブジェクトである。このオブジェクトは、ユーザごとに、かつポートレット・アプリケーションごとに存在する。ポートレット・アプリケーション・セッション・オブジェクト２０８は、所与のポートレット・アプリケーション内の複数のポートレットが独立のユーザ・セッション（ポートレット・セッション２０４、２０５、２０６と呼ぶ）を有するが、同一のポートレット・アプリケーション・セッションを共有し、単一のウェブ・アプリケーション・セッションを有するバックエンド・アプリケーション・サーバ２１０上のウェブ・アプリケーションと通信するようにインフラストラクチャを提供
する。
【００８４】
Ａ．１．３  ポートレット・アプリケーション・セッション・コンテキスト
ポートレット・アプリケーション・セッション・コンテキストは、ユーザごと、かつポートレット・アプリケーションごとの情報を提供する。このことは、同一のポートレット・アプリケーション（２０４、２０３）内のすべてのポートレットが、それらの間で共通の情報を共有する方法を有することができることを意味する。
【００８５】
Ａ．１．４  セッション中継機構３２０
セッション中継機構により、ポータル・サーバによって保持される元のｈｔｔｐセッションからポートレット・アプリケーションのｈｔｔｐクライアントによって作成されるバックエンドｈｔｔｐセッションに情報を渡すことが可能となる。この機構は以下のインフラストラクチャを使用する。
【００８６】
クッキー・テーブル３０５およびクッキー・ルックアップ・キー
クッキー・テーブル３０５（ユーザ・セッション情報テーブル）は、ポータル・サーバ・クッキーをバックエンド・ウェブ・アプリケーション・セッション・クッキーにマッピングする主エンティティである。ポータル・サーバに対するｈｔｔｐ要求のクッキーと所与のウェブ・アプリケーションに対するポートレット・アプリケーションｈｔｔｐクライアントのクッキーとの間のマッピング関係は１対１である。しかし、所与のポートレット・アプリケーションｈｔｔｐクライアントは、独立のセッションを維持する異なるウェブ・アプリケーションに対してｈｔｔｐ要求を行うことができる。この点で、ポータル・サーバ・セッション・クッキーとバックエンド・ウェブ・アプリケーションのセッション・クッキーとの間のマッピングは、（複数のバックエンド・ウェブ・アプリケーション・サーバのため）１対多でよい。
【００８７】
図１６にこのマッピングを示す。このマッピングには、いくつかの項目が示されている。
ＲＱ１：ポータル・サーバに対するユーザ・エージェント（ブラウザ）のｈｔｔｐ要求からのクッキー
ＲＱＡ：ウェブ・アプリケーションＡに対するポートレットｈｔｔｐアプリケーション・クライアントのｈｔｔｐ要求からのクッキー
ＲＱＢ：ウェブ・アプリケーションＢに対するポートレットｈｔｔｐアプリケーション・クライアントのｈｔｔｐ要求からのクッキー
【００８８】
ポートレット・アプリケーションｈｔｔｐクライアント２０９は、このテーブルを使用してバックエンド・ウェブ・アプリケーション・サーバ２１０上で動作するバックエンド・ウェブ・アプリケーションに対して合致するクッキーをルックアップする。
【００８９】
このクッキー・マッピング・テーブル３０５の存在により、ポータル・サーバ・セッションが満了したときにバックエンド・ウェブ・アプリケーション・セッションの自動満了が可能となる。
【００９０】
クッキー・ルックアップ・キー
ポートレット・アプリケーションｈｔｔｐクライアント２０９は、ポートレット・アプリケーションごとに作成される。クッキー・ルックアップ・キーが、同一のポートレット・アプリケーション内のすべてのポートレットにとってアクセス可能なポータル・アプリケーション・セッション・オブジェクト内に格納される。このクッキー・ルックアップ・キーは、ポータル・サーバのｈｔｔｐセッションをバックエンド・アプリケーションのｈｔｔｐセッションと合致させる任を担う。
【００９１】
クッキー・ルックアップ・キーの使用により、同一のｈｔｔｐクライアント・キーを共有する所与のポートレット・アプリケーション内のすべてのポートレットが、現在ログインしているユーザについての正しいバックエンド・ウェブ・アプリケーション情報の組を取り出して転送し、それによって同一のポートレット・アプリケーション内のすべてのポートレットが同期して機能し、使用中のバックエンド・ウェブ・アプリケーションを更新することが可能となる。これによりエンド・ユーザが複数のポートレットを介してバックエンド・ウェブ・アプリケーションの統一されたビューを見るという効果が得られる。
【００９２】
ポートレット要求パラメータ・マップ
ポートレット要求パラメータ・マップ３０８は、ポートレットごと、かつポータル・サーバ・セッションごとに作成される共有アプリケーション・セッション・データ・ストアに格納されたメモリ・オブジェクト内にある。ポートレット要求パラメータ・マップ３０８は、特定のポートレットに対する着信ユーザ要求からのすべての要求パラメータを格納するのに使用される。
【００９３】
Ａ．２．ポートレットの動的コンテンツ同期
Ａ．２．１  動的コンテキスト定義テンプレート
図５に、バックエンド・ウェブ・アプリケーションとのポータル統合を示す。以下については図５を参照することが役立つ。
【００９４】
動的コンテキスト定義テンプレート５０３は、各動的コンテキスト・グループについて以下を定義する。
コンテキストおよびそのタイプ（前の例では、アカウントＩＤである）
定義されたコンテキストの値を変更することができるマスタ・ポートレット
定義されたコンテキストが変更されたときに通知を受けるスレーブ・ポートレット
コンテキスト変更の通知時のスレーブ・ポートレット登録応答（またはアクション）
任意選択で、スレーブ・ポートレットのリフレッシュ・シーケンスを定義する（マスタは常に所与のグループ内で最初にリフレッシュされる）
【００９５】
１つの動的コンテキスト定義テンプレート５０３は、１つまたは複数の動的コンテキスト・グループを含むことができる。しかし、各動的コンテキスト・グループが有することのできるのは、
１つのマスタ・ポートレット
１つの定義済みコンテキスト
１つまたは複数のスレーブ・ポートレットだけである。
注：所与のポートレットは、各グループ内の異なる役割を有する複数の動的コンテキスト・グループに関与することができる。
【００９６】
Ａ．２．２  動的コンテキスト・ポートレット・グループ化生成ツール
このツール５０１は、動的コンテキスト定義テンプレート５０３を読み取り、ポートレット配置記述子５０２を更新することによって指定される定義に従って、すべての動的コンテキスト・グループについて動的コンテキスト・マスタ・ポートレットおよびスレーブ・ポートレットを生成する。
【００９７】
Ａ．２．３  動的コンテキスト・グループ
動的コンテキスト・グループは、同一のコンテキストを共有し、１つの動的コンテキスト・グループ下にグループ化されるポートレットのサブセットである。所与のポートレットは、複数の動的コンテキスト・グループに属することができる。
【００９８】
特定の動的コンテキスト・グループの動的コンテキストを定義するのに動的コンテキスト・グループ定義文書インスタンス５０４が使用される。
【００９９】
動的コンテキスト・マスタ・ポートレット
動的コンテキスト・マスタ・ポートレットは、
コンテキスト状態の変化を検出し、
コンテキスト状態の変化に関してすべてのスレーブ・ポートレットに通知する任を担う。
【０１００】
動的コンテキスト・スレーブ・ポートレット
動的コンテキスト・スレーブ・ポートレットは以下のことを行う。
マスタ・ポートレットによって通知されるコンテキスト変化をプルする
コンテキスト変化の通知時に、対応するバックエンド・アプリケーションに向けて送られた登録済みアクションを実施する
【０１０１】
動的コンテキスト・モデル
ポートレットを互いに関連付けるのに使用することができる２つのタイプの動的コンテキスト・モデルが存在する。
【０１０２】
Ａ．２．４  Ｓｙｎｃモデル
図１４に示すＳｙｎｃモデルでは、マスタ・ポートレット１０１が、動的コンテキスト・マスタ・ポートレットのコンテキストの状態変化についてスレーブ１７０１〜１７０３に通知する。すべてのスレーブは、以前に定義された応答に基づいてアクションを実施し、マスタのコンテキスト状態変化と同期する。
【０１０３】
Ｓｙｎｃモデル・ダイアグラム
Ａ．２．５  連鎖モデル
図１に示す連鎖モデルでは、マスタＡ  １０１の状態の変化の結果としてスレーブＡ  １０２の応答アクションが生じ、スレーブＡはマスタ・ポートレットＢでもあり、コンテキストＢの状態が変化し、その結果、スレーブＢ  １０３のコンテキスト変化応答が生じ、スレーブＢは動的コンテキスト・グループＣのマスタ・ポートレットでもあり、その結果、スレーブＣのアクション応答が生じる。
【０１０４】
Ａ．２．６  ポートレット・トランザクション・マネージャ
図１８によるシーケンス・アウェア・ポータル集約エンジン拡張では、ポートレット・トランザクション・マネージャ１８０２が、ポートレット要求、応答、およびセッションの作成を含むポートレットのランタイム・リフレッシュ順序付けを管理する任を担う構成要素である。
【０１０５】
１．任意のポートレット・アプリケーションについてリフレッシュすべき第１のポートレットが、所与のユーザについてのすべてのポートレットの間でまずリフレッシュされるポートレットとして定義される。所与のページ内のポートレットのリフレッシュ・シーケンスを定義する既存の機構は存在しない。
【０１０６】
したがって、実行時にマスタ・ポートレットを動的に識別することができる何らかのロジックが必要である。本実施形態では、各ポートレットがリフレッシュされるごとにマークを行う単純なスクラッチボードを使用する。ポートレットがこのスクラッチボード上に最初にマークを行うとき、ポートレットは、ポートレットが第１ポートレットすなわちマスタ・ポートレットであることを認識している。このリストにマークを行う次のポートレットは、他のポートレットがリストにマークを行っていることを既に認識することができ、マスタ・ポートレットではないことなどを認識している。次にポータル・ページがリフレッシュされたとき、このリストに２重マークを行う最初のポートレットがマスタ・ポートレットとなる。次いでマスタ・ポートレットは、次の要求のために、他のすべてのポートレットのマークを除去し、マスタ・ポートレットの２重マークの１つも除去することによってこのリストを再初期化する。このアルゴリズムにより、要求がポートレットのポータル・サーバから来るごとにマスタ・ポートレットを動的に検出することが可能となる。
【０１０７】
第１ポートレットがリフレッシュされた後、トランザクション・マネージャが引き継ぎ、動的コンテキスト・グループのマスタ／スレーブ・ポートレット・マッピングで事前定義されるように、シーケンス中の他のポートレットをリフレッシュする。
【０１０８】
２．シーケンス・ソータ：シーケンス・ソータ・モジュール１８０４が使用されて、ポートレットがそのリフレッシュ・シーケンス順でソートされる。ポートレット配置記述子が使用されて、各ポートレットのリフレッシュ順序が識別され、次いでそれを要求ディスパッチング・エンジンのためにソートする。
【０１０９】
３．シーケンス・アウェア要求ディスパッチング・エンジン拡張：このエンジン１８０５が使用されて、ポートレットに対して要求がディスパッチされ、ポータル集約エンジンがオーバーライドされる。その仕事は、適切なポートレット要求および応答オブジェクト、ならびに商業ポータル・アプリケーション内のすべてのポートレットについてのポートレット・セッションを構築することである。次いでこれがトランザクション・マネージャによって使用され、ポートレットが実際にリフレッシュされる。
【０１１０】
４．トランザクション・マネージャ・キャッシング・ユニット：トランザクション・マネージャ・キャッシング・ユニット１８０６がトランザクション・マネージャ１８０２によって使用され、ポートレットが要求ディスパッチング・エンジンによってリフレッシュされるときにポートレットによって生成される応答がキャッシュされる。これは、ポータル集約エンジンがポートレット・リフレッシュを要求するときに必要であり、これらのキャッシュされた応答が、トランザクション・マネージャによってポータル集約エンジンに送り戻される。これにより、着信ポータル要求ごとの２重リフレッシュの問題が回避される。
【０１１１】
Ａ．３．規則ベースおよび役割ベースの集合
図１１に、本発明の好ましい実施形態の規則ベースの動的集約構成要素構造マップを示す。図示する実施形態の構成要素およびその動作を以下で説明する。
【０１１２】
ポータル資源変換モジュール
ポータル資源変換モジュール１０１５は、ポートレット、ページ、およびページ・グループを含むポータル資源の組を、外部規則エンジン１０２２で解析および処理することができる形式に変換する任を担う。
【０１１３】
規則データベース
規則データベース１００１は、ポータル集約エンジン１００６に関するビジネス・マネージャ定義規則を保持する。
【０１１４】
ユーザ資源変換モジュール
ユーザ資源変換モジュール１０１３は、ユーザ資源および様々なユーザ・プロパティを、外部規則エンジンによって解析および機能することができる形式に変換する任を担う。
【０１１５】
プラグ可能規則エンジン
エンジン１０２２は、（本発明のこの実施形態では）動的な規則解析および実行のために使用される、ｗｅｂｓｐｈｅｒｅ（商標）パーソナライゼーション・エンジンなどの外部のプラグ可能規則エンジンである。このエンジン実行により、ユーザがビジネス・ユーザによって定義されるビジネス規則に基づいて見るべきポータル資源の組が生成される。
【０１１６】
ポータル役割ベース・パーソナライゼーション・エンジン
ポータル役割ベース・パーソナライゼーション・エンジン１００８は、ユーザの組織メンバシップに基づいて、ユーザがアクセスを許可されるポータル資源のリストと、ユーザがアクセスを許可されないポータル資源のリストとを抽出するのに使用される役割ベースの資源選択モジュールである。
【０１１７】
役割ベース・エンジン１００８はまず、役割データベース１００７にアクセスすることによってユーザの組織を見る。ユーザの組織を判定した後、ユーザの役割が、その組織の役割と同じであると仮定する。この後、役割ベース・パーソナライゼーション・エンジン１００８が、この組織に対して、ビジネス・ユーザによってアクセス可能およびアクセス不能と定義されている資源のリストを抽出する。このリストを求めた後、このリストが、後の処理のために、このモジュールによってポータル集約エンジンの集約資源変換サブシステムに転送される。
【０１１８】
役割ＤＢ
役割ＤＢ  １００７は、ポータル・サーバに関する組織データを保持する。役割ＤＢ  １００７は、様々なユーザに関する組織メンバシップについての情報を保持し、組織のメンバがその役割に基づいてアクセスすることができ、またアクセスすることができないポータル資源のリストも保持する。
【０１１９】
ポータル集約エンジン集約資源変化サブシステム
このモジュール１００４は、規則および役割ベース・パーソナライゼーション・エンジンの出力に基づいて、現ユーザが見ることを許可されているポータル資源（これにはポートレット、ページ、およびページ・グループが含まれる）のマスタ・リストを作成する任を担う。このモジュールはまた、実際のポータル集約エンジンに対するアダプタでもある。その仕事は、このマスタ・リストを作成するだけでなく、それを、エンド・ユーザ用の最終的なウェブ・サイトを作成する実際のポータル集約エンジンによってアクセスすることができる形式に変換することでもある。
【０１２０】
パートＢ：動作説明
Ｂ．１  ポータル／ウェブ・アプリケーション統合許可の説明
Ｂ．１．１  全体の統合構造および流れ図
【０１２１】
図２、３、および４に、それぞれポータルとのウェブ・アプリケーション統合、統合構造図、および統合流れ図を示す。
【０１２２】
Ｂ．１．２  詳細な説明
図２を参照すると、バックエンド・ウェブ・アプリケーションがポータル・サーバと統合されるとき、バックエンド・ウェブ・アプリケーション２２１は、ポートレットを介してポータル・サーバ２０１から要求を受け取る。バックエンド・ウェブ・アプリケーション２２１は、要求を行うポートレットに応答を送り戻す。
【０１２３】
ウェブ・アプリケーション２２１からの応答は、ポータル・サーバ２０１のポートレットを介して、ポートレットにアクセスするユーザにレンダリングされる。
【０１２４】
ポータル・アプリケーションｈｔｔｐクライアント２０９の実装では、バックエンド・ウェブ・アプリケーションに対する複数の要求および応答が、結合したセッションとしてバックエンド・ウェブ・アプリケーションに認識される。ポータル・アプリケーションｈｔｔｐクライアント２０９は、バックエンド・ウェブ・アプリケーション２２１に対するｈｔｔｐ通信接続をオープンするのに使用される。バックエンド・ウェブ・アプリケーションは、ポータル・アプリケーションｈｔｔｐクライアント２０９にセッション・サポート、クッキー処理、および単一サインオン（ＳＳＯ）機能を提供するように要求する。定位置のポータル・アプリケーションｈｔｔｐクライアント２０９を用いて、ポートレットは、ウェブ・アプリケーションと効果的に通信することができる。ポートレット・アプリケーション（ポートレット・アプリケーション２０５など）内のすべてのポートレットは、バックエンド・アプリケーション２２１の１つのポートレット・アプリケーション・セッション・オブジェクト２１１に対するアクセスを有する必要があり、このことは、同一のポータル・アプリケーション内のすべてのポートレットによってポータル・アプリケーションｈｔｔｐクライアント２０９を共有しなければならないことを意味する。
【０１２５】
このような共有を可能にするために、本発明者等は、所与のポータル・アプリケーション内のすべてのポートレットで共有することができる統一セッション・オブジェクトが必要であると判断した。このような目的を実現するために、本明細書の発明は、ポートレット・アプリケーション・セッション・オブジェクト２０８を提供する。ポートレット・アプリケーション・セッション・オブジェクト２０８は、商業ポートレット・アプリケーションによって作成されるオブジェクトである。ポートレット・アプリケーション・セッション・オブジェクト２０８は、所与のポートレット・アプリケーション内のすべてのポートレット（ポートレット・アプリケーション１、２０４内のポートレット２０５、２０６、２０７など）によってアクセス可能である。ポートレット・アプリケーション・セッション・オブジェクト２０８がないと、所与のポータル・アプリケーション内の複数のポートレットは、すべて独立のユーザ・セッションを有することになり、セッション関係の情報を共有することができなくなる。
【０１２６】
ポートレット・アプリケーションｈｔｔｐクライアント２０９がポートレット・アプリケーション・セッション２０８内に格納され、同一のポートレット・アプリケーション内のポートレット間でポートレット・アプリケーション・セッション２０８を共有することが可能となる。このポートレット・アプリケーション・セッション・オブジェクトがないと、ポートレットがバックエンド上の単一ウェブ・アプリケーション・セッションと通信することができなくなる。
【０１２７】
ポータル・アプリケーション・セッション・オブジェクト２０８内に格納されるすべてのデータはポータル・アプリケーション・セッション・コンテキストを表し、ユーザごと、かつポータル・アプリケーションごとに存在する。
【０１２８】
ポートレット・アプリケーションｈｔｔｐクライアント２０９がバックエンド・ウェブ・アプリケーション２２１に関するすべてのセッション情報を保持するので、ポートレット・アプリケーションｈｔｔｐクライアント２０９は、図３に示すセッション中継機構３２０に関するベースとして使用される。
【０１２９】
セッション中継により、全ポータル・サーバ２０１に特有のセッション情報（言語情報、ユーザ・エージェント情報など）をバックエンド・ウェブ・アプリケーション２２１のセッション情報に中継することができる。このことは、バックエンド・ウェブ・アプリケーション２２１がユーザによってポータル・サーバに送られた元の要求に含まれるすべての要件に合致するデータ表現を送達できることを意味する。
【０１３０】
例えば、デフォルト言語ロケールが「フランス語」に設定されたＷＡＰ（ワイヤレス・アプリケーション・プロトコル）使用可能モバイル装置を使用してユーザがポータルにアクセスする場合、ポータル・サーバ２０１に対する元のｈｔｔｐ要求が、「フランス語」に設定されたＩＴＳ言語パラメータと、「ＷＡＰ」に設定されたｈｔｔｐヘッダのユーザ・エージェント・フィールドとを有することになる。セッション中継機構３２０は、この情報をウェブ・アプリケーション２２１に中継し、ウェブ・アプリケーションは、ユーザのモバイル装置上にフランス語で表示するのに適したフランス語の応答を返す。セッション中継がない場合、ウェブ・アプリケーションは、デフォルト装置（例えばインターネット・ブラウザ）に適したデフォルト言語（例えば英語）で情報を返す。この場合、データがユーザのモバイル装置と非互換であるので、ユーザは取り出されたデータを見ることができない。
【０１３１】
図４のプロセス・ステップを列挙ステップで示す間、図３の構造図中の要素を参照する。
【０１３２】
ステップ４０１では、ユーザがウェブ・ポータル上のポートレットと、例えばコンピュータ・マウスを使用してユーザのウェブ・ブラウザ上のポートレット内に表示されるリンクまたはオブジェクトをクリックすることによって対話する。各ポートレットはそれ自体のポートレット・セッション３１０を有する（ポートレット・セッションは従来技術の１つである）。ユーザ対話の一部として、リモート要求３０６をバックエンド・ウェブ・アプリケーション３０７に対して行う。
【０１３３】
２．  ステップ４０３では、ポートレット・セッション内のすべてのパラメータをバックエンド・ウェブ・アプリケーションに渡すために、各ポートレット要求のパラメータ・リストをポートレット要求パラメータ・マップ（＃８）３０８に保存する。このパラメータはリモート・バックエンド要求に渡される。
【０１３４】
３．  ステップ４０４では、商業ポートレットがｈｔｔｐクライアント・キー３０１を使用して、ポートレット・アプリケーション・データ・ストア＃４  ３０２にアクセスすることによって既存のポートレット・アプリケーション・セッション・オブジェクト２０８およポートレット・アプリケーションｈｔｔｐクライアント３０３が既に存在しているかどうかを判定する。ステップ４０５では、それが見つからない場合、同一のポートレット・アプリケーション内のすべてのポートレットについて新しいものを作成する（ステップ４０７では、それが見つかった場合、既存のものをその代わりに使用する）。
【０１３５】
４．  ステップ４０６では、元のポートレット・セッションからの各ユーザ証明書をクッキー・テーブル３０５に保存する。
【０１３６】
５．  ステップ４０８では、クッキー・テーブル３０５からのユーザ証明書と、ポートレット要求パラメータ・マップ３０８に以前に保存したパラメータとを使用して、バックエンド・ウェブ・アプリケーションに対する新しいｈｔｔｐ要求を構築する。
【０１３７】
６．  ステップ４０９では、リモート・ウェブ・アプリケーション３０７に対する呼出しを作成する。
【０１３８】
７．  ステップ４１０では、リモート・ウェブ・アプリケーション３０７が、ポートレットが表示すべき、上記呼出しに対する応答を返す。
【０１３９】
Ｂ．２  ポートレットの動的コンテキスト同期
Ｂ．２．１  開発時間の説明
バックエンド・ウェブ・アプリケーションとのポータル統合の構造図を示す図５を参照すると、ポータル開発者が、動的コンテキスト・ポートレット・グループ化ツール５０１を利用して、新しい各動的グループ定義インスタンス５０４を作成することができることがわかる。この例は、関連するポートレットのグループ化であり、どのポートレットがスレーブであり、どのポートレットがそうしたスレーブのマスタであるかを定義する。動的グループ定義の必要な要素は、動的コンテキスト・グループ定義テンプレート５０３で指定される。
【０１４０】
ユーザは、同一のツール５０１を使用して既存の動的コンテキスト・グループ定義を更新する。
【０１４１】
ユーザが最新の動的コンテキスト・グループ定義を与えた後、動的コンテキスト・ポートレット・グ化ツール５０１が、適切なポートレット・アプリケーション配置記述子５０２を更新して、グループで定義された関係を反映する。
【０１４２】
図６を参照すると、上記のプロセスのポータル統合ステップを表す流れ図をより明確に視覚化することができる。
【０１４３】
ユーザが動的コンテキスト・グループを作成（６０８）または更新（６０９）したいとき、ユーザはグループ化ツール５０１（図５）を利用することができる。
【０１４４】
６０１では、動的コンテキスト・グループ化ツールが、動的コンテキスト・グループ定義テンプレート５０３で指定されたものに基づいてユーザ入力を促し、または更新の場合は、動的コンテキスト・グループ化ツールが既存の動的コンテキスト・グループ・インスタンスを読み取り、それを定義テンプレート５０３を用いて検証する。
【０１４５】
６０３では、ユーザが必要な情報を指定して、動的コンテキスト・グループを定義または更新する。
【０１４６】
６０５では、動的コンテキスト・グループ・インスタンス５０４を生成する。
【０１４７】
６０６では、すべての関係するポートレットの配置記述子を更新する。
【０１４８】
動的コンテキスト・グループ化
図７に、ポートレットに関する動的コンテキストを示す。動的グループ７０１は、マスタ・ポートレット７０４、スレーブ・ポートレット７０５、およびスレーブ・ポートレット７０７からなる。
【０１４９】
グループ７０３は、マスタ・ポートレット７０５、スレーブ・ポートレット７０６、およびスレーブ・ポートレット７０７からなる。
【０１５０】
動的グループ７０２は、マスタ・ポートレット７０４およびスレーブ・ポートレット７０８からなる。
【０１５１】
ポートレット・アプリケーション内のポートレットによって表されるデータがバックエンド・アプリケーション・レベルで同期される場合、ポートレットは、単にウェブ・アプリケーションからデータを取り出すことにより、調整したデータのビューを送達する。しかし、すべてのポートレット対話がバックエンド・ウェブ・アプリケーションでの変化となるわけではない。動的コンテキストは、「グラスでの（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>
【０１５６】
動的コンテキスト・グループ定義インスタンスの注：１つの動的コンテキスト・グループ定義は１つのインスタンスである。しかし、複数の動的コンテキスト・グループ定義を１つのファイルにまとめて、３つのポートレットからなるポートレット・アプリケーション内の２つのポートレット・セットを定義する上記の複数の定義例を定義することができる。
【０１５７】
第１動的コンテキスト・グループでは、ポートレット間で共有される動的コンテキストはｉｔｅｍＮａｍｅであり、ＯｒｄｅｒｅｄＩｔｅｍｓという名前のポートレットは動的コンテキスト・マスタ・ポートレットとして働き、ポートレットＵＰＳＴｒａｃｋｉｎｇおよびＩｎＳｔｏｃｋＩｎｖｅｎｔｏｒｙは動的コンテキスト・スレーブ・ポートレットとして働く。
【０１５８】
第２動的コンテキスト・グループでは、ポートレット間で共有される動的コンテキストはｉｔｅｍＳｋｕＮｕｍｂｅｒであり、ＩｎＳｔｏｃｋＩｎｖｅｎｔｏｒｙという名前のポートレットは動的コンテキスト・マスタ・ポートレットとして働き、ポートレットＯｒｄｅｒｅｄＩｔｅｍｓは動的コンテキスト・スレーブ・ポートレットとして働く。
【０１５９】
各動的コンテキスト・マスタ・ポートレットは、ユーザｈｔｔｐ要求を観測し、動的コンテキストを探す。動的コンテキストが要求内に見つかった場合、動的コンテキスト・ポートレットは動的コンテキスト（これはｈｔｔｐ要求内の名前／値対パラメータである）をスレーブ・ポートレットに送る。
【０１６０】
例えば、属性ｉｔｅｍＮａｍｅが「Ｐｅｎｔｉｕｍ（Ｒ）ＩＶ」に設定されたｈｔｔｐ要求をＯｒｄｅｒｅｄＩｔｅｍｓポートレットが受け取った場合、ＯｒｄｅｒｅｄＩｔｅｍｓポートレットは、動的コンテキストをポートレットＵＰＳＴｒａｃｋｉｎｇおよびＩｎＳｔｏｃｋＩｎｖｅｎｔｏｒｙに送り、それらに、値「Ｐｅｎｔｉｕｍ（Ｒ）ＩＶ」を有するコンテキストｉｔｅｍＮａｍｅが動的コンテキストに設定されたことを通知する。
【０１６１】
各動的コンテキスト・スレーブ・ポートレットは、同一の動的コンテキスト・グループのすべてのスレーブ・ポートレットに対するマスタの通知を聴取する。マスタの通知を受け取ったとき、属性「ＳｌａｖｅＰｏｒｔｌｅｔＡｃｔｉｏｎ」の下の動的コンテキスト・グループ定義インスタンスで定義されるアクションＵＲＬに動的コンテキストを加えることにより、対応するスレーブ・アクションが起動される。
【０１６２】
例えば、ｉｎＳｔｏｃｋＩｎｖｅｎｔｏｒｙポートレットが、ＯｒｄｅｒＩｔｅｍｓポートレットから、動的コンテキスト・タイプ「ｉｔｅｍＮａｍｅ」および値「Ｐｅｎｔｉｕｍ（Ｒ）ＩＶ」の動的コンテキストを受け取った場合、ｉｎＳｔｏｃｋＩｎｖｅｎｔｏｒｙポートレットは、http://inventoryserver.com/inStock/itemName=Pentium（Ｒ）IVのＵＲＬからデータを取り出す。
【０１６３】
動的コンテキスト・グループ定義テンプレートの一例についてのコーディングを以下に示す。
<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 EnabledPortal Dynamic Context GroupDefinition
Copyright 2002 IBM Corporation
<documentation>
</annotation>
<!-動的コンテキスト・グループ・インスタンス -->
<xsd:element name="DynamicContextGroup" 
type="DynamicContextGroupDefinitionTemplate",
minOccurs="1"/>
<!-動的コンテキスト・グループ定義テンプレート・スキーマ_
<xsd:complexTypename="DynamicContextGroupDefinitionTemplate">
<xsd:sequence>
<xsd:element name="DynamicContextGroupName"type="xsd:string"/>
<xsd:element name="DynamicContextMasterPortlet"type="PortletName"/>
<!- 動的コンテキスト・グループごとに１つの動的コンテキストだけ ->
<xsd:element name="DynamicContext"type="ContextParameter"maxOccurs="1"/>
<xsd:element name="DynamicContextSlavePortlet"type="SlavePortlet"
minOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SlavePortlet">
<xsd:sequence>
<xsd:element name="DynamicContextSlavePortlet"type="PortletName"/>
<xsd:element name="SlavePortletAction"type="xsd:string"/>
<xsd:element name="SlavePortletRefreshPriority"type="xsd:decimal", 
minOccurs="0"/>
<!- スレーブ・パラメータ・マップが欠けている場合、マスタのコンテキストはスレーブ・アクションｕｒｌ内にある-->
<xsd:element name="SlaveParamMapToContext"type="ContextParameter"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="PortletName">
<xsd:string>
</xsd:simpleType>
<!- マスタの要求ｕｒｌ内のパラメータの名前 -->
<xsd:simpleType name="ContextParameter">
<xsd:string>
</xsd:simpleType>
</xsd:schema>
【０１６４】
Ｂ．２．２  ランタイム
本節は、定義インスタンスで指定される動的コンテキストについてのポートレット・アプリケーション初期化である図８と、動的コンテキスト・ポートレット・グループの実行時フローである図９および図１０とを参照することによって最も良く理解できよう。
【０１６５】
動的コンテキストのランタイムの側面を処理するのに２つの鍵となる構成要素が存在する。
１）ＤｙｎａｍｉｃＣｏｎｔｅｘｔＡｃｔｉｏｎＬｉｓｔｅｎｅｒ（９０４）（ポートレット・アクション・リスナ）−マスタ・ポートレットの動的コンテキスト変化を聴取する。あらゆる動的コンテキスト・ポートレット・グループ内のマスタ・ポートレットが、それに添付されたＤｙｎａｍｉｃＣｏｎｔｅｘｔＡｃｔｉｏｎＬｉｓｔｅｎｅｒを有する。
２）ＤｙｎａｍｉｃＣｏｎｔｅｘｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒ（９０６）（ポートレット・メッセージ・リスナ）−特定の動的コンテキストが定義されるグループのマスタからの通知を聴取するメッセージ・リスナである。動的コンテキスト・ポートレット・グループ内のあらゆるスレーブ・ポートレットが、それに添付されたＤｙｎａｍｉｃＣｏｎｔｅｘｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒを有する。
【０１６６】
ランタイム・フローの段階的説明
ポートレット初期化時（図８：８０１）に、すべてのマスタ・ポートレットが、ポートレット記述子（８０２、８０５）に基づく定義済み動的コンテキストをマスタ・ポートレットのアクション・リスナに加える（８０６）。すべてのスレーブ・ポートレットについて、動的コンテキスト・タイプ、アクションｕｒｌ、パラメータ・マッピング、およびリフレッシュ・シーケンスがポートレット記述子（８０２、８０９）から取り出され、スレーブのポートレット・メッセージ・リスナに加えられる（８１０）。
【０１６７】
１）動的コンテキスト・ポートレット・グループ・マスタ・ポートレットとのユーザ対話の結果、動的コンテキストが変化する（９０１）。
２）マスタのポートレットＤｙｎａｍｉｃＣｏｎｔｅｘｔＡｃｔｉｏｎＬｉｓｔｅｎｅｒがユーザのアクションを検出する（９０２）。
３）ＤｙｎａｍｉｃＣｏｎｔｅｘｔＡｃｔｉｏｎＬｉｓｔｅｎｅｒが、マスタ・ポートレットの要求オブジェクト内の動的コンテキストに対応する名前／値対を設定する（９０４）。
４）マスタ・ポートレットが動的コンテキストの値を取得し、それについて、同一の動的ポートレット・グループ内のすべてのスレーブ・ポートレットに通知する（９０５）。
５）所与のマスタに対するスレーブ・ポートレットに関連するＤｙｎａｍｉｃＣｏｎｔｅｘｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒが通知（動的コンテキストの値）を受け取る（９０６）。
６）ＤｙｎａｍｉｃＣｏｎｔｅｘｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒが、スレーブ・ポートレットのポートレット要求オブジェクト内のＤｙｎａｍｉｃＣｏｎｔｅｘｔの値を設定する（９０７）。
７）スレーブ・ポートレットが動的コンテキストの値を取得する（１００８）。
８）コンテキストと何らかのパラメータとの間のマッピングが指定された場合、スレーブ・ポートレットが、所与のスレーブ・ポートレットについて定義されたアクションを修正する（１００９）。
９）マッピングが指定されなかった場合、動的コンテキストの名前／値対をスレーブのポートレット・アクションに追加する。
１０）スレーブ・ポートレットが、動的コンテキスト・グループ・インスタンス定義で定義されるアクションを実施する（１０１１、１０１２）。
【０１６８】
Ｂ．３  規則ベース役割ベース動的集約
本節では、役割ベース動的集約構成要素構造マップである図１１、規則ベース動的集約構成要素構造マップである図１２、規則ベース動的集約フロー・チャートである図１３乃至図１５を含むいくつかの図を参照する。
【０１６９】
ポートレット・サーバについての役割／規則ベース動的集約構成要素は、規則／役割データベースと各役割および規則についてのコンテンツ・グループの概念とに基づく。
【０１７０】
規則についてのコンテンツ・グループは、図１１に示す規則ＤＢ構成要素１００１内に保たれる。同様に、役割コンテンツ・グループは、図１１に示す役割ＤＢ構成要素１００７内に保たれる。各コンテンツ・グループは、特定の役割または規則の範囲内に含まれると評価されるユーザがアクセスすべきである１組のポータル・サーバ資源からなる。
【０１７１】
この方式での別の主な構成要素は、プラグ可能規則エンジン１０２２である。このエンジンの仕事は、変換されたユーザ・プロパティを読み取り、こうしたユーザ・プロパティに基づいて、一定の事前定義されたユーザ・グループのメンバシップの資格を有するユーザの組を実行時に動的に判断することである。さらに、このエンジンは、こうした動的ユーザ・グループの組を、役割／規則ＤＢ内に定義されているコンテンツ・グループの組にマッピングする。プラグ可能規則エンジンが、こうした作業を管理するためのＧＵＩを有することが好ましい。図１９に示すスクリーン・ショットは、どのようにＷｅｂＳｐｈｅｒｅパーソナライゼーション・サーバ・エンジンを使用してこうした作業を管理するかを示す。
【０１７２】
例えば、図１９は、どのように「ＭａｌｅＴｅｅｎ」と呼ばれる動的グループを定義し、１６〜１９歳の男性ユーザをこのグループに割り当てるかを示す。
【０１７３】
図２０に示すように、ユーザのプロパティに基づいて男性のティーンエージャと動的に評価されるすべてのユーザが、役割ＤＢ１００７から１０代男性グループに関するコンテンツ資源を選択するように動的規則および役割ベース・ポータル集約エンジン１０２２に指令する、ユーザに関して実行される「ｍａｌｅｔｅｅｎＡｃｔｉｏｎ」コマンドを有する。
【０１７４】
開発時には、ビジネス・マネージャの仕事は、ページ、ポートレットなどの１組のポータル資源を役割／規則ＤＢ内の特定のコンテンツ・グループに割り当てることである。これは現在、規則／役割ＤＢを直接ロードするＳＱＬスクリプトを使用することによって行われている。
【０１７５】
Ｂ．３．１  規則ベース役割ベース動的集約実行時使用可能化の説明
実行時、ポータル・ユーザ対して実行する最初のコマンドは、規則ベース・エンジンに関するラッパ・コマンドである。このコマンドは、実際には、実際のプラグ可能規則エンジンによってユーザのプロパティの評価を開始するプロキシである。
【０１７６】
次のステップでは、規則エンジンが、ユーザの記録されたプロファイルからユーザのプロパティを読み取り、ユーザ資源変換モジュールを使用することにより、ユーザが理解できる形式に変換する。
【０１７７】
図２１に、規則ＤＢ内の「ｍａｌｅｔｅｅｎｇｒｐ」と呼ばれるコンテンツ・グループ内に定義されているすべてのポータル資源を選択する「ＭａｌｅＴｅｅｎＡｃｔｉｏｎ」と呼ばれる新しいアクションの作成を示す。
【０１７８】
図２０に、動的ユーザ・プロパティに基づいて「ＭａｌｅＴｅｅｎｓ」を分類するのに以前に作成した規則の範囲内にあるすべてのユーザについて「ｍａｌｅｔｅｅｎｇｒｐ」のコンテンツを選択するように集約モジュールに命令する動的集約モジュール・コマンドの作成を示す。
【０１７９】
図２０は、所与のユーザについて集約するどのコンテンツがそのような分類に含まれるかを決定する際に、どのような所与のビジネス規則（例えば、何がｍａｌｅｔｅｅｎグループを構成するかを定義する際のビジネス規則）が効力を生じるか（例えばｍａｌｅＴｅｅｎＡｃｔｉｏｎ）を示す。
【０１８０】
ユーザ・プロパティを読み取った後、プラグ可能規則エンジンが、図２１に示す様々な動的グループに関して定義された規則に基づいて、このユーザの動的グループ・メンバシップを評価する。
【０１８１】
このユーザに関する動的グループの組を確認した後、規則エンジンは、図２１に示すこの動的グループに関して定義されたコンテンツ選択アクションを実行することにより、このユーザに関する適切なポータル・コンテンツを選択する。こうしたアクションは、実行時に、規則ＤＢ内でそれらに関して定義されたコンテンツ・グループからポータル資源の組を返す。
【０１８２】
次の実行ステップは、役割エンジンによってこのユーザに割り当てられた役割の評価である。役割エンジンは、（ユーザ・プロファイル・プロパティから抽出された）組織メンバシップを使用して、役割ＤＢからこのユーザの役割に関するコンテンツ資源の組を抽出する。次いでこうした資源が、以前の組で作成された既存の規則ベース・ポータル資源のリストに加えられる。
【０１８３】
次いでこのリストが、実行のために動的ポータル集約エンジンに転送される。次いで動的ポータル集約エンジンは、このリストで識別されるポータル資源を選択して、この現ユーザに関するデフォルト・ポータル・ビューをセットアップする。
【０１８４】
まとめ
１．共通バックエンド・ウェブ・アプリケーション統合実装
ポートレット・アプリケーションｈｔｔｐクライアントおよびポートレット・アプリケーション・セッションを用いて、共通バックエンド・ウェブ・アプリケーション統合モデルを有することが可能となる。これを使用して、同一のポートレット・アプリケーション内の複数のポートレットが同一のウェブ・アプリケーション・バックエンドと通信することが可能となる。
【０１８５】
本実装により、
ｉ．別々のブラウザを立ち上げずに、かつ同一のバックエンド・ウェブ・アプリケーションにアクセスするためのユーザＩＤおよびパスワードを求める複数のプロンプトを必要とすることなく、ネイティブ・ポートレット統合を有することが可能となり、
ｉｉ．セッション管理を有するバックエンド・アプリケーションに複数の要求を作成し、それから応答を受信することが可能となる。
【０１８６】
２．単純な共通システムにより得られる単純なツーリング
本実装は、ポートレット・アプリケーションの配置記述子内に関係するバックエンド・ウェブ・アプリケーションのｕｒｌの指定を単に必要とするだけで、バックエンド・サーバ上で動作する既存のウェブ・アプリケーションとポートレット・アプリケーションを統合する容易かつ迅速な方法を提供する。これにより、統合の共通作業を処理するツーリングを構築することが可能となる。
【０１８７】
３．ポートレット・アプリケーション共有共通セッションおよびセッション・データ内のポートレット
ポートレット・アプリケーション・セッション・オブジェクトの実装により、同一のポートレット・アプリケーションの各ポートレットが、ポートレット・アプリケーション内で固有であると同時にポータル・サーバの元のｈｔｔｐセッションとは異なるポートレット自体の間で共通データを共有することが可能となる。これにより、同一のポートレット・アプリケーション内のポートレット間で固有のデータの共有が容易となる。
【０１８８】
４．ポータル・セッションおよびバックエンド・セッション共有共通セッション・データ
セッション中継実装により、ポータル・サーバとそのバックエンド・ウェブ・アプリケーションとの間で共通セッション・データの共有が可能となる。これにより、バックエンド・ウェブ・アプリケーションがポータル・サーバから情報を受信することが可能となり、ウェブ・アプリケーションのビジネス・ロジックが、ポータル・サーバから渡されるこの情報を利用することが可能となる。
【０１８９】
例えば、現ポートレット状態が、ポートレットの最大化ビューを表示すべき場合、バックエンド・ウェブ・アプリケーションが単に情報の概要を送ることになる、ポートレットの通常のビューとは対照的に、バックエンド・ウェブ・アプリケーションは、この情報を受け取って、詳細なビジネス情報を送り戻すことによってこの情報を活用することができる。
【０１９０】
５．ポートレット・アプリケーション・セッション、ポートレット・アプリケーション・セッション・オブジェクト、ポートレットｈｔｔｐクライアント、およびセッション中継機構を有するポータル・サーバとは別個の結合バックエンド・ウェブ・アプリケーション・セッション
バックエンド・ウェブ・アプリケーションは、ポータル・サーバのセッションとは別個のそれ自体のセッションを保持することができるが、それでもなおポータル・サーバのクッキーと同一のクッキーを共有することができる。バックエンド・ウェブ・アプリケーションは、独立かつ正確に動作することができ、ポータル内の様々なポートレットからのポートレット要求を１つの仮想クライアントとして認識し、バックエンド・ウェブ・アプリケーションとの結合セッションを可能にする。
【０１９１】
６．ポータル・サーバおよびバックエンド・ウェブ・アプリケーションにわたる単一サインオン
セッション中継実施形態は単一サインオン機能を提供し、それによってユーザは、ポータル・サーバにログオンした後は、関連するバックエンド・ウェブ・アプリケーションにログオンするのにユーザ証明書を再サブミットする必要がない。これは、ポータルに対するｈｔｔｐセッションとポートレットｈｔｔｐクライアントからバックエンド・ウェブ・アプリケーションへのｈｔｔｐセッションとの間の１対１マッピングのクッキー・テーブルによって可能となる。
【０１９２】
７．ポータル・サーバの挙動と同期したバックエンド・ウェブ・アプリケーションの挙動
セッション中継実施形態は、ポータル・セッションからバックエンド・ウェブ・アプリケーションのセッションにセッション情報を中継することによりバックエンド・ウェブ・アプリケーションの挙動を同期することによってシームレスな統合を可能にする。
【０１９３】
以下はいくつかの例である。
【０１９４】
ポータル・サーバでの言語およびロケール設定をそのバックエンド・ウェブ・アプリケーションに渡すことができ、その結果、バックエンド・アプリケーションは、ポータル・サーバのロケール＋言語設定に基づいて応答メッセージを構成することができる。
【０１９５】
別の例は、ポータル・サーバからのセッション満了情報をバックエンド・ウェブ・アプリケーション・セッションに渡すことができ、その結果、ポータル・セッション・タイムアウトと同時にバックエンド・ウェブ・アプリケーション・セッションをタイムアウトすることができることである。バックエンド・ウェブ・アプリケーションは、ポータル・サーバから中継されるポータル状態およびイベントに応答することができる。
【０１９６】
８．同一のポータル・ページ内の同期コンテンツ
動的コンテキスト・ポートレット・グループ化により、同一の動的コンテキスト・グループ内のポートレット間の協働が可能となり、ビジネス・プロセスおよび情報の統合および同期が達成される。
【０１９７】
各ポートレットは、複数の動的コンテキスト・グループに関与することができる。これにより、ポータル管理者がポートレットを動的コンテキスト・ポートレット・グループにグループ化する非常にオープンかつ単純なプログラミング・モデルが提供される。
【０１９８】
動的コンテキスト定義の単純な構造により、各グループ化について動的コンテキスト・マスタ／スレーブ・ポートレットの自動生成のための単純なツーリングを構築することが可能となる。
【０１９９】
動的コンテキスト定義実装、動的コンテキスト・グループ、マスタ・ポートレットおよびスレーブ・ポートレット実装（スレーブ・タスク、スレーブ・コンテキスト・マップを含む）が、本発明の利点を実現する助けになる。
【０２００】
９．ポートレットのリフレッシュ・シーケンスを定義する能力
トランザクション・マネージャが、最初にポートレットのリフレッシュ・シーケンスを定義する能力を提供する。ポートレットのリフレッシュ・シーケンスを定義する能力により、ポータル／ポートレット・アーキテクチャを用いる順次ビジネス・ロジックの適切な実施が可能となる。トランザクション・マネージャ、資源ソータ、応答のキャッシングが、本発明の利点を実現する助けになる。
【０２０１】
１０．規則ベース役割ベース集約
ファイン・レベル・ポータル・パーソナライゼーションは、現在動的集約によってのみ達成することができる。これは、ポートレット、ページ、またはページ・グループの公式の概念が存在しない通常のウェブ・アプリケーションの従来技術の実装とははっきり異なる。ファイン・レベル・パーソナライゼーションは、ポータル・マーケットが成長し、ファイン・レベル・キャンペーン・ターゲティングなどに関するユーザ要件が導入されるにつれて一層重要となるであろう。
【０２０２】
記載の実施形態は、いかに列挙するいくつかの利点をもたらす。
【０２０３】
１．本発明者等の手法によって達成することができるパーソナライゼーションのレベルは、今日ポータル・サーバによって提供されるポートレット管理機構よりもずっと細かい。今日利用可能なポートレット管理は、本質的に手動構成である。構成した後は固定的であり、実行時に変化しない。本発明は、規則に基づいてポータル資源をレンダリングする動的機能を提供する。
２．ポータル集約モジュールは動的エンティティであるので、規則／役割エンジンを直接それに結びつけることにより、人間の介入なしにリアル・タイム動的集約機能が達成される。
３．ページやページ・グループなどの粗い分類のポータル資源のパーソナライゼーションにより、動的レイアウトを実施することが可能となる。
４．ずっと効果的なキャンペーン、契約などをセットアップすることができる。これは、ｅコマース・リテールおよびＢ２Ｂ組織のどちらにとってもかなり重要である。
５．通常のコンテンツ・パーソナライゼーションよりもずっと高いパーソナライゼーションが達成される。例えば、規則に基づいて、ウェブページの全セクションを使用不能にすることができる。通常のパーソナライゼーションではこれを行うことができない。さらに、動的集約は、資源関係ではなくコンテンツ関係の通常のパーソナライゼーションの領域には適用されない。
【図面の簡単な説明】
【０２０４】
【図１】動的コンテキスト連鎖モデルを示す図である。
【図２】ポータルとのウェブ・アプリケーション統合を示す図である。
【図３】統合構造図を示す図である。
【図４】統合流れ図を示す図である。
【図５】ウェブ・アプリケーションとのポータル統合のための構造図を示す図である。
【図６】統合のための流れ図を示す図である。
【図７】ポートレットに関する動的コンテキスト・グループの一例を示す図である。
【図８】定義インスタンスで指定される動的コンテキストについてのポートレット・アプリケーション初期化を示す図である。
【図９】動的コンテキスト・ポートレット・グループの実行時フローを示す図である。
【図１０】動的コンテキスト・ポートレット・グループの実行時フローを示す図である。
【図１１】規則ベース動的集約構成要素構造マップを示す図である。
【図１２】規則ベース動的集約構成要素フロー・マップを示す図である。
【図１３】役割ベース動的集約流れ図を示す図である。
【図１４】規則ベース動的集約流れ図を示す図である。
【図１５】規則ベース動的集約流れ図を示す図である。
【図１６】ウェブ・アプリケーションに対するポートレット要求の処理を示す図である。
【図１７】ｓｙｎｃモデル図を示す図である。
【図１８】シーケンス・アウェア・ポータル集約エンジンの流れ図を示す図である。
【図１９】「ＭａｌｅＴｅｅｎ」と呼ばれる動的グループの定義付けと、そのグループへのユーザの割当てを示す図である。
【図２０】動的ユーザ・グループへの規則データベース・コンテンツ・グループ選択アクションの割当てを示す図である。
【図２１】「ｍａｌｅＴｅｅｎＡｃｔｉｏｎ」と呼ばれる新しいアクションの作成を示す図である。
【図１】
0004473128.tif 000002
【図２】
0004473128.tif 000003
【図３】
0004473128.tif 000004
【図４】
0004473128.tif 000005
【図５】
0004473128.tif 000006
【図６】
0004473128.tif 000007
【図７】
0004473128.tif 000008
【図８】
0004473128.tif 000009
【図９】
0004473128.tif 000010
【図１０】
0004473128.tif 000011
【図１１】
0004473128.tif 000012
【図１２】
0004473128.tif 000013
【図１３】
0004473128.tif 000014
【図１４】
0004473128.tif 000015
【図１５】
0004473128.tif 000016
【図１６】
0004473128.tif 000017
【図１７】
0004473128.tif 000018
【図１８】
0004473128.tif 000019
【図１９】
0004473128.tif 000020
【図２０】
0004473128.tif 000021
【図２１】
0004473128.tif 000022