JP2009536403A - ワーク・アイテム・イベント処理 - Google Patents

Abstract

本明細書で詳述するのは、特に、フロントエンド・アプリケーションとバックエンド・サーバとの間のイベント・フローを監視する技術である。１つの方法は、新規イベントがバックエンド・サーバで受け取られる技術である。この新規イベントは、イベントのタイプを有し、これは、新規イベント・フラグを設定するのに使用され、該新規イベント・フラグはそのタイプの新規イベントが受け取られたことを指し示す。新規イベントがキュー・テーブルに追加される。キュー・テーブルから１つまたは複数のイベントが選択され、フェイルオーバー機構が、選択されたイベントが処理中の間、維持される。

Description

多くのソフトウェア・アプリケーションにおいて、特にネットワーク環境においては、１つまたは複数のステートレスな（stateless）フロントエンドのアプリケーションが、単一のステートフルな（state-full）バックエンドに接続する。種々のオブジェクトにアクセスする要求、種々のオブジェクトを変更する要求、種々のオブジェクトを除去する要求などのイベントが、フロントエンド・アプリケーションで受け取られ、バックエンドに転送される。同じオブジェクトへのアクセスを求める複数の要求が同時に、またはほぼ同時に受け取られる。多くのそのようなアプリケーションにおいては、そのようないずれの競合する要求も、オブジェクトがアクセスされている間、オブジェクトをロックすることにより、対処される。

ステートフルなバックエンドのオブジェクトがロックされると、要求が現在処理中のアプリケーションのみが、オブジェクトにアクセスすることができる。このようにして、潜在的に競合するアクセス要求や変更要求がオブジェクトに対して同時に行われないので、オブジェクトのインテグリティ（integrity：完全性）が保たれ、破損が避けられる。

この方法には多数の問題が存在する。例えば、オブジェクト・ハンドラは、新規のイベントが受け取られたことを確定する手段を持たない。イベント・ディスパッチ機構は、すでに処理中のイベントと、処理を待機中のイベントと、を区別できない。また、ほとんどのコンピュータ・アプリケーションと同様に、どのイベントが処理済みであるか、どのイベントが現在処理中であるか、どのイベントが未処理であるかの履歴が全く保持されないので、システム障害が重大な時間のロスにつながる。

本明細書で詳述するのは、特に、フロントエンド・アプリケーションとバックエンド・サーバとの間のイベント・フローを監視する技術である。複数のフロントエンド・アプリケーションがバックエンド・サーバ上の同じオブジェクトにアクセスしようとする時、その要求は、キュー・テーブルでキューイングされる。同じバッチ内で処理されるオブジェクトのタイプに従ってキュー・テーブルの順序付けを行うことにより、処理はより効率的になる。新規イベントが受け取られる時に設定されるフラグを組み込むことにより、イベント・ディスパッチ機構は、キュー・テーブルをポーリングすることを必要とせずに、新規イベントを知るようになる。キュー・テーブル内のイベントをフラグ設定することは、まだ処理する必要のある他のイベントに対して、どのイベントがすでに処理中であるかを識別することになる。フェイルオーバー「イベント」および関連するモニタを実装することにより、バックエンドが「処理中」の選択したイベントのシステム障害を検出することを可能にし、「正常」バージョンのキュー・テーブルを保存し、次の更新時にフェイルオーバー「イベント」を維持することにより、システムは最小のロスで障害から回復することができる。

この技術の１つの方法では、新規イベントがバックエンドに送られる。新規イベントは関連するイベント・タイプを有する。新規イベントが受け取られると、新規イベント・フラグが、その関連するイベント・タイプに基づいて設定され、特定のイベント・タイプの新規イベントが受け取られたことを指し示す。新規イベントはキュー・テーブルに追加される。複数のイベントが、処理するために、時にはイベント・タイプに基づき、事前にある時間に設定された期限切れ時間（expiration time）を有するグループで、キュー・テーブルから選択される。処理グループ内の各イベントがマークされ、その結果、システムが別のビジネス・アプリケーションが同じイベントを平行して処理するのを防止することになる。

この技術の別の方法では、例えば、１つまたは複数のイベントが処理するのに選択された時に、フェイルオーバー・イベントがキュー・テーブルに追加される。フェイルオーバーの保護イベントは期限切れタイマー（expiration timer）を有する。フェイルオーバー・イベントは監視され、期限切れタイマーが満了した場合、システム障害が発生し、システムは、回復されることが必要になる。例えば、処理中にキュー・テーブルへのアクセスに成功することによって、期限切れタイマーをリセットすることができる。「正常な」状態のキュー・テーブルが保存され、その結果、期限切れタイマーが満了した場合、キュー・テーブルを既知の正常なバージョンに回復することができる。キュー・テーブルの正常なバージョンは、例えば、期限切れタイマーが作成されるときに保存することができる。

上述した「発明を解決するための手段」として説明した内容は、以下の「発明を実施するための最良の形態」でさらに詳述する概念の選択を簡潔に説明するためのものである。本説明は、「請求の範囲」についての重要な機能または不可欠な機能を特定するものではなく、「請求の範囲」を限定するのに使用されることを意図していない。

本明細書の一部に組み込まれ、本明細書の一部を形成する添付図面は、実施形態を示すものであり、本記述と共に「請求の範囲」の原理を説明するのに役立つ。

