JP2009518724A

JP2009518724A - ポータル・システム内で非同期ポータル・ページを提供するための方法、システム、およびコンピュータ・プログラム

Info

Publication number: JP2009518724A
Application number: JP2008543770A
Authority: JP
Inventors: ドン、ビン; グー・フー・グアン; リー、ティエ; マー、ユエ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-12-06
Filing date: 2006-11-28
Publication date: 2009-05-07
Anticipated expiration: 2026-11-28
Also published as: US8099518B2; JP4857349B2; EP1969494B1; CN1979476A; EP1969494A1; ATE499652T1; US20070130293A1; CN100535900C; WO2007065813A8; DE602006020343D1; WO2007065813A1

Abstract

【課題】Ｗｅｂブラウザ上に常駐し、スクリプトによって実装されるポートレット・モニタを有し、非同期ポータル・ページを実装するための方法およびシステムを提供することにある。
【解決手段】ユーザがポートレットと対話する場合、ポートレット・モニタはＸＭＬＨＴＴＰ要求をポータル・サーバに送信する。ポータル・サーバは、要求に基づいて対応するポートレットから対応するＷｅｂコンテンツを入手する。次に、Ｗｅｂコンテンツが変更され、そこに含まれるＨＴＴＰ要求がＸＭＬＨＴＴＰ要求にリダイレクトされる。ポートレット・モニタは、ポータル・ページ全体を再ロードせずに、変更されたＷｅｂコンテンツを使用して、ポータル・ページ内の対応するポートレットのＷｅｂコンテンツをリフレッシュする。その上、ユーザがポートレットを求める要求を提示した後、ポートレットがリフレッシュされるのを待っている間、ユーザは、他のポートレットと対話し続けることができる。したがって、本発明は、部分的リフレッシュと非同期通信の能力を有する。
【選択図】図１

Description

本発明は、ポータル技術に関し、詳細には、非同期ポータル・ページを提供するための方法およびシステムに関する。

インターネットがますます普及するにつれて、Ｗｅｂコンテンツを表示するためにより良好な技術が絶えず開発されている。この点で、ポータル・サーバは、ユーザにＷｅｂコンテンツを配信する際のえり抜きの技術になっている。典型的には、ポータル・サーバは、Ｗｅｂコンテンツを複数ポートレットから構成されるポータル・ページに編成するポータル・プログラム（たとえば、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社によるＷｅｂＳｐｈｅｒｅポータル・サーバ）である。ユーザは、たとえば、ニュース、天気、およびスポーツに関するポートレットを有する自分専用のポータル・ページをセットアップすることができる。その場合、ポータル・プログラムは、適切なコンテンツ・プロバイダから所望のＷｅｂコンテンツを入手し、Ｗｅｂコンテンツを集約し、エンド・ユーザ用のポータル・ページを生成することになるであろう。

伝統的なＷｅｂアプリケーションにより、ユーザはＷｅｂページ上の書式に記入することができ、その書式が提示されると、ＷｅｂブラウザはＷｅｂサーバに要求を送信する。Ｗｅｂサーバは、その書式により送信された任意の情報を処理し、次に新しいＷｅｂページでそのＷｅｂブラウザに応答する。このようにして、第１のページ内のＷｅｂコンテンツの多くが第２のページにも含まれる可能性があるので、大量の帯域幅が浪費される可能性がある。アプリケーションとのすべての対話についてＷｅｂサーバに応答を送信しなければならないので、アプリケーションの応答時間はＷｅｂサーバの応答時間に依存する。このため、Ｗｅｂアプリケーションのユーザ・インターフェースはネイティブ・アプリケーションのものよりかなり遅くなる。

従来技術では、ポータル・システムはこのような伝統的なＷｅｂアプリケーションに過ぎない。ユーザがポートレット上に書式を提示すると、ポータル・サーバは、新しいポータル・ページを送信することによって応答することになる。しかし、実際には、ポータル・ページ内の他のポートレットのＷｅｂコンテンツを送信することは不必要なことである。そして、ユーザが対話しているポートレットのＷｅｂコンテンツのみを再ロードすることで十分である。

非同期ＷｅｂのためのＡＪＡＸ（ＡｓｙｎｃｈｒｏｎｏｕｓａｎｄＪａｖａＳｃｒｉｐｔＸＭＬ）という新興技術は、ユーザとアプリケーションとの間のすべての対話についてページ全体をリフレッシュする代わりに１ページの一部をリフレッシュするために開発されたものである。ＡＪＡＸアプリケーションでは、ユーザがあるページ内に書式を提示すると、ＷｅｂブラウザがＷｅｂサーバにＨＴＴＰ（ハイパーテキスト転送プロトコル）要求を直接送信する代わりに、通常はＷｅｂブラウザ上に常駐するＪａｖａＳｃｒｉｐｔプログラムであるスクリプト・プログラムがユーザの要求を受信し、ＡＰＩ（アプリケーション・プログラム・インターフェース）によりバックグラウンドでＷｅｂサーバにＸＭＬＨＴＴＰ（拡張マークアップ言語ＨＴＴＰ）要求を送信して、ページ全体の代わりに必要なＷｅｂコンテンツのみを検索し、Ｗｅｂサーバからの応答を受信したときにそのページを部分的にリフレッシュするための対応する処理を実行する。このようにして、ＷｅｂブラウザとＷｅｂサーバとの間で交換されるデータの量が大幅に削減されるので、アプリケーションの応答は加速される。また、処理の多くがクライアント側で実行されるので、Ｗｅｂサーバの処理時間が節約される。

