JP2004517424A - サーバーアーキテクチャー - Google Patents

Abstract

本発明は、サーバーの構造に係る。本発明は、多数の異なるサービスを同時に取り扱うことのできる少なくとも１つのスレッドを含むサーバーアーキテクチャーを備えている。スレッドは、タスクマネージャーを使用して、処理されるべき次のサービスをスケジュールする。オペレーティングシステムは、スレッド（１つ又は複数）の実行を取り扱う。指定リストは、スレッドに指定される全てのサービスを含む。

Description

【０００１】
【技術分野】
本発明は、サーバーに係る。より詳細には、本発明は、サーバーがいかに構成されるか及びサーバーがサービスをいかに実行するかといったサーバーの構造に係る。更に、本発明は、特に、テレコミュニケーションの分野におけるサーバーに係る。
【０００２】
【背景技術】
図１は、クライアント−サーバー環境の一例を示す。サーバー（１）は、多数のサービス（２）を含む。クライアント（３）は、サーバーにおける特定のサービスを呼び出す。クライアントとサーバーとの間のインターフェイスは、例えばＣＯＢＲＡをベースとする。サービスは、クライアントにより変化するある状態にある。サービスが希望のタスクを実行すると、クライアントに応答を返送する。これは、サーバーが現在クライアントからの要求を取り扱う方法である。
【０００３】
サーバーは、多数の方法で構成することができる。それらは全て欠点と利点がある。１つの考えられる方法は、オブジェクト指向のプログラミング言語であるＪａｖａを使用して、サーバーのファンクションを生成することである。Ｊａｖａの利点及び欠点と、本発明とについて述べた本明細書を読むときには、基本的なＪａｖａ構造を銘記しなければならない。
【０００４】
オブジェクトとは、実行可能なコード及びデータを通常含むソフトウェアコンポーネントである。オブジェクト指向の言語では、実際のオブジェクトが定義されず、オブジェクトのクラスが定義される。クラスとは、同様の特徴を伴う多数のオブジェクトのためのテンプレートである。クラスは、そのクラスの全オブジェクトに対する全ての共通の特徴を記述すると言える。従って、単一のオブジェクトは、クラスを具体的に表わすもので、換言すれば、インスタンスである。
【０００５】
メソッドとは、クラス又はオブジェクトにおいて動作するファンクション即ち実行可能なコードである。ストリームとは、ある情報のソースとその行先との間の通信経路である。Ｊａｖａは、異なるストリームを定義するための多数の入力ストリーム及び出力ストリームクラスを含む。シリアル化は、クラスのインスタンスの状態（クラスの具体的表示）をバイトラインの形態でセーブできるようにするＪａｖａ環境の特徴である。シリアル化されたインスタンスは、そのセーブされたクラス表示を後で使用できるようにデシリアル化することができる。
【０００６】
スレッドとは、スレッド−クラスのオブジェクトである。スレッドは、アプリケーションが多数のタスクを同時に実行する場合に使用されるのが好ましい。スレッドは、それに与えられたタスクを実行する。タスクは、オペレーティングシステムが実行するコマンドを含む。パラレルなスレッドが同時に実行され、即ちアプリケーションは、単一のコマンドが終了するのを待機してから次のコマンドを開始するのではなく、パラレルなコマンドを個々に実行することができる。従って、同時に実行されるべきアプリケーション及び／又はタスクが多数存在する場合には、スレッド−モデリングを使用するのが有用である。
【０００７】
要約すれば、Ｊａｖａアプリケーションは、オブジェクトと称するクラスを含む。１つのクラスは、「ルート」クラスで、これは、アプリケーションの基本的なメソッドを含み、そしてアプリケーションに属する他のクラスを得ることができる。
クライアントは、クライアントから到来する事象をリストしたスレッドを有するサーバーへ事象を送信する。これらのスレッドは、事象を受け取ると、実際の事象処理を行う処理スレッドへそれを通す。各事象は、それ自身の新たな処理スレッドを要求する。２つの形式のスレッドの協働が同期される。しかしながら、この同期は、常に、経費がかかり、設計が厄介である。
本発明の目的は、これら欠点を解消し、従来の解決策より優れたシステム性能を与えることである。これは、請求の範囲に記載したように達成される。
【０００８】
【発明の開示】
本発明の考え方は、サーバーアーキテクチャーが、多数の異なるサービスを同時に取り扱いできる少なくとも１つのスレッドを含むことである。このスレッドは、タスクマネージャーを使用して、処理されるべき次のサービスをスケジュールする。オペレーティングシステムは、スレッド（１つ又は複数）の実行を取り扱う。指定リストは、そのスレッドに指定された全てのサービスを含む。サービス環境は、サービス及びオブジェクト特有データを保持しそしてコンテナの動作を制御するための実際のサービスインスタンス及びエレメントを形成するオブジェクトを収容するコンテナクラスを備えている。更に、サービス環境は、コンテナの状態及びサブ状態の情報と、処理されるべき種々の形式の事象に対する待ち行列も備えている。これら待ち行列は、クライアントから到来する事象を、それらが実際に処理されるまで保持することができる。
【０００９】
サービス環境は、待ち行列の状態を観察する。タスクマネージャーは、指定リストにおいてサービス環境に、処理されるべき事象があるかどうか尋ねる。もしあれば、マネージャーは、事象を、それらが処理されようとしている順序で引き出す。スレッドは、オペレーティングシステムにおいて実行するために、マネージャーからその順序で事象を引き出す。スレッドは、指定リストにおける正しいサービスに対して事象をファイアし、実行を開始する。実行後に、サービス環境の状態が変更される。
【００１０】
【発明を実施するための最良の形態】
以下、図１ないし５を参照して本発明を詳細に説明する。
図３は、パラレルなサービスを取り扱うための本発明によるサーバーアーキテクチャーの一例を示す図である。実行されるべき同時プロセスを構成するときにはスレッドが非常に重要となる。通常、スレッドは、１つのサービスの実行を取り扱う。従って、例えば、１０個のパラレルなサービスがある場合には、１０個のパラレルなスレッドが存在する。しかしながら、サービスは、互いに独立して実行され、従って、オペレーティングシステムの観点では、アイドルスレッドとビジースレッドが存在する。アイドルスレッドは、オペレーティングシステムのリソースを消費する。本発明による図３のような構成体を使用すると、１つのスレッド（３１）が多数のサービスを同時に取り扱うことができ、オペレーティングシステムのリソースを節約する。本発明によるサーバーアーキテクチャーは、多数のサービスを各々取り扱う多数のパラレルなスレッドを含むことができる。従って、１つのスレッドは、１つないし多数のサービス（又はサービスのサービスインスタンス）を含むことができる。
【００１１】
サーバーアーキテクチャーは、サービスを実行するスケジューリングを取り扱うためにタスクマネージャー（３２）を必要とする。スレッド（３１）に指定されるサービス（３３ａ、３３ｂ、３３ｃ）は、指定リスト（３４）を形成する。タスクマネージャーは、このリストを使用して、リスト内のサービスから事象を引き出し、そしてスレッドに対して事象をスケジューリングし、スレッドは、タスクマネージャーから事象を引き出して実行する。スレッドは、サービスにおいて事象の実行をファイアする。
【００１２】
サービス環境、即ちプログラム環境は、サービス（４２）（プログラム）及びそのインスタンス（プログラムインスタンス）を受け入れて、サービスアーキテクチャーにおける動作時に実行することのできるコンテナ（図４の４１）（クラス）である。プログラム環境は、図４に示す要素を含む。
サービス環境は、クライアントから到来するメッセージ即ち事象を記憶するための１つないし多数の待ち行列（４７）を含む。各事象は、現在のサービスインスタンスが処理するタスクを表わす。
【００１３】
コンテナは、制御部分（４５）及びインスタンスコンテクスト（４４）を含む共通部分を備えている。更に、コンテナは、実際のサービスを形成する１組のオブジェクト（４３）も備えている。制御部分は、受け取った事象に基づいてオブジェクト（４３）を実行する。インスタンスコンテクストは、サービスインスタンスに対して特有のデータを記憶する。
サービス環境は、コンテナの状態及びサブ状態の情報（４６）と、処理されるべき種々の形式の事象に対する待ち行列（４７）とを備えている。事象は、３つの形式、即ち要求事象、ＩＳＣ事象及び非同期事象に分類される。ＩＳＣ（サービス間通信）とは、事象が別のサービスから送信され、そしてそれを同期又は非同期で送信できることを意味する。
【００１４】
同期メッセージ（事象）とは、サービスがそれを待機し、即ちサービス事象の処理が待機状態にあり、そしてサービスが特殊な（同期）メッセージを得たときに処理を継続するところのメッセージである。
非同期メッセージとは、サービスがそれを待機しないメッセージである。しかしながら、サービスは、同期メッセージを待機しなければならず、その時間中に、予期せぬメッセージ、即ち非同期メッセージ、又は同期メッセージを受け取ることがある。
【００１５】
信号メッセージは、非同期メッセージの特殊なケースである。信号ハンドラーが信号メッセージを取り扱うと同時に、別のハンドラーが同期又は非同期メッセージを取り扱うことができる。要求形式は、サービスの内部から到来する同期事象を取り扱う。しかしながら、もし必要であれば、他の形式及び別の数の形式を使用することもできる。待ち行列は、クライアントから到来する事象を、それらが実際に処理されるまで保持することができる。事象をどれほど長く保持できるかの周期は、サービス自体に依存する。サービス環境は、待ち行列の状態を登録する。
【００１６】
通信システムのサービスプラットホームにおけるサービスについて考える。１つのサービスは、サービス環境に埋め込まれるプログラムとして実施することができる。換言すれば、サービスは、そのプログラムコードがコンテナ内のオブジェクトとして実施されるようにして実施される。従って、サービスアーキテクチャー内で実行される上記プログラムの特定インスタンスは、サービス環境インスタンスである。
コンテナは、制御部分（４５）及びインスタンスコンテクスト（４４）を含む共通部分を備えている。更に、コンテナは、実際のサービスを形成する１組のオブジェクト（４３）も備えている。制御部分は、受け取った事象に基づいてオブジェクト（４３）を実行する。インスタンスコンテクストは、サービスインスタンスに対して特有のデータを記憶する。
【００１７】
サービス環境は、例えば、スレッド内でパラレルに実行できる種類のプログラムロードモジュールとして定義することができる。次いで、スレッドは、Ｊａｖａ仮想マシンのような実行環境内でパラレルに実行することができる。それ故、３つのレベル、即ちオペレーティングシステムレベル、仮想マシンレベル及びスレッドレベルに、パラレルなプロセスエンティティが存在する。
サービスアーキテクチャーは、オブジェクト指向のモデルをベースとするので、クライアントもオブジェクトとしてモデリングされる。クライアントは、要求又はメッセージをサービスに送信し、サービスも、クライアントに望まれるタスクを含むオブジェクトである。要求／メッセージオブジェクトは、事象と称される（事象は、別の形式のオブジェクトも意味し得ることに注意されたい）。
【００１８】
図３に示す状態のように、３つのサービスが指定された１つのスレッドを有するようにサービスアーキテクチャーが構成された一例を説明する。２つのサービス３３ａ及び３３ｂは、アイドル状態であるが、第３のサービス３３ｃが、クライアントからの事象を有する。事象は、当該待ち行列において待機している。サービス環境は、待ち行列及びサービスの状態を登録している。１つ又は多数のサービスが内部事象を実行する準備ができた場合には、サービス環境は、何らかの事象待機がある場合に要求待ち行列からサービスに対する事象を引き出す。
【００１９】
タスクマネージャーは、事象を引き出すために指定リストを検査する。サービスの状態をチェックするためにマネージャーが使用するサイクルに基づき、マネージャーは、３３ａからスタートする。サービス３３ａは、アイドル状態であり、従って、実行のための事象をもたない。又、マネージャーが次に検査するサービス３３ｂも、アイドル状態である。マネージャーは、サービス３３ｃの状態を検査するときに実行に対して引き出されるべき事象を見出す。マネージャーは、事象を引き出す。
【００２０】
通常、タスクマネージャー（３２）において実行のためにスケジュールされるべき多数の事象が存在するが、この例では、マネージャーが最初に実行するためにスケジュールすることのできる事象は、１つだけである。処理されるべき事象と共に指定リストに多数のサービスが存在する場合には、タスクマネージャーは、ラウンドロビン形態でサービスを通して進み、そして事象のプライオリティに基づく特定の順序で事象を処理する。サービス環境において、非同期事象は、事象のプライオリティの順序とされる。同期メッセージは、到来する順序に基づく順序とされる。（タスクマネージャーは、他の技術的解決策が使用される場合には他のスケジューリング方法も使用できることに注意されたい。）スレッドは、マネージャーから事象を引き出し（３１）、そしてサービス（３３ｃ）において事象の実行をファイアする。ファイアするとは、同じスレッドが事象を送信（及び受信）してそれを実行できることを意味する。事象を実行すると、サービス環境（４６）を検査するときにタスクマネージャーが通知できるそのサービス環境の状態が変化する。
【００２１】
図２は、本発明によるクライアント−サーバー環境の一例を示す。クライアントは、サーバー１に事象を送信する。この事象は、正しいサービス環境（Ｓ１）に向けられる。事象は、待ち行列に入れることができ、即ちサービスがタスクマネージャーにとってアイドル状態に見えるので、スレッドがそれをファイアする前に、サービス環境（Ｓ１）は、あるタスクに対して他のサービス環境を使用でき、その後、事象は、最終的な実行のためにスレッドに返送される。このため、サービスは、他のサービスを使用して最終的なサービスを生成するように構成することができる。サービス環境は、同じサーバー（５）又は別のサーバー（６）において別のサービス環境（５）を求めることができる。又、サービス環境のチェーンを形成して、最終的なサービスを生成することもできる。図２に示された状態では、ルートサービス環境Ｓ１（４）が、別のサーバー（６）における別のサービス環境Ｓ４（７）に、あるタスク（１つ又は複数）を行うように求め、そしてサーバー環境Ｓ４は、次いで、更に別のサーバー環境Ｓ５（８）に、あるタスク（１つ又は複数）を行うように求める。上記チェーンは、サービス環境Ｓ５がサービス環境Ｓ４に応答してタスク（１つ又は複数）をファイアするときに後方にディスチャージし、サービス環境Ｓ４は、次いで、サービス環境Ｓ１に応答してタスク（１つ又は複数）をファイアし、そこで、最終的に、事象は、クライアントにより望まれるサービスをファイアすることをスレッドに返送する。サービスは、クライアントに応答を与える。
【００２２】
本発明によるサーバーアーキテクチャーは、サービスを実行する方法を含む。図５は、好ましい方法の一例を示す。第１に（６１）、このサービス及びその事象を取り扱うサービス環境においてクライアントからの事象を待ち行列から引き出さねばならない。上述したように、サービス環境は、実際のサービスと、クライアントにより押し込まれた事象に対する少なくとも１つの待ち行列と、サービス及び待ち行列の状態情報とを含む。
【００２３】
サービス環境は、待ち行列に事象を保持するか、又はそれをタスクマネージャーにより引き出すことができる（６２）。その選択は、サービス及び待ち行列の状態情報に依存する。例えば、サービスは、他の事柄を実行していてビジーであるか、或いは待ち行列の１つが、最初に実行されるべき別の事象を有する。
タスクマネージャーは、事象を引き出すと、その事象を、他のサービス環境から引き出された他の事象と共に、それら事象が引き出された順序でスケジューリングする（６３）。これらのサービス環境は、指定サービス環境特有のサービスの処理を取り扱うスレッドに指定されている。スケジュールされた事象は、サービスの性能の順序である。
【００２４】
スレッドは、事象を処理するためにタスクマネージャーから事象を順に引き出す（６４）。スレッドは、サービスを遂行するためにサービス環境においてサービスに対し事象をファイアする（６５）。ファイアするとは、スレッドではなくサービスにおいて実際の処理が生じることを意味する。スレッドは、それに指定されたサービスのサービスクラスを含み、そしてそれらクラスを使用して事象を遂行する。或いは又、スレッドは、サービスに事象をポスティングできることにも注意されたい。ポスティングとは、種々のスレッドがサービスの実行及び送信（ポスティング）を取り扱うことを意味する。サービスアーキテクチャーは、上述した以外のやり方でも構成できることに注意されたい。例えば、引き出し動作は、事象をサービス環境からタスクマネージャーへそしてタスクマネージャーからスレッドへ押し込むような押し込み技術を使用して生成することができる。しかしながら、ここに述べるように引き出し技術を使用することが好ましい。更に、本発明のアーキテクチャーにおける引き出し順序は、例えば、最初に、スレッドがタスクマネージャーから事象を引き出し、そしてその後、タスクマネージャーがサービス環境から事象（１つ又は複数）を引き出す（タスクマネージャーは事象を独立して引き出さない）というものであることに注意されたい。
【００２５】
本発明の他の実施形態では、例えば、事象待ち行列が必ずしも所与のサービス環境インスタンスに関連して記憶されず、どこに記憶されてもよいが、到来する事象が通知されたときにプログラムインスタンスによって事象を検索できるようにされる。同様に、コンテナ部分は、必ずしも個別のオブジェクトで構成されない１つのコードモジュールで構成することができる。同様に、プログラムのコード部分は、共通の制御部分と、サービス特有の部分とに明確に分離されない。
【００２６】
本発明は、オペレーティングシステムのリソースをより効率的に使用して、膨大な量のサービスを同時に実行できるようにする。各サービスに対し、スレッドがサービス自体に対してのみ実行されるように見える。本発明によるサービスアーキテクチャーは、非同期で実行され、これは、クライアント要求の確認とクライアントへの応答との間の周期が、バッファ動作により、如何にでもなり得ることを意味する。同期を回避することは、コストの節約を意味する。又、本発明は、いわゆるホットサービスも可能にする。これは、サービスの状態がクライアントによって変更されず、サービス自体が状態を変更し得ることを意味する。あるサービスは、他のサービスに対するクライアントとなり得ることに特に注意されたい。
以上、本発明の幾つかの例を説明したが、本発明は、これに限定されるものではなく、本発明の考え方の範囲内で他の解決策にも使用できることが明らかであろう。
【図面の簡単な説明】
【図１】
現在のクライアント−サーバー環境の一例を示す図である。
【図２】
本発明によるクライアント−サーバー環境の一例を示す図である。
【図３】
本発明によりパラレルサービスを取り扱うためのサーバーアーキテクチャーの一例を示す図である。
【図４】
本発明によるサービス環境の一例を示す図である。
【図５】
本発明による方法の一例を示す図である。