いくつかの実施形態に関して詳細に言及する。主題を代替実施形態と併せて説明するが、「請求の範囲」の事項をこれらの実施形態に限定するためのものではないことは理解されるだろう。むしろ、「請求の範囲」の事項は、「請求の範囲」により定義される本発明の精神と範囲に含まれる代替物、変更物、等価物を網羅することを意図している。

さらに、以下の詳細な説明において、請求の範囲の主題についての深い理解を提供するために、多数の具体的な細部について説明する。しかし、当業者は、これらの具体的な細部を有しない、またはこれらと等価なものを有する実施形態が実施できることは認識するであろう。その他に、主題の捉え方（aspects）や機能を不必要に分かりにくくしないように、周知の方法、プロシージャ、コンポーネント、回路は、詳細に説明されていない。

以下の詳細な説明の一部は、方法に特有の表現で提示され、説明される。複数のステップとその順序付けは、本方法の動作を説明する本明細書内の図（図６）に示されており、これらのステップとその順序付けは例にすぎない。幾つかの実施形態が、本明細書の図のフローチャート内に列挙されたステップについて、種々の他のステップまたは変形を、本明細書内で図示し説明した以外の順序で、実行するのに十分適している。

詳細な説明の一部は、コンピュータ・メモリ上で実行することができる、データビットに関する動作についての、プロシージャ、ステップ、論理ブロック、処理、および他の記号的表現に特有の表現で、提示されている。これらの説明および表現は、データ処理分野の技術者により使用される意味であり、彼らの仕事の内容を最も効果的に他の当業者に伝達する。プロシージャ、コンピュータ実行ステップ、論理ブロック、処理などが示されるが、一般にこれらは、望ましい結果につながるステップまたは命令の首尾一貫した順序であると考えられる。それらのステップは、物理量の物理操作を要求するステップである。通常は、必ずというわけではないが、これらの物理量は、コンピュータ・システム内で保存され、転送され、結合され、比較され、またはその他の方法で操作されることが可能な電気信号または磁気信号の形をとる。これらの信号を、ビット、値、要素、記号、文字、専門語（terms）、数字などとして参照することは、主に共通に使用できるという理由から時々便利であることが分かった。

しかしながら、これらの語および同様な語の全ては、適切な物理量に関連付けられるべきであって、これらの物理量に付けられた便利なラベルに過ぎないということを心に留めておくべきある。以下の説明から明らかであるように、その他の方法で具体的に示さない限り、本発明全体にわたり、「アクセス」「書き込み」「格納（保存）」「送信」「トラバース」「関連付け」「識別」などの用語を使用する説明は、コンピュータ・システムまたは同様の電子計算装置のアクションおよび処理を指す。コンピュータ・システムまたは同様の電子計算装置は、コンピュータ・システム・レジスタおよびメモリ内の物理（電子）量として表されたデータを操作し、コンピュータ・システム・メモリまたはレジスタ、またはその他の該情報の記憶装置、送信装置または表示装置内の物理量として同様に表されたその他のデータに変換する。

コンピューティング・システム環境１０などのコンピューティング装置は、通常、少なくともいくつかの形式のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピューティング装置によりアクセスできる任意の利用可能な媒体である。例として、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含んでもよいが、これらに限定されない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラム・モジュールなどの情報を格納するために任意の方法または技術で実装される揮発性および不揮発性で、取り外し可能および取り外し不可能な媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）またはその他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク、またはその他の磁気記憶装置、所望の情報を格納するのに使用できる、またはコンピューティング装置によりアクセスできる、任意のその他の媒体を含むが、これらに限定されない。一般的に空きの媒体（Vacation media ）は、コンピュータ可読命令、データ構造、プログラム・モジュール、またはその他のデータを、キャリア波、またはその他の搬送波機構などの変調されたデータ信号の形で具現化し、任意の情報配信媒体を含む。用語「変調データ信号」は、情報を信号でエンコードするような態様で設定または変更された１つまたは複数の特性セットを有する信号を意味する。例として、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、音響、ＲＦ、赤外線などの無線媒体、およびその他の無線媒体を含むが、これらに限定されない。さらに、上述の任意の組み合わせは、コンピュータ可読媒体の範囲に含まれるべきである。

いくつかの実施形態を、１つまたは複数のコンピュータまたはその他の装置により実行されるプログラム・モジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラム・モジュールの機能性が、種々の実施形態で望ましいように組み合わせされ、あるいは分散されることができる。

ワークアイテム・イベント・モニタを以下に説明する。いくつかの実施形態において、ワークアイテム・イベント・モニタは、ウェブ・サーバ環境やポータル・サーバ環境などのサーバ・アプリケーションのバックエンドで動作する。モニタは、ステートレスなフロントエンド・アプリケーションから複数の競合する要求を、バックエンド全体で利用可能なステートフルなオブジェクトに調整する。

ワークアイテム・イベント・モニタは、キュー・テーブル（queuing table）を使用して、バックエンドの適切なオブジェクトにまだ配信されていない、フロントエンド・アプリケーションから受け取られたイベントを追跡する。いくつかの実施形態では、さらにワークアイテム・イベント・モニタは、イベント・ディスパッチ機構としての働きもする。本明細書内で示すように、多数の方法でこのキュー・テーブルを監視し、変更することにより、ワークアイテム・イベント・モニタは、タイミング良く新規イベントについてオブジェクトに情報を提供することができ、特定のイベントが配信されたか、または配信する必要があるかを追跡することができ、サーバーのシステム障害から回復させることができ、キュー・テーブルをより効率的にすることができる。

