JP2005524147A - 分散形アプリケーションサーバおよび分散された機能を実施するための方法 - Google Patents

Abstract

本発明は、２以上のノードのクラスタをピア構成で含む分散形アプリケーションサーバを提供する。２以上のノードは、関連したノードを通って伝播された複数のメッセージを含む少なくとも１つのメッセージ流と関連付けられている。本発明はまた、２以上のノードのクラスタをピア構成に配列し、ノードを少なくとも１つのメッセージ流と関連付けるステップを含んでいる分散形アプリケーションサーバの構成方法を提供する。

Description

本発明は、アプリケーションサーバに関し、とくに、統合されたネットワーク内での使用に適した故障許容性の分散形アプリケーションサーバ、および分散形アプリケーションサーバがサポートする種々の機能を実施する方法に関する。

広い見地から、アプリケーションサーバは、アプリケーションにランタイム環境を提供する情報システムである。

一般的に述べると、アプリケーションサーバによってホストされたアプリケーションは、ある組織体のデータベースサーバおよび、またはバックと、企業アプリケーションと、これらのリソースへのアクセスを所望した任意のエンドユーザまたはクライアントとの間のトランザクションを取り扱う。

図１は、１以上のクライアント110がアプリケーションサーバ130を介して中央計算リソース120にアクセスすることのできる簡単化されたシナリオを示している。クライアントは、たとえば、適切なオペレーティングシステムおよびアプリケーションソフトウェア下で動作しているワークステーションであってもよい。クライアントは、アプリケーションサーバに、たとえば、オブジェクトデータベース120A、関連データベース120B、または外部アプリケーション120C等の、１以上のリソースにアクセスするように要求してもよい。このタイプの構成は、何人かの従業員が彼等のワークステーションからアクセスする必要がある集中リソースを備えた小規模な企業に対して満足できるもの化もしれない。

しかしながら、今日の環境において、とくに、インターネットの人気とその他の多数の無線および通信ネットワークの成長により、アプリケーションサーバを介して伝統的なＷＡＮ、無線ネットワークおよび有線ネットワークによってサービスを消費者に提供する組織体がますます増加している。これらのサービスは、たとえば、インターネットによる、あるいはクライアントの自宅電話から移動電話またはボイスメールアクセスへの通信サービス呼転送サービスでの専用データベースへのアクセスを含むことができる。このようなサービスの消費者がインターネット、無線および有線ネットワークの特徴を統合した新しいサービスに対して高い需要を生んでいる。アプリケーションサーバテクノロジーは、これら消費者の需要に遅れをとらないようにするためにますます複雑になってきている。

アプリケーションサーバに関する大きな問題は、非常に利用し易く、高度にスケーラブルであり、故障許容性があることと、クライアントおよび顧客向けの次世代サービスの迅速な開発を容易にすることである。高度にスケーラブルで故障許容性があり、可搬性で規格化されたものであり、また、統合されたネットワークにおけるサービス提供に適した分散形アプリケーションサーバを有することが有用であろう。

１つの形態の広い見地から、本発明は、ピア構成すなわち同等の構成の２以上のノードのクラスタを含む分散形アプリケーションサーバを含み、２以上のノードは複数のメッセージを含む少なくとも１つのメッセージ流と関連付けられ、その複数のメッセージはその関連付けられたノードを通って伝播される。

別の形態の広い見地から、本発明は、２以上のノードのクラスタをピア構成に配列し、ノードを少なくとも１つのメッセージ流と関連付けるステップを含んでいる分散形アプリケーションサーバを構成する方法を提供する。

以下、添付図面を参照として分散された機能を実施する分散形アプリケーションサーバおよび方法の好ましい形態を説明する。
アプリケーションサーバは、インテリジェントアプライアンスまたは遠隔埋込み型装置用の小さいフットプリントのウェブベースプロセッサから、１つの企業を越えてスケール可能な多層アプリケーションをアセンブルし、配置し、維持する完全な環境に及んでいる。

個々のアプリケーションサーバは、本発明の構築ブロックである。ほとんどの任意の適切なタイプのアプリケーションサーバが本発明の基礎として機能することが可能であると予想される。

図２には、典型的な単一のアプリケーションサーバを簡単に表したものが一例として示されている。このアプリケーションサーバによってクライアントにアクセス可能なリソースは、たとえば、関連データベース210A、インメモリデータベース210B、メッセージ待ち行列210C、またはスイッチ210D等の、１以上のトランザクションおよび非トランザクションリソース210を含んでいてもよい。特定のリソース210はサーバごとに異なっている。