Claims (7)

1. 少なくとも１つのクライアントと、少なくとも１つのサービスを含む少なくとも１つのサーバーとを備えたクライアント−サーバープラットホームにおいてサーバーへ事象を送信するクライアントのためのサービスを実行するサーバーであって、
   スレッドをパラレルに実行するためのスレッド実行環境を備え、各スレッドはそれに指定された事象を処理し、
   上記スレッドの少なくとも１つは、そのスレッドに指定された少なくとも２つのサービスインスタンスの実行をパラレルに取り扱い、そして
   更に、事象をスケジュールするためのタスクマネージャーを備えたことを特徴とするサーバー。
2. 上記スレッド実行環境は、上記サービスインスタンスの１つに対してプラットフォームを形成するための少なくとも１つのサービス環境を備えた請求項１に記載のサーバー。
3. 上記サービス環境は、事象を待ち行列処理するための少なくとも１つの待ち行列を備えた請求項２に記載のサーバー。
4. 上記サービス環境は、更に、サービスインスタンス及び待ち行列の状態情報を備えた請求項２又は３に記載のサーバー。
5. 少なくとも１つのクライアントと、少なくとも１つのサービスを含む少なくとも１つのサーバーとを備えたクライアント−サーバープラットホームにおいてサーバーへサービス特有の事象を送信するクライアントのためのサービスを実行する方法において、
   サービスと、送信された事象に対する少なくとも１つの待ち行列と、サービス及び待ち行列の状態情報とで構成されたサービス環境へクライアントが送信する事象を、サービス環境により待ち行列から引き出し、
   サービス及び待ち行列の状態情報が許す場合にタスクマネージャーによりサービス環境から事象を引き出し、
   タスクマネージャーにおいて、指定サービス環境の事象の処理を取り扱うスレッドに指定されたサービス環境からの事象をスケジューリングし、
   サービス事象を処理するためにスレッドによりタスクマネージャーから上記スケジューリングされた事象を引き出し、そして
   サービスを実行するためにサービス環境におけるサービスに対してその事象をファイアする、
   という段階を備えたことを特徴とする方法。
6. 少なくとも１つのクライアントと、少なくとも１つのサービスを含む少なくとも１つのサーバーとを備えたクライアント−サーバープラットホームにおいてサーバーへサービス特有の事象を送信するクライアントのためのサービスを実行する方法において、
   サービスと、送信された事象に対する少なくとも１つの待ち行列と、サービス及び待ち行列の状態情報とで構成されたサービス環境へクライアントが送信する事象を、サービス環境により待ち行列から引き出し、
   サービス及び待ち行列の状態情報が許す場合にサービス環境によりタスクマネージャーへ事象を押し込み、
   タスクマネージャーにおいて、指定サービス環境の事象の処理を取り扱うスレッドに指定されたサービス環境からの事象をスケジューリングし、
   サービス事象を処理するためにタスクマネージャーによりスレッドへ上記スケジューリングされた事象を押し込み、そして
   サービスを実行するためにサービス環境におけるサービスに対してその事象をファイアする、
   という段階を備えたことを特徴とする方法。
7. サービスに事象をポスティングするのではなく、サービスに対して事象をファイアする請求項５又は６の記載の方法。

Images