特許 6336988 使用要求の小バッチ処理のためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6336988

(24)【登録日】2018年5月11日

(45)【発行日】2018年6月6日

(54)【発明の名称】使用要求の小バッチ処理のためのシステムおよび方法

(51)【国際特許分類】

   H04M 15/00 20060101AFI20180528BHJP

   G06F 9/50 20060101ALI20180528BHJP

   G06F 9/54 20060101ALI20180528BHJP

【ＦＩ】

   H04M15/00 E

   G06F9/46 465C

   G06F9/46 480F

【請求項の数】14

【全頁数】13

(21)【出願番号】特願2015-533179(P2015-533179)

(86)(22)【出願日】2013年9月19日

(65)【公表番号】特表2015-532073(P2015-532073A)

(43)【公表日】2015年11月5日

(86)【国際出願番号】US2013060591

(87)【国際公開番号】WO2014047269

(87)【国際公開日】20140327

【審査請求日】2016年9月16日

(31)【優先権主張番号】13/622,546

(32)【優先日】2012年9月19日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】ケンメラー，ジェンズ

(72)【発明者】

【氏名】スリバスタバ，アシシュ

【審査官】 山田 倍司

(56)【参考文献】

【文献】 特開２００５−０７１０３１（ＪＰ，Ａ）

【文献】 特表２００７−５２４８７９（ＪＰ，Ａ）

【文献】 特開２００３−３１６７８２（ＪＰ，Ａ）

【文献】 米国特許第０６１９５６８２（ＵＳ，Ｂ１）

【文献】 特開２００８−１３５０１３（ＪＰ，Ａ）

【文献】 特開２００８−１８６３３１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０２４１１１８（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６

９／４８

９／５０− ９／５２

９／５４

１３／００

１５／８２

１７／３０

Ｇ０６Ｑ ２０／００−２０／４２

４０／００−４０／０８

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｌ １２／００−１２／２６

１２／５０−１２／９５５

Ｈ０４Ｍ ３／００

３／１６− ３／２０

３／３８− ３／５８

７／００− ７／１６

１１／００−１１／１０

１５／００−１５／３８

Ｈ０４Ｗ ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

使用要求の小バッチ処理のための方法であって、
１つ以上のマイクロプロセッサ上で実行されるサービスブローカを提供するステップと、
各々が顧客データを含む複数のサーバを提供するステップと、
複数のキューを提供するステップとを含み、各々のサーバは異なるキューに関連付けられ、前記方法はさらに、
ネットワークエンティティから使用要求を受信するステップと、
前記使用要求によって要求されたデータに関連付けられる内部ＩＤ（Identification）を判定するステップと、
前記使用要求によって要求されたデータが前記複数のサーバのうち特定のどのサーバに格納されているかを判定するステップと、
前記特定のサーバに関連付けられる特定のキューに前記使用要求を入れるステップと、
トリガイベント時に前記特定のキューにあるすべての要求をバッチで前記特定のサーバに送信するステップとを含み、さらに、
前記特定のサーバが各々の要求を前記バッチで処理すると、
各々の要求についての応答データで前記バッチをポピュレートするステップと、
前記バッチを前記サービスブローカに返送するステップとを含む、方法。

【請求項2】

前記使用要求は、ある加入者から別の加入者に対する発呼またはダウンロード要求を含む、請求項１に記載の方法。

【請求項3】

前記サービスブローカはさらに、前記使用要求をネットワーク中心のプロトコルから内部プロトコルに翻訳する、請求項１または２に記載の方法。

【請求項4】

前記サービスブローカが前記特定のサーバから前記バッチを受信すると、
各々の要求についての前記応答データを内部プロトコルからネットワーク中心のプロトコルに翻訳して、翻訳された応答データを作成するステップと、
前記翻訳された応答データを各々のリクエスタに返送するステップとをさらに含む、請求項１から３のいずれかに記載の方法。

【請求項5】

各々のサーバ上のデータが維持される、請求項１から４のいずれかに記載の方法。

【請求項6】

第１のサーバに格納されたデータは、第２のサーバに格納することによって可用性が高くなる、請求項１から５のいずれかに記載の方法。

【請求項7】

コンピュータシステム上で実行されると、前記コンピュータシステムに、請求項１から６のいずれかに記載の方法のステップをすべて実行させる命令を含むコンピュータプログラム。

【請求項8】