ソフトウェアに関しては、アプリケーションサーバは、プログラマーが彼等のプログラムの中のビジネスロジック（ｂｕｓｉｎｅｓｓ ｌｏｇｉｃ）をプラットホーム関連コードから隔離するのを助ける１組のソフトウェアを含んでいる。アプリケーションサーバは、クライアントサーバアプリケーション中で見出されたアプリケーション論理および接続性の全てを取り扱うことができる。

これが意味するのは、リソース210にアクセスする方法がサーバの１組のソフトウェアにおいて規定され、ＡＰＩすなわちアプリケーションプログラミングインターフェースを介してアクセスされてもよいということである。ＡＰＩは、そのアプリケーションプログラムを書込んだあるプログラマーがオペレーティングシステムまたはその他のシステムリソースのリクエストを形成することのできる特定の予め規定された方法に対するインターフェースを規定する。このＡＰＩを使用することにより、プログラマーは、リソース210を含むデータベースまたはその他の継承システムのプラットホームまたは構造のどのような特性でも無視できることが多く、それは、これらの特性を処理する機能がサーバソウトウェアによって提供されるためである。

典型的に、アプリケーションサーバによってホストされたアプリケーションは、コンポーネントベースのものである。コンポーネントは、ある機能または１組の機能をカプセル化するソフトウェアオブジェクトであり、別のコンポーネントと対話するように設計されている。コンポーネントは、明確に定義されたインターフェースを有し、あるアーキテクチャ内の全てのコンポーネントに共通した規定された作用に従う。多数のコンポーネントを集めて、別のコンポーネントを形成することができる。大型ソフトウェアシステムは、既存のソフトウェアコンポーネントを統合することによって構築されることができる。したがつて、コンポーネントベースのアプリケーションは、あるアーキテクチャ内の全てのコンポーネントに共通する規定された機能に従う１以上のコンポーネントからなるソフトウェアである。

典型的に、ＡＰＩは、このようなコンポーネントベースの機能を構築する開発者用のインターフェースを規定する。したがって、典型的にアプリケーションコンポーネントが上述されたようにシステムリソース210にアクセスする。それ故、高い抽象化レベルにおいて、アプリケーションサーバは、それが実施する１組の機能に関して、サーバがホストするアプリケーションの実行をサポートすると考えられてもよい。

アプリケーションサーバ上において、通常ＡＰＩを介して提供される非常に重要な機能は、トランザクションに対するサポートである。あるトランザクションは、データベース管理システムまたは類似したリソースとの相互関係の単位である。それは、別のトランザクションとは無関係に一致して高い信頼性により扱われなければならない。あるトランザクションは、全体として成功または失敗しなければならない作業の最小単位にグループ化される１以上のソフトウェア問合せまたは命令から構成されている。トランザクションを管理しているとき、あるアプリケーションによりリクエストされたあるトランザクションによって更新された全てのリソースが常に一致した状態のままにされていることを確実にすることが重要である。とくに、あるユーザにより行われたあるトランザクション内の全ての変更は、同時に実行している別のユーザにより行われた変更から隔離されなければならない。

多くのアプリケーションコンポーネントおよびシステムリソース210がトランザクションに関係している可能性があるため、トランザクションが発生したときにその状態を設定し、維持することが重要である。この情報は通常トランザクションコンテキスト中に保存されている。トランザクションコンテキストは、リソース上のトランザクション動作または機能とその動作を呼出したコンポーネントとの間の関連である。

あるトランザクションコンテキスト内で実行することのできるコンポーネントベースのアプリケーションにとくに効果的なランタイム環境を提供するアプリケーションサーバのいくつかの例には、サーブレットエンジン、Ｊ２ＥＥサーバ、およびＪＡＩＮ ＳＬＥＥサーバが含まれる。

１実施形態において、本発明のアプリケーションサーバは、ＪＡＩＮ ＳＬＥＥ（サービス論理実行環境）ＡＰＩ仕様に従うＡＰＩからの機能に影響を与える。この仕様は、ベンダー装置および種々のタイプのネットワークに対して可搬性であり、標準化され、それによって多くの開発者は専門知識をそれ程必要とせずに所定の専用装置セットを使用するサーバを構築することが可能となる。ＪＡＩＮ ＳＬＥＥ ＡＰＩはとくに統合されたネットワークに適しており、また、とくに通信ネットワークサービスに適している。

