JP2008510259A - モジュラー型のイベントドリブン処理 - Google Patents

Abstract

複数のスレッド境界のそれぞれは、単一のスレッドによって所与のイベントについて実行される機能を有している。スレッド境界には、イベントをルーティング可能な複数のキューを結合可能である。定義済みの関係において複数のタスクを構成可能であり、それぞれのタスクは、スレッド境界と関連付けられており、特定の機能を実行するための一群のコードを有している。リソースは、キューの深度に基づいてスレッド境界に割り当て可能である。
【選択図】図１

Description

本開示の実施例は、一般に、高性能の演算と、モジュラー型のイベントドリブン方式における演算サービスの提供に関するものである。

コンピューティング・デバイスは、リクエストを処理するべく、限られた数のリソースを備えることが可能である。リクエストを効率的に処理するには、装置は、どのリクエストに対してリソースをどのように割り当て可能であるのかを管理する必要があろう。リソースがリクエストに割り当てられた際に、そのリクエストを処理可能である。

本出願は、２００４年８月１７日付けで出願された「ＴＥＣＨＮＩＱＵＥＳ ＦＯＲ ＤＥＬＩＶＥＲＩＮＧ ＰＥＲＳＯＮＡＬＩＺＥＤ ＣＯＮＴＥＮＴ ＷＩＴＨ Ａ ＲＥＡＬ−ＴＩＭＥ ＲＯＵＴＩＮＧ ＮＥＴＷＯＲＫ， ＭＯＤＵＬＡＲ ＥＶＥＮＴ−ＤＲＩＶＥＮ ＡＲＣＨＩＴＥＣＴＵＲＥ， ＭＯＤＵＬＡＲ ＥＶＥＮＴ−ＤＲＩＶＥＮ ＰＲＯＣＥＳＳＩＮＧ ＡＮＤ ＶＩＥＷＥＲ ＦＡＩＬＯＶＥＲ ＴＥＳＴＩＮＧ Ａ ＳＹＳＴＥＭ ＭＥＭＯＲＹ ＷＨＩＬＥ ＡＮ ＯＰＥＲＡＴＩＮＧ ＳＹＳＴＥＭ ＩＳ ＡＣＴＩＶＥ」という名称の同時係属中の米国仮特許出願第６０／６０２，５３９号に対する優先権を主張するものであり、この内容は、本引用により、本明細書中に完全に記述されているかのように、あらゆる目的のために、本明細書に包含される。

装置は、特定の理由から、リクエストの大幅な増大を遭遇する場合がある。例えば、多数のユーザに対してウェブサイトのウェブページをサービスしているサーバは、ウェブページに対する多数のリクエストをユーザから受信する場合がある。リソースがリクエストに対して効率的に割り当てられていない場合には、ユーザは、遅延を遭遇することになる。

一実施例においては、モジュラー型のイベントドリブン処理は、複数のスレッド境界を提供し、それぞれのスレッド境界は、所与のイベントについて単一のスレッドによって実行される機能を有している。イベントをルーティング可能なキューによってスレッド境界を結合できるように、複数のキューをスレッド境界に対して通信可能に結合可能である。演算機能を複数のスレッド境界に分割すれば、それらの対応しているキューが満杯になるため、負荷の影響を受けやすい部分を識別することが可能となる。この結果、キューの深度に基づいて、スレッドなどの演算リソースをスレッド境界に対して動的に割り当て可能である。

複数のタスクは、サービスを提供するべく、定義済みの関係にあってよく、それぞれのタスクは、スレッド境界と関連付け可能であり、且つ、特定の機能を実行するための一群のコードを包含している。又、複数のサービスユーティリティを提供することも可能であり、それぞれのサービスユーティリティは、複数のタスクがアクセス可能なユーティリティを包含している。

いくつかの実施例においては、タスク及びそれらの間における定義済みの関係は、システム自体の外部においてハイレベルに記述可能であり、且つ、このハイレベルな記述に応じた能力を有することができる。いくつかの実施例においては、このハイレベルな記述は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの宣言型言語におけるものであってよい。このハイレベルな外部記述により、タスクとそれらの間における関係、並びに、その認証の動的な構成が可能になる。

添付の図面は、いくつかの実施例を示しているが、これらは、例示を目的とするものに過ぎない。当業者であれば、以下の説明内容から、本明細書に示されている構造及び方法の代替実施例を利用可能であることを容易に認識するであろう。

本明細書の残りの部分及び添付の図面を参照することにより、本明細書に開示されている開示内容の特性及び利点について理解を深めることができよう。

図１は、一実施例によるシステム１０１のハイレベルな概要を示している。システム１０１は、情報を処理するあらゆるコンピューティング・デバイス内において提供可能である。例えば、システム１０１は、サーバ又はルータに包含可能である。