複数のサーバと通信するためのサービスブローカであって、前記複数のサーバの各々は、使用要求の小バッチ処理を実行するために顧客データを含み、前記サービスブローカは、
対応する複数のキューを含むように構成された複数のキューコンテナを含み、各々のサーバは異なるキューに関連付けられ、前記サービスブローカはさらに、
ネットワークエンティティから使用要求を受信するように構成された第１の受信インターフェイスと、
前記使用要求によって要求されたデータに関連付けられる内部ＩＤを判定するように構成された第１の判定ユニットと、
前記使用要求によって要求された前記データが、前記複数のサーバのうち特定のどのサーバに格納されているかを判定するように構成された第２の判定ユニットと、
前記特定のサーバに関連付けられる特定のキューに前記使用要求を入れるように構成されたキュー処理ユニットと、
トリガイベント時に前記特定のキューにあるすべての要求をバッチで前記特定のサーバに送信するように構成された第１の送信インターフェイスと、
前記特定のサーバが各々の要求を前記バッチで処理し、各々の要求についての応答データでポピュレートされた前記バッチを前記サービスブローカに返送すると、前記特定のサーバから前記バッチを受信するように構成された第２の受信インターフェイスとを含む、サービスブローカ。

【請求項9】

前記使用要求は、ある加入者から別の加入者に対する発呼またはダウンロード要求を含み得る、請求項８に記載のサービスブローカ。

【請求項10】

前記サービスブローカはさらに、前記使用要求をネットワーク中心のプロトコルから内部プロトコルに翻訳するように構成されたトランスレータを含む、請求項８に記載のサービスブローカ。

【請求項11】

前記トランスレータはさらに、各々の要求についての前記応答データを前記内部プロトコルから前記ネットワーク中心のプロトコルに翻訳して、翻訳された応答データを作成するように構成され、
前記サービスブローカはさらに、前記翻訳された応答データを各々のリクエスタに返送するように構成された第２の送信インターフェイスを含む、請求項１０に記載のサービスブローカ。

【請求項12】

使用要求の小バッチ処理のためのシステムであって、
１つ以上のマイクロプロセッサ上で実行される、請求項８から１１のいずれかに記載のサービスブローカと、
各々が顧客データを含み得る複数のサーバと、
複数のキューとを含み、各々のサーバは異なるキューに関連付けられ、
使用要求がネットワークエンティティから受信されると、前記サービスブローカは、
前記使用要求によって要求されたデータに関連付けられる内部ＩＤ（Identification）を判定し、
前記使用要求によって要求された前記データが前記複数のサーバのうち特定のどのサーバに格納されているかを判定し、
前記特定のサーバに関連付けられる特定のキューに前記使用要求を入れ、
トリガイベント時に前記特定のキューにおけるすべての要求をバッチで前記特定のサーバに送信するように構成される、システム。

【請求項13】

使用要求の小バッチ処理のためのシステムであって、
１つ以上のマイクロプロセッサ上で実行されるサービスブローカと、
各々が顧客データを含み得る複数のサーバと、
複数のキューとを含み、各々のサーバは異なるキューに関連付けられ、
使用要求がネットワークエンティティから受信されると、
前記サービスブローカは、
前記使用要求によって要求されたデータに関連付けられる内部ＩＤ（Identification）を判定し、
前記使用要求によって要求された前記データが前記複数のサーバのうち特定のどのサーバに格納されているかを判定し、
前記特定のサーバに関連付けられる特定のキューに前記使用要求を入れ、
トリガイベント時に前記特定のキューにおけるすべての要求をバッチで前記特定のサーバに送信し、
前記特定のサーバは、各々の要求を前記バッチで処理し、各々の要求についての応答データでポピュレートされた前記バッチを前記サービスブローカに返送するように構成される、システム。

【請求項14】

前記サービスブローカが前記特定のサーバから各々の要求についての前記応答データでポピュレートされた前記バッチを受信すると、前記サービスブローカは、
各々の要求についての前記応答データを内部プロトコルからネットワーク中心のプロトコルに翻訳して、翻訳された応答データを作成し、
前記翻訳された応答データを各々のリクエスタに返送するように構成される、請求項１３に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

著作権表示：
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許情報開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。

【0002】

発明の分野：
この発明は、電気通信ネットワークにおけるオンライン課金システムに関し、特に、電気通信システムにおける要求のバッチ処理のためのシステムおよび方法に関する。

【背景技術】

【0003】

背景：
典型的には、大量の使用要求が、連続的なネットワークストリームで、インテリジェント・ネットワーク・ノード（ＩＮ：Intelligent Network node）からオンライン課金システム（ＯＣＳ：Online Charging System）エントリポイントに送信される。使用要求は、たとえば、ピーク時間中に取引先の顧客が用いるキロワット電力；ある加入者から別の加入者に対する発呼；またはダウンロード要求を含む顧客データを課金目的で必要とするいずれかの形式の使用処理である。各々の使用要求は別々に処理され、応答が発信ＩＮに返送される。