ＪＡＩＮ ＳＬＥＥ仕様は本発明に好ましいが、任意のＡＰＩ仕様、とくに、異なったタイプのネットワークへのインターフェースを提供するものは種々のプロトコルへの簡単化されたアクセスを可能にし、ベンダー装置に対して可搬性であり、本発明のＡＰＩに対する適切な基礎となる。同様に、ＪＡＶＡプログラミング言語は本発明の開発に対して好ましい言語であるが、同じレベルの移植可能性を提供する任意のプログラミング言語が等しく適切である。

本発明のアプリケーションサーバ230は、故障許容性でなければならないことも想定される。故障許容性とは、サーバ上のある場所で故障が発生した場合でもそのサーバがクライアントリクエストを処理し続けることができるということである。故障許容性は、クラスタ化として知られているものにより達成されることが多い。

クラスタは本質的に、各インスタンスが別々にアドレス指定可能である１以上のアプリケーションサーバインスタンス（図２に示されている）のグループである。各インスタンスはノードと呼ばれ、１以上のプロセスとして具体化されてもよい。あるアプリケーションサーバクラスタは、あるネットワーク上の１以上の計算リソースまたはマシン上に配置されてもよい。

サーバノードは典型的にバックボーンによって接続され、分散形アプリケーションサーバを生成する。クラスタのノードはこのバックボーンを介してメッセージを互いに送ることによって通信する。１つのノード上に存在する状態および機能情報は、そのクラスタの中の残っているノードの少なくとも１つにおいて複製される。この冗長性により、クライアントはアプリケーションサーバシステムの故障から保護される。アプリケーションサーバリソースはクラスタのノードを横切って分配されているので、１つのノードが故障した場合、理論上、別のノードがクライアントリクエストの処理を引き継いで終了することができる。これは、フェイルオーバー（ｆａｉｌｏｖｅｒ）として知られている。

しかしながら、現在のクラスタ化されたアプリケーションサーバは典型的に、クラスタ中の１つのノードがそのクラスタ上で連係（ｃｏｏｒｄｉｎａｔｉｎｇ）作業を担うマスター／スレーブ構成を有している。あるマスター／スレーブ構成においては、マスターノードが故障した場合、フェイルオーバーを行うことははるかに困難である。同じことは、いくつかのノードが、その構成内の別のノードが有しない特別の機能または特定のリソースへのアクセスを有しているクラスタ構成にも該当する。このシナリオでは、重大な機能を有するノードが故障した場合、フェイルオーバーは事実上不可能である。

比較すると、本発明のクラスタ構成はマスター／スレーブ構成ではなく、ピア構成である。図３には、本発明による好ましいクラスタのピア構成が示されている。クラスタは、310、320、330および40でそれぞれ示された２以上のアプリケーションサーバノードを含んでいる。各ノードは、構造が図２のアプリケーションサーバに類似していることが好ましい。

本発明のピア構成において、各ノードは他のあらゆるノードと同じ機能セットを提供することができ、特別な役割を有するノードは存在しない。このようにして、ノードがクラスタ上で機能している限り、どのような単一の故障地点でも除去され、フェイルオーバーが保証されることができる。

本発明のクラスタサーバノードは、１以上のメッセージ流、たとえば、350によって対話する。好ましい形態のメッセージ流は、このネットワーク中のノードによって発生され、それらを通って伝播されたメッセージを含んでいる。あるノードはメッセージをメッセージ流から受取り、また、メッセージ流の中にメッセージを置くことができる。特定の流れと関連付けられているノードは、その流れのメンバーであると言われる。

メッセージ流上のあるメッセージは一般に、発生した重要な出来事（事象）に関係している。ある事象は通常、アプリケーションサーバによって完了されなければならないタスクを示している。

サーバのアクティビティは、事象によってドライブされる。あるアクティビティは一般に、事象のある関連した流れから構成されている。たとえば、通信アプリケーションサーバ上では、ボイスメールにアクセスするためにあるアクティビティが呼出されてもよい。ボイスメールシステムへのユーザアクセスを可能にするプロセスは非常に多くの事象を伴ない、これら事象は全て、その特定のセッションにおけるその特定のユーザのボイスメールアクセスのアクティビティに関連している。