（基本コンピューティング装置）
図１に関して、幾つかの実施形態を実装する例示的なシステムは、コンピューティング・システム環境１０などの、汎用コンピューティング・システム環境を含む。その最も基本的な構成においては、コンピューティング・システム環境１０は、通常、少なくとも１つの処理ユニット１２およびメモリ１４を含む。コンピューティング・システム環境の厳密な構成およびタイプに基づいて、メモリ１４は揮発性（ＲＡＭなど）か、不揮発性（ＲＯＭ、フラッシュメモリなど）か、これら２つのいくつかの組み合わせとすることができる。この最も基本の構成は、図１では破線１６で示されている。さらに、コンピューティング・システム環境１０は、追加の機能／機能性を有してもよい。例えば、コンピューティング・システム環境１０はさらに、追加の記憶装置（取り外し可能および／または取り外し不可能）を含んでもよい。この記憶装置には、磁気または光のディスクまたはテープを含むが、これらに限定されない。そのような追加の記憶装置は図１では、取り外し可能記憶装置１８および取り外し不可能記憶装置２０により示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラム・モジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実装された揮発性および不揮発性、取り外し可能および取り外し不可能な媒体を含む。メモリ１４、取り外し可能な記憶装置１８、取り外し不可能な記憶装置２０は全て、コンピュータ記憶媒体の例である。

コンピューティング・システム環境１０はさらに、他の装置との通信を可能にする通信接続２２を含むことができる。通信接続２２は、通信媒体の一例である。

コンピューティング・システム環境１０はさらに、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置（単数または複数）を含むことができる。ディスプレイ、スピーカ、プリンタなどの出力装置（単数または複数）も含むことができる。これらの装置全ては当技術分野で周知であり、ここで詳細に説明する必要はない。

（コンピューティング環境）
図２は、一実施形態に従うシステム２００が示されている。システム２００が特定の機能を含むとして示されているが、システム２００は一例にすぎないということは理解されたい。その他の実施形態では、システム２００は、示された以外の追加の機能、より少ない機能、または異なる機能を含んでもよい。さらに、いくつかの実施形態では、記載された機能は複数の個別の要素に分離してもよいし、組み合わせてより少ない要素にしてもよい。

図示するように、システム２００は、単一のステートフルなバックエンド２２０をインターフェースする複数のステートレスなフロントエンド・アプリケーション２１０、２１１、２１２を示す。いくつかの実施形態では、フロントエンド・アプリケーションとバックエンド・アプリケーションとの両方を、コンピューティング・システム環境１０などの単一のコンピュータ・システム上で実装してもよい。その他の実施形態では、１つまたは複数のフロントエンド・アプリケーションは遠隔で実行し、例えば単一のウェブ・サーバにアクセスする複数のウェブ・クライアントなどのネットワーク接続を介してバックエンド２２０にアクセスしてもよい。その他の実施形態では、フロントエンド・アプリケーション２１０、２１１、および／または２１２はその他の方法でバックエンド２２０と通信する。図示したバックエンド２２０は、データ・ストア２３０に接続されている。いくつかの実施形態では、データ・ストア２３０は、例えばＳＱＬデータベースのデータベースである。その他の実施形態では、データ・ストア２３０はその他の方法で実装される。

図３は、一実施形態に従うバックエンド２２０の詳細なブロック図である。バックエンド２２０は特定の機能を含むとして示されているが、バックエンド２２０は一例にすぎないということは理解されたい。その他の実施形態では、バックエンド２２０は、示された以外の追加の機能、より少ない機能、または異なる機能を含んでもよい。さらに、いくつかの実施形態では、記載された機能は複数の個別の要素に分離してもよいし、組み合わせてより少ない要素にしてもよい。

図示するように、バックエンド２２０は、キュー・テーブル２２１を含む。いくつかの実施形態では、キュー・テーブル２２１はバックエンド２２０に使用されて、フロントエンド・アプリケーションから受け取ったイベントを、データ・ストア２３０内のオブジェクトに配信されるまで保持する。いくつかの実施形態では、キュー・テーブル２２１はさらに、これらの要求を順序付けし、より効率的な処理を行うために使用される。

バックエンド２２０はさらに、いくつかのバッチ・テーブル２２２、２２３、２２４を含むとして示されている。複数のバッチ・テーブルを含むいくつかの実施形態では、フロントエンド・アプリケーションから受け取られたイベントおよびバックエンド２２０により生成されたイベントは、いくつかのバッチ・タイプに分類（sort）される。これらのバッチ・タイプの幾つかまたは全ては、バックエンド内のバッチ・テーブルに関連付けられていることができる。これらのバッチ・テーブルを使用して、イベントを処理するのに必要な追加の情報を保存することができる。その他の実施形態では、バッチ・テーブルを省略している。

図３は、キュー・テーブル２２１、バッチ・テーブル２２２〜２２４をバックエンド２２０の一部として示されているが、いくつかの実施形態では、これらのテーブルはバックエンド２２０にアクセス可能な任意の場所に保存されてもよい。例えば、これらのテーブルをデータ・ストア２３０内に格納してもよい。