現在、ポートレット開発者は、非同期ポータル・プログラムを提供するために、ＡＪＡＸを使用してポートレットを開発することができる。しかし、現在、最も人気のあるポートレット・プログラミング・モデルはいずれも非ＡＪＡＸ技術（たとえば、ＪＳＲ１６８）に基づくものであり、ほぼすべての既存のポートレットはこのようにして開発されている。したがって、ＡＪＡＸを使用してポートレットを開発するという解決策は、以下の短所を有することになるであろう。
ａ）新しいＡＪＡＸを使用するには完全に新しい方法でポートレットを作成する必要があり、多数の既存のポートレットを書き換えることはほとんど不可能である。
ｂ）ポートレット開発者はポートレット・ロジックのみに焦点を合わせる必要があり、ＡＪＡＸを使用すると、開発者は多数のプログラミングの細部を処理しなければならないので、開発の複雑さが増大することになる。

非同期ポータル・ページを提供するためのもう１つの解決策は、ＨＴＭＬで「ＩＦｒａｍｅ」（内部フレーム）タグを使用することであり、これにより、他のＨＴＭＬページ内のどこにでもＨＴＭＬページ全体を表示することができる。ＩＦｒａｍｅ内のページは別々にロードし操作することができる。したがって、ポートレットとＩＦｒａｍｅを結合することにより、ポートレットの非同期更新を実現することができる。しかし、この解決策は以下の欠陥を有する。
ａ）ＩＦｒａｍｅのサイズは変更不能である。そのサイズがＷｅｂコンテンツに十分な大きさではない場合、スクロール・バーが示されることになる。これは、ポートレットのＷｅｂコンテンツが変更されたときにポータル・ページのレイアウトの動的調整が不可能であることを意味する。
ｂ）ＩＦｒａｍｅ内のすべてのＷｅｂページが分離され、その結果、いずれの共通リソース（たとえば、ＣＳＳ、画像、その他）を共用することができない。同じリソースを繰り返しダウンロードしなければならない。

上記を考慮すると、明らかに、非同期ポータル・ページを提供するためのシステムおよび方法が必要である。具体的には、ポートレットが伝統的なＷｅｂ技術を使用して開発される（すなわち、同期リフレッシュ技術に基づくプログラミング・モデルを使用することによって開発される）ポータル・システム内で非同期ポータル・ページを提供するためのシステムおよび方法が必要である。

一般に、本発明は、伝統的なポートレット・プログラミング・モデルを変更せずに非同期ポータル・ページを提供するためのシステムおよび方法を提供する。

本発明の一態様によれば、請求項１に記載の方法と、対応するシステムおよびコンピュータ・プログラムが提供される。

好ましくは、この方法は、クライアント側のＷｅｂブラウザからのポータル・ページを求めるユーザ要求に応答して、ポータル・サーバがクライアント側にポートレット・モニタ（portlet monitor）をダウンロードする初期設定ステップをさらに含む。

好ましくは、前記初期設定ステップは、Ｗｅｂブラウザがポータル・ページを求める要求をポータル・サーバに送信するステップと、ポータル・サーバが前記ポートレット・モニタを含むポータル・ページをＷｅｂブラウザに返すステップと、対応するポートレットのＷｅｂコンテンツを入手するために、クライアント側のポートレット・モニタがＸＭＬＨＴＴＰ要求を前記ポータル・サーバに非同期的に送信するステップと、そこに含まれるＨＴＴＰ要求がＸＭＬＨＴＴＰ要求にリダイレクトされるように、前記Ｗｅｂコンテンツを変更するステップと、クライアント側のポートレット・モニタが前記変更されたＷｅｂコンテンツを含むポータル・ページ内のポートレットをそれぞれロードし、最終的にポータル・ページ全体を表示するステップとを含む。

好ましくは、前記初期設定ステップは、Ｗｅｂブラウザがポータル・ページを求める要求をポータル・サーバに送信するステップと、ポータル・サーバがポートレットを呼び出して、前記ポータル・ページ内のすべてのポートレットのＷｅｂコンテンツを入手するステップと、そこに含まれるＨＴＴＰ要求がＸＭＬＨＴＴＰ要求にリダイレクトされ、すべてのポートレットのＷｅｂコンテンツがポータル・ページに編成されるように、すべてのポートレットのＷｅｂコンテンツを変更するステップと、前記ポートレット・モニタを含むポータル・ページをＷｅｂブラウザに返すステップとを含む。