分散形サーバ上において、受取られた全ての事象は、処理のために経路指定されなければならない。典型的に、本発明のアプリケーションサーバ内の全てのノードのサブセットだけが特定の事象の処理を担当させられる。クラスタ内のサーバノードのこのサブセットは、それ自身のメッセージ流によって対話する。

図４は、ノード１、ノード２、ノード３、ノード４およびノード５の５個のノードから構成されたクラスタ400を示している。図４に示されているアプリケーションサーバにおいて、１つのメッセージ流410は全てのノード１乃至５と関連付けられている。クラスタはさらに、ノードのサブセットだけが関連付けられている４つのメッセージ流、すなわち、符号420、430、440および450でそれぞれ示されているメッセージ流Ａ、メッセージ流Ｂ、メッセージ流Ｃおよびメッセージ流Ｄを含んでいる。

ノード１および２は共にメッセージ流Ａのメンバーであり、これと関連付けられている。ノード１、４および５は全てメッセージ流Ｂのメンバーである。ノード２、３および４はメッセージ流Ｃのメンバーであり、一方ノード３および５はメッセージ流Ｄのメンバーである。

典型的に、特定のアクティビティに関連した全ての事象メッセージが同じメッセージ流で送られ、したがってそのサーバクラスタ上の同じノードのサブセットによって処理される。それ故、特定のメッセージ流と関連付けられ、したがってその特定のアクティビティを処理している全てのノードに対してアクティビティコンテキストが伝播される。

本発明のアプリケーションサーバにおいて、各メッセージ流上のメッセージは常にそのメッセージ流上の各ノードに特定の“順序”で配信される。メッセージ流のメンバーである各ノードは、ノードの１つが故障していない限り、あらゆる事象をその同じ順序で受取る。これは、たとえば、図４中のノード１がメッセージ１、メッセージ２およびメッセージ３をメッセージ流Ａ上におけるその順序で受取った場合に、ノード２はメッセージ１を受取り、続いてメッセージ２を受取り、その後メッセージ３を受取ることを意味する。メッセージ流Ａと関連した任意の他のノードが存在しているならば、それらもまたメッセージ１、メッセージ２およびメッセージ３をその順序で受取る。あるメッセージ流のメンバーである全てのノードによる同じ順序でのメッセージのこの保証された配信を、順序付けられたメッセージ配信と呼ぶことができる。

本発明のアプリケーションサーバにおいて、ストリームメンバーシップ変更メッセージと呼ばれる特別なタイプのメッセージが存在する。このメッセージは、その他任意のメッセージと同様に、そのメッセージ流と関連付けられたあらゆるノードによりメッセージ順序の一部として受取られる。メンバーシップ変更メッセージの内容は、あるメッセージ流と関連したノードはいずれの新しいメンバーノード、およびもはやそのメッセージ流のメンバーではないいずれのノードについて知っていることが可能であるというものである。

本発明のアプリケーションサーバにおいて、クラスタおよび分散形アプリケーションサーバ内の各ノードは、クラスタメンバーシップメッセージ流410と呼ばれる特別なメッセージ流のメンバーであることが好ましい。したがって、特定メッセージ流のメンバーシップは、特別なクラスタメンバーシップメッセージ流のメンバーシップのサブセットである。

別のメッセージ流の任意のもののメンバーシップの変更は、特別なクラスタメンバーシップメッセージ流410のメンバーシップの変更によってドライブされる。したがって、新しいノードがクラスタに追加され、それ故クラスタメンバーシップメッセージ流410のメンバーになる場合、新しいクラスタノードはまた、別のメッセージ流の１以上のものに割当てられたメンバーシップである可能性がある。同様に、クラスタ上のあるノードが故障しているか、あるいはそのクラスタから除去された場合、そのノードはそれ故、もはやそのクラスタのメンバーシップメッセージ流のメンバーではない。この場合、このノードが関連付けられていたその他全てのメッセージ流におけるそのノードのメンバーシップもまた終了する。

単一のノードはクラスタメンバーシップ流310に付加される他の２以上のメッセージ流のメンバーであってもよいが、どのようなノードの故障でも、そのノードがメンバーであるこれらのメッセージ流（クラスタメンバーシップ流以外の）だけに影響を与える。別の流れ（クラスタメンバーシップ流以外の）は、影響を受けない。クラスタ中における、したがってメッセージ流中における全てのメンバーは同等なもの（ｐｅｅｒ）なので、ノードとメッセージ流との関連付けおよびメッセージ流からのノードの削除を動的に行うことは比較的簡単である。