【0004】

使用要求の処理は典型的には非同期的に達成される。すなわち、１つの使用要求が処理されている間、次の使用要求を既にネットワーク接続から読み出すことができる。入ってくる使用要求および出ていく使用応答の発生順は、この非同期処理の結果、さまざまなものになる可能性がある。ＯＣＳの内部では、典型的には個別使用要求の処理は同期的に達成される。すなわち、使用要求は、ＯＣＳエントリポイントからＯＣＳビジネスロジックノードに送信されて処理される。１つのＯＣＳエントリポイントは典型的には多くのＯＣＳビジネスロジックノードのために機能する。

【0005】

小さい使用要求（典型的には１００〜２００バイトのサイズ）を送信することにより、結果として、ネットワークＩＯ動作、コンテキストスイッチおよび送信レイテンシの費用が高くなってしまう。個別使用要求を処理するためにかかる時間が非常に短い（たとえば、１ミリ秒未満である）場合、このコストはＯＣＳスループットに対する限定要因となってしまい、ＯＣＳの総保有コスト（ＴＣＯ：Total Cost of Ownership）が高くなる可能性がある。使用要求処理に対するＯＣＳレイテンシ要件によれば、すべての使用要求のうち９９．９％が５０ミリ秒未満で処理されなければならない。

【発明の概要】

【課題を解決するための手段】

【0006】

概要：
さまざまな実施形態に従うと、使用要求の小バッチ処理を提供するシステムおよび方法が提供される。使用要求の小バッチ処理のためのシステムは、サービスブローカと、各々が顧客データを含む複数のサーバと、複数のキューとを含み得る。複数のキューの各々は異なるサーバに関連付けられる。使用要求がネットワークエンティティから受信されると、サービスブローカは、使用要求を処理するのに必要なデータに関連付けられる内部ＩＤ（Identification）を判定し、使用要求によって要求されたデータが複数のサーバのうち特定のどのサーバに格納されているかを判定し、特定のサーバに関連付けられる特定のキューに使用要求を入れ、トリガイベント時に、特定のキューにあるすべての要求をバッチで特定のサーバに送信するように構成される。他のさまざまな実施形態に従うと、１つ以上のコンピュータに使用要求の小バッチ処理のための方法を実行させるためのプログラムが提供される。当該方法は、１つ以上のマイクロプロセッサ上で実行されるサービスブローカを提供するステップと、各々が顧客データを含み得る複数のサーバを提供するステップと、複数のキューを提供するステップとを含む。各々のサーバは異なるキューに関連付けられる。当該方法はさらに、ネットワークエンティティから使用要求を受信するステップと、使用要求によって要求されたデータに関連付けられる内部ＩＤ（Identification）を判定するステップと、使用要求によって要求されたデータが複数のサーバのうち特定のどのサーバに格納されているかを判定するステップと、特定のサーバに関連付けられる特定のキューに使用要求を入れるステップと、トリガイベント時に、特定のキューにあるすべての要求をバッチで特定のサーバに送信するステップとを含む。

【図面の簡単な説明】

【0007】

【図1】本発明の実施形態に従った、使用要求の小バッチ処理のためのシステムを示す図である。

【図2A】個別要求システムを示す図である。

【図2B】本発明の実施形態に従った小バッチシステムを示す図である。

【図3】本発明の実施形態に従った小バッチの作成を示すシーケンス図である。

【図4】本発明の実施形態に従った、小バッチ要求処理を示すシーケンス図である。

【図5】本発明の実施形態に従った、使用要求の小バッチ処理のための方法を示す図である。

【図6】本発明の実施形態に従った例示的なサービスブローカを詳細に示す図である。

【発明を実施するための形態】

【0008】

詳細な説明：
以下の説明においては、本発明は、添付の図面の図において、限定ではなく例示によって説明される。この開示におけるさまざまな実施形態を参照する場合、必ずしも同じ実施形態を指すものではなく、このような参照は少なくとも１つを意味する。特定の実現例を説明しているが、これが例示のためにのみ提供されることが理解される。当業者であれば、他の構成要素および構成が本発明の範囲および精神から逸脱することなく使用され得ることを認識するだろう。

【0009】