好ましくは、前記ポートレット・モニタは、前記Ｗｅｂコンテンツに組み込まれたスクリプトによって実装される。

好ましくは、前記ポートレット・モニタは、個別スクリプト・ファイルによって実装される。

好ましくは、前記変更ステップは、前記ポータル・サーバ内で実行される。

好ましくは、前記変更ステップは、クライアント側のポートレット・モニタによって実行される。

好ましくは、前記変更ステップは、ＨＴＭＬの書き換えとスクリプトの書き換えを含む。

好ましくは、前記変更ステップは、任意のＨＴＭＬリンク・タグについて、それがアクションＵＲＬを指す場合に、特殊スクリプト機能呼び出しによってその「ｈｒｅｆ」属性を置き換えるステップと、任意のＨＴＭＬフォーム・タグについて、その「ａｃｔｉｏｎ」属性がアクションＵＲＬと等しい場合に、特殊スクリプト機能呼び出しによってその「ａｃｔｉｏｎ」属性を置き換えるステップと、「ＧＥＴ」メソッドを使用してＨＴＴＰ要求を送信する任意のスクリプト・ステートメントについて、特殊スクリプト機能呼び出しによってそれを置き換えるステップと、「ＰＯＳＴ」メソッドを使用してＨＴＴＰ要求を送信する任意のスクリプト・ステートメントについて、特殊スクリプト機能呼び出しによってそれを置き換えるステップとを含む。

好ましくは、クライアント側からのＸＭＬＨＴＴＰ要求に基づいて対応するポートレットから対応するＷｅｂコンテンツを入手し、応答としてクライアント側にＷｅｂコンテンツを送信するように構成されたポートレット・サービス・モジュールと、同期リフレッシュ技術に基づくプログラミング・モデルを使用して開発され、ポートレット・サービス・モジュールからの要求を処理し、対応するＷｅｂコンテンツをそれに提供するように構成された少なくとも１つのポートレットとを有するポータル・サーバと、Ｗｅｂブラウザ上に常駐し、ユーザとポートレットとの間の対話中に前記ポータル・サーバにＸＭＬＨＴＴＰ要求を送信し、前記ポータル・サーバからの応答内のＷｅｂコンテンツで前記ポータル・ページ内の対応するポートレットのＷｅｂコンテンツをリフレッシュするように構成されたポートレット・モニタと、ポータル・サーバからクライアント側に送信されたＷｅｂコンテンツを書き換え、そこに含まれるＨＴＴＰ要求をＸＭＬＨＴＴＰ要求にリダイレクトするように構成されたＷｅｂコンテンツ書き換え手段とを有するクライアントとを有するポータル・システムが提供される。

好ましくは、クライアント側のＸＭＬＨＴＴＰ要求に基づいて対応するポートレットから対応するＷｅｂコンテンツを入手し、応答としてクライアント側にＷｅｂコンテンツを送信するように構成されたポータル・サーバ側のポートレット・サービス・モジュールと、クライアント側のＷｅｂブラウザ上に常駐し、ユーザとポートレットとの間の対話中にポータル・サービス・モジュールにＸＭＬＨＴＴＰ要求を送信し、ポータル・サービス・モジュールからの応答内のＷｅｂコンテンツで前記ポータル・ページ内の対応するポートレットのＷｅｂコンテンツをリフレッシュするように構成されたポートレット・モニタと、ポータル・サーバからクライアント側に送信されたＷｅｂコンテンツを書き換え、そこに含まれるＨＴＴＰ要求をＸＭＬＨＴＴＰ要求にリダイレクトするように構成されたＷｅｂコンテンツ書き換え手段とを有し、非同期ポータル・ページを提供するためのシステムが提供される。

上記により、本発明では、Ｗｅｂブラウザ上に常駐し、スクリプト（ＪａｖａＳｃｒｉｐｔまたはＶＢＳｃｒｉｐｔなど）によって実装されるポートレット・モニタが提供されることが分かる。ユーザがポートレットと対話する場合、ポートレット・モニタはＸＭＬＨＴＴＰ要求をポータル・サーバに送信する。ポータル・サーバは、要求に基づいて対応するポートレットから対応するＷｅｂコンテンツを入手する。次に、Ｗｅｂコンテンツが変更され、そこに含まれるＨＴＴＰ要求がＸＭＬＨＴＴＰ要求にリダイレクトされ、応答としてポートレット・モニタに送信される。ポートレット・モニタは、ポータル・ページ全体を再ロードせずに、変更されたＷｅｂコンテンツを使用して、ポータル・ページ内の対応するポートレットのＷｅｂコンテンツをリフレッシュする。その上、ユーザがポートレットを求める要求を提示した後、ポートレットのコンテンツがリフレッシュされるのを待っている間、ユーザは、他のポートレットと対話し続けることができる。したがって、本発明は、部分的リフレッシュと非同期通信の機能を有する。さらに、本発明は、ポートレット自体を変更する代わりに、ポートレットのＷｅｂコンテンツ内のＨＴＴＰ要求をＸＭＬＨＴＴＰ要求にリダイレクトするので、多数の既存のポートレットを使用することが可能である。一般に、本発明は以下の利点をもたらすことになる。