上述された構成により、本発明の分散形アプリケーションサーバは、メッセージ流の中のメッセージの完全性を保存しながら、構成中のメンバーの故障を検出すると共に動的に再構成されることができる。

図５は、本発明による上述されたアプリケーションサーバノード上のローカル機能510とアプリケーションサーバ上の分散された機能520とメッセージ流530、540、550および560との間の関係を示している。

各ノード、たとえば、ノード570は、アプリケーションサーバクラスタ中のあらゆる他のノードと同じであり、同じ機能セットを提供することが好ましく、あるノード上で利用可能な機能は典型的に１以上のソフトウェアコンポーネントから構成されている。たとえば、アプリケーションサーバ中の各ノードは同じローカル機能セットを含んでいることができる。

ローカル機能510は、任意の他のノードと協力することなしにクラスタノードの単一のものの上で開始され、終了されることのできる機能である。

本発明のアプリケーションサーバにおいて、ローカル機能は、決定性アルゴリズムを使用して実施されることが好ましい。それは、そのアルゴリズムによってなされたどの決定においてもランダム化（ｒａｎｄｏｍｉｚａｔｉｏｎ）は使用されないアルゴリズムである。決定性アルゴリズムは、それらが同じ入力によりアルゴリズムが常に同じ結果を生じることを保証するため、本発明に対してとくに好ましい。ある機能を特定の入力に基づいて行うあらゆるノードは、同じ機能を同じ入力に基づいて行う他のあらゆるノードと同じ出力を生成することが重要である。

分散された機能520は、所望の結果を生成するためにメッセージ流の少なくとも１つのものにおけるノードの間の協力を必要とする機能である。

図６に示されているように、分散された機能600は通常、２つの部分から構成されている。第１の部分は、少なくとも１つのサーバノード上で実施される少なくとも１つのローカル機能610であり、これは、たとえば、620、630および640等の１以上の順序付けられたメッセージ流上の事象メッセージと関連しており、これによってドライブされる。分散された機能の第２の部分は、事象が受取られ、送信されることのできる１以上のメッセージ流との１組の関連650である。

メッセージ流で受取られた事象は、ローカル機能への入力を構成する。同じ分散された機能をサポートする全てのノードは、必要とされる同じメッセージ流のメンバーである。したがって、各ノード上のローカル（決定性）機能は、調整のための付加的なメッセージ交換なしで同じアクションを同じ順序で行う。

調整のための付加的なメッセージ交換は必要とされないので、ローカル機能の決定性アルゴリズムは実質的にノード相互関係メカニズムから分離される。このようにして、分散された機能（ローカル機能）の実際の実施は、メッセージ流上のノードの間の相互関係から完全に分離されることができる。

上述したように、メンバーシップ変更メッセージは、あるメッセージ流のメンバーである全てのノードに対してそのメッセージ順序の一部として配信される。メンバーシップ変更メッセージの内容は、分散された機能（ローカル機能）の実施をすることにより、メンバーシップが変更したときに付加的なメッセージ交換を必要とせずにそのメッセージ流のメンバーである全てのノード間で一致したアクションがとられる、というものである。

本発明の分散形アプリケーションサーバの分散された機能の一例は、事象処理のためのノードの選択である。サーバ上の受取られた全ての事象は処理のために経路指定されなければならない。事象は、サーバクラスタ上の作業負荷のバランスが実効的に取られるようにして経路指定される必要がある。

負荷平衡は、応答時間および、またはスループットを改善するために作業負荷が２以上のサーバノードに対して分配される予め規定された手順を一般に示す用語である。実効負荷平衡は、分散形サーバのスケーラビリティの改善に対して重要である。

図７は、本発明の分散形サーバ内において事象を経路指定することに関与する構成要素のいくつかを、図４の例示的なクラスタからの２つのノード（ノード１および５）の視点から示している。

ノードが事象を受取ったとき、その事象を取り扱うためにあるメッセージ流が選択されなければならない。その後、この事象は選択されたメッセージ流に委任され、処理される。

たとえば、ノード１がある事象を受取った場合、ローカル事象プロセッサ機能はその事象をどこに経路指定すべきかを決定するが、しかしそれらは、メッセージ流関連への参照なしにこれを行うことはできない。