さらに、いくつかの場合には、本発明を十分に説明するために多数の具体的な詳細を述べることとする。しかしながら、本発明がこれらの具体的な詳細なしでも実施され得ることが当業者に明らかとなるだろう。他の場合には、本発明が不明瞭になるのを避けるために、周知の特徴はさほど詳細には説明されていない。

【0010】

典型的には、大量の使用要求が、連続的なネットワークストリームでオンライン課金システム（ＯＣＳ）に送信される。使用要求は、たとえば、ピーク時間に取引先の顧客が用いるキロワット電力；ある加入者から別の加入者に対する発呼；またはダウンロード要求を含む顧客データを課金目的で必要とするいずれかの形式の使用処理である。さまざまな実施形態に従うと、使用要求の小バッチ処理を提供するシステムおよび方法が提供される。使用要求の小バッチ処理のためのシステムは、サービスブローカと、ＯＣＳを形成する複数のサーバとを含み得る。各々のサーバは、顧客データと複数のキューとを含む。複数のキューは各々、異なるサーバに関連付けられる。使用要求がネットワークエンティティから受信されると、サービスブローカは、使用要求を処理するのに必要なデータに関連付けられる内部ＩＤを判定し、使用要求によって要求されたデータが複数のサーバのうち特定のどのサーバに格納されているかを判定し、使用要求を特定のサーバに関連付けられる特定のキューに入れ、トリガイベント時に、特定のキューにあるすべての要求をバッチで特定のサーバに送信するように構成される。

【0011】

本発明のさまざまな実施形態に従うと、ＯＣＳエントリポイントからＯＣＳビジネスロジック層まで、直接、各々の個別使用要求を送信するのではなく、使用要求は、まず、それらのＯＣＳビジネスロジックノード先に基づいてソートすることができる。ＯＣＳビジネスロジック層の各ノードは同じビジネスロジックを実行する。しかしながら、顧客データはすべてのＯＣＳビジネスロジックにわたって分割される。ＯＣＳビジネスロジックノード先は顧客データの位置に基づいて判定される。

【0012】

次に、宛先が同じであるすべての使用要求が同じ「小バッチ」コンテナ（すなわちキュー）に配置される。各々の「小バッチ」コンテナの最大サイズは、システムの特定の要求および特徴に応じて任意の数に設定することができる。ここに示される例は最大サイズとして２０を用いるが、これは限定するよう意図されたものではない。最大サイズに達すると、「小バッチ」コンテナが送信される。「小バッチ」コンテナを送信するコストは、ネットワークＩＯ動作、コンテキストスイッチおよび送信レイテンシの点からみて、使用要求ごとでは、各々の使用要求を個々に送信するコストよりも著しく低い。

【0013】

個別使用要求レイテンシを増加させる代わりに全体的なＯＣＳスループットを増加させることができる。個別使用要求のレイテンシは、このとき、「小バッチ」の大きさの関数であり、（個別使用要求のために１ミリ秒の処理時間を想定すると）３０ミリ秒にまで増加する。５０ミリ秒未満のＯＣＳレイテンシ要件は依然として満たされる。小バッチを送信させる追加のトリガも与えることができる。たとえば、使用要求トラフィック量が少ない期間中、「小バッチ」タイムアウト機構は、不完全な「小バッチ」の送信をトリガして、５０ミリ秒未満のレイテンシを保証することができる。要求に優先順位を付けるために追加のトリガを与えることができる。特定のタイプの要求が到着すると、小バッチが直ちに送信される。たとえば、長期にわたる要求が到着すると（すなわちロジックを実行するのに２５ミリ秒を超える処理時間を要する場合）、この要求は単独で小バッチにして直ちに送信することができる。

【0014】

図１は、本発明の実施形態に従った、使用要求の小バッチ処理のためのシステムを示す。１００において、加入者Ａ １０２が加入者Ｂ １０４に電話をかける。図１には電話が示されているが、これは、システムがイベントとみなすもの、たとえば、ＡからＢに対するＳＭＳ、料金が発生する媒体のダウンロードについてのＡからの要求、または結果として使用要求をもたらすこととなる他の任意の動作、とみなすものであればどんなものであってもよい。要求１０６はサービスブローカ１０８に送信される。サービスブローカ１０８は、要求をネットワーク中心のプロトコルからの内部固有プロトコル、たとえば、ＯＣＳの内部固有プロトコル、に翻訳することができる。次いで、サービスブローカ１０８は要求１０６を分析して、要求されたデータがどこにあるかを判定することができる。一実施形態に従うと、サービスブローカは、要求に用いられる外部ＩＤに対応するデータの内部（顧客）ＩＤ １１２を格納するキャッシュ１１０を用いて、データ位置を判定することができる。