図３はさらに、バックエンド２２０に接続されたデータ・ストア２３０を示す。データ・ストア２３０は、ワークフロー・タイプのオブジェクト、ワークフロー・オブジェクト２３１を収容しているとして示されている。

（イベントの効率的な順序付け）
システムの効率、特に要求を効率的に処理することは、実質的に、イベントがどのような順序でキュー・テーブルから対象とするオブジェクトに渡されるかによって決まる。いくつかの実施形態では、キュー・テーブルまたはその調整テーブルに対するインデックスは、この処理を速めるように順序付けされる。

キュー・テーブルの１つの手法は、イベントが処理されるべき時刻に基づいてそのテーブルを順序付けすることである。例えば、イベントがフロントエンドからバックエンドに渡されると、追加の要求される処理時間が生じることが多い。この処理時間は、要求に対する優先度、緊急度レベルを示すことができる。例えば、リアルタイムにバックエンドからのデータを求めるリアルタイム・アプリケーションは、イベントが早急に処理されることを要求するが、別の、非リアルタイムなフロントエンド・アプリケーションから受け取られたイベントは、緊急度が低く、したがってより長い利用可能な処理時間を有する。

いくつかの実施形態では、キュー・テーブルを順序付けする別の手法がとられている。いくつかのそのような実施形態では、キュー・テーブルまたはキュー・テーブルに対するインデックスは、バッチ・タイプにより順序付けされる。このようにして、特定のバッチ・タイプの全てのジョブが、一緒にグループ化され、その後一緒に処理される。同じバッチ内で処理されるオブジェクトのタイプに従ってキュー・テーブルを順序付けすることにより、これらの実施形態ではその他の手法では欠如している、あるレベルの効率性が得られる。

（新規イベントの監視）
イベント管理に対するキュー・テーブル手法に固有の１つの問題は、バックエンドが待機イベントを認識するが、種々のオブジェクトに対するイベント・ハンドラが一般に存在しないことである。いくつかの手法において、この問題は、キュー・テーブルをポーリングすることにより対処される。特定のオブジェクト用のイベント・ハンドラが、キュー・テーブルへのアクセス権が与えられ、イベント・ハンドラが担当するオブジェクトに向けられたイベントを、キュー・テーブル全体を通して、検索することになる。

いくつかの実施形態において、この問題は、イベントがキュー・テーブルに追加される際にイベントを監視することで、より良く対処できる。一実施形態では、例えば、バックエンドで実行中のワークアイテム・イベント・モニタは、イベントがキュー・テーブルに追加されるときにイベントを監視する。イベントが特定のバッチ・タイプ、例えばワークフロー・オブジェクトのイベントである場合、ワークアイテム・イベント・モニタは、このタイプの新規イベントが追加されたことを表示するシグナルまたはフラグを更新する。いくつかの実施形態では、このフラグは、特定のオブジェクト用のイベント・ハンドラに利用できる。

一実施形態においては、フラグは、簡単なブール（Boolean）タイプであり、このタイプの新規のイベントがあるか否かを表示する。その他の実施形態では、より複雑なフラグ・システムが利用される。

いくつかの実施形態において、新規のイベント・フラグが、適切なバッチ・タイプのバッチ・テーブルに配置され、例えば、新規ワークフロー・イベントを指し示す新規イベント・フラグが、ワークフロー・タイプ用のバッチ・テーブルの一部になる。その他の実施形態では、フラグはその他の場所に配置される。

（イベントのディスパッチ）
キュー・テーブルの手法により生じた別の問題は、イベントが適切なイベント・ハンドラに渡されたか否かをイベント・ディスパッチ機構がどのようにして判断するかである。いくつかの実施形態では、この問題に対処するのに使用される手法は、イベントをキュー・テーブル自身内でマーク付けすることである。

いくつかの実施形態では、イベント・ディスパッチ機構がキュー・テーブルを調べて、今実行されるべきワークアイテムを識別する。いくつかの実施形態では、このタスクは、上述の方法で、処理時間が期限切れになった処理時間を有する、または期限切れになりつつある処理時間を有する、特定のバッチ・タイプに関連する全てのワークアイテムを見つけることにより、達成される。このようにキュー・テーブルを調べることは、処理されていないイベントと、現在処理中のイベントとの両方を識別することになる。

異なるフロントエンド・マシーン上で実行する複数のイベント・ハンドラに重複イベントを渡すのを避けるために、現在処理中のイベントは、排除する必要がある。いくつかの実施形態では、これは、キュー・テーブル内のワークアイテムをタグ付けして、すでにイベント・ハンドラに渡されたことを示すことにより対処される。いくつかのそのような実施形態では、このタグ付けは、特定のイベントがすでに処理されたか否かを表示する簡単なブール・フラグの形式である。その他の実施形態では、例えば、イベントは、グローバル一意識別子またはＧＵＩＤの識別子でマーク付けされる。いくつかの実施形態では、イベントは追加の情報を伝達するような方法でマーク付けされる。別の実施形態では、その他の方法が、すでに適切なイベント・ハンドラに渡されたイベントを識別するのに、使用される。いくつかの実施形態では、この手法は、タグやマークの非存在が特定のイベントがすでに処理されたか否かを表示するという点で、逆になる。