システム１０１は、いくつかの機能（例えば、１つのサービス）を提供している。この機能は、複数のスレッド境界１０３に分割可能であり、それぞれのスレッド境界１０３は、所望の機能のアプリケーションロジックの一部をカプセル化可能である。スレッド境界は、スレッド境界キュー１０５によって接続可能である。イベント１０７（例えば、サービスに対するリクエストやメッセージ）は、スレッド境界１０３との間において、スレッド境界キュー１０５を介して入出力可能である。

イベントは、必要となる任意の処理であってよい。イベント１０７の一例が、サービスに対するリモートクライアントからのリクエストであってよい。例えば、クライアントは、ログインするべく要求可能であり、この場合には、システム１０１（例えば、サーバ）は、クライアントのクレデンシャルをチェックした後に、適切なアクションをとることが必要となろう。いくつかの実施例によれば、システム１０１は、このリクエストをイベント１０７としてカプセル化し、スレッド１０３（このそれぞれは、サービスの小さな構成要素を実行する能力を有することができる）のチェーンを通じて伝達することにより、このリクエストを処理し、最終的に、ログインの確認又は拒絶のいずれかを出力可能である。当業者には、本明細書に鑑み、イベントの様々なその他の例について明らかであろう。例えば、イベントは、データベースに対するレコードリクエストの処理、到来電子メールメッセージの処理、送出するエンコード済みデータの処理、送出エラーメッセージの送信、ウェブページに対するリクエストの処理などを包含可能である。

サーバなどの演算システムは、多数のイベントを同時に処理する必要があろう。従って、スレッド境界１０３間におけるイベント１０７は、スレッド境界キュー１０５内に存在可能である。スレッド境界１０３内においては、単一のスレッドがイベント１０７を処理可能である。但し、第１スレッド境界１０３がイベント１０７に関するその処理を完了し、イベント１０７をキュー１０５内に配置した後に、別のスレッドがイベント１０７をピックアップし、次のスレッド境界１０３を通過させることができる。

尚、図１には、２つのスレッド境界１０３が示されているが、任意の数のスレッド境界を提供可能である。多くの演算システムは、複雑な機能を提供しており、この複雑な機能は、必要に応じて、多数のスレッド境界１０３に分割可能である。複数のスレッド境界１０３への機能の分割と、使用するスレッド境界１０３の数は、異なったものであってよい。本明細書に鑑み、当業者には、多数の変形が明らかであろう。

機能を多数のスレッド境界１０３に分割することにより、それらの対応しているスレッド境界キュー１０５が満杯になるため、負荷の影響を受けやすい部分を識別することが可能となる。いくつかの実施例においては、リソース割当モジュール１０９により、スレッド境界キュー１０５を監視しており、キューの深度に基づいて、対応するスレッド境界１０３に演算リソースを割り当てている。例えば、第１キュー１０５及び第２キュー１０５内に保持されているイベントの数を判定可能である。そして、それぞれ、第１キュー１０５及び第２キュー１０５内に保持されているイベントの数に基づいて、リソースを割り当て可能である。例えば、第１キュー１０５が、第２キュー１０５よりも長い場合には、より多くのリソースを第１スレッド境界１０３に割り当て可能である。従って、スレッド境界１０３の負荷を使用することにより、リソースを動的に割り当てる方法を判定可能である。尚、キューの長さについて説明しているが、スレッド境界１０３によって処理されるイベントの数を使用するものなど、負荷を判定するその他の技法を使用することも可能であることを理解されたい。図１に示されている実施例においては、リソース割当モジュール１０９は、中央集中化可能であり、従って、これは、スレッド境界１０３及びキュー１０５によってカプセル化されているアプリケーションロジックとは別個のものになっている。

いくつかの実施例においては、リソース割当モジュール１０９は、そのインバウンドキュー１０５の長さに従って（或いは、必要に応じて、その他の測定基準に従って）、スレッドプール１１１のスレッドをスレッド境界１０３に割り当てている。当業者であれば、スレッド境界１０３内において、単一のスレッド（又は、複数のスレッド）により、それぞれのイベント１０７を処理可能であることを理解するであろう。同一のバウンダリ１０３により、複数のイベント１０７を並行して処理可能であり、必要に応じて、このような並行したイベント１０７の処理を複数のスレッドによって実行可能である（一実施例においては、スレッドは、１つのイベント１０７当たりに１つを上回っていない）。

