JP2002529854A

JP2002529854A - 分散処理システムにおける複製されたネーミングサービス

Info

Publication number: JP2002529854A
Application number: JP2000581540A
Authority: JP
Inventors: ディーンビージェイコブズ; エリックエムハルパーン
Original assignee: BEA Systems Inc
Current assignee: BEA Systems Inc
Priority date: 1998-11-05
Filing date: 1999-10-21
Publication date: 2002-09-10
Also published as: US20020023173A1; CA2349863A1; AU772589B2; CA2349863C; CN1143220C; AU1217700A; EP1137993A4; US20050203986A1; US6236999B1; US6928457B2; CN1338074A; WO2000028424A1; KR20010099793A; EP1137993A1; US7480679B2; KR100614265B1

Abstract

(57)【要約】クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）分散処理システムが供給される。前記分散処理システムは、通信媒体に結合された第一および第二のコンピュータを含む。第一のコンピュータは、ジャバ（ＪＡＶＡ登録商標）仮想マシン（ＪＶＭ）（３５４）およびメッセージを転送するためのカーネルソフトウェア（３５５）を含み、リモートジャバ（ＪＡＶＡ登録商標）仮想マシン（ＲＪＶＭ）（３５６）を含む。第二のコンピュータは、ＪＶＭと、およびＲＪＶＭを有するカーネルソフトウェア層とを含む。メッセージは、一方のコンピュータにおいてはＲＪＶＭからＪＶＭへ、第二のコンピュータにおいてはＪＶＭおよびＲＪＶＭへと送られる。メッセージは、ネットワーク再構築の後、中間サーバ（３０２および３０３）を通して送信され、またはリルートされてもよい。各負荷バランシングソフトウェアコンポーネント（３６２）およびフェイルオーバソフトウェアコンポーネント。各コンピュータは、ノードにおいて、スマートスタブのプールを記憶するために、複製されたサービスネーミングツリーを含む。前記コンピュータは、ステートレス、ステートレスファクトリ、またはステートフルプログラミングモデルでプログラムされてもよい。クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）分散処理システムは、向上したスケーラビリティおよび故障耐性を可能にする。

Description

【発明の詳細な説明】

【０００１】

【発明の分野】

本発明は、分散処理システムに関するものであり、特に、分散処理システムに
おけるコンピュータソフトウエアに関するものである。

【０００２】

【関連出願のクロスレファレンス】

本願は、１９９８年１１月５日に出願された米国仮出願第６０／１０７１６７
号の優先権を主張している。

【０００３】次の同時に係属中の米国特許出願は、本出願の譲受人に譲渡されており、それ
らの開示は引用によりここに組み入れられている。（A） Dean B. Jacobs およびAnno R. Langenによって(出願日未通知)出願され
「CLUSTERED ENTERPRISE JAVA HAVING A MESSAGE PASSING KERNEL IN A DISTRIB
UTED PROCESSING SYSTEM」と題する出願（番号未通知）（代理人整理番号ＢEAＳ
１０２７）（B） Dean B. Jacobs およびEric M. Halpernによって(出願日未通知)出願さ
れ「A SMART STUB OR ENTERPRISE JAVA BEAN IN A DISTRIBUTED PROCESSING SYS
TEM」と題する出願（番号未通知）（代理人整理番号ＢEAＳ１０２９）（C） Dean B. Jacobs およびEric M. Halpernによって(出願日未通知)出願さ
れ「A DUPRICATED NAMING SERVICE IN A DISTRIBUTED PROCESSING SYSTEM」と
題する出願（番号未通知）（代理人整理番号ＢEAＳ１０２９）

【０００４】

【発明の背景】

分散処理システムにはいくつかのタイプがある。一般的に、分散処理システム
は、通信媒体に結合された２つのコンピュータの如き複数の処理装置を含む。通
信媒体は、ワイヤド媒体、ワイヤレス媒体またはイーサネット（登録商標）ローカルエリアネットワークまたはセルラーネットワークの如きそれらの組み合わせたものを含みうる。分散処理システムにおいては、少なくとも１つの処理装置は、通信媒体にて情報を別の１つの処理装置へ転送する。

【０００５】図１ａに例示するクライアント／サーバアーキテクチャー１１０が１つのタイ
プの分散処理システムである。クライアント／サーバアーキテクチャー１１０は
、クラインアト１０５およびアプリケーションサーバ１０３として例示されるよ
うな少なくとも２つの処理装置を含む。クラインアト１０８の如き付加的クライ
アントも通信媒体１０４に結合されうる。

【０００６】典型的には、サーバ１０３は、ビジネスロジックをホストし、および／または
クライアント１０３および／またはクラインアト１０８の如き別の処理装置へサ
ービスを提供する際のトランザクションを調整する。アプリケーションサーバ１
０３は、典型的には、あるサービスを提供するためソフトウエアでプログラムさ
れる。そのプログラムは、図１ａ−ｂに例示したようなエンタープライズジャバ
（登録商標）ビーン（ＥＪＢ）１００ｂの如き種々なプログラミングモデルを使
用してプログラムされうる。サービスは、例えば、データベースからデータを検
索したり転送したりすること、イメージを提供しおよび／または等式を計算した
りすることを含む。例えば、サーバ１０３は、クライアント１０５からのリクエ
ストに応答して通信媒体１０２を介して持続記憶媒体１０１におけるデータベー
ス１０１ａからデータを検索する。そのとき、アプリケーションサーバ１０３は
、そのリクエストされたデータを通信媒体１０４を介してクライアント１０５へ
転送する。

【０００７】クライアントは、サーバからのサービスを利用する処理装置であり、そのサー
ビスを要求する。しばしば、ユーザ１０６は、クライアント１０６と対話し、ク
ライアント１０５がアプリケーションサーバ１０３から通信媒体１０４を介して
サービスを要求するようにさせうる。クライアントは、しばしば、リクエストの
受け入れおよび結果の表示の如きエンドユーザとの直接対話を取り扱う。

【０００８】アプリケーションサーバ１０３および／またはクライアント１０５をプログラ
ムするのに種々異なるタイプのソフトウエアが使用される。１つのプログラミン
グ言語は、ジャバ（ＪＡＶＡ登録商標）プログラミング言語である。ジャバ（Ｊ
ＡＶＡ登録商標）アプリケーションオブジェクトコードは、ジャバ（ＪＡＶＡ登
録商標）仮想マシン（ＪＶＭ）へロードされる。ＪＶＭは、特定のマシンまたは
処理装置をエミュレートする処理装置へロードされるプログラムである。ジャバ
（ＪＡＶＡ登録商標）プログラミング言語に関するさらなる情報は、ここに引用
により組み込まれるhttp://www.javasoft.comにて得られる。

【０００９】図１ｂは、ジャバ（ＪＡＶＡ登録商標）アプリケーションコードを基礎となる
トランザクションシステム、データベースおよびネットワ−クインフラストラク
チャーと独立したままとしうるいくつかのジャバ（ＪＡＶＡ登録商標）エンター
プライズアプリケーションプログラミングインターフェース（ＡＰＩ）１００を
例示している。ジャバ（ＪＡＶＡ登録商標）エンタープライズＡＰＩ１００は、
例えば、リモートメソッド呼出し（ＲＭＩ）１００ａ、ＥＪＢ１００ｂおよびジ
ャバ（ＪＡＶＡ登録商標）ネーミングおよびディレクトリインターフェース（Ｊ
ＮＤＩ）１００ｃを含む。

【００１０】ＲＭＩ１００ａは、以下に説明するピア・トゥ・ピアキテクチャーにしばしば
使用される分散プログラミングモデルである。特に、一組のクラスおよびインタ
ーフェースは、一つのジャバ（ＪＡＶＡ登録商標）オブジェクトが異なるＪＶＭ
にてランしている別のジャバ（ＪＡＶＡ登録商標）オブジェクトのパブリックメ
ソッドを呼び出すことができるようにする。

【００１１】ＥＪＢ１００ｂの一例は、典型的には、前述したクライアント／サーバアーキ
テクチャーに使用される。ＥＪＢ１００ｂの一例は、ソフトウエアコンポーネン
トまたは他のコンポーネントと結合されうるエンキャプシュレーテドアプリケー
ションコードの再使用可能なプレビルトピースである。典型的には、ＥＪＢ１０
０ｂの一例は、ビジネスロジックを含む。サーバ１０３に記憶されたＥＪＢ１０
０ｂの一例は、持続性、トランザクション、コンカーレンシー、スレッディング
およびセキュリティを管理する。

【００１２】ＪＮＤＩ１００ｃは、ジャバ（ＪＡＶＡ登録商標）ソフトウエアアプリケーシ
ョンに対してディレクトリおよびネーミングファンクションを与える。

【００１３】クライアント／サーバアーキテクチャー１１０は、多くの欠点を有している。
第一に、アーキテクチャー１１０は、良好にスケールしない。何故ならば、サー
バ１０３は、多くのコネクションを取り扱わなければならないからである。換言
するならば、サーバ１０３に加えられ得るクライアントの数は制限されている。
その上、２倍の数の処理装置（クライアント）を加えても、必ずしも、２倍の性
能が与えられるわけではない。第二に、クライアント１０５および１０８に関す
るアプリケーションコードを維持するのが難しい。第三に、アーキテクチャー１
１０は、システム故障または単一ポイントの故障の影響を受けやすい。サーバ１
０１が故障し、バックアップが利用できない場合には、クライアント１０５は、
サービスを受けることができない。

【００１４】図１ｃは、マルチ・ティアーアーキテクチャー１６０を例示している。クライ
アント１５１、１５２は、エンドユーザとの直接対話を管理し、リクエストの受
け入れおよび結果の表示の管理を行う。アプリケーションサーバ１５３は、アプ
リケーションコードをホストし、通信、同期、およびトランザクションを調整す
る。データベースサーバ１５４およびポータブル記憶装置１５５は、データの耐
性のあるトランザクション管理を行う。

【００１５】マルチ・ティアーアーキテクチャー１６０は、前述したのと同様のクライアン
ト／サーバアーキテクチャー１１０の欠点を有する。