いくつかの実施形態では、タグ付けされていないイベントは、処理するために選択された際にマーク付けされる。例えば、ワークフロー・タイプのイベントを処理すべきである場合、すでにタグ付けされたワークフロー・タイプのどのイベントも無視され、タグ付けされていないイベントがタグ付けされてイベント・ハンドラに渡される。例えば、ＳＱＬ環境のいくつかの実施形態では、これは２ステップ処理になる。まず、タグ付けされていないイベントがマーク付けされ、次に新しくタグ付けされたイベントが選択される。その他のデータ記憶装置環境を含むその他の実施形態では、このプロセスはより少ないステップか、または追加のステップが必要になる場合がある。

いくつかの実施形態では、処理が完了したとき、イベントはキュー・テーブルから削除されない可能性がある。この状況は、例えば、完全に完了するために、そのイベントが、その後にさらに処理が必要になるなどの、種々の理由から、生じる可能性がある。いくつかのそのような実施形態では、イベントの現在処理中の動作が完了すると、イベントが現在処理中であることを表示するタグが削除される。

（障害回復）
コンピューティング・アプリケーションに固有の関心事（concern）の１つは、障害回復である。本明細書で述べるように、バックエンド・サーバがキュー・テーブル内のイベントが原因で機能しなくなる場合、キュー・テーブルをリストアできるいくつかの手段を組み込むことは、回復プロセスに有益である。

いくつかの実施形態では、このワークアイテム・イベント・モニタは、そのような障害回復機構を組み込む。いくつかのそのような実施形態では、ワークアイテム・イベント・モニタは、システム障害を識別し、システムが安定であると認識されると、キュー・テーブルの前のバージョンに戻すことができる。

いくつかの実施形態では、このタスクは、フェイルオーバー・タイプのイベントをキュー・テーブルに追加することにより達成される。いくつかの実施形態では、このイベントはワークアイテム・イベント・モニタにより生成される。その他の実施形態では、このイベントの作成前に、その他の機構が対応することができる。フェイルオーバー・イベントはキュー・テーブルに追加され、所定の時間に、例えば、追加された時点から１５分で期限切れになるように設定される。いくつかの実施形態では、キュー・テーブルがタッチされたときは常に、例えば、キュー・テーブル内のワークアイテムが処理のために選択され、処理ＩＤでタグ付けされるときは常に、フェイルオーバーの期限切れ時間（expiration time）がリセットされる。

一方、いくつかのそのような実施形態では、フェイルオーバー保護モジュールはしばしば、例えば、５分ごとにキュー・テーブルを検査し、フェイルオーバー・イベントを観察する。期限切れになったフェイルオーバー・イベントが検出される場合、ワークアイテム・イベント・モニタは何らかのシステム障害が発生したと認識する。いくつかの実施形態では、システムは、フェイルオーバー保護モジュールが最後にキュー・テーブルのチェックに成功した時の状態に戻る。その他の実施形態では、システムは最後のフェイルオーバー・イベントがリセットされた時の状態に戻る。

いくつかの実施形態において、キュー・テーブルの最後のバッチが処理されたときにフェイルオーバー・イベントは削除される。その他の実施形態では、複数のフェイルオーバー・イベントは、それぞれ異なるバッチ・タイプに関連付けられて利用される。そのような実施形態では、新規のバッチがキュー・テーブルに入るときにフェイルオーバー・イベントが追加され、そのバッチの処理が完了されるときにフェイルオーバー・イベントは削除される。

時間の長さについて上記で例示したが、フェイルオーバー・イベントの期限切れ時間（expiration time）およびフェイルオーバー保護モジュールの動作頻度は、さまざまな実施形態によって異なることは理解されたい。いくつかの実施形態では、システム管理者がこれらのチェックが行われる頻度を判断できるなど、これらの時間は、ユーザが設定可能である。

（ワークアイテム・イベント・モニタ）
図４は、本発明に従うワークアイテム・イベント・モニタのブロック図を示す。ワークアイテム・イベント・モニタ４００は、具体的な方法で配置された具体的なコンポーネントを有するとして示されているが、ワークアイテム・イベント・モニタ４００は例示するためのものであって、排他的ではない。その他の実施形態では、ワークアイテム・イベント・モニタは、異なるコンポーネント、および／または異なる方法で配置されたコンポーネントを有する。

図示した実施形態において、ワークアイテム・イベント・モニタ４００は、バックエンド・サーバの一部として実行される。その他の実施形態では、ワークアイテム・イベント・モニタ４００は別の場所で実行することができる。

ワークアイテム・イベント・モニタ４００は、入力モジュール４１０を有するとして示されている。図示した実施形態において、入力モジュール４１０は、ワークアイテム・イベント・モニタ４００が、フロントエンド・アプリケーション、例えばフロントエンド２１０からイベントを受け取ることを可能にする。ワークアイテム・イベント・モニタ４００は、また出力モジュール４９０を有し、これは、いくつかの実施形態では、適切なイベント・ハンドラ、例えば、データ・ストア２３０内のオブジェクト、にイベントをディスパッチするのに使用される。

ワークアイテム・イベント・モニタ４００はさらに、キュー・テーブル４２０を有するとして示されている。キュー・テーブル４２０は、フロントエンド・アプリケーションから受け取られたイベントを、列にして待機させるのに使用される。ワークアイテム・イベント・モニタ４００はさらに、多数のバッチ・テーブル４２５ａ〜４２５ｎを有するとして示されている。これらのバッチ・テーブルを含むいくつかの実施形態では、特定のバッチ・タイプに関連付けられた各バッチ・テーブルは、そのバッチ・タイプのイベントの処理に関する情報を保存するのに使用される。