従って、さもなければボトルネックになり得るシステム１０１の部分が、より多くのリソースを受領することになり、この結果、アプリケーションフローが円滑になると共に、性能を改善可能である。割当は、動的なものであってよいことから、リソース割当モジュール１０９は、状態の変化に対応可能である。例えば、特定のタイプのリクエストがシステム１０１に殺到すると、通常はボトルネックにならない部分が過負荷状態となる可能性がある。このような状況に対して、リソース割当モジュール１０９は、演算リソースの割当を動的に変更することにより、相応して対応可能である。

複数のスレッド境界に処理を分割するステップには、単一のリクエストを１つのスレッドに割り当てるステップ（この結果、この１つのスレッドが、そのリクエストのすべての処理を実行する）が伴っていないため、これは、利点を提供している。必要とするリソースの観点において、それぞれのリクエストを同一のものとして取り扱わなくてもよい。システム１０１は、イベントがキューイングされるスレッド境界に形成される負荷に対して、自身をチューニング可能である。従って、システム１０１の内部性能を監視可能であり、これを負荷に応答してチューニング可能である。

又、システム１０１は、スレッド境界用のキューのキュー長を使用することにより、リソースを割り当てる先を判定可能である。この結果、システム１０１は、イベントを優先順位付けする方法に伴う複雑な機能を導入することなしに、リソースを割り当てる先を判定可能である。

尚、リソース割当モジュール１０９は、単一のエンティティとして図示可能ではあるが、本明細書において使用されているリソース割当モジュール１０９という用語は、ソフトウェア、ハードウェア、ファームウェア、又はこれらの３つの任意の組み合わせとして実装可能な機能の集合体を意味していることを理解することができよう。リソース割当モジュール１０９をソフトウェアとして実装可能である場合には、これは、スタンドアロンプログラムとして実装可能であるが、例えば、より大きなプログラムの一部として、複数の別個のプログラムとして、又は１つ又は複数の静的又は動的にリンクされたライブラリとしてなど、その他の方法によって実装することも可能である。

図１に示されているように、それぞれのスレッド境界１０３によってカプセル化されている機能は、１つ又は複数のタスク１１３によって実行可能である。本明細書において使用されているこのタスク１０３という用語は、特定の機能を実行するためのコードの任意のブロックを包含可能である。所望の演算サービスを提供するためのチェーン内に複数のタスク１１３を包含可能である。

図２は、メッセージを暗号化及び送信する能力を有する４つのタスク１１３の単純な例を示している。暗号化及び伝送の対象である入力メッセージ２０１は、タスク１によって受信可能であり、このタスク１が宛先アドレスの有効性をチェックする。宛先アドレスが有効である場合には、タスク３が入力メッセージ２０１を暗号化し、暗号化されたメッセージ２０３をタスク４が出力として宛先アドレスに送信する。一方、宛先アドレスが無効である場合には、タスク２が、適切なエラーメッセージを生成し、これをタスク４が出力メッセージ２０３として発信元アドレスに送信する。４つのタスクによって提供されている機能は、必要に応じて、格段に大きな演算システムの一部であってよい。

図１を再度参照すれば、タスク１１３は、スレッド境界１０３よりも微細な粒度レベルにおけるものであってよい。複数のタスク１１３を単一スレッド境界１０３内にカプセル化可能であるが、単一のタスク１１３のみをスレッド境界１０３が格納することも可能であろう。特定のタスク１１３を特定のスレッド境界１０３に割り当て可能である。例えば、図１は、タスク１及び２がスレッド境界１内においてカプセル化され、且つ、タスク３〜５が、スレッド境界２内においてカプセル化されるものとして示している。その他の実施例においては、タスク１〜５は、２つを上回る数のスレッド境界１０３に分割可能であり、或いは、必要に応じて、５つのタスクのすべてを単一のスレッド境界内にカプセル化することも可能である。様々な実施例に応じて、タスク１１３をスレッド境界に割り当てるための多数の可能性が存在し得る。当業者には、本明細書に鑑み、必要に応じて、構成の変化により、タスク１１３とスレッド境界１０３間の関係を設定及び変更可能であることが明らかであろう。

図１に示されているように、すべての所望の機能をタスク１１３によって実行可能である必要はない。例えば、特定の機能をサービスユーティリティ１１５によって実行可能であり、これらのサービスユーティリティは、複数のタスク１１３によって使用可能なユーティリティであってよい。標準的なユーティリティを中央集中化することによって効率が向上することに加えて、サービスユーティリティ１１５によれば、柔軟性も向上することになる。タスク１１３が、インタフェースを通じてサービスユーティリティ１１５にアクセスする実施例においては、そのサービスに依存しているタスク１１３のいずれをも変更することなしに、サービス１１５の実装をスワップ可能であろう。例えば、ログファイルに書き込むべく多数のタスク１１３を必要としている場合には、ロギングサービスを提供可能である。タスク１１３は、サービスユーティリティ１１５を通じてロギングサービスにアクセス可能である。サービス１１５は、状態を保存可能であり、従って、複数のタスク１１３がこれらをイベント用に使用可能である。