【００１６】図２は、ピア・トゥ・ピアキテクチャー２１４を例示している。処理装置２１
６，２１７および２１８が、通信媒体２１３に結合されている。処理装置２１６
、２１７および２１８は、媒体２１３を介しての通信のためネットワークソフト
ウエア２１０ａ、２１０ｂ、および２１０ｃを含む。典型的には、ピア・トゥ・
ピアキテクチャーにおける各処理装置は、同様の処理能力およびアプリケーショ
ンを有する。ピア・トゥ・ピアプログラムモデルの例としては、コモンリクエス
トブローカーアーキテクチャー（ＣＯＲＢＡ）および分散オブジェクトコンポー
ネントモデル（ＤＣＯＭ）アーキテクチャーがある。

【００１７】プラットフォーム特定分散処理システムにおいては、各処理装置は、同じオペ
レーティングシステムを稼働し得る。これにより、処理装置の間の通信のため、
シェアドディスク、マルチテイルドディスクおよびハイスピードインターコネク
トの如き専用ハードウエアを使用することができる。プラットフォーム特定分散
処理システムの例としては、ＩＢＭ（登録商標）コーポレーションのＳ／３９０
パラレルＳｙｓｐｌｅｘ、コンパックのタンデムディビジョンヒマラヤサーバ、
コンパックのデジタルエクイップメントコーポレーション（ＤＥＣ登録商標）デ
ィビジョンＯｐｅｎＶＭＳ（登録商標）クラスタソフトウエア、およびマイクロ
ソフトコーポレーションＷｉｎｄｏｗｓＮＴ（登録商標）クラスタサービス（
ウルフパック）がある。

【００１８】図２ｂは、トランザクション処理（ＴＰ）アーキテクチャー２２０を例示して
いる。特に、ＴＰアーキテクチャー２２０は、ＢＥＡ（登録商標）システムのＴ
ＵＸＥＤＯ（登録商標）アーキテクチャーを例示している。ＴＰモニタ２２４は
、それぞれ通信媒体２８０、２８１、および２８２によって、処理装置ＡＴＭ２
２１、ＰＣ２２２およびＴＰモニタ２２３に結合されている。ＡＴＭ２２１は、
自動テラーマシンであってよく、ＰＣ２２２は、パーソナルコンピュータであっ
てよく、ＴＰモニタ２２３は、別のトランザクションプロセッサモニタであって
よい。ＴＰモニタ２２４は、通信媒体２８３，２８４および２８５によってバッ
クエンドサーバ２２５，２２６および２２７に結合される。サーバ２２５は、通
信媒体２８６によって、データベースを記憶する持続記憶装置２８７に結合され
る。ＴＰモニタ２２４は、ＡＴＭ２２１、ＰＣ２２２またはＴＰモニタ２２３の
如き処理装置からのサービスリクエストをサーバ２２５，２２６および２２７の
如き種々なサーバへルーティングするためのワークフローコントローラ２２４ａ
を含む。ワークフローコントローラ２２４ａは、（１）サーバの間のワーク負荷
のバランシング、（２）制限されたスケーラビリティまたは付加的サーバおよび
／またはクライアントの許容、（３）リダンダントバックエンドサーバの故障耐
性（またはサービスリクエストは故障していないサーバへワークフローコントロ
ーラによって送られ得る）および（４）バックエンドサーバへの同時接続の数を
制限するためのセッション集中をイネーブルする。その他のトランザクション処
理アーキテクチャーの例としては、ＩＢＭ（登録商標）コーポレーションのＣＩ
ＣＳ（登録商標）、コンパックのタンデムディビジョンのパスウエイ／フォード
／ＴＳ、コンパックのＤＥＣ（登録商標）ＡＣＭＳ、およびトランザークコーポ
レーションのエンシナがある。

【００１９】ＴＰアーキテクチャー２２０もまた、多くの欠点を有している。第一に、単一
処理装置またはＴＰモニタ２２４が故障すると、ネットワークが作動しなくなっ
てしまう。第二に、ＴＰモニタ２２４に結合される処理装置（サーバおよびクラ
イアントの両方）のスケーラビィリティまたは数は、ＴＰモニタ２２４のハード
ウエアおよびソフトウエアによって制限されてしまう。第三に、クライアントリ
クエストをサーバへルーティングする融通性が制約されてしまう。例えば、通信
媒体２８０が不作動であるが、通信媒体２９０が利用しうるようになる場合に、
ＡＴＭ２２１が典型的には通信媒体２９０を介してサーバ２２５から直接的にサ
ービスを要求できず、ＴＰモニタ２２４にアクセスしなければならない。第四に
、クライアントは、典型的には、バックエンドサーバまたはその他の処理装置の
状態を知らない。第五に、負荷バランシングのために工業的標準ソフトウエアま
たはＡＰＩを使用できない。そして、第六に、クライアントは、典型的に、その
クライアントが効率的サービスをイネーブルする適切な情報を有する場合でも、
特定のサーバを選択できない。

【００２０】したがって、従来の分散処理システムの利点を有するがそれらの固有の欠点を
有していないような分散処理システム、特に、分散処理システムソフトウエアを
提供することが望ましい。そのソフトウエアは、典型的にはクライアント／サー
バ、マルチ・ティアー、またはピア・トゥ・ピア分散処理システムに使用される
工業的標準ＡＰＩを考慮すべきである。そのソフトウエアは、種々なコンピュー
タプログラミングモデルを支援するものであるべきである。また、そのソフトウ
エアは、（１）故障耐性を高めることのできるもの、（２）効率的なスケーラビ
リティを可能とするもの、（３）実効的な負荷バランシングを可能とするもの、
および（４）セッション集中制御を可能とするもの、であるべきである。その改
良されたコンピュータソフトウエアは、再ルーティングまたはネットワーク再構
成を行えるものであるべきである。また、そのコンピュータソフトウエアは、処
理装置の状態を決定することができるものであるべきである。

【００２１】

【発明の概要】

改良された分散処理システムが提供され、特に、分散処理システムのためのコ
ンピュータソフトウエアが提供される。このコンピュータソフトウエアは、分散
処理システムの故障耐性を改善し且つ効率的なスケーラビリティを可能とする。
このコンピュータソフトウエアは、効率的な負荷バランシングおよびセッション
集中を可能とする。このコンピュータソフトウエアは、再ルーティングまたはコ
ンピュータネットワークの再構成を支援する。このコンピュータソフトウエアは
、種々なコンピュータプログラミングモデルを支援し、クライアント／サーバア
ーキテクチャーおよびピア・トゥ・ピア分散処理アーキテクチャーの両者に使用
される工業的標準ＡＰＩの使用を可能とする。このコンピュータソフトウエアは
、サーバまたは他の処理装置の状態の決定を可能とする。このコンピュータソフ
トウエアは、また、セキュリティモデルを含む種々な環境の下でのメッセージ送
信を支援する。

【００２２】本発明の一つの観点によれば、分散処理システムは、第１の処理装置および第
２の処理装置に結合された通信媒体を備える。第１の処理装置は、データ構造（
ＲＪＶＭ１）を有する第１のカーネルソフトウエア層を含む処理装置（ＪＶＭ１
）をエミュレートする第１のソフトウエアプログラムを含む。第２の処理装置は
、データ構造（ＲＪＶＭ２）を有する第１のカーネルソフトウエア層を含む処理
装置（ＪＶＭ２）をエミュレートする第１のソフトウエアプログラムを含む。第
１の処理装置からのメッセージは、第２の処理装置における第１のカーネルソフ
トウエア層および第１のソフトウエアプログラムに対する第１の処理装置におけ
る第１のカーネルソフトウエア層および第１のソフトウエアプログラムを通して
第２の処理装置へ転送される。

【００２３】本発明の別の観点によれば、第１の処理装置における第１のソフトウエアプロ
グラムは、ジャバ（ＪＡＶＡ登録商標）仮想マシン（ＪＶＭ）であり、第１の処
理装置におけるデータ構造は、リモートジャバ（ＪＡＶＡ登録商標）仮想マシン
(ＲＪＶＭ)である。同様に、第２の処理装置における第１のソフトウエアプログ
ラムは、ＪＶＭであり、第２の処理装置におけるデータ構造は、ＲＪＶＭである
。第２の処理装置におけるＲＪＶＭは、第１の処理装置におけるＪＶＭに対応す
る。

【００２４】本発明の別の観点によれば、第１の処理装置におけるＲＪＶＭは、ソケットマ
ネージャソフトウエアコンポーネント、スレッドマネージャソフトウエアコンポ
ーネント、メッセージルーティングソフトウエアコンポーネント、メッセージ圧
縮ソフトウエアコンポーネント、および／またはピア中断検出ソフトウエアコン
ポーネントを含む。

【００２５】本発明の別の観点によれば、第１の処理装置は、トランスミッションコントロ
ールプロトコル（ＴＣＰ）、セキュアソケットレーヤ（ＳＳＬ）、ハイパーテキ
ストトランスポートプロトコル（ＨＴＴＰ）トンネリング、およびインターネッ
トインテルＯＲＢプロトコル（ＩＩＯＰ）トンネリングからなる群から選択され
たプロトコルを使用して第２の処理装置と通信する。

【００２６】本発明の別の観点によれば、第１の処理装置は、ジャバ（ＪＡＶＡ登録商標）
プリケーションのためのメモリ記憶装置を含む。

【００２７】本発明の別の観点によれば、第１の処理装置は、第２の処理装置のピアである
。また、第１の処理装置は、サーバであり、第２の処理装置は、クライアントで
ある。

【００２８】本発明の別の観点によれば、第２の通信媒体が第２の処理装置に結合される。
第３の処理装置が第２の通信媒体に結合される。第３の処理装置は、第１のデー
タ構造（ＲＪＶＭ１）および第２のデータ構造（ＲＪＶＭ２）を有するカーネル
ソフトウエア層を含む処理装置（ＪＶＭ３）をエミュレートする第１のソフトウ
エアプログラムを含む。

【００２９】本発明のさらに別の観点によれば、第１の処理装置は、レプリカ−ハンドラー
ソフトウエアコンポーネントを有するスタブを含む。レプリカ−ハンドラーソフ
トウエアコンポーネントは、負荷バランシングソフトウエアコンポーネントおよ
び故障回復ソフトウエアコンポーネントを含む。