【0015】

データは、サーバＡ １１４およびサーバＢ １１６などの１つ以上のサーバに位置する。顧客データは、複数のサーバマシンにわたって（１次元）、かつ、単一のサーバマシン内における複数の処理（ここでは「サーバ」と称する）にわたって（２次元）分散される。典型的な処理によって複数のパーティションが「ホストされる」。このため、各サーバは複数のパーティションを含み得る。複数のパーティションは各々、複数の顧客オブジェクトを含む。要求を処理するのに必要なデータを含む処理が（どのサーバのどのパーティションにデータが格納されているかを識別することを含め）位置特定されると、この要求はその処理に関連付けられるキューに入れることができる。各々のキューはサーバごとのキューであるので、この場合、２つのキュー、すなわちキューＡ １２０およびキューＢ １２２が存在することとなるだろう。特定のサーバのために受信されるトラフィックは特定のサーバの関連するキューに蓄積される。たとえば、要求１０６が翻訳された後、翻訳された要求１２４がキューＢ １２２に配置される。トリガイベントが起こると、キューＢからの要求１２６のバッチがサーバＢ １１６に送信されて処理される。

【0016】

本発明の実施形態に従うと、サーバは、各々の要求を順番に取り込んで応答を生成するという要求１２６のバッチを順次処理することができる。バッチにおけるすべての要求がサーバによって処理されると、応答のバッチ全体が、サービスブローカ１０８にまで送り返される（１２８）。次いで、サービスブローカ１０８は、それら応答をそれらの内部固有の表現からリクエスタのネットワーク中心プロトコルに翻訳する。すると、翻訳された応答がリクエスタに送り返される。たとえば、サービスブローカ１０８は、翻訳された要求１２４に対する応答を識別することができ、当該応答を、内部固有プロトコルから要求のネットワーク中心プロトコルに翻訳し直すことができる。次いで、翻訳された応答１３０が返送される。

【0017】

加えて、図１に示されるとおり、サーバからのデータは同期的にシリアル化されて別のノード上にバックアップされ得る。このようにして、データは別のノード上でレプリケートされて（１３４）高い可用性をもたらすことができる。データはまた、データベースにおいて非同期的に維持させる（１３２）こともできる。レプリケートされたおよび／または維持させたデータは、たとえば、要求、顧客データおよび／またはイベント関連データを処理するのに必要なデータのうち１つ以上を含み得る。サーバがバッチ処理の途中でクラッシュしてしまうといったノード障害がある場合、そのバッチに含まれる要求が隔離され、バックアップサーバがオンラインとなる。隔離が終了すると、要求が再び処理される。

【0018】

図２Ａおよび図２Ｂは、本発明の実施形態に従った、個別要求処理と小バッチ処理との比較を示す。図２Ａおよび図２Ｂでは、本発明の実施形態に従って典型的な個別要求システム２００を小バッチ要求システム２０２と比較する。

【0019】

図２Ａに示されるとおり、個別要求システム２００のクライアント側２０４、たとえば、（サービスブローカ１０８など）のサービスブローカは、課金プロセッサクライアント２０８を含み得る。使用要求２１２がネットワークエンティティ２１４から受信される（たとえば、第１の加入者が第２の加入者に電話をかけるかまたは加入者が媒体をダウンロードするよう要求する）と、その要求２１２は、課金プロセッサクライアント２０８を実行する別個のスレッドに引き渡される（かまたは、要求２１２が引き渡されるよう要求される）（なお、典型的には、クライアント２０４において同時に実行されるこのようなスレッドが何百個も存在するであろうことに留意されたい）。課金プロセッサは、個別要求システム２００のサーバ側２１６に要求を転送する前に必要に応じて要求を翻訳することができる。

【0020】

サーバ側２１６では、エントリプロセッサ２１８が要求２１２を受信し、これを適切な課金サービス２２０へと転送する。次いて、応答が同様の方法で返送される。応答は同期的に返送される。したがって、図２Ａに関連付けて上述された個別要求システム２００においては、各々の要求が入ってくると、各要求が受信され、処理されてサーバに送信される。従来のシステムではこの構成が実現可能であることが判明した。というのも、典型的なトランジット時間が１ミリ秒である一方で、サーバ処理時間が５０ミリ秒近くになるからである。しかしながら、アーキテクチャを改善することにより、サーバ処理時間を１ミリ秒未満をはるかに下回るまで減らして、トランジット時間を実質的な係数にした。要求をバッチで提出することにより、このトランジット時間が多くの要求の間で分散され、メッセージ毎にトランジットに費やされる時間量を大幅に減らすことができる。