サービスユーティリティ１１５は、イベント１０７の生成ソースとして使用可能である。例えば、クライアントがリクエストを発行した際には、このリクエストをタスクフローに入力するべく、ネットワークプロトコルサービス１１５が、このリクエストをイベント１０７としてパッケージ化し、適切なスレッド境界キュー１０５に挿入する責任を担うことができる。イベント１０７は、サービスユーティリティ１１５によって生成され、処理のためにタスク１１３に伝達可能であり、タスクは、通常、既存のイベント１０７を変更し、それらをその他のタスク１１３に転送する。

いくつかの実施例においては、サービスユーティリティ１１５は、状態を保存可能であり、タスク１１３は、ステートレスであってよい。例えば、現時点において登録されているユーザのリストは、通常、サービス１１５によって制御されることになろう。タスク１１３は、サービス１１５に関するメソッドを呼び出すことにより、リストにアクセス可能である。尚、タスク１１３は、ステートレスであるものとして説明されているが、いくつかの実施例においては、タスク１１３も状態を保存可能である。

一実施例においては、タスク１１３は、スレッドを生成したり、或いは、内部タスク１１３の手順を制御しているスレッドに関する知識を具備している必要はない。一方、サービスユーティリティ１１５は、異なるスレッド境界１０３内において稼動している複数のタスク１１３がそれらにアクセス可能であるため、スレッドセーフであってよい。従って、サービスユーティリティ１１５は、複数のスレッドからアクセス可能である。

タスク１１３を利用するケースとサービス１１５を使用するケースは変化可能である。いくつかの実施例においては、可能な限りタスクを使用可能である。このような実施例においては、サービス１１５は、多数のタスク１１３にわたって横断しているユーティリティ、イベント１０７を生成するコンポーネント、又は状態を管理するコンポーネント用に使用可能である。その他の実施例においては、タスク１１３及び／又はサービスユーティリティ１１５は、必要に応じて、より多くの又は少ない目的に使用可能である。本明細書に鑑み、当業者には、本明細書において、「タスク」及び「サービス」という用語が、単に様々な機能を説明するべく使用されていることが明らかであろう。これらの機能に対するこの特定の命名法は、必須又は重要ではなく、様々な実施例及び／又はその特徴を実装するメカニズムは、様々な名称、分割、及び／又はフォーマットを具備可能である。

前述のように、複数のタスク１１３は、サービス用の所望の機能を提供するべく、定義済みの関係にあってよい。このタスク１１３間における定義済みの関係は、提供される機能によって左右されることになる。例えば、タスク１１３は、所望の機能に応じて異なる方式で構成可能である。前述のように、タスク１１３は、入力としてイベント１０７を受信し、これに関する動作を実行し、（恐らくは変形された）イベント１０７を更なる処理のためにその他のタスク１１３に伝達可能である。タスク１１３は、その内容又はその他の要因に基づいて、イベント１０７の処理方法及び／又はその伝達先について決定を下すことができる。

特定のタスク１１３は、特定の入力を受信し、特定の処理を実行し、特定の出力を送信する能力を有することができる。タスク１１３は、処理コードであってよく、ゼロ又はこれを上回る数の入力（即ち、タスク１１３がイベント１０７の形態でデータを受信する供給ソース）とゼロ又はこれを上回る数の出力を有しており、この出力を通じて、タスクは、処理の後にイベント１０７を送信する。タスク１１３と関連している入力、処理、及び出力は、タスク１１３のコントラクトを定義するものとして見なすことができる。供給ソースコントラクトは、タスク１１３の入力を介して受信するイベント１０７に関する制約を規定している。処理コントラクトは、タスクを通過するイベント１０７に対してタスク１１３が実行する変更の内容について記述している。この「入力」、「出力」、「供給ソースコントラクト」、及び「処理コントラクト」という用語は、言語学的な用語であり、本明細書においては、基礎をなしている機能を記述するべく使用されている。このような側面及び機能を記述するべく使用されるその他の名称を想起することも可能である。