本発明は、部分的リフレッシュと非同期通信により得られる、良好な応答を備えたポータル・ページを提供することができる。このようなポータル・ページは非同期ポータル・ページと呼ばれる。ポータル・ページ内のすべてのポートレットは、同じＷｅｂページ内にあるので、繰り返しダウンロードせずに共通リソースを共用することができる。本発明は、伝統的なＷｅｂ技術に基づく複数ポートレットを１つの非同期ポータル・ページに統合することができる。ポートレット開発者は、ＡＪＡＸを使用してそれらを書き換える必要はない。

本発明は、プラグ可能モジュールとして、既存のポータル・サーバに容易に実装することができる。このモジュールは、ポートレット開発者にとって透過的なものである。

添付図面に関して以下に示す本発明の諸実施形態の詳細な説明を読むことにより、本発明を完全に理解することができる。

本発明は、非同期ポータル・ページを提供するためのシステムを提案する。図１および図２は、本発明の好ましい諸実施形態による、ポータル・システムのブロック図および非同期ポータル・ページを提供するための方法の流れ図をそれぞれ示している。

次に、図１を参照すると、本発明の好ましい一実施形態によるポータル・システムが示されている。同図に示されている通り、このポータル・システムは、ポータル・サーバ１０４とクライアント１０３とを有する。ポータル・サーバ１０４は、イニシエータ１０５と、ポートレット・サービス・モジュール１０６と、１つまたは複数のポートレット１０７という３通りのコンポーネントを有する。これらのポートレットは、同期技術（ＪＳＲ１６８など）に基づくプログラミング・モデルを使用して開発されている。クライアント１０３は、Ｗｅｂブラウザ上に常駐するポートレット・モニタ１０２を有する。本発明の一実施形態によれば、ポータル・サーバ１０４は、Ｗｅｂコンテンツを書き換えるための手段をさらに有する（点線で示されている）。他の実施形態によれば、Ｗｅｂコンテンツを書き換えるための手段はクライアント側に位置する（点線で示されている）。

ポートレット・モニタ１０２は、Ｗｅｂコンテンツ内に常駐し、Ｗｅｂブラウザ上で実行されるスクリプト（ＪａｖａＳｃｒｉｐｔまたはＶＢＳｃｒｉｐｔなど）によって実装することができる。これは、少なくとも２つの機能、すなわち、ＸＭＬＨＴＴＰ要求をポータル・サーバ１０４に送信することと、ポータル・ページ全体をリフレッシュせずに、更新する必要があるポートレットのＷｅｂコンテンツをポータル・サーバ１０４からの応答内のＷｅｂコンテンツで置き換えることという機能を有する。ポートレット・サービス・モジュール１０６の機能は、ポートレット・モニタ１０２からの要求に基づいてポートレット１０７からＷｅｂコンテンツを入手し、応答としてＷｅｂコンテンツをポートレット・モニタ１０２に送信することである。イニシエータ１０５は、ユーザが最初にポータル・ページを要求するときにポートレット・モニタ１０２およびポートレット構成ファイルなどをクライアント側にダウンロードするために使用され、その構成ファイルは、ポートレットのＩＤ、レイアウト、およびスタイルなどに関する情報を提供する。ポートレット１０７は、ポートレット・サービス・モジュール１０６からの要求を処理し、Ｗｅｂコンテンツをそれに提供するために使用される。Ｗｅｂコンテンツを書き換えるための手段は、ポータル・サーバ１０４からクライアント側に返されるＷｅｂコンテンツ内の伝統的なＨＴＴＰ要求をＸＭＬＨＴＴＰ要求にリダイレクトするために使用される。この手段は、ポータル・サーバ１０４内の個別コンポーネントまたはポートレット・サービス・モジュール１０６によって実装される場合もあれば、クライアント側の個別コンポーネントによってまたはポートレット・モニタの一部として実装される場合もあることに留意されたい。

次に、図２を参照すると、本発明の好ましい一実施形態による非同期ポータル・ページを提供するための方法を示す流れ図が示されている。作業の流れは、６つのフェーズ２０１〜２０６に分割することができる。