【0021】

図２Ｂは小バッチ要求システム２０２を示す。小バッチ要求システム２０２のクライアント側２２２では、要求が同様にネットワークエンティティから受信される。しかしながら、これらの要求を直ちに処理してサーバ側２２４に転送するのではなく、要求バッチサービス２２６が、サーバごとのキュー（たとえば、図１に示されるキュー１２０および１２２）に要求を集約させる。タイムアウトまたはバッチがフルになるといったトリガイベントが起こると、要求のバッチがキューの内容から作成され、課金実行可能クライアント（charging invocable client）２２８を用いて、要求のバッチをサーバ側２２４に提出することができる。次いで、サーバ側の課金実行可能モジュール２３０が要求のバッチを順次処理し、各々の個別要求をエントリプロセッサ２３２に転送する。エントリプロセッサ２３２はさらに、当該要求を適切な課金サービス２３４に転送することができる。バッチにおける各要求が処理されると、サーバ側の課金実行可能モジュール２３０が、このとき応答データでポピュレートされている要求のバッチを、課金実行可能クライアント２２８に送り返し、さらに、要求バッチサービス２２６に到達させることができる。次いで、要求バッチサービス２２６は、各々の応答をそのリクエスタに返送することができる。

【0022】

図３は、本発明の実施形態に従った小バッチ作成のシーケンス図を示す。上述のとおり、本発明の実施形態に従うと、複数の異なるトリガを用いて、要求のバッチをキューからその関連するサーバに送信することができる。これらのトリガは、要求に関連付けられる期間、最大キューサイズまたはプライオリティ情報を含み得るが、これらに限定されない。トリガが満たされると、バッチ要求が、関連するサーバへと送信されるキューの内容から作成される。

【0023】

図３に示されるとおり、クライアント３００（たとえば、サービスブローカ１０８などのサービスブローカ）は、翻訳された要求をバッチ要求サービス３０４に提出する（３０２）ことができる。バッチ要求サービスは、使用要求を処理するのに必要なデータが格納されるノードを判定し（３０６）、要求されたデータが格納されているノードの名前を返送する（３０８）。たとえば、ノードがクラッシュしたせいで、返送されたノード情報が無効、たとえばヌル、である場合、システムは一時停止（３１０）モードにすることができ、その関連するキューにおける要求がリカバリ処理中に隔離される（すなわち、サーキュレーションから取出される）。そうでない場合、３１２に示されるように、個別要求が、識別されたノードのための要求キューに挿入される。トリガイベントが起こると（３１４）、バッチ要求３１６が要求キュー３１８の内容から作成される。バッチ要求が作成されると（３２０）、バッチ要求は、「専用のスレッド」に引き渡され、その後、バッチ要求がキューの関連サーバに送信される（３２２）。「専用のスレッド」は、大きいスレッドプールの一部として予め割り当てられている。専用のスレッドは、このときからバッチ要求のライフサイクル全体に対処する。次に、バッチ応答が返送される（３２４）。

【0024】

図４は、本発明の実施形態に従った小バッチ要求処理のシーケンス図を示す。図４は、バッチ要求サービス４０４、要求キュー挿入スレッド４００および要求キューデキュースレッド４１２を示す。典型的には、１ノード当たり、多くの要求キュー挿入スレッドがあるが、要求キューデキュースレッドは１つしかない。要求キュー挿入スレッド４００を用いて、バッチ要求サービス４０４から要求キューに要求を追加する（４０２）ことができる。要求が追加されると、要求キュー挿入スレッド４００は、要求されたノードがまだ存在しているかどうかを判定することができ、（たとえば、サーバがクラッシュしたために）要求されたノードが存在していなければ（４０６）、一時停止の管理を開始し得る。

【0025】

要求キュー挿入スレッド４００は、トリガが起こるのを待機するループ４０８を含む。要求キュー挿入スレッドおよび要求キューデキュースレッドは、監視パターンを用いて、要求キューに対する相互排除アクセスを確実にする。いくつかの条件変数（トリガ）のうちの１つが真である場合にのみ、要求キュー挿入スレッドは待機することとなるだろう。トリガの例は、バッチがフルである場合、タイムアウト条件に達する場合、またはエラーが起こる場合を含み得る。バッチフルトリガが起こると、要求キュー挿入スレッドが条件をバッチフル４１０に設定し、引き続き、要求キューデキュースレッド４１２の処理が行われる。要求キューデキュースレッド４１２は、任意のエラー条件についての監視を行う第１のループ４１４と、タイムアウト条件を待機する第２のループ４１６とを含む複数のネスト化ループを含み得る。経過時間がタイムアウト時間以上であれば、タイムアウトトリガ４１８が発生したこととなる。タイムアウトトリガまたはバッチフルトリガが起こる（４２０）と、キューにおける要求がデキューされ（４２２）、バッチ要求４２４が作成される。次いで、バッチ要求４２４が専用のバッチ要求スレッドに送信され（４２６）、バッチがサーバに送信され、応答バッチを待って、サービスブローカに応答バッチが返送される。