ワークアイテム・イベント・モニタ４００は、新規イベント・モニタ４３０を組み込み、これは、入力モジュール４１０から受け取った入力を監視し、新規イベントを識別する。ワークアイテム・イベント・モニタ４００は、図示するように、キュー順序付けモジュール４３５を含む。いくつかの実施形態では、キュー順序付けモジュール４３５は、効率を高めるようにキュー・テーブル４２０内のイベントを配列する。その他の実施形態では、キュー順序付けモジュール４３５は、キュー・テーブル４２０へのインデックス・ファイルを変更する。

ワークアイテム・イベント・モニタ４００はさらに、イベント・ディスパッチ・モジュール４４０を含む。イベント・ディスパッチ・モジュール４４０は、キュー・テーブル４２０にアクセスし、処理すべきイベントを識別する。図示するように、イベント・ディスパッチ・モジュール４４０は、いくつかのタイマー・ジョブ４４１ａ〜４４１ｎを組み込む。いくつかの実施形態では、各バッチ・タイプは、個別の関連付けられたタイマー・ジョブ４４１を有する。その他の実施形態では、異なる数のタイマー・ジョブ４４１が使用される。

ワークアイテム・イベント・モニタ４００はさらに、フェイルオーバー保護モジュール４５０を含む。フェイルオーバー保護モジュール４５０は、キュー・テーブル４２４の期限切れになったフェイルオーバー・イベントを監視する。

（ワークアイテム・イベント・モニタの操作）
図５は、一実施形態に従うワークアイテム・イベント・モニタの利用方法のフローチャート５００を示す。フローチャート５００では固有のステップを示しているが、このステップは例にすぎない。つまり、本発明の実施形態は、種々のその他の（追加の）ステップまたはフローチャート５００に示されたステップの変形を実行するのに適している。フローチャート５００のステップは提示されたのとは異なる順序で実行してもよく、必ずしもフローチャート５００の全てのステップを実行しなくてもよいことは理解されたい。

ステップ５１０と図２、４を参照すると、ワークアイテム・イベント・モニタが新規イベントを受け取る。例えば、フロントエンド２１０が、入力モジュール４１０により受け取られるイベントをバックエンド２２０にサブミットする。

ステップ５２０と図４を参照すると、新規イベント・フラグが更新される。いくつかの実施形態では、新規イベント・フラグは、受け取るワーク・アイテム・イベントのタイプに対応する。例えば、受け取られたイベントがワークフロー・タイプである場合、新規イベント・モニタ４３０は、ワークフロー・タイプに対応するバッチ・テーブル４２５内のフラグを更新する。

ステップ５３０と図４を参照すると、新規イベントがキュー・テーブルに追加される。例えば、新規イベント・モニタ４３０が受け取ったイベントをキュー・テーブル４２０に渡す。

ステップ５４０と図４を参照すると、キュー・テーブルはバッチ・タイプに基づいて順序付けされる。いくつかの実施形態では、同じバッチ・タイプで、同じまたは同じくらいの期限切れ時間（expiration time）を有する全てのイベントを一緒にグループ化する。例えば、ワークアイテム・イベント・モニタ４００が、それまでに期限切れ時間（expiration times）を有するワークフロー・タイプのいくつかのイベントを受け取った場合、これらのイベントは一緒に処理されるようにグループ化される。

ステップ５５０と図４を参照すると、イベントが処理のために選択される。いくつかの実施形態では、イベントはジョブのタイプと期限切れ時間（expiration time）に基づいてキュー・テーブルから選択される。いくつかのそのような実施形態では、現在処理中でないイベントのみが選択される、例えば、すでに処理中としてマーク付けされていないイベントのみが選択される。例えば、イベント・ディスパッチ・モジュール４４０は、ワークフロー・タイプのイベントで、処理中であるとしてすでにマーク付けされておらず、キュー・テーブル４２０からこれから実行するようにスケジューリングされた全てのイベント、を選択する。

いくつかの実施形態では、イベント選択は、タイマーによってトリガされる。いくつかのそのような実施形態では、複数のタイマーが利用され、特定のイベント・タイプは固有のタイマーを有してもよい。例えば、ワークフロー・タイプに関連付けられたタイマー・ジョブ４４１ａは、リセットしたり期限が切れたりするときには常にワークフロー・タイプのイベントの選択をトリガする。その他の実施形態では、単一のタイマーが利用される。いくつかの実施形態では、イベント選択はその他の方法によりトリガされる。

ステップ５６０と図４を参照すると、選択されたイベントが処理中であるとしてマーク付けされる。上述したように、種々の実施形態では、このステップは、多数のポイントで実装することができる。例えば、イベント・ディスパッチ・モジュール４４０は、キュー・テーブル４２０内の選択したワークフロー・イベントを、ＧＵＩＤでマーク付けすることにより識別する。

ステップ５７０と図４を参照すると、選択したイベントは適切なイベント・ハンドラに渡される。例えば、イベント・ディスパッチ・モジュール４４０により選択されたイベントは、処理するために出力モジュール４９０に渡される。