【００３０】本発明の別の観点によれば、第１の処理装置は、エンタープライズジャバ（Ｊ
ＡＶＡ登録商標）ビーンズオブジェクトを含む。

【００３１】本発明のさらに別の観点によれば、第１の処理装置は、ツリーのノードに記憶
されたスタブのプールを有するネーミングツリーを含み、第２の処理装置は、そ
のネーミングツリーの複製を含む。

【００３２】本発明のさらに別の観点によれば、第１の処理装置は、ステートレスプログラ
ムモデルにコード化されたアプリケーションプログラムを含み、そのアプリケー
ションプログラムは、ステートレスセッションビーンズを含む。

【００３３】本発明のさらに別の観点によれば、第１の処理装置は、ステートレスファクト
リプログラムモデルにコード化されたアプリケーションプログラムを含み、その
アプリケーションプログラムは、ステートフルセッションプログラムを含む。

【００３４】本発明のさらに別の観点によれば、第１の処理装置は、ステートフルプログラ
ムモデルにコード化されたアプリケーションプログラムを含み、そのアプリケー
ションプログラムは、エンティティセッションビーンズを含む。

【００３５】本発明のさらに別の観点によれば、情報記憶媒体を含むアーティクルオブマニ
ュファクチャーが提供される。このアーティクルオブマニュファクチャーは、第
１の処理装置におけるＲＪＶＭから第２の処理装置におけるＲＪＶＭへメッセー
ジを転送するためのデジタル情報の第１のセットを備える。

【００３６】本発明の別の観点によれば、アーティクルオブマニュファクチャーは、複数の
サービスプロバイダからあるサービスプロバイダを選択するための負荷バランシ
ングソフトウエアプログラムを有するスタブを含むデジタル情報の第１のセット
を備える。

【００３７】本発明の別の観点によれば、スタブは、複数のサービスプロバイダから故障し
たサービスプロバイダを除去するための故障回復ソフトウエアコンポーネントを
有する。

【００３８】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、特定のサービスプロバイダについての類縁性に基づいてサービスプロバイダを
選択する。

【００３９】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、ラウンドロビン方式にてサービスプロバイダを選択する。

【００４０】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、ランダムにサービスプロバイダを選択する。

【００４１】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、各サービスプロバイダの負荷に基づいて複数のサービスプロバイダからサービ
スプロバイダを選択する。

【００４２】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、要求されたデータタイプに基づいて複数のサービスプロバイダからサービスプ
ロバイダを選択する。

【００４３】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、最も近い物理的サービスプロバイダに基づいて複数のサービスプロバイダから
サービスプロバイダを選択する。

【００４４】本発明の別の観点によれば、負荷バランシングソフトウエアコンポーネントは
、各サービスプロバイダが応答する時間期間に基づいて複数のサービスプロバイ
ダからサービスプロバイダを選択する。

【００４５】本発明の別の観点によれば、アーティクルオブマニュファクチャーは、複数の
サービスプロバイダからサービスプロバイダを選択するためのエンタープライズ
ジャバ（ＪＡＶＡ登録商標）ビーンズオブジェクトを含むデジタル情報の第１の
セットを備える。

【００４６】本発明の別の観点によれば、あるスタブは、分散処理システムにおける処理装
置に記憶される。そのスタブは、サービスプロバイダのリストを得るステップと
、そのサービスプロバイダのリストからサービスプロバイダを選択するステップ
とを含む方法を含む。

【００４７】本発明の別の観点によれば、その方法は、さらに、サービスプロバイダのリス
トから故障したサービスプロバイダを除去することを含む。

【００４８】本発明のさらに別の観点によれば、ある装置は、第１の処理装置および第２の
処理装置に結合される通信媒体を備える。その第１の処理装置は、サービスプロ
バイダにアクセスするためのリモートメソッド呼出し（ＲＭＩ）を含むネーミン
グツリーを記憶する。

【００４９】本発明の別の観点によれば、ネーミングツリーは、現在のサービスプロバイダ
のサービスプールを含むノードを有する。

【００５０】本発明の別の観点によれば、そのサービスプールは、スタブを含む。

【００５１】本発明の別の観点によれば、分散処理システムは、第２のコンピュータに結合
された第１のコンピュータを備える。その第１のコンピュータは、サービスプロ
バイダにアクセスするためのリモート呼出しスタブを含むネーミングツリーを有
する。第２のコンピュータは、複製されたネーミングツリーおよびサービスプロ
バイダを有する。

【００５２】本発明の別の観点によれば、第２の処理装置に結合された第１の処理装置を備
える分散処理システムが提供される。その第１の処理装置は、ＪＶＭおよび第１
のＲＪＶＭを含む第１のカーネルソフトウエア層を有する。第２の処理装置は、
第１のＪＶＭおよび第２のＲＪＶＭを含む第１のカーネルソフトウエア層を含む
。第１のＪＶＭと第２のＪＶＭとの間に利用しうるソケットがない時、第１の処
理装置から第２の処理装置へメッセージが転送されうる。

【００５３】本発明の別の観点によれば、第１の処理装置は、ファイアウオールの背後でア
プレットセキュリティモデルの下で稼働し、または、クライアントであり、第２
の処理装置もクライアントである。

【００５４】本発明の他の観点および効果は、図面、詳細な説明および請求の範囲の記載か
ら理解されよう。

【００５５】本発明は、添付図面および以下の詳細な説明からより良く理解されよう。添付
図面において、同様の参照符号は、同様のコンポーネントを示している。

【００５６】

【詳細な説明】

１．クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）分散処理シス
テムＡ．クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）ソフトウエアアーキテクチャー図３ａは、本発明の一実施例によるクラスター化エンタープライズジャバ（Ｊ
ＡＶＡ登録商標）システムの処理装置におけるソフトウエア層の簡単化したブロ
ック図３８０を例示している。クラスター化エンタープライズジャバ（ＪＡＶＡ
登録商標）分散処理システムの詳細な説明は以下になされる。ソフトウエアの第
１の層は、イーサネットローカルエリアネットワークの如き通信媒体にて情報を
転送したり受信したりするための通信媒体ソフトウエアドライバ３５１を含む。
送信コントロールプロトコル（ＴＣＰ）ソフトウエアコンポーネント３５３およ
びインターネットプロトコル（ＩＰ）ソフトウエアコンポーネント３５２を含む
オペレーティングシステム３１０は、特定のフォーマットにて情報のパッケージ
またはブロックを検索し送信するための上方ソフトウエア層である。上方ソフト
ウエア層は、一般的には、１つまたはそれ以上の下方ソフトウエア層またはソフ
トウエアコンポーネントを使用しまたはアクセスするソフトウエアコンポーネン
トとして定義されている。そこで、ＪＶＭ３５４が実施される。リモートジャバ
（ＪＡＶＡ登録商標）仮想マシン３５６を有するカーネル３５５がＪＶＭ３５４
にレーヤードされる。後述するカーネル３５５は、クラスター化エンタープライ
ズジャバ（ＪＡＶＡ登録商標）分散処理システムにおいて処理装置の間にメッセ
ージを転送するのに使用される。リモートメソッド呼出し３５７およびエンター
プライズジャバ（ＪＡＶＡ登録商標）ビーン３５８は、カーネル３５５の上方ソ
フトウエア層である。ＥＪＢ３５８は、種々なジャバ（ＪＡＶＡ登録商標）アプ
リケーションのためのコンテナである。

【００５７】図３ｂは、図３ａに例示したカーネル３５５の詳細を例示している。カーネル
３５５は、ソケットマネージャコンポーネント３６３、スレッドマネージャ３６
４コンポーネント、およびＲＪＶＭ３５６を含む。ＲＪＶＭ３５６は、メッセー
ジルーティングソフトウエアコンポーネント３６０、短縮テーブルを含むメッセ
ージ圧縮ソフトウエアコンポーネント３６１、およびピア中断検出ソフトウエア
コンポーネント３６２を含むデータ構造である。ＲＪＶＭ３５６およびスレッド
マネージャコンポーネント３６４は、処理装置の間でデータを転送するため、ソ
ケットマネージャコンポーネント３６３と対話する。

【００５８】Ｂ．分散処理システム図３は、クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）分散処理
システム３００の簡単化したブロック図を例示している。処理装置は、通信媒体
３０１に結合されている。通信媒体３０１は、ワイヤドおよび／またはワイヤレ
ス通信媒体、またはそれらの組合体でありうる。一つの実施例においては、通信
媒体３０１は、ローカルエリアネットワーク（ＬＡＮ）である。別の実施例では
、通信媒体３０１は、インターネットまたはワールドワイドウエブの如きワール
ドエリアネットワーク（ＷＡＮ）である。さらに別の実施例では、通信媒体３０
１は、ＬＡＮおよびWＡＮの両者である。

【００５９】種々な異なるタイプの処理装置が通信媒体３０１に結合されうる。一つの実施
例では、処理装置は、図８に例示した後述されるような汎用コンピュータ１００
でありうる。当業者には理解できるように、図８およびその説明は、異なるソフ
トウエアおよびハードウエアコンフィギュレーションを有した複数の他の型の処
理装置が本発明の一実施例にしたがって使用されうるような特定のタイプの処理
装置を示している。別の実施例では、処理装置は、プリンタ、携帯コンピュータ
、ラップトップコンピュータ、スキャナ、セルラーフォン、ページャー、または
それらの等価物でありうる。

【００６０】図３ｃは、サーバ３０２および３０３が通信媒体３０１に結合されている本発
明の一実施例を例示している。サーバ３０３は、また、通信媒体３０１に関して
前述したような類似の実施例を有し得る通信媒体３０５に結合されている。クラ
イアント３０４もまた、通信媒体３０５に結合されている。別の実施例では、ク
ライアント３０４は、図３ｃにおいて点線およびボックスによって例示したよう
に通信媒体３０１に結合されうる。理解されるように、別の実施例では、サーバ
３０２は、（１）クライアントおよびサーバの両者であり、または（２）クライ
アントである。同様に、図３は、３つの処理装置が示されているような実施例を
例示しており、本発明の他の実施例では、楕円によって例示されるように複数の
他の処理装置または通信媒体を含む。