【0026】

図５は、本発明の実施形態に従った使用要求の小バッチ処理のための方法を示す。ステップ５００では、１つ以上のマイクロプロセッサ上で実行されるサービスブローカが提供される。ステップ５０２では、複数のサーバが提供される。各々のサーバは顧客データを含んでいる（複数のサーバの各々は顧客ベースのデータのサブセットを含む）。ステップ５０４では、複数のキューが提供される。各々のサーバは異なるキューに関連付けられる。ステップ５０６では、使用要求がネットワークエンティティから受信される。ステップ５０８では、使用要求によって要求されたデータに関連付けられる内部ＩＤが判定される。ステップ５１０では、複数のサーバのうち、使用要求によって要求されるデータが格納されている特定のサーバが判定される。ステップ５１２では、使用要求は、特定のサーバに関連付けられる特定のキューに入れられる。ステップ５１４では、トリガイベントが起こると、特定のキューにおけるすべての要求がバッチで特定のサーバに送信される。

【0027】

図６は、本発明の実施形態に従った例示的なサービスブローカ６００を詳細に示す。サービスブローカ６００は、図１に示されるようにサービスブローカ１０８の具体的な一実施形態であり得る。しかしながら、当業者には明らかなように、本発明に従ったサービスブローカの実現例はこのように限定されるものではない。たとえば、サービスブローカ６００は、複数のサーバ（Ｎ個のサーバなど、図１の場合には２つのサーバ、すなわちサーバＡ １１４およびサーバ１１６ Ｂ）と通信している。各々のサーバは顧客データを含んでもよい。たとえば、サービスブローカ６００は、複数のサーバと協働して使用要求の小バッチ処理を実行するように構成される。

【0028】

図６に示されるとおり、サービスブローカ６００は、対応する複数のキューを含むように構成された複数のキューコンテナ（６００１−１、６００１−２…６００１−Ｎ）を含み、各々のサーバは異なるキューに関連付けられる。たとえば、図１に示されるサーバＡ １１４およびサーバ１１６ Ｂなどの２つのサーバがある場合、２つのキューコンテナ６００１−１および６００１−２があってもよい（すなわちＮ＝２）。この場合、キューコンテナ６００１−１はサーバＡ １１４に関連付けられるキューを含み、キューコンテナ６００１−２はサーバ１１６ Ｂに関連付けられるキューを含む。

【0029】

サービスブローカ６００はさらに、ネットワークエンティティから使用要求を受信するように構成された第１の受信インターフェイス６００３を含み得る。受信インターフェイス６００３は、当該技術において周知であるかまたは近い将来公知となるであろう如何なるインターフェイスであってもよい。一実施形態においては、使用要求は、ある加入者から別の加入者に対する発呼またはダウンロード要求を含み得る。

【0030】

図１に関連付けて説明されたように、サービスブローカは、たとえば、要求において用いられる永久ＩＤに対応するデータの内部（顧客）ＩＤを格納するキャッシュを用いて、データ位置を判定することができる。図６に示されるとおり、サービスブローカ６００はさらに、使用要求によって要求されるデータに関連付けられる内部ＩＤを判定するように構成された第１の判定ユニット６００４と、使用要求によって要求されるデータが複数のサーバのうち特定のどのサーバに格納されているかを判定するように構成された第２の判定ユニット６００５とを含む。たとえば、使用要求は、たとえばサーバＡ １１４上に位置するデータを要求してもよく、こうして、第１の判定ユニット６００４が、使用要求によって要求されたデータに関連付けられる内部ＩＤを判定し、第２の判定ユニット６００５が、使用要求によって要求されたデータがサーバＡ １１４に格納されていると判定する。第１の判定ユニット６００４および第２の判定ユニット６００５は、別個のユニットであってもよく、または１つのユニットに一体化されてもよい。当業者に公知であるように、内部（顧客）ＩＤは、キャッシュ以外の他のストレージに格納することができる。

【0031】