供給ソースコントラクト及び処理コントラクトの一例を示すべく、クライアントは、イベント１０７（即ち、認証リクエスト）をシステム１０１（例えば、サーバ）に対して伝送することにより、ユーザの認証を要求可能である。例として、イベント１０７が、「ｕｓｅｒｎａｍｅ」というストリングと「ｐａｓｓｗｏｒｄ」というストリングを格納していると想定しよう。このイベント１０７は、「ｐａｓｓｗｏｒｄ」というストリングと「ｕｓｅｒｎａｍｅ」というストリングを受領することが供給ソースコントラクトに規定されている検証タスク１１３に伝達可能である。タスク１１３は、これらのストリングを使用することにより、ユーザを認証可能である。認証結果は、下流の様々なタスク１１３に伝達可能であり、検証タスク１１３の処理コントラクトにおいて、「ｖａｌｉｄ」というブーリアンをイベント１０７に付加する旨を規定可能である。その他のケースにおいては、タスク１１３の処理コントラクトは、イベント１０７からアイテムを除去可能であろう。

いくつかの実施例においては、タスク１１３及びそれらの間における定義済みの関係は、システム自体の外部においてハイレベルに記述可能であり、且つ、このハイレベルな記述に従って構成可能である。いくつかの実施例においては、このハイレベルな記述は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの宣言型言語におけるものである。ハイレベルな記述は、例えば、ＸＭＬ構成ファイル内に保存可能である。

このハイレベルな外部記述により、タスク１１３、それらの間の関係、並びに、その認証の動的な構成が可能となる。本明細書に鑑み、当業者には、タスク１１３及びそれらの間における定義済みの関係のハイレベルな記述が、タスク１１３の機能、入力及び出力、供給ソースコントラクト及び処理コントラクト、並びに、複数のタスク１１３を１つに関係付けて所望の機能を提供する方法、及びスレッド境界１０３に対するタスク１１３の割当に関する説明を包含可能であることが容易に明らかであろう。いくつかの実施例においては、更に多くの又は更に少ない情報をハイレベルな記述内に包含可能である。

図３は、本発明に従ってタスク１１３及びそれらの間における関係のハイレベルな記述を処理するステップを示している。ステップ３０１において、システム１０１は、ハイレベルな記述を（例えば、ＸＭＬ構成ファイルから）読み取る。ステップ３０３において、システム１０１は、複数のタスクを相応して動的に構成する。

対応した変更をハイレベルな記述に対して実行することにより、タスク１１３及び／又はタスク１１３間における関係に対する動的な変更を実行可能である。ステップ３０５において、システム１０１は、ハイレベルな記述に対する対応した変更に応答し、タスク１１３を動的に変更可能である。又、ステップ３０７及び３０９において、システム１０１は、ハイレベルな記述に対応した変更に応答し、複数のタスク１１３間における定義済みの関係（又は、タスク１１３のスレッド境界１０３に対する割当）を動的に変更可能である。

ステップ３１１において、ハイレベルな記述を使用することにより、タスク１１３間における定義済みの関係が論理的に一貫性を有しているかどうかを自動的に判定することも可能である。このような判定は、例えば、供給ソース及び処理コントラクトの検証をも包含可能である。

図４は、一実施例による管理モジュール４０１のハイレベルな概要を示している。図４に示されているように、いくつかの実施例においては、タスク１１３、サービスユーティリティ１１５、及び／又はスレッド境界１０３は、これらのコンポーネントを、管理モジュール４０１を介して監視及び制御できるように実装可能である。このような実施例においては、タスク１１３及び／又はその他のコンポーネントは、管理モジュール４０１に対して通信可能に結合可能であり、これらのタスク１１３及びその他のコンポーネントの属性（例えば、アクティブ接続の数）を、例えば、グラフィカルユーザインタフェース４０５又はコマンドライン４０７、或いは、適宜、構成ファイルを介して、管理モジュール４０１から監視又は動的に変更可能である。

このような一実施例においては、コンポーネントと管理モジュール４０１間における前述の通信は、ＪＭＸ（Ｊａｖａ（登録商標） Ｍａｎａｇｅｍｅｎｔ Ｅｘｔｅｎｔｉｏｎ）のＭＢｅａｎインタフェースを介して実行可能である。このような実施例においては、タスク１１３、サービスユーティリティ１１５、及び／又はスレッド境界１０３は、ＭＢｅａｎの実装体であってよく、従って、管理モジュール４０１に対して露出したＭＢｅａｎインタフェースを自動的に包含可能であり、このような実施例においては、これをＪＭＸ上に構築可能である。

ＪＭＸによれば、コンポーネントの管理、運用、及び監視が、これらのコンポーネント自体から分離される。この結果、アプリケーションの管理フロントエンドがスワップ可能となる。一例として、サーバなどのコンピューティング・システムは、コンポーネントを監視及び制御するべく、ウェブベースのグラフィカルユーザインタフェース４０５とコマンドラインインタフェース４０７の両方を有するようにパッケージ化された管理モジュール４０１を包含可能であろう。これらのインタフェース４０５、４０７は、本明細書に鑑み、当業者には明らかな方式により、ＪＭＸによって定義されている規則及びインタフェースを用いて独立的に開発可能である。その後、これらのインタフェース４０５、４０７を使用することにより、こちらも、本明細書に鑑み、当業者には明らかな方式により、タスク１１３、サービスユーティリティ１１５、及び／又はスレッド境界１０３を監視及び動的に構成可能である。当然のことながら、必要に応じて、ＪＭＸ以外の開発環境においてその他の実施例を実装することも可能である。