たとえば、ノード１がある事象を受取った場合、このノード１上のローカル事象プロセッサ機能は、メッセージ流関連を参照する。これは、ノード１がメッセージ流ＡおよびＢのメンバーであることを明らかにし、それはまた、他のどのノードがそのメッセージ流のメンバーであるかに関する情報を提供する。さらに、各ノードは、それがメンバーである各メッセージ流に対する負荷のローカル推定値を維持する。この推定値は、これまで受取られて処理された事象の履歴から得られる。

したがって、関連データにより、事象処理および負荷平衡に対するルールを定めるローカル事象プロセッサ機能は、その事象が経路指定されるべきメッセージ流を決定することが可能になる。たとえば、ローカル事象プロセッサ機能は、難しい負荷平衡を実施することができる。その後、事象メッセージは選択されたメッセージ流のメンバーに送信される。このようにして、分散された事象経路指定および負荷平衡機能が行われる。

本発明の分散形アプリケーションサーバ上で実施される分散された機能の別の例は、コンポーネント状態（ホストされたアプリケーションコンポーネントの状態）の複製（ｒｅｐｌｉｃａｔｉｏｎ）、事象処理成功／失敗の調整、フィードバックベースの事象レート制限、およびこのアプリケーションサーバ内の全てのノードにわたる管理動作の調整である。

上記は、好ましい形態を含む本発明を説明したものである。当業者に明らかになるであろう変更および修正は、添付された請求の範囲によって規定された本発明の技術的範囲内に含まれるものである。

従来技術のアプリケーションサーバの簡単な例を示す概略図。 単一のアプリケーションサーバに対する好ましいアーキテクチャを示す概略図。 本発明によるピア構成のクラスタベースの分散形アプリケーションサーバの概略図。 ノードが１以上のメッセージ流と関連付けられた本発明によるクラスタベースの分散形アプリケーションサーバの概略図。 本発明によるアプリケーションサーバノード上のローカル機能と分散された機能とメッセージ流との間の関係を示す概略図。 本発明において実施されたときの分散された機能の構成を示す概略図。 図４の分散形サーバ内における事象の経路指定に含まれるいくつかの構成要素を示す概略図。

Claims (13)

1. ピア構成の２以上のノードのクラスタを含んでおり、その２以上のノードは複数のメッセージを含む少なくとも１つのメッセージ流と関連付けられ、その複数のメッセージは関連付けられたノードを通って伝播される分散形アプリケーションサーバ。
2. アプリケーションサーバ内の各ノードは、クラスタメンバーシップメッセージ流と関連付けられている請求項１記載の分散形アプリケーションサーバ。
3. 特定のメッセージ流上のメッセージは、そのメッセージ流と関連付けられた各ノードに定められた順序で配信される請求項１または２記載の分散形アプリケーションサーバ。
4. ノードがアプリケーションサーバに動的に追加されることを可能にするように構成されている請求項１乃至３のいずれか１項記載の分散形アプリケーションサーバ。
5. ノードがアプリケーションサーバから動的に除去されることを可能にするように構成されている請求項１乃至４のいずれか１項記載の分散形アプリケーションサーバ。
6. メッセージ流メンバーシップの変更を示すメッセージは、メッセージ順序の一部として配信される請求項３乃至５のいずれか１項記載の分散形アプリケーションサーバ。
7. アプリケーションサーバ内のノードは、あるローカル機能のセットを含んでいる請求項１乃至６のいずれか１項記載の分散形アプリケーションサーバ。
8. アプリケーションサーバ内の各ノードは、同じローカル機能のセットを含んでいる請求項７記載の分散形アプリケーションサーバ。
9. さらに、１以上のローカル決定性機能として実施される分散された機能と、関連したメッセージ流のセットとを含んでいる請求項７または８記載の分散形アプリケーションサーバ。
10. 決定性ローカル機能は実質的に、メッセージ流上のノード間の相互作用から隔離されている請求項９記載の分散形アプリケーションサーバ。
11. ２以上のノードのクラスタをピア構成に配置し、
    ノードを少なくとも１つのメッセージ流と関連付けるステップを含んでいる分散形アプリケーションサーバを構成する方法。
12. メッセージを特定のメッセージ流で、そのメッセージ流と関連付けられた各ノードに定められた順序で配信するステップをさらに含んでいる請求項１１記載の分散形アプリケーションサーバを構成する方法。
13. メッセージ流メンバーシップの変更を示すメッセージを、そのメッセージ順序の一部として配信するステップをさらに含んでいる請求項１２記載の分散形アプリケーションサーバを構成する方法。

Images