加えて、図６に示されるように、サービスブローカ６００はさらに、特定のサーバに関連付けられる特定のキューに使用要求を入れるように構成されたキュー処理ユニット６００７を含む。使用要求によって要求されたデータがサーバＡ １１４に格納されていると判定される上述の例においては、キュー処理ユニット６００７は、サーバＡ １１４に関連付けられるキュー６００１−１に使用要求を入れてもよい。

【0032】

サービスブローカ６００はさらに、トリガイベントが起こると、特定のキューにおけるすべての要求をバッチで特定のサーバに送信するように構成された第１の送信インターフェイス６００９を含み得る。上述のように、トリガイベントは、キューにおける要求の所定の数に達すること、特定のタイプの要求の到着、長期にわたる要求の到着などであり得る。たとえば、キューコンテナ６００１−１における使用要求の数が所定の数に達すると、キューコンテナ６００１−１におけるすべての要求がバッチで送信される。

【0033】

上述のとおり、サービスブローカは、要求をネットワーク中心のプロトコルから内部固有プロトコル、たとえば、ＯＣＳの内部固有プロトコル、に翻訳することができる。図６に示されるとおり、サービスブローカ（６００）はさらに、使用要求をネットワーク中心のプロトコルから内部プロトコルに翻訳するように構成されたトランスレータ（６０１１）を含み得る。

【0034】

実施形態においては、各々のサーバは、各々の要求をバッチで処理し、各々の要求についての応答データでポピュレートされたバッチをサービスブローカに返送してもよい。このような場合、サービスブローカ６００はさらに、特定のサーバが各々の要求をバッチで処理し、各々の要求についての応答データでポピュレートされたバッチをサービスブローカに返送したときに特定のサーバからバッチを受信するように構成された第２の受信インターフェイス６０１３を含んでもよい。一実施形態においては、トランスレータ６０１１はさらに、各々の要求についての応答データを内部プロトコルからネットワーク中心のプロトコルに翻訳して、翻訳された応答データを作成するように構成されてもよい。これ対応して、サービスブローカ６００はさらに、翻訳された応答データを各々のリクエスタに返送するように構成された第２の送信インターフェイス６０１５を含んでもよい。

【0035】

当業者であれば、ブローカサーバ６００におけるユニットのうちのいずれも、ソフトウェア、ハードウェアまたはこれらの組合せによって実現可能であることを理解し得る。ブローカサーバ６００におけるユニットは、別個に実現されてもよく、または任意の組合せで一体化されてもよい。

【0036】

適切なソフトウェアコーディングは、ソフトウェア技術に精通した当業者に明らかになるように、熟練したプログラマであれば本開示の教示に基づいて容易に準備することができる。本発明はまた、当業者に容易に明らかになるように、特定用途向け集積回路を用意することによって、または従来の構成回路の適切なネットワークを相互接続することによって実現され得る。

【0037】

さまざまな実施形態は、この明細書中に示された特徴のうちいずれかを実行するために、命令が格納されている記憶媒体／汎用または専用のコンピューティングプロセッサ／デバイスをプログラムするのに使用することのできる記憶媒体であるコンピュータプログラムプロダクトを含む。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気光ディスク、ホログラフィックストレージ、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、（分子メモリＩＣを含む）ナノシステムを含む如何なるタイプの物理的媒体；紙または紙ベースの媒体；ならびに命令および／もしくは情報を記憶するのに適した如何なるタイプの媒体もしくは装置のうち、１つ以上を含み得るが、これらには限定されない。コンピュータプログラムプロダクトは、全体的または部分的に、かつ１つ以上の公衆網および／または私設網を介して伝送することができる。この場合、この伝送は、この明細書中に示される特徴のうちのいずれかを実行するために１つ以上のプロセッサによって用いることができる命令を含む。この伝送は複数の別個の伝送を含み得る。しかしながら、いくつかの実施形態に従うと、命令を含むコンピュータ記憶媒体は非一時的である（すなわち、伝送される処理にはない）が、物理デバイス上で維持される。

【0038】

本発明の好ましい実施形態の上述の記載は例示および説明のために提供されたものであり、網羅的なものとして意図されたものではなく、または、開示された厳密な形態に本発明を限定するよう意図されたものではない。多くの変更例および変形例が当業者に明らかになるだろう。変更例および変形例は、開示された特徴の如何なる関連する組合せをも含む。本発明およびその実用化の原理を最も良く説明することにより、当業者が本発明を理解することを可能にするために、実施形態が選択され、記載されている。本発明の範囲は、添付の特許請求の範囲およびその同等例によって規定されるよう意図されている。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】