フェーズ２０１では、ユーザはＵＲＬを有するポータル・ページを要求する。次に、フェーズ２０２では、Ｗｅｂブラウザはポータル・ページをダウンロードする。２通りのポータル初期設定モードが存在し、ポートレット・モニタのみをダウンロードすること（フェーズ２０２ａに示されている通り、ここでポートレット・モニタをダウンロードすることは、通常、ポートレット・モニタをダウンロードすることと、ポートレット構成ファイルをダウンロードすることという２つの部分を含む）またはポートレット・モニタとポートレットのＷｅｂコンテンツの両方をダウンロードすること（フェーズ２０２ｂに示されている通り）である。ポートレット・モニタのみがダウンロードされる場合、ポートレット・モニタは、その後、非同期的にＷｅｂコンテンツを入手することになる。したがって、ユーザの経験は初期設定中に改善することができる。しかし、このような解決策の場合、ブラウザとポータル・サーバとの間で必要なネットワーク入出力の回数が多くなる可能性がある。ポートレット・モニタとポートレットのＷｅｂコンテンツの両方がダウンロードされる場合、必要なネットワーク入出力の回数が少なくなる。しかし、ポータル・ページは同期的にロードされる。フェーズ２０２ａおよびフェーズ２０２ｂのいずれでも、元のＨＴＴＰ要求をＸＭＬＨＴＴＰ要求で置き換えるために、ポートレットのＷｅｂコンテンツが書き換えられることになる。次に、フェーズ２０３では、ユーザはポータル・ページ内で要求を提示することになり、この要求はＸＭＬＨＴＴＰによりポートレット・モニタからポータル・サーバに提示されることになる。フェーズ２０４では、ポートレットは、ポートレット・サービス・モジュールから受信したユーザの要求に基づいてポートレットのＷｅｂコンテンツを生成し、フェーズ２０５でそのＷｅｂコンテンツも書き換えることになる。最終的にフェーズ２０６では、元のＷｅｂコンテンツを新しいＷｅｂコンテンツで置き換えることにより、ポータル・ページが部分的にリフレッシュされる。

フェーズ２０５はクライアント側またはポータル・サーバ側のいずれか一方で行うことができることに留意されたい。クライアント側で行われた場合、必要なコストはクライアント側で高く、サーバ側で低くなり、逆の場合も同様である。

その上、上記の諸実施形態では、Ｗｅｂブラウザからの初期ポータル・ページを求めるユーザの要求に基づいて、ポータル・サーバがポートレット・モニタ（ポートレット構成ファイルを含む）をクライアント側にダウンロードするのは初期設定フェーズ中であることにさらに留意されたい。しかし、代替例として、ポートレット・モニタを既存のＷｅｂブラウザに組み込むことができ、その結果、ユーザが初期ポータル・ページを要求すると、ポートレット・モニタは、その要求をインターセプトし、ＸＭＬＨＴＴＰ要求により初期ポータル・ページのすべてのポートレットを非同期的にロードすることができる。

次に、図１に示したシステムにより、図２に示した６つのフェーズについて詳細に説明する。

ポータル・ページ初期設定メカニズム
図２に示されている通り、ポータル・ページ初期設定ステップはフェーズ２０１〜２０２を含む。本発明では、２通りの初期設定モードが存在する。次に、この２つのモードについてそれぞれ説明する。

１）ポータル・ページ初期設定メカニズム（ポートレット・モニタのみをダウンロードする）
図３は、本発明の好ましい一実施形態によるポータル・ページ初期設定メカニズム（ポートレット・モニタのみをダウンロードする）を示すシーケンス・チャートである。

図３を参照すると、ポートレット・モニタのみをダウンロードするモードでは、フェーズ２０２ａはステップ３０２〜３１０を含み、そのステップがポータル・ページをダウンロードする機能を実行する。

ステップ３０１では、ユーザは、ＷｅｂブラウザにＵＲＬを入力し、ポータル・ページを入手するための要求をポータル・サーバに送信する。

ステップ３０２では、Ｗｅｂブラウザは、ポータル・サーバ上のイニシエータにポータル・ページを求める要求を送信する。

ステップ３０３では、応答において、イニシエータは、ポートレット・モニタを含むＷｅｂページを返送する。

ステップ３０４では、Ｗｅｂブラウザは、受信したポートレット・モニタを呼び出して、ポートレットのＷｅｂコンテンツを入手するためのＸＭＬＨＴＴＰ要求を送信する。

ステップ３０５では、ポートレット・モニタは、ＸＭＬＨＴＴＰ要求をポータル・サーバに非同期的に送信する。このステップでは、ユーザは待たずにポータル・ページと対話することができる。

ステップ３０６では、ポートレット・サービス・モジュールはポートレットからＷｅｂコンテンツを要求する。ポートレットは、ローカル・ポートレット・コンテナまたはリモート・サービス（たとえば、リモート・ポートレット用のＷｅｂサービス）にすることができる。したがって、このステップはローカルまたはリモートで呼び出すことができる。