当業者であれば、その精神又は基本的な特性を逸脱することなしに、本開示をその他の特定の形態において実施可能であることを理解することができよう。同様に、モジュール、特徴、属性、方法、及びその他の側面の特定の命名法及び分割は、必須又は重要ではなく、実施例及びその特徴を実装するメカニズムは、様々な命名法、分割、及び／又はフォーマットを具備可能である。又、当業者には、本開示のモジュール、特徴、属性、方法、及びその他の側面は、ソフトウェア、ハードウェア、ファームウェア、又はこれら３つの任意の組み合わせとして実装可能であることが明らかであろう。コンポーネントをソフトウェアとして実装可能である場合には、コンポーネントは、スタンドアロンプログラムとして、より大きなプログラムの一部として、複数の別個のプログラムとして、静的又は動的にリンクされたライブラリとして、カーネル読み込み可能なモジュールとして、デバイスドライバとして、及び／又はコンピュータプログラミング分野の当業者に現在又は将来判明するすべての任意のその他の方法によって実装可能である。又、実施例は、特定のプログラミング言語や特定のオペレーティングシステム又は環境における実装には決して限定されていない。従って、本開示は、本開示の範囲を例示することを意図するものであり、これを限定するものではなく、本開示の範囲は、添付の請求項に記述されているとおりである。

一実施例においては、「及び／又は」という文言は、「及び／又は」によって接続されている要素の任意の組み合わせを使用可能であることを示し得る。例えば、「及び／又は」を使用するフレーズ内における２つの単語又は表現は、１つ又はもう一方、或いは、これらの両方を示し得る。一実施例においては、「実質的」という文言は、ほとんど（但し、完全にではなく）規定可能であること（或いは、規定可能であるもの）を意味可能である。一実施例においては、「〜する能力を有する」とう文言は、「構成されている」、「適合されている」、「可能である」などを意味可能である。例えば、「アクションを実行する能力を有している」という文言は、要素が、「そのアクションを実行可能であってよい」、「そのアクションを実行するべく構成可能である」、及び／又は「そのアクションを実行するべく適合可能である」を示し得る。

実施例は、ソフトウェア又はハードウェア、或いは、これらの組み合わせとして、制御ロジックの形態において実装可能である。この制御ロジックは、一実施例に開示されているステップのペアを情報処理装置に実行させるべく適合された複数の命令として情報ストレージ媒体内に保存可能である。当業者であれば、本明細書に提供されている開示及び教示内容に基づいて、実施例を実装するためのその他の方法及び／又は方式について理解することができよう。

以上の説明は、例示を目的としており、制限を意図するものではない。本開示を参照することにより、当業者には、本開示の多数の変形が明らかとなろう。従って、本開示の範囲は、以上の説明を参照することによって判断されるべきものではなく、添付の請求項をその完全な範囲又はその等価物と共に参照して、判断されるべきである。

本発明の一実施例によるシステムのハイレベルな概要を示すブロックダイアグラムである。 本発明の一実施例による送出メッセージを暗号化及び送信する能力を有する４つのタスクの一例を示すブロックダイアグラムである。 本発明の一実施例によるタスクとそれらの間における関係のハイレベルな記述を処理するステップを示すフローチャートである。 本発明の一実施例による管理モジュールのハイレベルな概要を示すブロックダイアグラムである。

Claims (34)

1. イベントを処理する方法において、
   複数のスレッド境界の中の第１スレッド境界における負荷を判定するステップであって、前記複数のスレッド境界は、１つ又は複数のイベント用のサービスを実行可能であり、前記複数のスレッド境界の中のそれぞれのスレッド境界は、少なくとも１つのタスクが実行可能な前記サービスの少なくとも一部と関連付けられた当該少なくとも１つのタスクを含んでいる、ステップと、
   前記判定された負荷に基づいて、１つ又は複数のリソースを前記第１スレッド境界に対して動的に割り当てるステップであって、前記１つ又は複数のリソースにより、前記第１スレッド境界の前記少なくとも１つのタスクは、前記少なくとも１つのタスクと関連付けられている前記サービスの少なくとも一部を実行可能である、ステップと、
   を有することを特徴とする方法。