【００６１】サーバ３０２は、それぞれネットワークソフトウエア３０２ａおよびネットワ
ークソフトウエア３０３ａを使用することにより、通信媒体３０１を介して情報
をサーバ３０３へと転送する。一つの実施例では、ネットワークソフトウエア３
０２ａ、３０３ａ、および３０４ａは、通信媒体ソフトウエアドライバ３５１、
送信コントロールプロトコルソフトウエア３５３、およびインターネットプロト
コルソフトウエア３５２（ＴＣＰ／ＩＰ）を含む。クライアント３０４は、また
、通信媒体３０５を介して上方をサーバ３０３へ転送するためのネットワークソ
フトウエア３０４ａを含む。サーバ３０３におけるネットワークソフトウエア３
０３ａは、また、通信媒体３０５を通してクライアント３０４へ情報を転送する
のにも使用される。

【００６２】本発明の一つの実施例によれば、クラスター化エンタープライズジャバ（ＪＡ
ＶＡ登録商標）アーキテクチャー３００における各処理装置は、マルチ・ティア
ーおよびピア・トゥ・ピア機能の両者を支援するメッセージパッシングカーネル
３５５を含む。カーネルは、処理装置に関する他のソフトウエアプログラムに対
して基本的サービスを提供するのに仕様されるソフトウエアプログラムである。

【００６３】詳細には、サーバ３０２、サーバ３０３、およびクライアント３０４は、それ
ぞれカーネル３０２ｂ、３０３Ｌ、および３０４ｂを有する。詳細には、２つの
ＪＶＭが対話するために、それらがクライアントまたはサーバであるならば、各
ＪＶＭは、他方を表すＲＪＶＭを構成する。メッセージは、一方の側の上方層か
ら対応するＲＪＶＭを通して通信媒体を介してピアＲＪＶＭを通して送られ、他
方の側の上方層へと送付される。種々な実施例では、メッセージは、これには限
定されないが、送信コントロールプロトコル／インターネットプロトコル（ＴＣ
Ｐ／ＩＰ）、セクアソケットレーヤー（ＳＳＬ）、ハイパーテキストトランスポ
ートプロトコル（ＨＴＴＰ）トンネリング、およびインターネットインテルＯＲ
Ｂプロトコル（ＩＩＯＰ）トンネリング、およびそれらの組合体を含む種々異な
るプロトコルを使用して転送されうる。ＲＪＶＭおよびソケットマネージャは、
これらのプロトコルに基づくソケットを生成し維持し、それらを上方層における
すべてのオブジェクトの間で共用する。ソケットは、分散処理システムにおける
処理装置の間のターミナルを表す論理的場所である。カーネルは、実行スレッド
のプールを維持し、スレッドマネージャソフトウエアコンポーネント３６４は、
ソケット読み出しおよびリクエスト実行の間でスレッドを多重化する。

【００６４】例えば、サーバ３０２は、ＪＶＭ１およびジャバ（ＪＡＶＡ登録商標）アプリ
ケーション３０２ｃを含む。サーバ３０２は、サーバ３０３のＪＶＭ２を表すＲ
ＪＶＭ２を含む。もし、メッセージがサーバ３０２からサーバ３０３へ送られる
べき場合には、そのメッセージは、サーバ３０３におけるＲＪＶＭ１へサーバ３
０２におけるＲＪＶＭ２を通して送られる。

【００６５】Ｃ．メッセージ送りクラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）ネットワーク３０
０は、中間サーバを介してメッセージを送ることができる。この機能は、クライ
アントがフロントエンドゲートウエイを通してバックエンドサーバからのサービ
スを要求する場合に重要である。例えば、サーバ３０２（クライアント３０２）
からのメッセージ、特に、ＪＶＭ１は、サーバ３０３（フロントエンドゲートウ
エイ）またはＪＶＭ２を介してクライアント３０４（バックエンドサーバ（３０
４）またはＪＶＭ３へ送られ得る。この機能は、セッション集中を制御し、また
はサーバと多くのクライアントとの間にどのくらいの数の接続が確立されるかを
制御する上で重要である。

【００６６】さらに、メッセージ送りは、２つのＪＶＭの間にソケットが生成され得ないよ
うな環境において使用されうる。例えば、メッセージのセンダーは、元のサーバ
に対するソケットが生成され得ないようなアプレットセキュリティモデルの下で
稼働する。アプレットセキュリティモデルの詳細な説明は、引用によりここに組
み込まれるhttp//:www.javasoft.com.にて提供されている。別の実施例は、メッ
セージのレシーバがファイアウオールの背後にある時を含む。また、後述するよ
うに、メッセージ送りは、センダーがクライアントでありレシーバがクライアン
トであり、したがって、入来ソケットを受け入れない場合に適用しうるものであ
る。

【００６７】例えば、もし、メッセージがサーバ３０２からクライアント３０４へ送られる
場合には、そのメッセージは、サーバ３０３を通してルーティングされねばなら
ない。詳細には、ＲＪＶＭ３（クライアント３０４を表す）の間で３０２ｆによ
って例示されるように、メッセージハンドオフは、サーバ３０２におけるＲＪＶ
Ｍ２（サーバ３０３を表す）に対してなされる。そのメッセージは、サーバ３０
２におけるＲＪＶＭ２とサーバ３０３におけるＲＪＶＭ１の間でソケット３０２
ａを使用して転送される。メッセージは、点線３０３ｆによって例示されるよう
に、ＲＪＶＭ１からサーバ３０３におけるＲＪＶＭ３へとハンドオフされる。そ
の時、メッセージは、サーバ３０３におけるＲＪＶＭ３のソケットとクライアン
トにおけるＲＪＶＭ２との間に通される。それから、メッセージは、点線３０４
ｆによって例示されるように、クライアント３０４におけるＲＪＶＭ２からクラ
イアント３０４におけるＲＪＶＭ１へと通される。

【００６８】Ｄ．再ルーティングクライアント／サーバにおけるＲＪＶＭは、いつでも他のＲＪＶＭに対して通
信路または通信媒体を切り替えることができる。例えば、もし、クライアント３
０４がサーバ３０２に対する直接ソケットを生成する場合には、サーバ３０２は
、サーバ３０３を通してメッセージを送る代わりに、ソケットを使用して開始す
ることができる。この実施例は、クライアント３０４を表す点線およびボックス
によって例示されている。一つの実施例では、ＲＪＶＭによるメッセージ送りを
使用することにより、ネットワーク再構成後の順番でのメッセージ送付を信頼性
のあるものとすることができる。例えば、クライアント３０４が図３に例示した
ような通信媒体３０５に代わる通信媒体３０１に対して再構成される場合である
。別の実施例では、メッセージは、順番に送付されない。

【００６９】ＲＪＶＭは、ルーティングを通して実行されるいくつかのエンドツーエンドオ
ペレーションを行う。最初に、ＲＪＶＭは、各クライアント／サーバが突然停止
したときを検出する責任を負う。一つの実施例では、図３ｂに例示したように、
ピア中断選択ソフトウエアコンポーネント３６２がこの機能の責任を負う。ある
実施例では、ＲＪＶＭは、所定の時間期間にて他のメッセージが送られなかった
時に、心拍メッセージを他のクライアント／サーバへ送る。もし、クライアント
／サーバが所定のカウント時間において心拍メッセージを受け取らない場合には
、その心拍メッセージを送るべきであった故障クライアント／サーバが検出され
る。ある実施例では、故障クライアント／サーバは、接続タイムアウトによって
検出され、または、その故障クライアント／サーバが所定の時間内にメッセージ
を受け取らなかったことによって検出される。

【００７０】第二に、メッセージ直列化中に、ＲＪＶＭ、特に、メッセージ圧縮ソフトウエ
ア３６０は、メッセージサイズを減ずるため送信されたデータ値を共通に短縮す
る。これを行うため、各ＪＶＭ／ＲＪＶＭペアは、マッチング短縮テーブルを維
持する。例えば、ＪＶＭ１は、短縮テーブルを含み、ＲＪＶＭ１は、マッチング
短縮テーブルを含む。中間サーバの間でのメッセージ送り中に、メッセージの本
体は、ルートにおける中間サーバに関して直列化を解かれていない。Ｅ.マルチ・ティアー／ピア・トゥ・ピア機能クラスター化エンタープライズＪａｖａ登録商標アーキテクチャ３００は、マ
ルチ・ティアーおよびピア・トゥ・ピアプログラミングを可能にする。

【００７１】クラスター化エンタープライズＪａｖａ登録商標アーキテクチャ３００は、マ
ルチ・ティアー分散処理アーキテクチャと一致した、クライアント／サーバプロ
グラミングのための、明確なシンタクス（syntax）をサポートする。一例として
、以下のクライアントサイドのコードフラグメントは、情報メッセージを、サー
バのログファイルに書き込む： T3Client clnt = new T3Client{"t3://acme:7001"}； LogServices log = clnt.getT3Services().log（）； log.info("Hello from a client"); 1行目は、ｔ３プロトコルを使用して、acmeサーバとのセッションを確立する
。ＲＪＶＭがまだ存在しない場合、各ＪＶＭは、他方のためにＲＪＶＭを構築し
、および基底ＴＣＰソケットが確立される。このセッションのクライアントサイ
ドの表示−T3Clientオブジェクト−およびサーバサイドの表示は、これらのＲＪ
ＶＭを通して通信する。サーバサイドは、データベースアクセス、リモートファ
イルアクセス、ワークスペース、イベント、およびロギングを含む、様々なサー
ビスをサポートする。２行目は、LogServerオブジェクトを含み、および３行目
はメッセージを書く。