ステップ３０７では、ポートレットはポートレットのＷｅｂコンテンツを返す。

ステップ３０８では、ポートレット・サービス・モジュールは、ポートレットのＷｅｂコンテンツを含む応答をＷｅｂブラウザに返送する。このステップ中に、Ｗｅｂコンテンツは、そこに含まれる要求をＸＭＬＨＴＴＰにリダイレクトするように書き換えなければならない。この書き換え動作は、ステップ３０８の開始時または終了時に行うことができ、すなわち、この書き換え動作は、ポータル・サーバまたはクライアント側のポートレット・モニタに実装することができる。

ステップ３０９では、ポートレットのＷｅｂコンテンツが新しいＷｅｂコンテンツで置き換えられる。

ステップ３１０では、ＷｅｂブラウザはＷｅｂコンテンツを表示する。すべてのポートレットのＷｅｂコンテンツが入手されると、ポータル・ページ全体が表示される。

２）ポータル・ページ初期設定メカニズム（ポートレット・モニタとＷｅｂコンテンツの両方をダウンロードする）
図４は、本発明の他の好ましい実施形態によるポータル・ページ初期設定メカニズム（ポートレット・モニタとＷｅｂコンテンツの両方をダウンロードする）を示すシーケンス・チャートである。

図４を参照すると、ポートレット・モニタとＷｅｂコンテンツの両方をダウンロードするモードでは、フェーズ２０２ｂはステップ３５１〜３５６を含み、そのステップがポータル・ページをダウンロードする機能を実行する。

ステップ３５１では、ユーザは、ＷｅｂブラウザにＵＲＬを入力し、ポータル・ページを入手するための要求をポータル・サーバに送信する。

ステップ３５２では、Ｗｅｂブラウザは、イニシエータにポータル・ページを求める要求を送信する。

ステップ３５３では、イニシエータは、ポートレットを呼び出して、ポータル・ページ内のすべてのポートレットのＷｅｂコンテンツを入手する。

ステップ３５４では、ポートレットはすべてのポートレットのＷｅｂコンテンツを返す。イニシエータは、そこに含まれる要求をＸＭＬＨＴＴＰにリダイレクトするようにＷｅｂコンテンツを書き換え、それをポートレット・モニタを含むポータル・ページに結合する。

ステップ３５５では、イニシエータはポータル・ページをＷｅｂブラウザに返す。

ステップ３５６では、Ｗｅｂブラウザはポータル・ページを表示する。

非同期対話メカニズム
図２を参照すると、本発明の一実施形態による非同期対話メカニズムは、４つのフェーズ２０３〜２０６を含む。図５は、非同期対話メカニズムのシーケンス・チャートを示している。

図５を参照すると、フェーズ２０３は、ステップ４０１〜４０３を含み、ポートレット・モニタによりポートレット・サービス・モジュールにＸＭＬＨＴＴＰ要求を送信する機能を実行し、フェーズ２０４は、ステップ４０４〜４０６を含み、ポートレットからＷｅｂコンテンツを入手する機能を実行する。フェーズ２０５は、ステップ４０６の開始時または終了時に行うことができる。フェーズ２０６は、ステップ４０７および４０８を含み、ポートレットの元のＷｅｂコンテンツを受信した新しいＷｅｂコンテンツで置き換え、それを表示する機能を実行する。

ステップ４０１では、ユーザは特定のポートレット内で書式を提示する。

ステップ４０２では、Ｗｅｂブラウザは、ポートレット・モニタを呼び出して、ポートレットの新しいＷｅｂコンテンツを入手するためのＸＭＬＨＴＴＰ要求を送信する。

ステップ４０３では、ポートレット・モニタは、ポータル・サービスにＸＭＬＨＴＴＰ要求を非同期的に送信する。このステップ中に、ユーザは待たずにポータル・ページと対話することができる。

ステップ４０４では、ポートレット・サービス・モジュールはポートレットからＷｅｂコンテンツを要求する。

ステップ４０５では、ポートレットはポートレットのＷｅｂコンテンツをポートレット・サービス・モジュールに返す。

ステップ４０６では、ポートレット・サービス・モジュールは、ポートレットのＷｅｂコンテンツを含む応答をポートレット・モニタに送信する。フェーズ２０５は、ステップ４０６の開始時または終了時に行われ、すなわち、フェーズ２０５は、ポータル・サーバ内にまたはクライアント側のポートレット・モニタ内に実装することができる。

ステップ４０７では、ポートレット・モニタは、ポートレットの元のＷｅｂコンテンツを受信した新しいＷｅｂコンテンツで置き換える。

ステップ４０８では、Ｗｅｂブラウザは、ポータル・ページ全体をリフレッシュせずに、ポートレットの新しいＷｅｂコンテンツを含むポータル・ページを表示する。