2. 前記負荷は、前記第１スレッド境界が処理することを要するイベントの数に基づいている請求項１に記載の方法。
3. 複数のスレッド境界キューを提供するステップを更に有しており、前記第１スレッド境界は、前記イベントの数を保持可能である第１スレッド境界キューを有する請求項２に記載の方法。
4. 前記負荷は、前記スレッド境界キュー内に保持されている前記イベントの数に基づいて判定される請求項３に記載の方法。
5. 前記第１スレッド境界は、前記イベントの数に対して前記サービスの前記少なくとも一部を実行可能である請求項２に記載の方法。
6. 前記複数のスレッド境界の中の第２のスレッド境界における第２負荷を判定するステップと、
   判定された前記第２負荷に基づいて、１つ又は複数のリソースの第２の組を前記第２のスレッド境界に対して動的に割り当てるステップであって、前記１つ又は複数のリソースの第２の組により、前記第２のスレッド境界の前記少なくとも１つのタスクは、第２の前記サービスの少なくとも一部を実行可能である、ステップと、
   を更に有する請求項２に記載の方法。
7. 前記第２負荷は、前記第２スレッド境界が処理すること要する第２のイベントの数に基づいている請求項６に記載の方法。
8. 前記第１スレッド境界の前記負荷及び前記第２スレッド境界の前記第２負荷は、前記第１スレッド境界及び前記第２スレッド境界に対して割り当てるリソースの数を判定するために使用される請求項６に記載の方法。
9. １つ又は複数のリソースを前記第１スレッド境界に動的に割り当てるステップは、
   前記負荷に基づいてスレッドを前記第１スレッド境界に割り当てるステップであって、それぞれの割り当てられたスレッドは、それが割り当てられている前記スレッド境界と関連付けられた前記サービスの少なくとも一部を実行する、ステップを更に有する請求項１に記載の方法。
10. 前記複数のスレッド境界のそれぞれの前記少なくとも１つのタスクは、前記１つ又は複数のイベント用の前記サービスを実行するために、定義済みの関係を有している請求項１に記載の方法。
11. 前記１つ又は複数のイベントの中のイベントは、該イベント用の前記サービスを実行するために、前記複数のスレッド境界によって処理される請求項１に記載の方法。
12. 前記１つ又は複数のイベントの中の第１イベント及び第２イベントは、前記第１スレッド境界内において並列処理される請求項１に記載の方法。
13. イベントを処理するためのコンピュータシステムにおいて、
    サービスを実行可能な複数のスレッド境界であって、該複数のスレッド境界の中の第１スレッド境界は、前記サービスの少なくとも一部を実行可能な少なくとも１つのタスクを含んでいる、複数のスレッド境界と、
    前記スレッド境界に結合された複数のスレッド境界キューであって、前記第１スレッド境界は、前記第１スレッド境界にルーティングするための１つ又は複数のイベントを保持可能な第１スレッド境界キューを含んでいる、複数のスレッド境界キューと、
    前記第１スレッド境界キューの第１スレッド境界キュー深度に基づいて、１つ又は複数のリソースを前記第１スレッド境界に割り当て可能なリソース割当モジュールであって、前記第１スレッド境界キュー深度は、前記第１スレッド境界キュー内に保持されているイベントの数に基づいている、リソース割当モジュールと、
    を有することを特徴とするシステム。
14. 前記割り当てられた１つ又は複数のリソースにより、前記第１スレッド境界の少なくとも１つのタスクは、前記第１スレッド境界キュー内に保持されている前記イベントの数のための前記サービスの少なくとも一部を実行可能である請求項１３に記載のシステム。
15. 前記複数のスレッド境界の中の第２スレッド境界は、第２のイベントの数を保持する第２スレッド境界キューを含んでおり、
    前記リソース割当モジュールは、前記第１スレッド境界キュー深度及び前記第２スレッド境界キュー深度に基づいて、第１のリソースの組を前記第１スレッド境界に、そして、第２のリソースの組を前記第２スレッド境界に割り当て可能であり、前記第１スレッド境界キュー深度は、前記第１スレッド境界キュー内に保持されている前記イベントの数に基づいており、前記第２スレッド境界キュー深度は、前記第２スレッド境界キュー内に保持されている前記第２のイベントの数に基づいている請求項１３に記載のシステム。