（フェイルオーバー保護の利用）
図６を参照すると、一実施形態に従うフェイルオーバー保護を利用することによる障害回復の方法のフローチャート６００が示される。フローチャート６００では、具体的なステップが示されているが、このステップは例にすぎない。つまり、本発明の実施形態は、種々のその他の（追加の）ステップまたはフローチャート６００に示されたステップの変形を実行するのに適している。フローチャート６００のステップは提示されたのとは異なる順序で実行してもよく、必ずしも全てのフローチャート６００のステップを実行しなくてもよいことは理解されたい。

ステップ６１０と図４を参照すると、フェイルオーバー・イベントがキュー・テーブルに追加される。上述したように、このイベントを追加するための機構はさまざまな実施形態によって異なる。いくつかの実施形態では、フェイルオーバー・イベントは、新規イベントがキュー・テーブルに追加されるときには常に追加される。その他の実施形態では、フェイルオーバー・イベントは、イベントの１つのバッチが処理するために選択されるときに追加される。例えば、新規イベントが入力モジュール４１０により受け取られ、新規イベント・モニタ４３０に渡され、キュー・テーブル４２０に追加され、そして複数のイベントがバッチ・テーブル４２５内で処理するために選択される時に、フェイルオーバー・イベントがキュー・テーブル４２０に追加される。

ステップ６２０と図４を参照すると、フェイルオーバー・イベントが更新される。上述したように、フェイルオーバー・イベントが、事前に設定された期限切れ時間（expiration time）を有して、キュー・テーブルに追加される。フェイルオーバー・イベントが期限切れになるまで放置される場合、これはシステムがなんらかの形で機能しなくなったことを指す。システムが正常に実行すると、フェイルオーバー・イベントは期限切れになる前に更新され、期限切れタイマーがリセットされる。いくつかの実施形態では、フェイルオーバー・イベントが関連付けられたイベント・タイプに対してキュー・テーブルがアクセスされると、フェイルオーバー・イベントは更新される。いくつかの実施形態では、上述したように、フェイルオーバー・イベント保護によりフェイルオーバー・イベントは更新される。

ステップ６３０と図４を参照すると、フェイルオーバー・イベントが削除される。いくつかの実施形態では、フェイルオーバー・イベントに関連したバッチの処理が完了したときにフェイルオーバー・イベントは削除される。いくつかのその他の実施形態では、キュー・テーブル内にイベントが残っていないときにこの削除が生じる。例えば、キュー・テーブル４２０がフェイルオーバー・イベントを除いて、空（empty）の時、そのフェイルオーバー・イベントが削除される。いくつかの実施形態では、この削除は、フェイルオーバー保護モジュール４５０により実行される。その他の実施形態では、このタスクはイベント・ディスパッチ・モジュール４４０により実行される。その他の実施形態では、その他の方法で、キュー・テーブルからフェイルオーバー・イベントが削除される。

各イベントのタイプが関連するフェイルオーバー・イベントを有する場合を含む、その他の実施形態では、フェイルオーバー・イベントは、キュー・テーブル内に、それに関連したイベント・タイプのイベントが何もないときに、削除される。

フローチャート６００で示すように、ステップ６５０、６６０、６７０はループされ、ステップ６２０と同時に実行される。その他の実施形態では、これらのステップを異なる順序で実行してもよい。

ステップ６５０と図４を参照すると、キュー・テーブルは、定期的に期限切れになったフェイルオーバー・イベントに対してチェックされる。例えば、フェイルオーバー保護モジュール４５０は、期限切れになったフェイルオーバー・イベントに対して５分ごとにキュー・テーブルをチェックしながら、キュー・テーブルを監視する。フェイルオーバー・イベントがキュー・テーブル内に存在し、期限切れになった場合、システムはイベントがキュー・テーブル内に残っていることを認識するが、最後のフェイルオーバー・イベントが更新されて以来、キュー・テーブルへのアクセスが成功することはない。

ステップ６６０と図４を参照すると、期限切れになったフェイルオーバー・イベントが発生しない場合、キュー・テーブルの今の状態が保存される。例えば、フェイルオーバー保護モジュール４５０は、キュー・テーブル４２０をチェックし、期限切れになったフェイルオーバー・イベントがないことを発見して、キュー・テーブル４２０の現在の状態は、正常であると認識されて、保存される。いくつかの実施形態において、キュー・テーブルの状態は、フェイルオーバー・イベントの更新が成功するたびにバックアップされる。例えば、処理時にキュー・テーブルがアクセスされる時は常に、フェイルオーバー・イベントが更新され、キュー・テーブルの現在の状態がバックアップされる。

ステップ６７０と図４を参照すると、期限切れになったフェイルオーバー・イベントがキュー・テーブル内に配置される場合、キュー・テーブルは保存された状態に戻る。例えば、フェイルオーバー保護モジュール４５０が、キュー・テーブル４２０内に期限切れになったフェイルオーバー・イベントを検出する場合、キュー・テーブル４２０は最後に保存した「正常な」状態、例えば、フェイルオーバー・イベントが更新された最後の状態に戻る必要がある。いくつかの実施形態では、ワークアイテム・イベント・モニタは、期限切れになったフェイルオーバー・イベントが検出された場合に追加の動作を実行する。