Ｗｅｂコンテンツ書き換えメカニズム
フェーズ２０５はＷｅｂコンテンツの書き換えという機能を実行する。ポートレットの元のＷｅｂコンテンツが使用される場合、いずれかの提示によりＷｅｂブラウザがＨＴＴＰ要求を送信することになり、その結果、ページ全体がリフレッシュされる。したがって、ポータル・ページを部分的にリフレッシュするために、Ｗｅｂコンテンツを書き換えて任意の提示をＸＭＬＨＴＴＰにリダイレクトしなければならない。本発明の一実施形態では、この書き換えプロセスは２つのステップ、すなわち、ＨＴＭＬの書き換えおよびスクリプトの書き換えを含む。

次に、原理および実施例に基づいて、この２つのステップについて詳細に説明する。以下の実施例では、「ｘｍｌＡｃｔｉｏｎ」という関数は、ＸＭＬＨＴＴＰにより要求を送信し、新しいポータル・ページを部分的にリフレッシュすることになる。典型的な実装例では、異なるポータル・ページでそれを再利用するために、ポートレット・モニタのプログラムは個別スクリプト・ファイルに保管しなければならない。

たとえば、
<scriptsrc="xmlaction.js"/> </script>
異なるポータル・プログラムがスクリプト・ファイルに依存する場合、Ｗｅｂブラウザはスクリプト・ファイルをキャッシュに入れることができる。

１）ＨＴＭＬの書き換え
任意のＨＴＭＬリンク・タグについて、それがアクションＵＲＬを指す場合に、その「ｈｒｅｆ」属性を置き換えるために特殊スクリプト機能呼び出しが使用される。

たとえば、
<a href="actionurl"> link </a>
は
<a href="javascript:xmlAction('actionurl')"> link </a>
で置き換えられ、
<a href="javascript:form.submit()"> link </a>
は
<a href="javascript:xmlAction(form)"> link </a>
で置き換えられることになる。任意のＨＴＭＬフォーム・タグについて、その「ａｃｔｉｏｎ」属性がアクションＵＲＬと等しい場合に、その「ａｃｔｉｏｎ」属性を置き換えるために特殊スクリプト機能呼び出しが使用される。

たとえば、
<formaction= "actionurl">
<input type="submit" value= "submit"/>
< /form>
は
<formaction= "actionurl" onsubmit= "xmlAction('actionurl')">
<input type="submit" value= "submit"/>
< /form>
で置き換えられることになる。

２）スクリプトの書き換え
「ＧＥＴ」メソッドを使用してＨＴＴＰ要求を送信する任意のスクリプト・ステートメントについて、それを置き換えるために特殊スクリプト機能呼び出しが使用される。

たとえば、
document.location.href="actionurl";
は
xmlAction("actionurl");
で置き換えられることになる。

「ＰＯＳＴ」メソッドを使用してＨＴＴＰ要求を送信する任意のスクリプト・ステートメントについて、それを置き換えるために特殊スクリプト機能呼び出しが使用される。

たとえば、
form.submit();
は
xmlAction(form);
で置き換えられることになる。

上記では本発明の諸実施形態について説明してきたが、その説明は例示的なものであって制限的なものではない。本発明の精神および範囲を逸脱せずに、本発明に対して様々な変更を行うことができる。たとえば、ポートレット・モニタは、ブラウザ上で実行可能な任意のスクリプト言語で実装することができる。さらに、Ｗｅｂコンテンツ書き換え手段がポータル・サーバ内に実装される場合、その手段はポートレット・サービス・モジュール内にまたは個別コンポーネントとして統合することができ、様々な方法および順序で他のコンポーネントに接続することもできる。さらに、Ｗｅｂコンテンツ書き換え手段がポートレット・モニタで実装される場合、その手段はポートレット・モニタの一部またはポートレット・モニタによって呼び出される個別コンポーネントのいずれかにすることができる。その上、本発明の諸実施形態内の機能モジュールは、別々に存在するかまたは様々な方法でまとめて結合することができ、本発明の諸機能を実現できる限り、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせで実装することができる。さらに、本明細書で使用される用語は、記述的なものであり、当業者に本発明の本質を理解させるためのものであって、本発明に厳密な制限を課すためのものではない。本発明の範囲は、特許請求の範囲によって明確に定義される。

本発明の好ましい一実施形態によるポータル・システムを示すブロック図である。本発明の好ましい一実施形態による非同期ポータル・ページを提供するための方法を示す流れ図である。本発明の好ましい一実施形態によるポータル・ページ初期設定メカニズムを示すシーケンス・チャートである。本発明の他の好ましい実施形態によるポータル・ページ初期設定メカニズムを示すシーケンス・チャートである。本発明の好ましい一実施形態による非同期対話メカニズムを示すシーケンス・チャートである。

Claims