【００７２】クラスター化エンタープライズＪａｖａ登録商標コンピュータアーキテクチャ
３００はまた、ピア・トゥ・ピア分散処理アーキテクチャに一致する、サーバ中
立シンタクスもサポートする。一例として、以下のコードフラグメントは、サー
バ上に、ＪＮＤＩコンプライアント（JNDI-compliant）なネーミングサービスか
らの、ＲＭＩオブジェクトに関するスタブ（stub）を含み、およびその方式の一
つを呼び出す； Hashtable env = new Hashtable()； env.put（Context.PROVIDER_URL,"t3：//acme：7001"）; env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WebLogicInitialContextFactory")； Context ctx = new InitialContext(env); Example e = (Example)ctx.lookup("acme.eng.example")； result＝e.example(37)；一つの実施形態において、ＪＮＤＩネーミングコンテクストは、リモートアク
セスを実行するために、ＲＭＩオブジェクトとしてパーッケージされる。このよ
うに、上述のコードは、一種のＲＭＩブートストラッピング（boot-strapping）
を示す。最初の４行は、アクメサーバ上の初期コンテクストに関するＲＭＩスタ
ブを含む。ＲＪＶＭがまだ存在しない場合、各サイドは、他方のためにＲＪＶＭ
を構築し、およびｔ３プロトコルに関する基底ＴＣＰソケットが確立される。呼
び出しサイドオブジェクト−ＲＭＩスタブ−および呼び出されサイドオブジェク
ト−RMI.impl−は、ＲＪＶＭを通して通信する。５行目は、他のＲＭＩオブジェ
クト、Exampleを、acme.eng.Exampleと言う名前において検索し、および６行目
は、前記Example方式の一つを呼び出す。一つの実施形態において、Example im
plはネーミング・サービスと同じ処理装置上にはない。他の実施形態において、
Example implはクライアント上にある。Exampleオブジェクトの呼び出しは、そ
れらがまだ存在しない場合に、適切なＲＪＶＭの生成へと導く。ＩＩ．複製アウェア（replica-aware）またはスマートスタブ（smart stub）／
ＥＪＢオブジェクト図３ｃにおいて、処理装置は、ＲＭＩおよび／またはＥＪＢオブジェクトを複
製することによって、アーキテクチャ３００における他の処理装置にサービスを
供給することができる。このように、アーキテクチャ３００は、容易にスケール
することができ、および故障許容がある。付加的サービスは、現存する処理装置
または新たに付加された処理装置に、複製されたＲＭＩおよび／またはＥＪＢオ
ブジェクトを付加することによって、アーキテクチャ３００に、容易に加えられ
てもよい。さらに、ＲＭＩおよび／またはＥＪＢオブジェクトは、アーキテクチ
ャ３００全体に複製されうるので、単一の処理装置、複数の処理装置、および／
または通信媒体は、障害を起こすかもしれないし、アーキテクチャ３００を操作
不能にまたは明らかに劣化させないかもしれない。

【００７３】図５ａは、アーキテクチャ５００における複製アウェア（“ＲＡ”）またはス
マートスタブ５８０を示す。アーキテクチャ５００は、通信媒体５０１に結合さ
れたクライアント５０４を含む。サーバ５０２および５０３は、それぞれ通信媒
体５０１に結合されている。持続記憶装置５０９は、それぞれ通信媒体５６０お
よび５６１によって、サーバ５０２および５０３に結合される。様々な実施形態
において、通信媒体５０１、５６０、および５６１は、上述の通り、ワイヤドま
たはワイヤレス通信媒体でもよい。同様に、ある実施形態において、クライアン
ト５０４、サーバ５０２、およびサーバ５０３は、上述の通り、クライアントお
よびサーバの両方でもよい。通常の当業者は、別の実施形態において、複数の他
のサーバおよびクライアントが、楕円で示されたとおり、アーキテクチャ５００
に含まれてもよい。また、上述のとおり、別の実施形態において、クライアント
５０４、サーバ５０２、およびサーバ５０３のハードウェアおよびソフトウェア
・コンフィギュレーションは、後述され、図８に記載されている。

【００７４】ＲＡＲＭＩスタブ５８０は、サービス・プロバイダのすべてを探し出し、お
よびそれらの間で、負荷バランシング方式５０７および／または故障回復方式５
０８に基づいて切り替えることができる、スマートタブである。ある実施形態に
おいて、ＲＡスタブ５８０は、適切な負荷バランシング方式５０７および／また
は故障回復方式５０７を選択する複製ハンドラ５０６を含む。別の実施形態にお
いて、単一の負荷バランシング方式および／または単一の故障回復方式が実行さ
れる。別の実施形態において、複製ハンドラ５０６は、複数の負荷バランシング
方式および／または複数の故障回復方式およびそれらの組み合わせを含んでもよ
い。ある実施形態において、複製ハンドラ５０６は、以下のインターフェースを
実行する： public interface ReplicaHandler{ Object loadBalance(Object currentProvider)throws RefreshAbortedException; Object failOver(Object failedProvider, RemoteException e)throws RemoteException； } 一つの方式を呼び出す直前に、ＲＡスタブ５８０は、負荷バランス方式５０７
を呼び出し、それは現在のサーバを取って、置き換え（replacement）を戻す。
例えば、クライアント５０４は、データベース５０９ａまたはパーソナル記憶装
置５０９に関して、データを検索するために、サーバ５０２を使用していてもよ
い。サーバ５０２は、サービス要求で過負荷（overloaded）にされているので、
負荷バランス方式５０７は、サーバ５０３に切り替えてもよい。ハンドラ５０６
は、おそらくサーバ５０２負荷に関する情報を使用して、完全に呼び出し側にサ
ーバ置き換えを選択してもよく、またはハンドラ５０６は、特定の種類のデータ
を検索するように、サーバ５０２に要求してもよい。例えば、ハンドラ５０６は
、前記サーバが、向上した計算能力を有するので、方程式を計算するための特定
のサーバを選択してもよい。ある実施形態において、複製ハンドラ５０６は、生
成される接続の数を最小化するように努めるので、すべての呼び出しに対して、
実際にはプロバイダを切り替える必要はない。

【００７５】図６ａは、図５ａ乃至ｂに記載の負荷バランシングソフトウェア５０７を示す
、制御フローダイアグラムである。図６ａは、負荷バランシング方式５０７にお
けるソフトウェアによって達成される機能またはステップの論理的シーケンスを
示す、制御フローダイアグラムであることが理解される。別の実施形態において
、付加的機能またはステップが達成される。さらに他の実施形態において、ハー
ドウェアは、特定の機能またはすべての機能を実行してもよい。

【００７６】負荷バランシングソフトウェア５０７は、円６００で示されたとおりに始まる
。呼び出しスレッド（calling thread）が、特定のサーバに関して「類縁性」を
確立したかについて、論理ブロック６０１において決定される。クライアントは
、その現在のトランザクションを調整するサーバに対して類縁性を有し、サーバ
は、自らに対して類縁性を有する。類縁性が確立されると、制御は論理ブロック
６０２に渡され、そうでなければ、論理ブロック６０４に渡される。前記類縁性
サーバが、要求されたサービスを提供するか、論理ブロック６０２で決定される
。そうであれば、制御は論理ブロック６０３に渡される。そうでなければ、制御
は論理ブロック６０４に渡される。前記類縁性サーバ上のサービスのプロバイダ
は、論理ブロック６０３において、前記クライアントに戻される。論理ブロック
６０４において、ネーミングサービスがコンタクトされ、現在のサービスプロバ
イダの更新されたリストが得られる。getNextProvider方式は、論理ブロック６
０５において、サービスプロバイダを入手するために呼び出される。getNextPro
vider方式の様々な実施形態が、図６ｂ乃至ｇに図示され、詳細は後述される。
前記サービスは、論理ブロック６０６で入手される。故障回復方式５０８は、サ
ービスが論理ブロック６０６において供給されない場合に呼び出され、および負
荷バランシング方式５０７は、論理ブロック６０８で示されたとおり、存在する
。故障回復方式５０８の実施形態は、図７に記載されており、詳細は後述される
。

【００７７】図６ｂ乃至ｇは、図６ａの論理ブロック６０５において使用されるgetNextPro
vider方式の様々な実施形態を示す。図６ｂに記載のとおり、getNextProvider方
式は、ラウンドロビン方式で、サービスプロバイダを選択する。getNextProvide
r方式６２０は、円６２１で記載されたとおりに始まる。現在のサービスプロバ
イダのリストは、論理ブロック６２２において入手される。ポインタは、論理ブ
ロック６２３で増大する。次のサービスプロバイダは、論理ブロック６２４にお
けるポインタに基づいて選択され、および新しいサービスプロバイダは、論理ブ
ロック６２５で戻され、およびgetNextProvider方式６２０は、円６２６で記載
のとおり、存在する。

【００７８】図６ｃは、サービスプロバイダを無作為に選択することによって、サービスプ
ロバイダを入手する、getNextProvider方式の別の実施形態を示す。getNextProv
ider方式６３０は、円６３１によって示されたとおりに始まる。現在のサービス
プロバイダのリストは、論理ブロック６３２によって記載のとおり、入手される
。次のサービスプロバイダは、論理ブロック６３３によって記載のとおり、無作
為に選択され、新しいサービスプロバイダは、論理ブロック６３４において戻さ
れる。getNextProvider方式６３０は、円６３５に記載されたとおり、存在する
。

【００７９】 getNextProvider方式の、さらに他の実施形態は、図６ｄに記載されており、
それは前記サービスプロバイダの負荷に基づいて、サービスプロバイダを入手す
る。getNextProvider方式６４０は、円６４１によって記載のとおりに始まる。
現在のサービスプロバイダのリストは、論理ブロック６４２において入手される
。各サービスプロバイダの負荷は、論理ブロック６４３において入手される。最
小の負荷を有するサービスプロバイダは、論理ブロック６４４において選択され
る。新しいサービスプロバイダは、論理ブロック６４５において戻され、getNex
tProvider方式６４０は、円６４６によって記載のとおり、存在する。

【００８０】 getNextProvider方式の他の実施形態は、図６ｅに記載されており、それは前
記サービスプロバイダから入手されたデータの種類に基づいて、サービスプロバ
イダを入手する。getNextProvider方式６５０は、円６５１によって記載のとお
りに始まる。現在のサービスプロバイダのリストは、論理ブロック６５２におい
て入手される。前記サービスプロバイダから要求されたデータの種類は、論理ブ
ロック６５３において決定される。サービスプロバイダは、論理ブロック６５４
において、データの種類に基づいて選択される。サービスプロバイダは、論理ブ
ロック６５５において戻され、getNextProvider方式６５０は、円６５６に記載
のとおり、存在する。