主題が、構造的特徴および／または方法論的な動作に固有の言葉で説明してきたが、請求の範囲で定義された主題は、必ずしも上述の具体的な特徴または動作に限定されないことは理解されたい。むしろ、上述した具体的な特徴および動作は、請求の範囲を実施する例示的な形態として開示されたものである。

実施形態を実装する例示的なコンピューティング・システムのブロック図である。 一実施形態に従うコンピューティング環境のブロック図である。 一実施形態に従うバックエンドのブロック図である。 一実施形態に従うワークアイテム・イベント・モニタのブロック図である。 一実施形態に従うワークアイテム・イベント・モニタの利用方法のフローチャートである。 一実施形態に従う障害回復方法のフローチャートである。

Claims (20)

1. イベント・タイプのプロパティを備えるイベントを受け取るステップ、
   前記イベント・タイプのプロパティに対応する新規イベント・フラグを更新するステップ、
   複数のイベントを含むキュー・テーブルに前記イベントを追加するステップ、
   前記キュー・テーブルから前記複数のイベントのうち１つまたは複数を選択して、選択したイベントのグループを得るステップ、および
   前記選択したイベントのグループが処理中であることを表示するために、前記選択したイベントのグループをマーク付けするステップと
   を含むことを特徴とするイベント・モニタの操作方法。
2. 前記イベント・タイプのプロパティに基づいて、前記キュー・テーブルを順序付けするステップをさらに含むことを特徴とする、請求項１に記載の方法。
3. 前記選択するステップは、前記イベント・タイプのプロパティを有する前記複数のイベントのうち１つまたは複数を識別するステップを含むことを特徴とする、請求項２に記載の方法。
4. 前記新規イベントは、期限切れ時間（expiration time）を備えることを特徴とする、請求項１に記載の方法。
5. 前記選択するステップは、設定された期限切れ時間（expiration time）を有する前記複数のイベントのうち１つまたは複数を識別するステップを含むことを特徴とする、請求項４に記載の方法。
6. 前記選択したイベントのグループを出力するステップをさらに含むことを特徴とする、請求項１に記載の方法。
7. 前記キュー・テーブルはＳＱＬテーブルを備えることを特徴とする、請求項１に記載の方法。
8. ステップを実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体であって、前記ステップは、
   期限切れタイマー（expiration timer）を備えるフェイルオーバー・イベントをキュー・テーブルに追加するステップ、
   前記キュー・テーブルの正常状態を保存するステップ、
   前記フェイルオーバー・イベントと前記期限切れタイマー（expiration timer）とを監視するステップ、および
   前記期限切れタイマー（expiration timer）が経過した場合、前記キュー・テーブルを前記正常な状態にリストアするステップ
   を含むことを特徴とするコンピュータ可読媒体。
9. 前記キュー・テーブルへのアクセスに成功した時に、前記期限切れタイマー（expiration timer）をリセットするステップをさらに含むことを特徴とする、請求項８に記載のコンピュータ可読媒体。
10. 前記キュー・テーブルの前記正常な状態を更新するステップをさらに含むことを特徴とする、請求項９に記載のコンピュータ可読媒体。
11. 前記正常な状態を更新するステップは、前記期限切れタイマー（expiration timer）のリセットに成功した時に発生することを特徴とする、請求項１０に記載のコンピュータ可読媒体。
12. 前記監視するステップは、定期的に前記キュー・テーブルにアクセスするステップを含むことを特徴とする、請求項８に記載のコンピュータ可読媒体。
13. 前記フェイルオーバー・イベントを追加するステップは、前記キュー・テーブルからのイベントの処理に応答して行うことを特徴とする、請求項８に記載のコンピュータ可読媒体。
14. 前記処理が完了した時に、前記キュー・テーブルから前記フェイルオーバー・イベントを削除するステップをさらに含むことを特徴とする、請求項１３に記載のコンピュータ可読媒体。
15. 待機イベントを保存するためのキュー・テーブル、
    前記待機イベントを前記キュー・テーブルに追加したことを検出するための、前記キュー・テーブルに結合された新規イベント・モニタ、
    前記待機イベントが前記キュー・テーブルに追加されたことを指し示すための、前記新規イベント・モニタに結合された、新規イベント・フラグ、および
    前記キュー・テーブルから前記待機イベントを選択するための、前記キュー・テーブルに結合されたイベント・ディスパッチャ
    を備えることを特徴とする、ワークアイテム・イベント・モニタ。
16. 前記待機イベントは、イベント・タイプを備えることを特徴とする、請求項１５に記載のワークアイテム・イベント・モニタ。
17. 前記イベント・ディスパッチャは、前記イベント・タイプに基づいて、前記キュー・テーブルから前記待機イベントを選択することを特徴とする、請求項１６に記載のワークアイテム・イベント・モニタ。
18. 前記新規イベント・フラグを収容するための、前記新規イベント・モニタに結合された、バッチ・テーブルをさらに備えることを特徴とする、請求項１５に記載のワークアイテム・イベント・モニタ。
19. 前記イベント・ディスパッチャは、前記待機イベントを選択すべき時間を指し示すタイマーをさらに備えることを特徴とする、請求項１５に記載のワークアイテム・イベント・モニタ。
20. 前記ワークアイテム・イベント・モニタ内の障害を検出するための、前記キュー・テーブルに結合された、フェイルオーバー保護モニタをさらに備えることを特徴とする、請求項１５に記載のワークアイテム・イベント・モニタ。

Images