(57)【特許請求の範囲】
【請求項１】
クライアント・コンピュータからポイントツーポイントの要求メッセージを受信するステップと、
前記ポイントツーポイントの要求メッセージを、サブジェクト名がメッセージの内容およびメッセージの宛先を指定する文字列として設定されたサブジェクトベースのメッセージに変換するステップと、
前記サブジェクトベースのメッセージを複数のアプリケーション・サーバに対してマルチキャストするステップと、
前記サブジェクトベースのメッセージに対する応答を前記複数のアプリケーション・サーバから受信するステップと、
前記サブジェクトベース・メッセージに対する応答をポイントツーポイントの応答メッセージに変換するステップと、
前記ポイントツーポイントの応答メッセージをクライアント・コンピュータに送信するステップと
から成ることを特徴とする方法。
【請求項２】
前記ポイントツーポイントの要求メッセージは、ハイパーテキスト転送プロトコルに基づくことを特徴とする請求項１に記載の方法。
【請求項３】
前記サブジェクトベースのメッセージは、そのサブジェクトベースのメッセージを受信するサブスクライバのグループを表すことを特徴とする請求項１に記載の方法。
【請求項４】
前記サブジェクトベースのメッセージは、受信者の識別に依存しないことを特徴とする請求項１に記載の方法。
【請求項５】
前記サブジェクトベースのメッセージは、そのサブジェクトベース・メッセージの受信者の識別に依存しないことを特徴とする請求項１に記載の方法。
【請求項６】
命令を提供する機械可読媒体であって、前記命令がプロセッサによって実行されると、前記プロセッサは、
クライアント・コンピュータからポイントツーポイントのメッセージを受信するステップと、
ポイントツーポイントの要求メッセージを、サブジェクト名がメッセージの内容およびメッセージの宛先を指定する文字列として設定されたサブジェクトベースのメッセージに変換するステップと、
前記サブジェクトベース・メッセージを複数のアプリケーション・サーバに対してマルチキャストするステップと、
前記サブジェクトベース・メッセージに対する応答を前記複数のアプリケーション・サーバから受信するステップと、
前記サブジェクトベース・メッセージに対する応答をポイントツーポイントの応答メッセージに変換するステップと、
ポイントツーポイントの応答メッセージをクライアント・コンピュータに送信するステップと
から成る動作を実行することを特徴とする機械可読媒体。
【請求項７】
前記ポイントツーポイントの要求メッセージは、ハイパーテキスト転送プロトコルに基づくことを特徴とする請求項６に記載の機械可読媒体。
【請求項８】
前記サブジェクトベースのメッセージは、そのサブジェクトベース・メッセージを受信するサブスクライバのグループを表すことを特徴とする請求項６に記載の機械可読媒体。
【請求項９】
前記サブジェクトベースのメッセージは、受信者の識別に依存しないことを特徴とする請求項６に記載の機械可読媒体。
【請求項１０】
前記サブジェクトベースのメッセージは、そのサブジェクトベース・メッセージの受信者の識別に依存しない請求項６に記載の機械可読媒体。
【請求項１１】
ネットワークに結合されたアプリケーション・サーバであって、
データを有するデータベースと、
サーバから受信したサブジェクトベースのメッセージを処理する、データベースに結合されたプロセッサとから構成され、前記サブジェクトベースのメッセージは、サブジェクト名がメッセージの内容およびメッセージの宛先を指定する文字列として設定されたものであり、前記プロセッサ内で前記サブジェクトベースのメッセージはデータ内容に対する要求を有し、前記サブジェクトベースのメッセージは、クライアント・コンピュータから前記サーバが受信するポイントツーポイント・メッセージから前記サーバによって生成され、この処理は、
サブジェクトベースの要求メッセージのサブジェクトを感知するため、ネットワークから受信されるサブジェクトベースの要求メッセージをリッスンするステップと、
前記サブジェクトベース・メッセージ中の要求に基づいて、データベース中のデータの一部を抽出するステップと、
前記データベースから抽出されたデータの一部を含む、サブジェクトベースの応答メッセージを生成するステップと、
前記サブジェクトベースの応答メッセージをサーバに送信するステップと
から構成されることを特徴とするアプリケーション・サーバ。
【請求項１２】
前記ポイントツーポイントの要求メッセージは、ハイパーテキスト転送プロトコルに基づくこと特徴とする請求項１１に記載のアプリケーション・サーバ。
【請求項１３】
前記サブジェクトベース・メッセージは、受信者の識別に依存しないことを特徴とする請求項１１に記載のアプリケーション・サーバ。
【請求項１４】
前記サブジェクトベース・メッセージは、そのサブジェクトベース・メッセージの受信者の識別に依存しないことを特徴とする請求項１１に記載のアプリケーション・サーバ。
【請求項１５】
サーバと複数のアプリケーション・サーバとを含むシステムにおいて、
前記サーバは、ネットワークに結合され、ウェブ・ブラウザからハイパーテキスト転送プロトコル（ＨＴＴＰ）に基づくポイントツーポイントの要求メッセージを受信し、そのポイントツーポイント要求メッセージを処理するが、そのポイントツーポイント要求メッセージの処理は、
前記ポイントツーポイントの要求メッセージを、サブジェクト名がメッセージの内容およびメッセージの宛先を指定する文字列として設定されたサブジェクトベースのメッセージに変換するステップと、
前記サブジェクトベースのメッセージを複数のアプリケーション・サーバに対してマルチキャストするステップと、
前記サブジェクトベースのメッセージに対する応答を前記複数のアプリケーション・サーバから受信するステップと、
前記サブジェクトベースのメッセージをポイントツーポイントの応答メッセージに変換するステップと、
前記ポイントツーポイントの応答メッセージをウェブ・ブラウザに送信するステップとから成り、
前記複数のアプリケーション・サーバは、ネットワークに結合され、それぞれのサーバは、
データを有するデータベースと、
サーバから受信した前記サブジェクトベースのメッセージを処理する、データベースに結合されたプロセッサと
から構成され、
前記サブジェクトベース・メッセージの処理は、
ネットワークから受信されるサブジェクトベースの要求メッセージをリッスンするステップと、
サブジェクトベース・メッセージ中の要求に基づいて、データベース中のデータの一部を抽出するステップと、
データベースから抽出したデータの一部を含む、サブジェクトベースの応答メッセージを生成するステップと、
サブジェクトベースの応答メッセージをサーバに送信するステップと
から構成されることを特徴とするシステム。
【請求項１６】
さらに前記複数のアプリケーション・サーバのうち少なくとも１つは分散キューを有し、前記分散キューは前記サーバから前記サブジェクトベース・メッセージを受信し、前記複数のアプリケーション・サーバの１つは、前記分散キューで受信した前記サブジェクトベース・メッセージをどのアプリケーション・サーバが処理するかをスケジューリングすることを特徴とする請求項１５に記載のシステム。
【請求項１７】
受信者は前記サブジェクトベースのメッセージのサブジェクトに基づいて、前記サブジェクトベースのメッセージに応答することを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
本願は、１９９９年１２月２２日出願の「Ｗｅｂ  Ｓｅｒｖｅｒ  ａｎｄ  Ｗｅｂ  Ｓｅｒｖｅｒ  Ｍｅｔｈｏｄ  ｆｏｒ  Ａｎｏｎｙｍｏｕｓ  Ｓｕｂｊｅｃｔ−Ｂａｓｅｄ  Ａｄｄｒｅｓｓｉｎｇ」という名称の米国仮特許出願第６０／１７１，９３０号の継続出願である。
【０００２】
（発明の分野）
本発明は、ネットワーク通信に関する。より詳細には、本発明は、リモート・サーバのコンテンツにアクセスするクライアント・コンピュータに関する。
【０００３】
（発明の背景）
ワールド・ワイド・ウェブ、およびその使用人口と採用の増大により、情報アドレッシングの標準的な方式が開発された。通例は、ウェブ・ブラウザがホスト・サーバにファイル要求を送信し、ホスト・サーバがそのファイルをユーザに「提供」する。
【０００４】
これは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ハイパーテキスト転送プロトコル・セキュア（ＨＴＴＰＳ）、伝送制御プロトコル（ＴＣＰ）、およびインターネット・プロトコル（ＩＰ）という基盤の上に構築された、インターネットの基盤アーキテクチャを使用して実現される。ウェブ・サーバ上のサーバ・プログラムは、このプロトコル・セットに従って、接続するクライアント・コンピュータで実行されるクライアント・プログラム（クライアントのウェブ・ブラウザ）を「リッスン」する。クライアントのブラウザは、ユニフォーム・リソース言語（ＵＲＬ）を利用することによってサーバに接続する。ＵＲＬは、プロトコルの指定（例えばＨＴＴＰ、ＦＴＰ）、ホストの宛先、およびファイルの指定から構成される。ホストの宛先は、実際上は、ポイントツーポイント通信のアドレスである。
【０００５】
この典型的なインターネット通信を図１に示す。詳細には、図１には、従来技術によるブラウザ、ウェブ・サーバ、およびアプリケーション・サーバのシステム図を示している。図１には、ウェブ・ブラウザ１１、インターネット１３、サーバ１５、サーバ１５．１〜１５．５、データベース１７、およびコンテンツ・サーバ１９が含まれる。図に示すように、サーバ１５は、ファイル１６．１〜１６．ｎと実行可能ファイル１８を含む。さらに、サーバ１５．１〜１５．５もファイル１６．１〜１６．ｎと実行可能ファイル１８（図示せず）を含むことができ、これについては下記でさらに詳細に説明する。ウェブ・ブラウザ１１は、インターネット１３を通じてサーバ１５および１５．１〜１５．５に結合される。動作中、ウェブ・ブラウザ１１は、インターネット１３を通じて、サーバ１５および１５．１〜１５．５の１つに呼出しを提出する。この呼出しの一例は、「ｈｔｔｐ：／／ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ／ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」などである。この呼出しには、プロトコルの指定（ｈｔｔｐ）と、サーバ１５のアドレスであるホスト・アドレス（ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ）、およびファイルの指定（ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ）が含まれている。
【０００６】
通常、サーバ１５はこの呼出しをファイルに基づくルックアップとして処理する。その後、要求されるファイルが、サーバ１５により、例えばウェブ・ページなどのＨＴＴＰに準拠したファイルとして、インターネット１３を通じてウェブ・ブラウザ１１に戻される。サーバ１５は、ウェブ・ブラウザ１１に直接ファイルを戻すことも、要求のファイルを処理して、その処理の結果を戻すこともできる。ファイルを処理した場合は、例えば、データベース１７の呼出しが行われるか、かつ／またはコンテンツ・サーバ１９のファイルへのアクセスが行われる。
【０００７】
このように、クライアントすなわちウェブ・ブラウザ１１は、サーバ１５と、双方向あるいはポイントツーポイントの通信をセットアップする。通信は、ウェブ・ブラウザ１１がＨＴＴＰによる要求をサーバ１５に送信することによって確立される。「ｈｔｔｐ／／ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ／ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」の呼出しの例では、サーバ１５（「ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ」に位置する）が、この要求をＧＥＴとして解釈し、クライアント（ウェブ・ブラウザ１１）が「ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」の名称のファイルを要求していると判断する。したがって、呼出し「ｈｔｔｐ：／／ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ／ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」は実際上はファイル・ポインタであり、「ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」は、ＨＴＴＰプロトコルを使用して取り出される、サーバｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍに記憶されたファイルであるということになる。さらに、接尾辞「ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」がない場合には、呼出し「ｈｔｔｐ：／／ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ」はデフォルト・ページのＧＥＴ呼出しとして解釈されるファイル・ポインタになるが、デフォルト・ページは一般的にはサーバ「ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ」の「ｉｎｄｅｘ．ｈｔｍｌ」である。図１で表すように、現在のインターネット（ＨＴＴＰ／ＨＴＴＰＳ／ＴＣＰ／ＩＰ）アーキテクチャは、クライアントとサーバ間のポイントツーポイント通信に依拠する、ファイルベースのウェブ・サーバを基盤とするものである。
【０００８】
３６５日２４時間（７×２４）のサービスの拡大に対する需要の高まりと併せて、ファイルベースのアーキテクチャをセキュリティの向上という面から見ると、スケーラビリティに著しい制約を課し、さもなければ様々なサーバの更新および修正を行わなければならない。詳細には、ファイルベースのウェブ・サーバは、このシステムに対する拡張に対応するには内部的に更新しなければならない。これは、更新、アップグレード、およびスケーリングのためにサーバをシャットダウンし、したがって３６５日２４時間の利用可能性が失われることを意味する。このように、ファイルベースのサーバは、特に顧客サービスの拡大と、動的なリアルタイム・コンテンツに対する需要が高まるのに従って、維持、拡張、およびスケーリングを行うのが難しいものになっている。
【０００９】
この問題は、同じく図１に示すマルチサーバ環境でさらに悪化する。５つのサーバ１５．１〜１５．５を有する、図１に示すようなマルチサーバ環境では、サーバ１５のコンテンツをサーバ１５．１〜１５．５のそれぞれに複製することが必要である。これはすなわち、ファイル１６．１〜１６．ｎすべてと実行可能ファイル１８のコピーを、サーバ１５．１〜１５．５それぞれのために５回複製しなければならないことを意味する。同様に、図に示すように、サーバ１５および１５．１〜１５．５からデータベース１７およびコンテンツ・サーバ１９へのポイントツーポイント・リンクも、これらサーバそれぞれについて作成しなければならない。
【００１０】
先に指摘したように、更新とスケーリングを行うにはウェブ・サーバの内部更新が必要であるが、これは、すべてのコンピュータ（サーバ）をシャットダウンしなければならず、３６５日２４時間の利用可能性に否定的な影響を与えることを意味する。これはまた、ビジネスが、顧客のニーズを満たすためにそのシステムを拡大し、適合するのが困難であることも意味する。このために代替システムが必要とされる。
【００１１】
（発明の概要）
本発明の一実施態様は、クライアント・コンピュータからポイントツーポイントの要求メッセージを受信することを含む方法を提供する。この方法は、そのポイントツーポイントの要求メッセージを、サブジェクトベースのメッセージに変換することも含む。サブジェクトベースのメッセージはマルチキャストも行う。さらに、サブジェクトベースのメッセージに対する応答も受信する。この方法は、サブジェクトベースのメッセージに対する応答を、ポイントツーポイントの応答メッセージに変換することも含む。さらに、このポイントツーポイントの応答メッセージをクライアント・コンピュータに送信する。
【００１２】
本発明の実施形態は、以下の説明と、その実施形態を表す添付図面を参照することによって最もよく理解されるものと思われる。
【００１３】
（詳細な説明）
ネットワーク通信におけるアノニマスなサブジェクトベースのアドレッシングの方法および装置を説明する。したがって、ネットワークにおけるサブジェクトベースのアドレッシングに関連する種々の用語をここで開示する。用語「パブリッシュする」は用語「送信する」と同義であり、用語「サブスクライブする」は用語「リッスンする」と同義である。さらに、以下の説明では説明の目的で、本発明の完全な理解を提供するために多数の具体的な詳細事項を述べる。ただし、本発明はこれらの具体的な詳細を用いずとも実現できることは当業者には明らかであろう。
【００１４】
図２は、本発明の実施形態による、ウェブ・ブラウザ、ウェブ・サーバ、およびアプリケーション・サーバのシステム図を表す。詳細には、図２は、ウェブ・ブラウザ１１、ネットワーク２０２、サーバ２０４、ネットワーク経路２０６、およびアプリケーション・サーバ２０８〜２１４を含む。ウェブ・ブラウザ１１は、ネットワーク２０２を通じてサーバ２０４に結合される。サーバ２０４はさらに、ネットワーク経路２０６を通じてアプリケーション・サーバ２０８〜２１４に結合される。
【００１５】
一実施形態では、ネットワーク２０２はローカル・エリア・ネットワーク（ＬＡＮ）である。別の実施形態では、ネットワーク２０２はワイド・エリア・ネットワーク（ＷＡＮ）である。そのような実施形態では、ネットワーク２０２はインターネットである。さらに、ネットワーク２０２は、ウェブ・ブラウザ１１とサーバ２０４〜２１４間に通信を提供する異なるネットワークの組み合わせでもよい。さらに、図２のトポロジは、制限ではなく例示を目的とするもので、他タイプのトポロジを本発明の実施形態に組み込むことが可能である。例えば、サーバ２０４〜２１４間の結合は、ネットワーク２０２とは別のネットワーク経路２０６を通じて行う代わりに、ネットワーク２０２を通じて行ってもよい。
【００１６】
図３は、本発明の実施形態による、ブラウザ、ウェブ・サーバ、アプリケーション・サーバ、およびこれらにおける機能のシステム図を表す。詳細には、図３には、本発明の実施形態による、サーバ２０４とアプリケーション・サーバ２０８〜２１４の動作方法を示している。図を簡略にするために、図３では１つのブロックで、アプリケーション・サーバ２０８〜２１４それぞれの機能を示している。動作中、ウェブ・ブラウザ１１が、ＨＴＴＰプロトコルによるデータ要求をネットワーク２０２を通じてサーバ２０４に送信する。サーバ２０４は、プロセス・ブロック３０２でＨＴＴＰ要求を受信する。
【００１７】
サーバ２０４は、プロセス・ブロック３０４で、そのＨＴＴＰ要求を、パブリッシュ／サブスクライブ通信のためにサブジェクトベースの要求に変換する。パブリッシュ／サブスクライブ通信の技術は、例えば金融業界などでリアルタイム情報の配信を促進している。詳細には、パブリッシュ／サブスクライブ通信は、あらゆる環境にあるアプリケーションが、確実かつ透過的に最新の情報を共有することを可能にする。このような通信では、所与のパブリッシュ／サブスクライブ・メッセージはネットワークを横断し、そのネットワークに接続されたサーバなどのデバイスが、異なるパブリッシュ／サブスクライブ・メッセージをサブスクライブすることができる。例えば、所与のパブリッシュ／サブスクライブ・メッセージは、ネットワーク上の異なるサーバに常駐する特定のファイルに対する要求に関するものである。このメッセージは、それが受信されたときに、そのパブリッシュ／サブスクライブ・メッセージを最初に送信した要求元のデバイスに送信する必要があるファイルがサブスクライバに分かるようにフォーマットされる。これに対し、ポイントツーポイント通信では、同じメッセージを各サブスクライバに個々に送信するので、ネットワークの帯域幅を浪費し、そのようなメッセージの配信速度が低下する。
【００１８】
さらに、サーバ２０４はプロセス・ブロック３０６で応答サブジェクトを割り当て、そのサブジェクトベースのメッセージをプロセス・ブロック３０８でパブリッシュする。一実施形態では、サブジェクト名は、メッセージの内容を記述し、メッセージの宛先を指定する文字列である。サブジェクトベースのアドレッシング技術は、ネットワーク・アドレス、プロトコル、パケット、ポート、およびソケットの詳細に関して、アプリケーション設計者を関与させることなく、メッセージがそれぞれの宛先に到達することを助ける。一実施形態では、そのようなアプリケーション設計者が、直感的で人間が読んで理解できるサブジェクト名の規則を考案する。
【００１９】
さらに、従来のネットワーク・プログラミングでは、メッセージの配布にＩＰアドレスを組み込み、それにより特定のコンピューティング・デバイスにプログラムを結びつけている。それに対し、サブジェクトベースのアドレッシング・アプリケーションは、サブジェクト名によって情報を共有し、それにより、アプリケーションをネットワーク上のどの位置にあるどのコンピューティング・デバイスでも自由に実行できるようにする。詳細には、ネットワーク上のサーバなど、関係するパーティが特定のサブジェクト名をリッスン（サブスクライブ）する。したがって、第１のデバイス（パブリッシャ）が、特定のサブジェクト名でメッセージをパブリッシュし、ネットワークの他のデバイス（サブスクライバ）がそのサブジェクト名をリッスン（サブスクライブ）している場合、このサブジェクトベースのアドレッシング方式は、そのメッセージをパブリッシャからサブスクライバまで確実にルーティングする。したがって、ネットワークのあるデバイスで実行されるアプリケーションはいずれも、ネットワーク上のデバイスで実行される他のどのアプリケーションにもメッセージを送信することができる。このサブジェクトベースのアドレッシング方式により、分散型システムがより柔軟になり、保守が容易になる。
【００２０】
このように、アプリケーションはリッスンすることによってメッセージを受信する。さらに、一実施形態では、所与のデバイスによるリッスンは、サブジェクト名を、そのようなデバイスで実行することのできるコールバック関数と関連付ける。詳細には、メッセージが到着すると、サブジェクトベースのアドレッシング・ソフトウェアが、所与のサブジェクト名を特定のコールバック関数と一致させることにより、そのメッセージを該当するコールバック関数にディスパッチする。
【００２１】
上記のように、サブジェクトベースのアドレッシング技術は、位置の透過性を可能にする。この技術のパブリッシャとサブスクライバは、ネットワーク上のどのコンピュータにおいても実行することができる。さらに、サーバ・アプリケーションは、既存のクライアントに影響を与えずに、（重いクライアント負荷を共有するために）移送および複製することができる。例えば、パブリッシャ（あるいはクライアント）は、そのサブスクライバの具体的なアドレス（例えばＩＰアドレス）を知る必要がないので、パブリッシャがどのようにそのサブジェクトベースのメッセージを送信するかに影響を与えることなく、サブスクライバを追加、削除、あるいは修正することができる。したがって、このサブジェクトベースのアドレッシング技術により、エンド・ユーザは、変化や発展に対して容易に適合することのできるスケーラブルなワークフロー・システムを構築することができる。
【００２２】
スケーラブルなワークフロー・システムの構築の一例は、システムが、その負荷に対応するために資源を追加して応答する必要があるような重負荷時に行うことができる。旧来のシステムでは、システムに対するこのようなアップグレードは事前に計画する必要がある。それでも、インターネット人口の真のサイズや、ウェブ・サーバによって処理する必要がある同時の要求の数を見誤ることがある。このようなことが起きた場合、現在のアーキテクチャはスケーリングすることができない。これは、現在のアーキテクチャが、資源に限界のある静的に作られたシステムであって、迅速な適合を選択する余地がないためである。本発明の実施形態によると、待ち時間を短縮し、顧客に対するサービスの遅延を回避するために、追加資源をオンザフライに、リアルタイムで動的に追加することができる。これらのバックエンド・システムは、負荷が軽減するとオフラインになることもできる。
【００２３】
図３に戻ると、一実施形態では、このサブジェクトベースの要求メッセージはネットワーク２０６を介してマルチキャストされる。このような実施形態では、アプリケーション・サーバ２０８、２１０、２１２、および２１４は、プロセス・ブロック３１０で、所与の件名で要求をリッスンする。サブジェクトベースの要求を受信すると、アプリケーション・サーバ２０８、２１０、２１２および２１４は、プロセス・ブロック３１２で、所与の件名についてのコンテンツを取り出すことによってその要求を処理する。一実施形態では、コンテンツは、アプリケーション・サーバ２０８、２１０、２１２、および２１４内に記憶されたローカル・データベースから取り出される。ただし、本発明の実施形態はこの形に限定されず、このコンテンツを他の位置から取り出すこともできる。例えば、別のリモート・サーバにコンテンツを記憶することができる。さらに、プロセス・ブロック３１４で、アプリケーション・サーバ２０８、２１０、２１２、および２１４は、プロセス・ブロック３０６でサーバ２０４が割り当てた応答サブジェクトを有するメッセージを使用して、取り出したそのコンテンツをパブリッシュする。
【００２４】
一実施形態では、プロセス・ブロック３０８でサブジェクトベースの要求がパブリッシュされると、サーバ２０４が、プロセス・ブロック３１６で、そのサブジェクトベース・メッセージの応答に対するリッスンを開始する。アプリケーション２０８、２１０、２１２、または２１４のいずれかからサブジェクトベース・メッセージに対する応答を受信すると、サーバ２０４は、その応答中のフィールドおよび内容に基づいてポイントツーポイント応答を生成する。一実施形態では、このポイントツーポイント応答はＨＴＴＰプロトコルに基づく。ポイントツーポイント応答の生成については、下記で図４との関連でより詳細に説明する。サーバ２０４は、プロセス・ブロック３１８で、ネットワーク２０２を通じてこのポイントツーポイント応答をウェブ・ブラウザ１１に送り返す。一実施形態では、この応答を受信すると、ウェブ・ブラウザ１１は、ウェブ・ブラウザ１１のユーザに対してこの応答の内容を表示するウェブ・ページを生成する。ただし本発明の実施形態はこの形に限定されず、ウェブ・ブラウザ１１は、そのような応答を受信すると他の動作を行うこともできる。例えば、この応答を別のウェブ・ページに転送し、それによりウェブ・ブラウザ１１がサーバ２０４に対して新しいＨＴＴＰプロトコル要求を生成するようにしてもよい。
【００２５】
したがって、ウェブ・ブラウザ１１は、ＴＣＰ／ＩＰ／ＨＴＴＰ／ＨＴＴＰＳのプロトコル・セットを使用して、ネットワーク２０２を通じてＨＴＴＰ／ＨＴＴＰＳに準拠したプロトコルを送信する。サーバ２０４はこの呼出し、パケット、またはメッセージをウェブ・ブラウザ１１から受信し、それをサブジェクトベースの呼出しに変換する。例えば、ウェブ・ブラウザ１１から発信された呼出し「ｈｔｔｐ：／／ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ／ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」は、サブジェクトベースのメッセージ「ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」に変換される。このブラウザ呼出しを受信するサーバ２０４は、アドレス「ｗｗｗ．ｒｖ．ｔｉｂｃｏ．ｃｏｍ」で識別されるサーバであることに留意されたい。サーバ２０４は、「Ａ７６２  ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」などの応答サブジェクトを割り当てると、ネットワーク２０６を介してこのサブジェクトベースの要求をマルチキャストし、この特定のサブジェクトベースのメッセージをリッスンしているサーバ（例えばアプリケーション・サーバ２０８〜２１４）はすべて、このメッセージを受信することができる。一実施形態では、アプリケーション・サーバ２０８〜２１４は、複数コンピュータからなるローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク上に位置することができる。一実施形態では、アプリケーション・サーバ２０８〜２１４はスケーラブルである。さらに一実施形態では、サーバ２０４および２０８〜２１４を同じサーバに置くことができる。
【００２６】
図４は、本発明の一実施形態による、サブジェクトベースのメッセージを組み込んだ要求を処理する方法を説明する流れ図である。詳細には、図４は、プロセス・ブロック４０２でウェブ・ブラウザ１１で開始される呼出しで始まる方法４００を示している。プロセス・ブロック４０４で、ウェブ・ブラウザ１１は、ＴＣＰ／ＩＰ／ＨＴＴＰ／ＨＴＴＰＳのプロトコル・セットを使用して、ＨＴＴＰ／ＨＴＴＰＳに準拠した呼出しをネットワーク２０２を通じて送信することによって呼出しを開始する。その結果、サーバ２０４はプロセス・ブロック４０６でその呼出しを受信する。プロセス・ブロック４０８で、サーバ２０４は、ポイントツーポイントの呼出し、すなわち要求をサブジェクトベースのメッセージに対応付ける。例えば、ウェブ・ブラウザ１１から来た呼出し、すなわち要求が、「ｈｔｔｐ：／／．  ．  ．／ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」のようなファイル要求である場合、この呼出しすなわち要求は「ｗｈｉｔｅｐａｐｅｒ．ｈｔｍｌ」というサブジェクト空間に対応付けられる。
【００２７】
さらに、プロセス・ブロック４１０で、ＨＴＴＰ要求を名前／値の対に対応付け、サブジェクトベースのメッセージにパックする。さらに、プロセス・ブロック４１２で、サーバ２０４が応答サブジェクトを生成する。一実施形態では、この応答サブジェクトの生成には、サーバ２０４によってその特定のサブジェクトでパブリッシュされるそれ以降のすべてのメッセージに対するリッスン・イベントを生成することが含まれる。このメッセージは、ウェブ・ブラウザ１１にその内容を送信すべき応答を表す。さらに、応答サブジェクトの生成には、サブジェクトベースの要求をパブリッシュすることが含まれる。
【００２８】
アプリケーション・サーバ２０８〜２１４の１つが、サブジェクトベースの要求に対する応答を戻すと、サーバ２０４は、プロセス・ブロック４１４で、以前に割り当てた応答サブジェクトに基づいてこの応答を受信する。さらに、サーバ２０４は、プロセス・ブロック４１６で、そのサブジェクトベースの応答の内容とタイプ・フィールドに基づいてポイントツーポイント応答を生成する。一実施形態では、ポイントツーポイント応答はＨＴＴＰまたはＨＴＴＰＳによる応答である。サーバ２０４は次いで、プロセス・ブロック４１８で、このポイントツーポイント応答をウェブ・ブラウザ１１に送り返す。一実施形態では、プロセス・ブロック４２０で、ウェブ・ブラウザ１１がこの応答をＨＴＭＬのウェブ・ページとして表示する。ただし、上記のように、サーバ２０４から戻される応答は表示用のウェブ・ページに限定されず、本発明の実施形態は、サーバとクライアント・コンピュータ間の他タイプの応答通信をいずれも取り入れることができる。
【００２９】
図５は、本発明の実施形態のシステム・アプリケーションのブロック図を表す。図２と同様に、図５も、ウェブ・ブラウザ１１、ネットワーク２０２、サーバ２０４、ネットワーク経路２０６、およびアプリケーション・サーバ２０８〜２１４を含む。ウェブ・ブラウザ１１は、ネットワーク２０２を通じてサーバ２０４に結合される。サーバ２０４はさらに、ネットワーク経路２０６を通じてアプリケーション・サーバ２０８〜２１４に結合される。
【００３０】
また、図に示すように、アプリケーション・サーバ２１４は、その中に複数のサーバ（アプリケーション・サーバ２１４．１〜２１４．ｎ）を含むことができる。一実施形態では、アプリケーション・サーバ２１４．１〜２１４．ｎは、ローカル・エリア・ネットワーク（ＬＡＮ）を通じて接続される。別の実施形態では、アプリケーションサーバ２１４．１〜２１４．ｎは、ワイド・エリア・ネットワーク（ＷＡＮ）を通じて接続される。そのような実施形態では、アプリケーション・サーバ２１４．１〜２１４．ｎはインターネットを通じて接続される。さらに、アプリケーション・サーバ２１４．１〜２１４．ｎは、これらのアプリケーション・サーバ間に通信を提供する異なるネットワークの組み合わせを通じて接続される。
【００３１】
ポイントツーポイント・ベースのアドレッシングと異なり、サブジェクトベースのアドレッシングは、図５に示すように、要求メッセージのキューイングとロード・バランシングを可能にする。本発明の実施形態は、分散キューを取り入れることも可能にし、これを、アプリケーション・サーバ２１４の構成と動作によって説明する。
【００３２】
作動の際、アプリケーション・サーバ２１４．１〜２１４．ｎは分散キューと関連付けられ、上記で図３〜４との関連で説明した、受信したサブジェクトベースのメッセージがそのキューに置かれる。さらに、アプリケーション・サーバ２１４．１〜２１４．ｎの１つが、この分散キューのためのアクティブなスケジューラに指定される。一実施形態では、このアクティブ・スケジューラは、スケジューラの重みに基づいて決定される。スケジューラの重みは、同じキューの他のメンバに対する、あるメンバ・セッションのスケジューラの役割を果たす能力を表す。このような一実施形態では、スケジューラの重みは、それが持つ資源の利用可能度に基づく。さらに一実施形態では、最高のスケジューラ重みを有するアプリケーション・サーバ２１４．１〜２１４．ｎがスケジューラに指定される。
【００３３】
さらに、一実施形態では、アクティブ・スケジューラである所与のサーバ（例えばアプリケーション・サーバ２１４．１）が、分散キューの他のサーバ・メンバ（例えばアプリケーション・サーバ２１４．２〜２１４．ｎ）に対して、指定の間隔でハートビート・メッセージを送信する。このハートビート・メッセージは、そのアクティブ・スケジューラがまだ生きていることを他のメンバ・サーバに知らせる。したがって、分散キューの各サーバは、このハートビート・メッセージを受信するために、同じスケジューラ活動化間隔を指定しなくてはならない。アクティブ・スケジューラからのハートビート・メッセージがこの活動化間隔にわたって送信されないと、残りのキュー・メンバの中で最大のスケジューラ重みを有する１つのキュー・メンバが、アクティブ・スケジューラに代わって新しいアクティブ・スケジューラになる。
【００３４】
したがって、このタイプのスケジューリングは必要とされる耐障害性を提供し、所与のメンバ・サーバ２１４．１〜２１４．ｎが分散キューのスケジューラとして機能する。この耐障害性のパラメータ（例えばスケジューリングの重み）によって、分散キューのアクティブ・スケジューラに最も適したメンバ・サーバを選択するので、どのメンバ・サーバ２１４．１〜２１４．ｎもスケジューラになる可能性がある。
【００３５】
さらに、分散キューの一部である、アクティブ・スケジューラを含むすべてのアプリケーション・サーバは、これらが、分散キューに入って来るサブジェクトベースのメッセージをリッスンし、これらのサブジェクトベース・メッセージに対する作用または処理を行うタスクを割り当てられることから、ワーカまたはリスナとして定義される。一実施形態では、分散キューのアプリケーション・サーバ２１４．１〜２１４．ｎは、各自がその名前を持つキューのメンバであることを示す、再利用が可能な同じ対応名を共用することができる。このような一実施形態では、分散キューの各メンバは同じサブジェクトをリッスンする。ただし、各メンバがリッスンする際でも、各インバウンド・メッセージについて、そのメッセージを処理するのは１つのメンバだけである。
【００３６】
詳細には、アプリケーション・サーバ２１４．１〜２１４．ｎの分散キューでサブジェクトベースのメッセージが受信されると、アクティブ・スケジューラ（例えばアプリケーションサーバ２１４．１）は、アクティブ・スケジューラを含めて、その分散キューに関連付けられたアプリケーション・サーバのいずれかに、そのサブジェクトベースのメッセージを処理するタスクを割り当てる。一実施形態では、アクティブ・スケジューラは、ワーカまたはリスナの重みに基づいて、所与のサブジェクトベースのメッセージに対する処理タスクを割り当てる。
【００３７】
このような一実施形態では、アクティブ・スケジューラは、最大のワーカまたはリスナ重みを有する利用可能なワーカまたはリスナに処理タスクを割り当てる。一実施形態では、ワーカまたはリスナは、（１）そのワーカまたはリスナに割り当てられた保留中のタスクがそのタスク能力を超えていないか、または（２）そのワーカまたはリスナがアクティブ・スケジューラでなければ利用可能であると見なされる。ただし、アクティブ・スケジューラは、他のワーカまたはリスナが利用可能でないときには、それ自身にタスクを割り当てることもある。
【００３８】
タスク能力は、ワーカまたはリスナが受け入れることのできる最大のタスク数として定義される。一実施形態では、受け入れたタスクの数がこの最大数に達すると、その時点で保留中のタスクの少なくとも１つが完了するまで、ワーカまたはリスナはそれ以上のタスクを受け入れることができない。アクティブ・スケジューラは、着信するサブジェクトベースのメッセージに基づくタスクを受け取ると、最大のワーカまたはリスナ重みを有するワーカまたはリスナに割り当てられた保留中のタスクがそのタスク能力を超えていない限り、そのワーカまたはリスナにそのタスクを割り当てる。一実施形態では、この好ましいワーカまたはリスナがそのタスク能力を超えているとき、アクティブ・スケジューラは、その次に大きいワーカまたはリスナ重みを有するワーカまたはリスナにその新しいタスクを割り当てる。
【００３９】
一実施形態では、あるサーバが分散キューと関連付けられる際にそのサーバに割り当てられるデフォルトのタスク能力は１である。ただし、この値は、複数の異なる要素に基づいて変更することができる。一実施形態では、マルチスレッド・プログラムを実行する複数のプロセッサを含むサーバで、ｎ個のスレッドとｎ個のプロセッサをインバウンド・タスクに向けるサーバはｎのタスク能力を有する。
【００４０】
一実施形態では、通信時間の遅れを、所与のサーバのタスク能力の要因として考慮に入れる。大半の分散キュー・アプリケーションでは、通信時間は、タスクのターンアラウンド時間の中で取るに足らないわずかな部分である。言い換えると、タスクを割り当て、その完了を通知するのに必要な時間は、実際のタスクを処理するのに必要とされる時間に比較すると非常にわずかである。例えば、平均的なタスクのターンアラウンド時間が２０００ミリ秒で、通信時間がその全体の１０ミリ秒を占める場合、そのタスク能力は、プロセッサまたはスレッドの数と同じになる。
【００４１】
しかし、状況によっては、通信時間が無視できないものになる可能性がある。例えば、ＷＡＮあるいはイントラネットやインターネットによって接続された遠隔地にキュー・メンバが分散されている場合には、通信時間が多大になる可能性がある。通信時間が多大になると、タスク能力の意味が変化する。詳細には、タスク能力は、リスナが同時に処理することのできるタスクの数を表す代わりに、通信時間の遅れにかかわらずそのリスナの能力を満たすことのできるタスク数を表すことになる。例えば、平均的なタスクのターンアラウンド時間が１５００ミリ秒で、その内訳が、全体の時間に対して平均的なタスク処理時間が１０００ミリ秒、平均的な通信時間が５００ミリ秒である場合、タスク能力の設定によって通信時間を補償することにより、タスク間のリスナのアイドル時間を最小にすることができる。
【００４２】
したがって、タスク能力を変えて通信時間の送れを補償する際には、バランスが重要になる。リスナを「過小負荷する」（そのタスク能力を過度に低く設定することによる）と、アクティブ・スケジューラがその次のタスクを割り当てるのを待つ間、リスナがアイドルの状態のままでいることになる。逆に、リスナを「過負荷にする」（そのタスク能力を過度に高く設定することによる）と、割り当てられるタスクの一部を待たせることになり、そのタスクを受け入れることができた可能性のある他のリスナがアイドルのままになる。一実施形態では、アプリケーション・サーバ２１４．１〜２１４．ｎは、サブジェクトベースのメッセージの配信に対して複数のサービス品質をサポートする。
【００４３】
上記のように、分散型のキューイングは、特定のアプリケーション・サーバ２１４を構成するｎ個のアプリケーション・サーバすべてが、サーバ２０４によってパブリッシュされるすべてのメッセージを受け取るのは望ましくないという問題に対処する。一般的には、グループ２１４のすべてのサーバが同じタスクを実行する。これは、例えばグループ２１４中のｎ個のアプリケーション・サーバそれぞれが動作を行うので望ましくない。さらに、各アプリケーション・サーバがメッセージを受信する（そして恐らくはそれに応答する）と、ネットワークの帯域幅を消費することになる。
【００４４】
それでも、グループ２１４中のｎ個のアプリケーション・サーバのうち少なくとも１つがメッセージを受信し、その要求メッセージを可能なすべてのアプリケーション・サーバ間でロード・バランシングすることはどうしても必要である。すなわち、理想的には、システムが、ｎ個のアプリケーション・サーバ２１４の１つだけにメッセージを配信するとよい。多数のｎ個のアプリケーション・サーバ２１４が、望ましいレベルの耐障害性および／またはロード・バランシングを提供する必要があるような状況が発生する。例えば、アプリケーションが不安定であるか、あるいはメッセージの配信が絶対的にクリティカルであるような状況では、耐障害性が重要になる。
【００４５】
本発明の実施形態では、グループ２１４の各アプリケーション・サーバは、例えばサーバ２１４．１など、アクティブ・スケジューラとして機能するｎ個のアプリケーション・サーバの１つにメッセージを送信し、その重みの指示を与える。すると、アクティブ・スケジューラ２１４．１は、受け取ったそのサブジェクトベースのメッセージを、グループ中で最大の重みを有する特定のアプリケーション・サーバに送信することによって応答する。したがって、グループ２１４中のサブスクライブ・サーバによる分散キューは、タスク（更新、および問い合わせ）を表すメッセージを受け入れることができる。このシステムは各タスクをサーバの１つだけに割り当て、サーバのグループとタスクの配布はウェブ・サーバにとって常に完全に透過である。分散型のキューイング機能およびタスクのスケジューリング機能は、公開されたＰＣＴ出願ＷＯ９９／０９４９０により詳細に記載される。この出願は参照により本明細書に組み込む。
【００４６】
さらに、ここに記載するサーバなどのコンピューティング・デバイスは、処理装置および記憶装置（図示せず）を含んでもよい。その記憶装置は、上記に記載した方法論のいずれか１つ、またはすべてを実施する命令のセット（すなわちソフトウェア）を記憶した機械可読媒体を含む。ソフトウェアは、このメモリおよび／またはこの処理装置の中に、完全にまたは少なくとも部分的に常駐することができる。本明細書の目的には、用語「機械可読媒体」は、機械（例えばコンピュータ）が読み出すことのできる形で情報を提供（すなわち、記憶および／または送信）する任意の機構を含むものと解釈されたい。例えば、機械可読媒体には、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリ・デバイス、電気、光、音響、あるいはその他の形の伝搬信号（例えば搬送波、赤外線信号、デジタル信号など）などが含まれる。
【００４７】
以上、ネットワーク通信におけるアノニマスなサブジェクトベースのアドレッシングのための方法および装置を説明した。本発明は、特定の例示的実施形態を参照して説明したが、本発明のより広い精神および範囲から逸脱することなく、これらの実施形態に各種の修正および変更を行えることは明らかであろう。例えば、所与のウェブ・ブラウザと所与のサーバ間でＴＣＰ／ＩＰ／ＨＴＴＰ／ＨＴＴＰＳプロトコルを利用する本発明の実施形態を記載している。しかし、このような実施形態は例示であって制限ではなく、他のタイプのポイントツーポイントのプロトコルを所与のサーバで受信し、サブジェクトベースのメッセージに変換することができる。
【００４８】
上記の実施形態に行うことが可能な別の変更例は、図２、３、および５に示すネットワーク経路２０６の排除である。詳細には、本発明の実施形態は、ネットワーク経路２０６に結合された外部サーバにサブジェクトベースのメッセージを送信する形態に限定されず、サブジェクトベースのメッセージを、サーバ２０４内のプロセスにローカルに送信することもできる。したがって、本明細書および図面は、制限的な意味ではなく例証的な意味に捉えるべきである。
【図面の簡単な説明】
【図１】  従来技術によるブラウザ、ウェブ・サーバ、およびアプリケーション・サーバのシステム図である。
【図２】  本発明の実施形態による、ウェブ・ブラウザ、ウェブ・サーバ、およびアプリケーション・サーバのシステム図である。
【図３】  本発明の実施形態による、ブラウザ、ウェブ・サーバ、アプリケーション・サーバ、およびそれらにおける機能のシステム図である。
【図４】  本発明の実施形態による、サブジェクトベースのメッセージを組み込んだ要求を処理する方法を説明する流れ図である。
【図５】  本発明の実施形態のシステム・アプリケーションのブロック図である。
【図１】
0004663948.tif 000002
【図２】
0004663948.tif 000003
【図３】
0004663948.tif 000004
【図４】
0004663948.tif 000005
【図５】
0004663948.tif 000006