【００８１】 getNextProvider方式のさらに他の実施形態は、図６ｆに記載されており、そ
れは前記サービスプロバイダの物理的場所に基づいて、一つのサービスプロバイ
ダを選択する。getNextProvider方式６６０は、円６６１によって記載のとおり
に始まる。サービスプロバイダのリストは、論理ブロック６６２によって記載の
とおり、入手される。各サービスプロバイダまでの物理的な距離は、論理ブロッ
ク６６３において決定され、および要求しているクライアントまで、最も近い物
理的距離を有するサービスプロバイダが、論理ブロック６６４において選択され
る。新しいサービスプロバイダは、論理ブロック６６５で戻され、およびgetNex
tProvider方式６６０は、円６６６によって記載のとおり、存在する。

【００８２】 getNextProvider方式のさらに他の実施形態は、図６ｇに記載されており、前
記サービスプロバイダが、以前の要求に応答するためにかかった時間の合計に基
づいて、サービスプロバイダを選択する。getNextProvider方式６７０の制御は
、円６７１によって記載のとおりに始まる。現在のサービスプロバイダのリスト
は、論理ブロック６７２において入手される。各サービスプロバイダが、特定の
メッセージに応答するための時間間隔は、論理ブロック６７３で決定される。最
短の時間間隔で応答するサービスプロバイダが、論理ブロック６７４で選択され
る。新しいサービスプロバイダは、論理ブロック６７５で戻され、getNextProvi
der方式６７０からの制御は、円６７６によって記載のとおり、存在する。

【００８３】サービス方式の呼び出しが、再試行が保証されるような方法で故障した場合、
ＲＡ５８０スタブは、故障回復方式５０８を呼び出し、それは故障したサーバお
よび前記故障が何であったかを示す例外を取り、および再試行のために新しいサ
ーバを戻す。新しいサーバが入手不可能である場合、ＲＡスタブ５８０は、例外
を投げる。

【００８４】図７は、図５ａ乃至ｂに記載された故障回復ソフトウェア５０８を示す、制御
フローチャートである。故障回復方式５０８は、円７００によって記載のとおり
始まる。現在のサービスのプロバイダのリストから、故障したプロバイダが、論
理ブロック７０１において除去される。getNextProvider方式は、サービスプロ
バイダを入手するために、呼び出される。新しいサービスプロバイダが、論理ブ
ロック７０３において戻され、および故障回復方式５０８は、円７０４によって
記載のとおり存在する。

【００８５】図６乃至７は、複製ハンドラ５０６の実施形態を示す一方で、別の実施形態は
、ラウンドロビン方式で実行される、以下の機能またはそれらの組み合わせを含
む。

【００８６】第一に、サービスのサーバまたはサービスプロバイダのリストが維持される。
前記リストが使用される必要があり、および前記リストが最近更新されていなか
った場合はいつも、ハンドラ５０６は、後述のとおり、ネーミングサービスにコ
ンタクトし、プロバイダの最新のリストを入手する。

【００８７】第二に、ハンドラ５０６が、前記リストからプロバイダを選択しようとし、最
終の心拍期間（heartbeat period）中に、メッセージが受信されなかったホス
ティングサーバへの、現存するＲＪＶＭレベルの接続がある場合、ハンドラ５０
６は、前記プロバイダを省略する。一つの実施形態において、いくつかの心拍期
間の後で、デスオブピア（death of peer）が決定されるので、サーバは後で
回復してもよい。こうして、サーバ負荷に基づいた、負荷バランシングが得られ
る。

【００８８】第三に、プロバイダが故障した場合、ハンドラ５０６は前記プロバイダを前記
リストから除去する。これは、非稼動サービスプロバイダを使用するための、反
復した試みによって生じる遅延を回避する。

【００８９】第四に、サービスが、前記サービスのプロバイダをホストするサーバから呼び
出されている場合、そのプロバイダが使用される。これは、サービスの連鎖した
呼び出しに関して、プロバイダのコロケーション（colocation）を容易にする。

【００９０】第５に、サービスが、トランザクションの範囲内から呼び出されており、およ
びトランザクションコーディネータ（transaction coordinator）として機能し
ているサーバが、前記サービスのプロバイダをホストする場合、そのプロバイダ
が使用される。これは、トランザクション内におけるプロバイダのコロケーショ
ンを容易にする。

【００９１】方式呼び出し中に生じうる故障は、（１）アプリケーション関連のもの、また
は（２）インフラストラクチャ関連のもののいずれかとして、分類されてもよい
。問題が改善する例外はありえないので、ＲＡスタブ５８０は、アプリケーショ
ン関連の故障の場合には、オペレーションを再試行しないであろう。インフラス
トラクチャ関連の故障の場合、ＲＡスタブ５８０は、そのオペレーションを安全
に再試行することができるかもしれないし、できないかもしれない。データベー
スにおけるフィールドの値を増大させる等、初期非冪等オペレーションは、完了
しているかもしれない。一つの実施形態において、ＲＡスタブ５８０は、（１）
ユーザが、サービス方式が冪等であることを宣言した場合、または（２）システ
ムが、要求の処理を決して開始しないと決定することができる場合にのみ、イン
フラストラクチャの故障の後、再試行するであろう。後者の一例として、ＲＡス
タブ５８０は、負荷バランシング方式の一部として、スタブ５８０が、故障した
ホストを有するサービスプロバイダに切り替える場合、再試行するであろう。他
の例として、ＲＡスタブ５８０は、それがトランザクションのオペレーションへ
の、否定的な認識を得る場合に、再試行するであろう。

【００９２】ＲＭＩコンパイラは、オブジェクトに関するＲＡスタブを生成するように、コ
ンパイラに命令する特殊フラグを認識する。サービス方式が冪等であることを特
定するための付加的フラグが、使用されうる。一つの実施形態において、ＲＡス
タブ５８０は、上述の、および図５ａに記載の複製ハンドラを使用するであろう
。異なるハンドラを特定するために、付加的フラグが使用されてもよい。さらに
、サービスが展開され、すなわち、後述のとおり、クラスター化ネーミングサー
ビスへと束ねられる点で、前記ハンドラはオーバーライド（overridden）されて
もよい。

【００９３】図５ｂは、図５ａに記載のとおり、スタブの代わりにＥＪＢオブジェクト５５
１が使用される、本発明の他の実施形態を示す。

【００９４】ＩＩＩ．複製された、ＪＮＤＩコンプライアントなネーミングサービス図４に記載のとおり、アーキテクチャ４００におけるサービスプロバイダへの
アクセスは、ＪＮＤＩコンプライアントなネーミングサービスを通して得られ、
それは故障の点が一つもないように、アーキテクチャ４００全体に複製される。
従って、ＪＮＤＩコンプライアントなネーミングサービスを提供する処理装置が
故障した場合、複製されたネーミングサービスを有する他の処理装置が使用可能
である。サービスのインスタンスを提供するために、サーバは、複製されたネー
ミングツリーで、特定のノードにおけるサービスのプロバイダを広告する。一つ
の実施形態において、各サーバは、前記ネーミングツリーのサーバのコピーにお
ける前記ノードに記憶された、互換性のあるサービスプールへ、前記プロバイダ
に関するＲＡスタブを加える。新しい提供の種類が、現存するプールにおける提
供の種類と互換性がない場合、新しい提供は保留され、およびConflictHandler
インターフェースを通してコールバックされる。いずれかの種類の提供が取り消
された後、他方は最終的に、どこにでもインストールされるであろう。クライア
ントが前記サービスを検索する時、前記クライアントは、サービスプロバイダの
、前記クライアントのリストを更新するために、前記サービスプールにコンタク
トするＲＡスタブを得る。

【００９５】図４は、アーキテクチャ４００における複製されたネーミングサービスを示す
。一つの実施形態において、サーバ３０２および３０３は、それぞれexampleサ
ービスプロバイダＰ１およびＰ２を示し、それぞれネーミングサービスツリー４
０２および４０３の複製を有する。ネーミングサービスツリー４０２および４０
３におけるノードacme.eng.exampleは、それぞれサービスプール４０２ａおよび
４０３ａを有し、ExampleサービスプロバイダＰ１およびＰ２への参照を含む。
クライアント３０４は、acme.eng.exampleノードにおいてネーミングサービス検
索をすることによって、ＲＡスタブ３０４ｅを含む。スタブ３０４ｅは、利用可
能なサービスプロバイダへの参照の現在のリストを入手するために、サービスプ
ールのインスタンスに接続する。スタブ３０４ｅは、負荷バランシングおよび故
障回復のために必要であれば、サービスプールの前記インスタンス間で切り替え
てもよい。

【００９６】ネーミングサービスの初期コンテクストに関するスタブは、ネーミングサービ
スプロバイダの間で最初に負荷バランスをし、および故障の場合に切り替えをす
る、複製アウェア又はスマートスタブである。前記ネーミングサービスツリーの
各インスタンスは、現在のネーミングサービスプロバイダの完全なリストを含む
。前記スタブは、それが現在使用しているインスタンスから、新しいリストを入
手する。この処理をブートストラップするために、本システムは、インスタンス
の（潜在的に不完全な）初期リストを探すために、ドメインネーミングサービス
（“ＤＮＳ”）を使用し、それらのうちの一つから、完全なリストを入手する。
一例として、前記ネーミングサービスの初期コンテクストに関するスタブは、以
下のとおり、入手されうる： Hashtable env = new Hashtable(); env.put(Context.PROVIDER_URL,"t3://acmeCluster:7001"); env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WebLogicInitialContextFactor"); Context ctx = new InitialContext(env); アーキテクチャにおけるサーバの、あるサブセットは、acmeClusterの名の下
に、ＤＮＳへと束ねられていた。さらに、アプリケーションは、個別のサーバの
アドレスを特定することができるが、そのアプリケーションは、最初にスタブを
入手しようと試みる時に、単一の故障点を有するであろう。