16. 前記１つ又は複数のリソースは、１つ又は複数のスレッドを有しており、前記１つ又は複数のスレッドは、前記第１スレッド境界キュー深度に基づいて前記第１スレッド境界に割り当てられる請求項１３に記載のシステム。
17. それぞれの割り当てられたスレッドは、前記イベントの数のための前記第１スレッド境界内において前記少なくとも１つのタスクを実行する請求項１６に記載のシステム。
18. スレッド境界キュー深度に基づいてスレッド境界に割り当てられる前記１つ又は複数のスレッドを有し、かつ、前記リソース割当モジュールに結合されたスレッドプールを更に有する請求項１６に記載のシステム。
19. 前記複数のタスクのそれぞれは、ステートレスである請求項１３記載のシステム。
20. ユーティリティを提供可能な１つ又は複数のサービスユーティリティを更に有しており、前記複数のスレッド境界のそれぞれの中の前記少なくとも１つのタスクは、前記１つ又は複数のサービスユーティリティの中のサービスユーティリティを使用して、前記サービスのその一部を実行する請求項１３に記載のシステム。
21. 前記１つ又は複数のサービスユーティリティの中の少なくとも１つは、ステートフルである請求項２０に記載のシステム。
22. 前記複数のスレッド境界の少なくとも１つのタスクは、前記１つ又は複数のイベント用の前記サービスを実行するために、定義済みの関係を有している請求項１３に記載のシステム。
23. 前記イベントの数の中のイベントは、該イベント用の前記サービスを実行するために、前記複数のスレッド境界によって処理される請求項１３に記載のシステム。
24. 前記イベントは、前記第２スレッド境界が前記イベントを次に処理できるように、前記第１スレッド境界から第２スレッド境界の第２スレッド境界キューに伝達される請求項２３に記載のシステム。
25. 前記１つ又は複数のイベントの中の第１イベント及び第２イベントは、前記第１スレッド境界内において並列処理される請求項１３に記載のシステム。
26. 処理するためのコンピュータシステムにおいて、
    少なくとも１つのタスクを有する第１スレッド境界であって、該第１スレッド境界内の第１タスクは、第１機能を実行するための処理機能を有する、第１スレッド境界と、
    少なくとも１つのタスクを有する第２スレッド境界であって、前記第２スレッド境界内の第２タスクは、第２機能を実行するための処理機能を有する、第２スレッド境界と、
    前記第１スレッド境界に結合された第１スレッド境界キューと、
    前記第２スレッド境界に結合された第２スレッド境界キューであって、該第２スレッド境界キューは、前記１つ又は複数のイベントが、前記第２スレッド境界キューを通じて前記第１スレッド境界から前記第２スレッド境界にルーティングされるように、前記第１スレッド境界及び前記第２スレッド境界を結合する、第２スレッド境界キューと、
    １つ又は複数のリソースを前記第１及び第２スレッド境界に割り当て可能なリソース割当モジュールであって、１つ又は複数のリソースにより、前記第１及び第２タスクは、それぞれの第１及び第２機能を実行可能であり、前記１つ又は複数のリソースは、前記第１スレッド境界キューの第１スレッド境界キュー深度及び前記第２スレッド境界キューの第２スレッド境界キュー深度に基づいて前記第１及び第２スレッド境界に割り当てられており、前記第１スレッド境界は、前記１つ又は複数のリソースの中の第１のリソースの組を受領し、前記第２スレッド境界は、前記１つ又は複数のリソースの中の第２のリソースの組を受領する、リソース割当モジュールと、
    を有することを特徴とするコンピュータシステム。
27. 前記１つ又は複数のリソースは、前記第１タスクの前記第１機能、又は、前記第２タスクの第２機能を処理可能なスレッドを有する請求項２６に記載のコンピュータシステム。
28. 前記第１及び第２スレッド境界キュー深度に基づいて前記第１及び第２スレッド境界に割り当てられる前記１つ又は複数のスレッドを有するスレッドプールを更に有する請求項２７に記載のコンピュータシステム。
29. 第１及び第２タスクは、ステートレスである請求項２６に記載のコンピュータシステム。
30. １つ又は複数のサービスユーティリティを更に有しており、サービスユーティリティは、前記第１機能又は前記第２機能を実行するときに前記第１タスク又は第２タスクからアクセス可能なユーティリティを有する請求項２６に記載のコンピュータシステム。
31. 前記１つ又は複数のサービスユーティリティの中の少なくとも１つは、ステートフルである請求項３０に記載のコンピュータシステム。
32. 前記第１スレッド境界内の前記少なくとも１つの第１タスク、及び、前記第２スレッド境界内の前記少なくとも１つのタスクは、前記イベント用の前記第１機能及び第２機能に基づいて全体的な機能を実行するために、定義済みの関係を有している請求項２６に記載のコンピュータシステム。
33. 前記イベントは、前記イベント用の前記第１及び第２機能によって定義された全体的な機能を実行するために、前記複数のスレッド境界によって処理される請求項２６に記載のコンピュータシステム。
34. 前記１つ又は複数のイベントの中の第１イベント及び第２イベントは、並列処理される請求項２６に記載のコンピュータシステム。

Images