ポータル・システム内で非同期ポータル・ページを提供するための方法において、前記ポータル・システム内のポートレットが同期リフレッシュ技術に基づくプログラミング・モデルを使用して開発され、前記方法が、
ポートレットを求めるユーザの要求に応答して、クライアント側のポートレット・モニタがポータル・サーバにＸＭＬＨＴＴＰ要求を送信するステップと、
前記ＸＭＬＨＴＴＰ要求に応答して、前記ポータル・サーバが対応するポートレットを呼び出して、前記ポートレットの対応するＷｅｂコンテンツを入手するステップと、
そこに含まれるＨＴＴＰ要求がＸＭＬＨＴＴＰ要求で置き換えられ、応答として前記クライアント側の前記ポートレット・モニタに送信されるように、前記Ｗｅｂコンテンツを変更するステップと、
前記クライアント側の前記ポートレット・モニタが、前記ポータル・ページ内の前記対応するポートレットの前記Ｗｅｂコンテンツを前記変更されたＷｅｂコンテンツでリフレッシュするステップと、
を含む、方法。
前記方法が、前記クライアント側のＷｅｂブラウザからのポータル・ページを求める要求に応答して、前記ポータル・サーバが前記ポートレット・モニタを前記クライアント側にダウンロードする初期設定ステップをさらに含む、請求項１に記載の方法。
前記初期設定ステップが、
前記Ｗｅｂブラウザがポータル・ページを求める要求を前記ポータル・サーバに送信するステップと、
前記ポータル・サーバが前記ポートレット・モニタを含むポータル・ページを前記Ｗｅｂブラウザに返すステップと、
前記対応するポートレットの前記Ｗｅｂコンテンツを入手するために、前記クライアント側の前記ポートレット・モニタがＸＭＬＨＴＴＰ要求を前記ポータル・サーバに非同期的に送信するステップと、
そこに含まれる前記ＨＴＴＰ要求がＸＭＬＨＴＴＰ要求にリダイレクトされるように、前記Ｗｅｂコンテンツを変更するステップと、
前記クライアント側の前記ポートレット・モニタが前記変更されたＷｅｂコンテンツを含む前記ポータル・ページ内の前記ポートレットをそれぞれロードし、最終的に前記ポータル・ページ全体を表示するステップと、
を含む、請求項２に記載の方法。
前記初期設定ステップが、
前記Ｗｅｂブラウザがポータル・ページを求める要求を前記ポータル・サーバに送信するステップと、
前記ポータル・サーバがポートレットを呼び出して、前記ポータル・ページ内のすべてのポートレットのＷｅｂコンテンツを入手するステップと、
そこに含まれる前記ＨＴＴＰ要求がＸＭＬＨＴＴＰ要求にリダイレクトされるようにすべてのポートレットの前記Ｗｅｂコンテンツを変更し、前記すべてのポートレットの前記Ｗｅｂコンテンツをポータル・ページに編成するステップと、
前記ポートレット・モニタを含む前記ポータル・ページを前記Ｗｅｂブラウザに返すステップと、
を含む、請求項２に記載の方法。
前記ポートレット・モニタが、前記Ｗｅｂコンテンツに組み込まれたスクリプトによって実装される、請求項２ないし４のいずれかに記載の方法。
前記ポートレット・モニタが、個別スクリプト・ファイルによって実装される、請求項１ないし４のいずれかに記載の方法。
前記変更ステップが前記ポータル・サーバ内で実行される、請求項１ないし４のいずれかに記載の方法。
前記変更ステップが前記クライアント側の前記ポートレット・モニタによって実行される、請求項１ないし３のいずれかに記載の方法。
前記変更ステップが、ＨＴＭＬの書き換えとスクリプトの書き換えを含む、請求項１ないし４のいずれかに記載の方法。
前記変更ステップが、
任意のＨＴＭＬリンク・タグについて、それがアクションＵＲＬを指す場合に、特殊スクリプト機能呼び出しによってその「ｈｒｅｆ」属性を置き換えるステップと、
任意のＨＴＭＬフォーム・タグについて、その「ａｃｔｉｏｎ」属性がアクションＵＲＬと等しい場合に、特殊スクリプト機能呼び出しによってその「ａｃｔｉｏｎ」属性を置き換えるステップと、
「ＧＥＴ」メソッドを使用してＨＴＴＰ要求を送信する任意のスクリプト・ステートメントについて、特殊スクリプト機能呼び出しによってそれを置き換えるステップと、
「ＰＯＳＴ」メソッドを使用してＨＴＴＰ要求を送信する任意のスクリプト・ステートメントについて、特殊スクリプト機能呼び出しによってそれを置き換えるステップと、
を含む、請求項９に記載の方法。
請求項１ないし１０のいずれかに記載の前記方法のすべての前記ステップを実行するために適合された手段を有するシステム。
コンピュータ・システム上で実行されるときに請求項１ないし１０のいずれかに記載の前記方法のすべての前記ステップを実行するための命令を含むコンピュータ・プログラム。