【００９７】信頼性のあるマルチキャストプロトコルが望ましい。ある実施形態において、
プロバイダスタブは分散され、および複製されたネーミングツリーは、ＩＰマル
チキャスト又はポイントツーポイントプロトコルによって作成される。ＩＰマル
チキャストの実施形態において、三種類のメッセージ：心拍、アナウンスメント
（Announcements）、およびStateDumpsがある。心拍は、サーバ間に情報を運搬
するため、およびそれらがないことによって、故障したサーバを識別するために
使用される。アナウンスメントは、一組の、サービスの提供および取り消しを含
む。各サーバからのアナウンスメントは、順番に番号をつけられる。各レシーバ
は、失われたアナウンスメントを識別するために、アナウンスメントを処理する
。各サーバは、それが送信した最後のアナウンスメントのシーケンス番号を、そ
の心拍に含む。失われたアナウンスメントに対するネガティブ・アクノレッジメ
ント（“ＮＡＫｓ”）は、その後の外向きの心拍に含まれる。ＮＡＫを処理する
ために、各サーバは、サーバが送信した最後のいくつかのアナウンスメントのリ
ストを維持する。ＮＡＫが、削除されたアナウンスメントに到達すると、前記サ
ーバは、StateDumpを送信し、それはサーバのサービスの完全なリストおよびそ
の次のアナウンスメントのシーケンス番号を含む。新しいサーバが、現存するア
ーキテクチャに加わると、各他のサーバからの第一のメッセージに対する新しい
サーバＮＡＫは、送信されているStateDumpsという結果を生む。サーバが、予め
決められた時間間隔の後で、他のサーバから心拍を受け取らない場合、前記サー
バは、心拍を生成していないサーバによって提供されたすべてのサービスを取り
消す。

【００９８】ＩＶ．プログラミング・モデル図３乃至５に記載のアーキテクチャにおいて使用されるアプリケーションは、
三つの基本プログラミング・モデル；（１）ステートレス又はダイレクト、（２
）ステートレスファクトリ又はインダイレクト、又は（３）ステートフル又はタ
ーゲテッドの一つを、前記アプリケーション状態が扱われるべき方法に基づいて
、使用する。ステートレスモデルにおいて、ネーミングサービス検索によって戻
されるスマートスタブは、サービスプロバイダを直接参照する。

【００９９】 Example e = (Example)ctx.lookup("acme.eng.example"); result1 = e.example(37); result2 = e.example(38); この例において、exampleへの二つの呼び出しは、スマートスタブが、負荷バ
ランシングのために、それらの間で切り替えることができるので、異なるサービ
スプロバイダによって扱われてもよい。このようにExapmpleサービスオブジェク
トは、前記アプリケーションのために、内部に情報を記憶することができない。
典型的には、前記ステートレスモデルは、前記プロバイダがステートレスである
場合にのみ使用される。一例として、純粋なステートレスプロバイダは、その引
き数の数学的な関数を計算し、その結果を戻してもよい。ステートレスプロバイ
ダは、例えば会計の目的等、自らのために情報を記憶してもよい。より重要なこ
とは、ステートレスプロバイダは、基底の持続記憶装置にアクセスしてもよく、
および必要であれば、アプリケーション状態をメモリにロードしてもよいことで
ある。例えば、引き数として、それに渡されるすべての値のランニング合計を戻
すためのexampleのため、exampleは、データベースから前の合計を読み取り、そ
の現在の引き数に加え、新しい値を書き込み、およびそれを戻してもよい。この
ステートレスサービスモデルは、スケーラビリティ（scalabitily）を促進する
。

【０１００】ステートレスファクトリプログラミングモデルにおいて、前記検索によって戻
されるスマートスタブは、所望のサービスプロバイダを作るファクトリであり、
それ自身ではスマートスタブではない。

【０１０１】 ExampleFactory gf = (ExampleFactory) ctx.lookup("acme.eng.example"); Example e = gf.create(); result1 = e.example(37); result2 = e.example(38); この例において、exampleへの二つの呼び出しは、同じサービスプロバイダに
よって扱われることが保証される。前記サービスプロバイダは、アプリケーショ
ンのために、情報を安全に保存するかもしれない。ステートレスファクトリモデ
ルは、呼び出し側が、プロバイダとの「会話」に関与する必要がある時に、使用
されるであろう。例えば、呼び出し側およびプロバイダが、相互の交渉に関与し
ているかもしれない。複製アウェアスタブは、通常はステートレスおよびステー
トレスファクトリモデルにおいて同じであり、唯一の違いは、スタブが、サービ
スプロバイダを参照するか、又はサービスプロバイダファクトリを参照するかで
ある。

【０１０２】プロバイダファクトリスタブは、このオペレーションが冪等であるので、プロ
バイダを作成するための試みにおいて、自由に故障回復してよい。さらに、間接
的なサービスの利用可能性を向上させるために、アプリケーションコードは、サ
ービス作成および呼び出しについての、明白な再試行ループを含まなければなら
ない。

【０１０３】 while (true) { try{ Example e = gf.create(); result1 = e.example(37); result2 = e.example(38); break; }catch (Exception e){ if (!retry Warranted(e)) throw e; } } これは、例えば、ファクトリによってうまく作成されたプロバイダｅの故障を
扱うであろう。この場合、アプリケーションコードは、非冪等オペレーションが
完了したか、決定する。さらに利用可能性を向上させるために、アプリケーショ
ンコードは、そのようなオペレーションを取り消して、再試行するよう試みても
よい。

【０１０４】ステートフルプログラミングモデルにおいて、サービスプロバイダは、独自の
システムワイドなキーによって識別される、長命で、ステートフルなオブジェク
トである。このモデルを使用してアクセスされてもよい「エンティティ」の例は
、データベーステーブルにおけるリモートファイルシステムおよび列を含む。対
象となるプロバイダは、各プロバイダが、一つのクライアントによって１回使用
される、他の二つのモデルとは異なり、多くのクライアントによって、何回もア
クセスされてもよい。対象となるプロバイダに対するスタブは、前記キーが、単
にネーミングサービス名である直接検索によって、又は前記キーが、作成オペレ
ーションへの引き数を含むファクトリを通して入手されうる。いずれの場合も、
スタブは、負荷バランシング又は故障回復をしない。あるとすれば、再試行は、
前記スタブを明確に再度入手しなければならない。

【０１０５】ＥＪＢには、三種類のビーンズがあり、その各々は、三つのプログラミングモ
デルの一つにマッピングする。ステートレスセッションビーンズは、特定の呼び
出し側のために作成されるが、呼び出しの間に、内部状態を維持しない。ステー
トレスセッションビーンズは、ステートレスモデルにマッピングする。ステート
フルセッションビーンズは、特定の呼び出し側のために作成され、呼び出しの間
に内部状態を維持する。ステートフルセッションビーンズは、前記ステートレス
ファクトリモデルにマッピングする。エンティティビーンズは、システムワイド
なキーによって識別される、単一の、ステートフルオブジェクトである。エンテ
ィティビーンズは、前記ステートフルモデルにマッピングする。三種類すべての
ビーンズは、ＥＪＢホームと称されるファクトリによって作成される。一つの実
施形態において、それらが作成するＥＪＢホームおよびビーンズの両方は、ＲＭ
Ｉを使用して参照される。図３乃至５に記載のアーキテクチャにおいて、ＥＪＢ
ホームに関するスタブは、スマートスタブである。ステートレスセッションビー
ンズに関するスタブは、スマートスタブである一方で、ステートフルセッション
ビーンズおよびエンティティビーンズに関するスタブは、そうではない。ＥＪＢ
に基づいたサービスのために使用する複製ハンドラは、その展開ディスクリプタ
において特定されうる。

【０１０６】目的が、呼び出し側のために状態を維持することである場合に要求される、間
接的な、ＲＭＩに基づいたサービスを作成するために、アプリケーションコード
は、ファクトリを明確に構築しなければならない。対象となるＲＭＩに基づいた
サービスは、特殊フラグはなく、ＲＭＩコンパイラをランさせ、それからその結
果のサービスを、複製されたネーミングツリーに束ねることによって、作成され
うる。前記オビジェクトに関するスタブは、ネーミングツリーの各インスタンス
に直接束ねられ、サービスプールは作成されない。これは、前記キーが、ネーミ
ングサービス名である、対象となるサービスを供給する。一つの実施形態におい
て、これはリモートファイルシステムを作成するために使用される。

【０１０７】Ｖ．ハードウェアおよびソフトウェアコンポーネント図８は、図３乃至５に記載された例示的なサーバおよび／またはクライアント
のハードウェアおよびソフトウェアコンポーネントを示す。図８に記載のシステ
ムは、ＬＡＮ８４０およびＷＡＮへの、接続８２９等の一つ以上の通信媒体によ
って接続された、汎用コンピュータ８００を含み、ここではインターネット８８
０として示されている。ＬＡＮ８４０を通して、コンピュータ８００は、ファイ
ル・サーバ８４１等の他のローカルコンピュータと通信することができる。一つ
の実施形態において、ファイルサーバ８０１は、図３に記載のサーバ３０３であ
る。インターネット８８０を通して、コンピュータ８００はワールドワイドウェ
ブサーバ８８１等、ローカルおよびリモートの両方で、他のコンピュータと通信
することができる。一つの実施形態において、ウェブサーバ８８１は、図３に記
載のサーバ３０３である。理解されるであろうとおり、コンピュータ８００から
インターネット８８０への接続は、様々な方式、たとえば直接接続８２９を介し
て、又はローカルエリアネットワーク８４０を通して、又はモデム（図示されて
いない）によって作られうる。

【０１０８】コンピュータ８００は、例えば、ワークステーション、パーソナルコンピュー
タ、又は他の単一ユーザあるいはマルチユーザコンピュータシステムでもよい、
パーソナル又はオフィスコンピュータである；例示的な実施形態は、ＳｕｎＳＰＡＲＣ−２０ワークステーション（Sun Microsystems, Inc., Mou
ntain View, CA）を使用する。説明のために、コンピュータ８００は都合よく、
ハードウェアコンポーネント８０１およびソフトウェアコンポーネント８０２へ
と分割されうる；しかしながら、通常の当業者は、この分割は概念的であり、や
や任意であり、およびハードウェアとソフトウェアの間のラインは、ハードで速
いものではないことを理解するであろう。さらに、ホストコンピュータとその付
属の周辺装置との間のラインは、ハードで速いものではなく、特に、いくつかの
コンピュータの周辺装置と考えられるコンポーネントは、他のコンピュータの構
成部分であると考えられることが理解される。このように、例えば、ユーザＩ／
Ｏ８２０は、キーボード、マウス、およびディスプレイモニタを含むことができ
、その各々は、周辺装置またはコンピュータそのものの一部であると考えられ、
さらにローカルプリンタを含むことができ、それは典型的には周辺装置であると
考えられる。他の例として、持続記憶装置８０８は、ＣＤ−ＲＯＭ（コンパクト
・ディスク読み取り専用メモリ）装置を含むことができ、それは周辺装置か、ま
たはコンピュータに組み込まれることができる。

【０１０９】ハードウェアコンポーネント８０１は、プロセッサ（ＣＰＵ）８０５、メモリ
８０６、持続記憶装置８０８、ユーザＩ／Ｏ８２０、およびバス８１０に結合さ
れているネットワークインターフェース８２５を含む。これらのコンポーネント
は、当業者によってよく理解され、それに従ってここでは簡単に説明されればよ
い。

【０１１０】プロセッサ８０５は、例えば、マルチプロセッシングのために構成されたマイ
クロプロセッサまたはマイクロプロセッサの集まりでもよい。読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、仮想メモ
リ、またはメモリ技術を単一で、またはそれらの組み合わせを含みうる。持続記
憶装置８０８は、例えば、磁気ハードディスク、フロッピディスク、または他の
持続読み取り−書き込みデータ記憶技術を、単一で、または組み合わせで含みう
る。それはさらに、ＣＤ−ＲＯＭまたは他の大容量記憶技術によって供給されう
るような、大容量またはアーカイバル（archival）記憶装置を含みうる。（ファ
イルサーバ８４１は、プロセッサ８０５が使用することができる付加的記憶能力
を供給することが注目される。）ユーザＩ／Ｏ（入力／出力）ハードウェア８２０は、典型的にはＣＲＴまたは
フラットパネルディスプレイ等のビジュアルディスプレイモニタ、英数字キーボ
ード、およびマウスまたは他の位置決め装置を含み、任意でさらに、プリンタ、
光学スキャナ、またはユーザ入力および出力のための他の装置を含みうる。

【０１１１】ネットワークＩ／Ｏハードウェア８２５は、コンピュータ８００と外界との間
にインターフェースを供給する。より特定的には、ネットワークＩ／Ｏ８２５は
、プロセッサ８０５に、接続８２９を介して、ＬＡＮ８４０およびインターネッ
ト８８０を通して、他のプロセッサおよび装置と通信させる。

【０１１２】ソフトウェアコンポーネント８０２は、オペレーティングシステム８５０およ
びジャバ（ＪＡＶＡ登録商標）アプリケーションプログラム８６０等のオペレー
ティングシステム３１０の制御下での一組のタスク、および重要なことに、ＪＶ
Ｍソフトウェア３５４およびカーネル３５５を含む。オペレーティングシステム
３１０はまた、プロセッサ８０５に、持続記憶装置８０８、ユーザＩ／Ｏ８２０
、およびネットワークインターフェース８２５等、様々な装置を制御させる。プ
ロセッサ８０５は、オペレーティングシステム３１０、アプリケーション８６０
、ＪＶＭ３５４およびカーネル３５５のソフトウェアを、メモリ８０６およびコ
ンピュータシステム８００の他のコンポーネントとともに実行する。一つの実施
形態において、ソフトウェア８０２は、図３に記載のサーバ３０２に記載のとお
り、ネットワークソフトウェア３０２ａ、ＪＶＭ１、ＲＪＶＭ２およびＲＪＶＭ
３を含む。一つの実施形態において、ジャバ（ＪＡＶＡ登録商標）アプリケーシ
ョンプログラム８６０は、図３ｃに記載のとおり、ジャバ（ＪＡＶＡ登録商標）
アプリケーション３０２ｃである。

【０１１３】通常の当業者は、図８に記載のシステムは、制限的なものではなくて、例示的
なものであり、幅広い計算、通信および情報装置が、図８に記載のものの代わり
にまたは付加的に使用されうることを、理解するであろう。例えば、インターネ
ット８８０を通した接続は通常、中間ルータコンピュータ（図示されていない）
によるパケット切り替えを伴い、通常のウェブクライアントセッションの間に、
コンピュータ８００は、コンピュータ８００およびウェブサーバ８８１を含むが
それらに限定されないウェブサーバのいくつにでもアクセスするであろう。

【０１１４】本発明の好ましい実施形態の前述の説明は、図示と説明のために示されてきた
。それは完全なものではなく、あるいは開示された詳細な形式に本発明を限定す
るものではない。明らかに、多くの変更または変形が、当業者には明らかになる
であろう。本発明の原理および実践的なアプリケーションを最も良く説明するた
めに、前記実施形態が選ばれおよび説明され、それによって当業者は、様々な実
施形態に関して、および考えられる特定の使用に適した様々な変更で、本発明を
理解することができるであろう。本発明の範囲は、以下の特許請求の範囲および
それらに相当するものによって定義されるものである。

【図面の簡単な説明】

【図１ａ】従来のクライアント／サーバアーキテクチャーを例示する図である。

【図１ｂ】従来のジャバ（ＪＡＶＡ登録商標）エンタープライズＡＰＩを例示する図であ
る。

【図１ｃ】マルチ・ティアーアーキテクチャーを例示する図である。

【図２ａ】従来のピア・トゥ・ピアアキテクチャーを例示する図である。

【図２ｂ】従来のトランザクション処理アーキテクチャーを例示する図である。

【図３ａ】本発明の一実施例の簡単化されたソフトウエアブロック図を例示する図である
。

【図３ｂ】図３ａに例示したカーネルの簡単化したソフトウエアブロック図を例示する図
である。

【図３ｃ】クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）ネーミングサービ
スアーキテクチャーを例示する図である。

【図４】クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）ネーミングサービ
スアーキテクチャーを例示する図である。

【図５ａ】スマートスタブアーキテクチャーを例示する図である。

【図５ｂ】ＥＪＢオブジェクトアーキテクチャーを例示する図である。

【図６ａ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図６ｂ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図６ｃ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図６ｄ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図６ｅ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図６ｆ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図６ｇ】負荷バランシングメソッドを例示するコントロールフローチャートである。

【図７】故障回復メソッドを例示するコントロールフローチャートである。

【図８】図３から図５に示すクラスター化エンタープライズジャバ（ＪＡＶＡ登録商標
）アーキテクチャーにおけるクライアント／サーバのハードウエアおよびソフト
ウエアコンポーネントを例示する図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (71)出願人 2315 ＮｏｒｔｈＦｉｒｓｔＳｔｒｅｅｔ，ＳａｎＪｏｓｅ，ＣＡＬＩＦＯＲＮＩＡ 95131 Ｕ．Ｓ．Ａ． (72)発明者ハルパーンエリックエムアメリカ合衆国カリフォルニア州 94117 サンフランシスコデルマーストリート 41 Ｆターム(参考） 5B045 GG01 GG02 JJ46 5B098 HH01 【要約の続き】は、ステートレス、ステートレスファクトリ、またはステートフルプログラミングモデルでプログラムされてもよい。クラスター化エンタープライズジャバ（ＪＡＶＡ登録商標）分散処理システムは、向上したスケーラビリティおよび故障耐性を可能にする。

Claims

【特許請求の範囲】

【請求項１】通信媒体を具備し；ネーミングサービスを有する、前記通信媒体に結合された、第一の処理装置と
；及び複製されたネーミングサービスを有する、前記通信媒体に結合された、第二の
処理装置とを具備する装置。
【請求項２】前記ネーミングサービスは、ＪＮＤＩコンプライアントなネーミングサービス
であることを特徴とする、請求項１に記載の装置。
【請求項３】前記複製ネーミングサービスは、前記第一のネーミングサービスの故障時に使
用可能であることを特徴とする、請求項１に記載の装置。
【請求項４】前記第一のネーミングサービスは、サービスプールを含むノードを有するネー
ミングツリーを含み、および前記複製されたネーミングサービスは、複製された
ネーミングツリーを含むことを特徴とする、請求項１に記載の装置。
【請求項５】前記サービスプールは、サービスプロバイダの現在のリストを含むことを特徴
とする、請求項４に記載の装置。
【請求項６】前記第一の処理装置は、サービスプロバイダの前記リストに一つのサービスプ
ロバイダを含むことを特徴とする、請求項５に記載の装置。
【請求項７】前記サービスプールはスタブを含むことを特徴とする、請求項４に記載の装置
。
【請求項８】前記ネーミングサービス及び前記複製されたネーミングサービスは、マルチキ
ャストプログラムによって作成されることを特徴とする、請求項１に記載の装置
。
【請求項９】前記第一の処理装置は、複製ハンドラを有する第一のスタブを含み、および前
記第二の処理装置は、第二の複製ハンドラを有する第二のスタブを含むことを特
徴とする、請求項１に記載の装置。
【請求項１０】通信媒体と；サービスプロバイダにアクセスするためのリモートメソッド呼出し（ＲＭＩ）
スタブを含むネーミングツリーを有する、前記通信媒体に結合された、第一のコ
ンピュータと；複製されたネーミングツリーおよび前記サービスプロバイダを有し、前記通信
媒体に結合された、第二のコンピュータとを具備する、分散処理システム。
【請求項１１】前記第一のコンピュータは、前記第二のコンピュータにおける第二のカーネル
に、メッセージを転送するための第一のカーネルを含むことを特徴とする、請求
項１０に記載の分散処理システム。
【請求項１２】前記第一のカーネルは、リモートジャバ（ＪＡＶＡ登録商標）マシンを含み、
および前記第二のカーネルは、リモートジャバ（ＪＡＶＡ登録商標）マシンを含
むことを特徴とする、請求項１１に記載の分散処理システム。
【請求項１３】前記第一のカーネルは、スレッドマネージャソフトウェアコンポーネントを含
むことを特徴とする、請求項１１に記載の分散処理システム。
【請求項１４】前記第一のカーネルは、ソケットマネージャソフトウェアコンポーネントを含
むことを特徴とする、請求項１１に記載の分散処理システム。
【請求項１５】前記第一のリモートジャバ（ＪＡＶＡ登録商標）仮想マシンは、ピア中断検出
ソフトウェアコンポーネントを含むことを特徴とする、請求項１２に記載の分散
処理システム。
【請求項１６】前記第一のリモートジャバ（ＪＡＶＡ登録商標）仮想マシンは、メッセージ圧
縮ソフトウェアコンポーネントを含むことを特徴とする、請求項１２に記載の分
散処理システム。