JP5065259B2 - 企業情報システムとクライアントとの間の通信に役立つ装置、システム、方法、およびコンピュータプログラム（企業情報システムとクライアントとの間の通信に役立つ装置、システム、および方法） - Google Patents

Description

本発明は、企業情報システム（ＥＩＳ）とクライアントとの間の通信に役立つ装置、システム、および方法に関し、特に、複数のクライアントへのＥＩＳイベントの配信を保証する装置、システム、および方法に関する。

今日のビジネスの世界では、膨大な量の情報が生成されている。この情報はビジネスの成功に不可欠であり、ビジネスの最も価値ある商品であり得る。情報は、ビジネスのオペレーションユニットにより処理、記憶、更新、および共有されなければならない。例えば、製造業者は、営業所、サポートスタッフ、供給業者、配給業者、および他の各種エンティティと情報を共有できなければならない。その結果、多くのビジネスは、中央に配置でき、ビジネスに関連する誰もがアクセス可能な情報ストレージシステムを利用している。このような１つの情報システムが企業情報システム（ＥＩＳ：Ｅｎｔｅｒｐｒｉｓｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）である。ビジネスは、１つまたは複数のＥＩＳにアクセスするいくつかのサブエンティティまたは「クライアント」を有し得る。

多くの場合、処理ロジックを含むソフトウェアが、ＥＩＳとクライアントシステムとの間の通信を管理するために利用される。このソフトウェアまたはコードは一般にアダプタに常駐し、ＥＩＳ間の接続構築を支援する。アダプタは、ＥＩＳとの双方向通信を可能にする。これにより、クライアントはデータの照会または変更等のＥＩＳ内部でのオペレーションを実行することができる。こういったオペレーションはアウトバウンド通信と呼ばれることもある。アダプタは、クライアントがＥＩＳからデータを受信できるように、またはＥＩＳ内の変更に気づくことができるようにもする。

通常、インバウンド通信は、ＥＩＳ内部で作成または変更されたビジネスデータについての情報を含む。ＥＩＳ内での情報の作成、変更、更新、または削除はＥＩＳイベントと呼ばれる。多くの場合、サブエンティティまたはクライアントのすべてが同じＥＩＳイベントを受信することがビジネスにとって重要である。ビジネスは、各部門に矛盾したデータセットを使用してオペレーションを行って欲しくない。ビジネスは、クライアントシステム間でデータを同期させたい。ビジネスはまた、データの整合性を保つために、ＥＩＳイベントの複数のコピーをクライアントシステムに送信したくない。データに複数のコピーがあると、混乱およびデータの信頼性の欠如を招く恐れがある。さらに、余分なデータがスペースを占有し、多くの場合、このコストは高くつく。

大半のアダプタの１つの問題は、クライアントへのイベントの配信を保証しないことである。例えば、メッセージベースシステム等のパブリッシャ／サブスクライバシステムでは、情報がパブリッシャにより提供され、サブスクライバはその情報にアクセスすることができる。しかし、サブスクライバクライアントがオフラインの場合、または他の理由で応答しない場合、クライアントサブスクライバはその更新を見逃す。大半のパブリッシャプログラムは見逃された情報を応答していないクライアントに後に提供する機能を有していない。大半のパブリッシャプログラムは、サブスクライバが更新を見逃したことを知りさえもしない。

いくつかのアダプタに伴う別の問題は、クライアントが所与のイベントの唯一のコピーの受信を保証しないことである。こういったアダプタは、特定のデータを特定の時間にブロードキャストまたは転送するようにプログラムされ、クライアントまたはエンドユニットがそのイベントをすでに受信しているか否かを考慮しない。多くのアダプタに伴うさらに別の問題は、イベントを複数のクライアントに送信する間に任意の個々のクライアントの状態を考慮しないことである。このため、マルチクライアントシステム内のクライアントは、データ転送に関する限り、その他のクライアントとの同期を失う可能性が高い。

多くのアダプタに伴う別の問題は、イベント処理中に予期せぬ問題が発生した場合にイベントが失われるのを防ぐためのリカバリプロトコルを有さないことである。多くの現在のアダプタに伴うさらに別の問題は、クライアントを動的に追加または削除できないことである。クライアントが応答しなくなる（オフラインになるか、または他の理由により利用できなくなる）と、アダプタによってはもはやイベントをそういったクライアントに送信することができなくなるものがある。

上記考察から、クライアントへのＥＩＳイベントの配信を保証する、ＥＩＳと１つまたは複数のクライアントとの間の通信に役立つ装置、システム、および方法を提供することが当分野における進歩であることが明らかなはずである。各クライアントに１度だけイベントを送信するような装置、システム、および方法を提供することが当分野におけるさらなる進歩である。１つまたは複数のクライアントが利用できなくなった後であってもイベントを追跡するような装置、システム、および方法を提供することが当分野におけるさらなる進歩である。このような装置、システム、および方法を本明細書において開示し、特許請求する。

本発明は、当分野の現状に応えて、特に企業情報システム（ＥＩＳ）とクライアントとの間で通信する現在利用可能な装置、システム、および方法によりまだ完全には解決されていない当分野における問題および必要性に応えて開発された。したがって、本発明は、当分野での上記欠点の多くまたはすべてを解消するような装置、システム、および方法を提供するために開発された。

ＥＩＳと１つまたは複数のクライアントとの間の通信に役立つ装置に、イベントを求めてＥＩＳをポーリングするのに必要なステップ、イベントをクライアントに配信する準備としてイベントをステージングするのに必要なステップ、およびイベントが配信されたか否かを確認するのに必要なステップを機能的に実行するように構成される複数のモジュールを含む論理装置を提供することができる。説明する実施形態でのこれらモジュールは、ポーリングモジュール、ステージングモジュール、配信モジュール、および確認モジュールを含む。

一実施形態では、アダプタは、イベントがクライアントに送信された後、そのイベントをＥＩＳから除去するのに役立つ除去モジュールも含む。装置は、ＥＩＳイベントの受信に利用できなくなった、永続サブスクライバとして指定されたクライアントに対してイベントを保持するようにさらに構成される。一実施形態では、装置は、利用できなくなったクライアントが再び利用できるようになったときに保持されていたイベントを再配信するように構成される。

装置は、トランザクションサービスを使用して、イベントを１つまたは複数のクライアントに配信し、イベントが配信されたことを確認することができる。一実施形態では、トランザクションサービスは、ＸＡに準拠して配信されるトランザクションの一部としてイベントを配信する。

装置は、ＥＩＳ、１つまたは複数のクライアント、およびデータソースを含み、イベントのステージングおよび配信にむけてのイベントの準備に役立つシステムで具現することもできる。一実施形態では、データソースはＸＡ準拠データベースである。システムは装置によるトランザクションサービスの使用に役立つＸＡトランザクションマネージャを含むこともできる。一実施形態では、クライアントは、１つまたは複数のサブシステム、計算装置、またはエンドポイントを含むことができる。クライアントは装置に直接接続することができ、ＥＩＳイベントはまずクライアントに配信し、次にクライアントサブシステムに渡すことができる。本開示では、クライアントおよびそのサブシステム、計算装置、エンドポイント、または他の「ダウンライン」装置は、個々に、また集合的に「クライアント」と呼ばれる。

ＥＩＳと１つまたは複数のクライアントとの間の通信に役立つ本発明の方法が提示される。開示する実施形態での方法は、実質的に、上記装置およびシステムの動作に関して上に提示した機能の実行に必要なステップを含む。一実施形態では、方法は、イベントを求めてＥＩＳをポーリングするステップ、クライアントへの配信準備としてイベントをステージングするステップ、イベントを配信するステップ、およびイベントが配信されたか否かを確認するステップを含む。本明細書において開示する方法ステップは、コンピュータプログラムのコンピュータ可読コードにより実行される動作として具現することもできる。

ＥＩＳを顧客の１つまたは複数のクライアントシステムと統合する方法も開示される。この方法は、統合要件セットを受信するステップ、ＥＩＳおよび複数のソフトウェアクライアントを接続するように構成された統合アダプタを構築するステップ、統合アダプタを顧客に配信するステップ、および統合アダプタをセットアップするステップを含むことができる。一実施形態では、統合アダプタは上記装置である。統合アダプタをセットアップするステップは、各クライアントをＥＩＳからのイベント受信に登録するステップを含むことができる。アダプタをセットアップするステップは、イベントを求めてＥＩＳをポーリングする頻度および配信前にステージングするイベントの数量を判断するステップを含むこともできる。

クライアントへのイベントの配信が一度だけであることを保証する、企業情報システム（ＥＩＳ）を複数のソフトウェアクライアントに統合するように構成されるコンピューティングインフラを導入する方法も開示される。一実施形態では、この方法は、複数の拡張可能モジュールを有するソフトウェアツールキットを開発するステップ、トランザクションサービスをソフトウェアツールキットに統合するステップ、およびソフトウェアツールキットを発行するステップを含む。拡張可能モジュールは上記装置の拡張可能モジュールを含むことができる。一実施形態では、モジュールは、イベントを求めて少なくとも１つのＥＩＳをポーリングし、少なくとも１つのクライアントへの配信に向けてイベントをステージングし、イベントを少なくとも１つのクライアントに配信し、イベントの１つだけのインスタンスが各クライアントに配信されたことを確認するように構成される。

本明細書全体を通しての特徴、利点、または同様の言葉への言及は、本発明を使用して実現できるその特徴および利点のすべてが、本発明の任意の一実施形態にあるべきである、またはあることを意味するものではない。むしろ、特徴および利点に言及する言葉は、一実施形態に関連して説明される特定の特徴、利点、または特徴が本発明の少なくとも１つの実施形態に含まれることを意味するものと理解される。したがって、本明細書全体を通しての特徴および利点の考察ならびに同様の言葉は、同じ実施形態を指し得るが、そうである必要はない。

さらに、説明する本発明の特徴、利点、および特徴は、１つまたは複数の実施形態において任意の適した様式で組み合わせることができる。本発明が特定の実施形態の特定の特徴または利点のうちの１つまたは複数なしで実施可能なことを当業者は認めよう。場合によっては、特定の実施形態において、本発明のすべての実施形態に存在しなくてもよい追加の特徴および利点を認めることができる。

本発明のこういった特徴および利点は、以下の説明および添付の特許請求の範囲からより完全に明らかになるか、または、以下説明する本発明の実施により学習することができる。

本発明の好ましい実施形態を、添付図面を参照して単に例として以下に説明する。
本明細書において説明する機能ユニットの多くは、実施独立性を特に強調するためにモジュールと記されている。例えば、モジュールは、カスタムＶＬＳＩ回路またはゲートアレイを含むハードウェア回路、論理チップ、トランジスタ等の市販の半導体、または他の離散構成要素として実施することができる。モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブル論理装置等のプログラマブルハードウェア装置で実施することもできる。

モジュールは、各種のプロセッサにより実行されるソフトウェアで実施することもできる。例えば、実行可能コードの識別されているモジュールは、例えば、オブジェクト、プロシージャ、または関数として編成できるコンピュータ命令の１つまたは複数の物理的または論理的なブロックを含む。それにも関わらず、識別されたモジュールの実行可能コード（ｅｘｅｃｕｔａｂｌｅ）は物理的に共に配置される必要はなく、論理的に統合されるとモジュールを構成し、モジュールの規定の目的を実現する、異なる場所に記憶された異なる命令を含むことができる。

実際に、実行可能コードのモジュールは１つの命令であってもよく、または多くの命令であってもよく、さらにはいくつかの異なるコードセグメント、異なるプログラム、およびいくつかのメモリ装置に分散してもよい。同様に、本明細書ではオペレーションデータはモジュール内で識別して示すことができ、任意の適した形態にて具現することができ、任意の適した種類のデータ構造内に編成することができる。オペレーションデータは、１つのデータセットとして集められてもよく、または異なる記憶装置を含む異なるロケーションに分散し、かつ少なくとも部分的に、システムもしくはネットワーク上の単なる電気信号として存在してもよい。

本明細書全体を通しての「一実施形態」、「実施形態」または同様の言葉への言及は、その実施形態に関係して説明される特定の特徴、構造、または特性が本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書全体を通しての語句「一実施形態では」、「実施形態では」、および同様の言葉の出現は、すべて同じ実施形態を指し得るが、必ずしもそうである必要はない。

本発明の実施形態は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはハードウェア要素およびソフトウェア要素の両方を含む実施形態の形態をとることができる。好ましい実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコード等を含むがこれらに限定されないソフトウェアで実施される。

さらに、本発明の実施形態は、コンピュータまたは任意の命令実行システムにより使用されるか、またはこれと関係して使用されるコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセス可能なコンピュータプログラムの形態をとることができる。この説明では、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスにより使用されるか、またはこれと関係して使用されるプログラムの収容、記憶、通信、伝搬、または搬送を行うことができる任意の装置であることができる。

媒体は、電気、磁気、光学、電磁、赤外線、または半導体のシステム（または装置もしくはデバイス）あるいは伝搬媒体であることができる。コンピュータ可読媒体の例としては、半導体または固体状態メモリ、磁気テープ、リムーバブルコンピュータディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛体磁気ディスク、および光ディスクが挙げられる。光ディスクの現在の例としては、コンパクトディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが挙げられる。

プログラムコードの記憶または実行、あるいはこれら両方に適したデータ処理システムは、システムバスを通してメモリ要素に直接または間接的に結合された少なくとも１つのプロセッサを含む。メモリ要素は、プログラムコードの実際の実行中に利用されるローカルメモリ、大容量記憶装置、および実行中にコードを大容量記憶装置から検索しなければならない回数を低減するために少なくともいくつかのプログラムコードの一時的な記憶を提供するキャッシュメモリを含むことができる。

入出力またはＩ／Ｏ装置（キーボード、ディスプレイ、ポインティングデバイス等を含むが、これらに限定されない）は、直接、または介在するＩ／Ｏコントローラ通してシステムに結合することができる。ネットワークアダプタもシステムに結合して、データ処理システムを、介在する私設ネットワークまたは公衆ネットワークを通して他のデータ処理システムまたは遠隔プリンタまたは記憶装置に結合できるようにする。モデム、ケーブルモデム、およびイーサネット（登録商標）カードが、現在利用可能な種類のネットワークアダプタのほんの数例である。

図１は、本発明の好ましい実施形態によるシステム１００を示す。システム１００は、企業情報システム（ＥＩＳ）１０２および１つまたは複数のクライアント１０４を含む。装置またはアダプタ１０６はＥＩＳ１０２およびクライアント１０４と通信して、ＥＩＳ１０２とクライアント１０４との間での情報の伝送に役立つ。

アダプタ１０６は、トランザクションサービス１１０を含むＪ２ＥＥコネクタアーキテクチャコンテナ１０８内で動作することができる。Ｊ２ＥＥコネクタアーキテクチャは、アダプタ１０６がＥＩＳ１０２と対話できるようにする。一実施形態では、Ｊ２ＥＥコネクタアーキテクチャは、ＥＩＳ１０２とアダプタ１０６との関係を支配するインタフェースを定義する。このインタフェースは、接続、トランザクション、およびセキュリティの管理に関連するものとしてアダプタ１０６とＥＩＳ１０２との対話を判断する。

ＥＩＳ１０２は、メインフレームトランザクション処理システム、企業リソース計画システム、レガシー非Ｊａｖａ（登録商標）アプリケーション等であることができる。一実施形態では、ＥＩＳ１０２はデータベース管理システムである。ＥＩＳ１０２は、アダプタ１０６とインタフェースするように構成される。一実施形態では、インタフェースはＪ２ＥＥコネクタアーキテクチャコントローラ１０８と通信できるようにＪａｖａ（登録商標）コードで書かれる。

ＥＩＳ１０２において変更が発生した場合、アダプタ１０６はその変更を各クライアント１０４にブロードキャストまたは通信する。本明細書では、このような変更をイベント１１２と呼ぶ。クライアント１０４へのイベント１１２のブロードキャストはインバウンドイベントとも呼ばれることが当業者に理解されよう。イベント１１２は、データ変更、エラーメッセージ、タイムスタンプ変更、ロケーション変更、更新等を含むがこれらに限定されない、ＥＩＳに含まれる任意の情報であることができる。ＥＩＳがデータベースである一実施形態では、イベント１１２は、データベース変更、テーブル行変更、顧客アドレス変更等であることができる。別の実施形態では、イベント１１２は、顧客アドレス変更、顧客ＩＤ変更であることができる。イベント１１２は、ＥＩＳ１０２とクライアント１０４との間で通信する必要がある任意の種類の情報であることができる。イベント１１２は、ＥＩＳ内の永続記憶装置に配置することができる。

一実施形態では、イベント１１２は構造化され、クライアントによる使用に向けて準備される。本開示では、任意の様式でのクライアント１０４によるイベント１１２の使用をイベントの消費と呼ぶことがある。上述したように、イベント１１２の最終的な消費は、クライアント、クライアントのサブシステム、計算装置、エンドポイント、または他の「ダウンライン」装置によるものであることができる。

アダプタ１０６は、ＸＡデータソース１１４とも通信する。アダプタ１０６は、ＸＡデータソース１１４内のステージングテーブル１１６を利用することができる。一実施形態では、ステージングテーブル１１６は、ＸＡ準拠のデータベースであり、トランザクションサービス１１０と通信することができる。一実施形態では、ステージングテーブル１１６は、市販の第三者データベース管理ソフトウェア内のテーブルである。

イベント１１２がＥＩＳ１０２内で検出されると、アダプタ１０６は、利用可能な各クライアント１０４のステージングテーブル１１６にイベント１１２へのリファレンス１１８を書き込む。本開示では、クライアントは、応答している、オンラインである、アクティブである、リッスンしている、また受信したイベントに適宜機能している場合に「利用可能」である。リファレンス１１８は、イベントＩＤ１１９およびエンドポイントＩＤ１２１を含む。リファレンス１１８ａ〜１１８ｃ内のイベントＩＤ１１９ａ〜１１９ｃは、１つのイベント１１２への各リファレンス１１８内で同じであることができる。しかし、クライアントＩＤ１２１ａ〜１２１ｃは、各クライアントまたはクライアントエンドポイントに固有である。上述したように、クライアントリソースは、追加のリソース、サブクライアント、サブシステム等を有することができる。各リファレンス１１８は特定のエンドポイントＩＤを含む。各クライアントはイベント１１２を必要とするサブシステムを有し得るが、プライマリクライアント（またはエンドポイント）１０４ａのみがステージングテーブル１１６内で参照される。クライアント１２１ａがこのようなサブシステム１２０、１２２を含む場合、クライアント１０４ａはこれらサブシステムへのイベントのルーティングを担当する。

イベント１１２のその他の識別特徴がリファレンス１１８の一部であってもよいことが当業者に理解されよう。例えば、イベントの一部またはすべては、ステージングテーブル１１６内にリファレンス１１８として記憶することができる。さらに、リファレンス１１８はタイムスタンプまたは他の情報を含むこともできる。

次に、ステージングテーブル１１６内の各イベント１１２が、トランザクションサービス１１０により対応するリッスン中のクライアント１０４に配信される。一実施形態では、アダプタ１０６は、トランザクションサービス１１０の協力を得て、Ｊ２ＥＥアプリケーションサーバにより制御される一意のトランザクションの一部としてイベント１１２を対応するクライアント１０４に配信する。各クライアント１０４ａ、１０４ｂ、および１０４ｃ、またはクライアントラインは、それぞれのトランザクションを受信する。

トランザクションサービス１１０により生成されるトランザクションは、すべてのアクションが実行されるか、またはまったく実行されないかのいずれかである１つの作業論理単位として実行される一連のアクションである。これらトランザクションは「論理」または「単純」トランザクションと呼ばれることもあることが当業者に理解されよう。一実施形態では、トランザクションは原子動作である。原子動作が、１つのステップで行われ、中断できない動作であることが当業者に理解されよう。トランザクション中にクライアント１０４内で行われた変更は、暫定的である。変更を永久的にするために、トランザクションは変更を確定する「コミット」動作で終わる。

任意の変更をコミットすることができない場合、トランザクションは「ロールバック」し、トランザクションが行われなかったかのように変更をすべて取り消す。アクションを実行中の任意の１つのクライアント１０４内のコードが、コミットしないと判断した場合、またはコミットを首尾良く行うことができない場合、クライアント１０４はトランザクションをロールバックして、その特定のクライアント１０４のアクションを取り消さなければならない。アプリケーションがトランザクションの最中にクラッシュした場合、再開時に、トランザクションリカバリプロセスがオープントランザクションをロールバックする。書き込みトランザクションでは、すべての変更をすべてコミットするか、またはすべてロールバックしなければならない。読み出しトランザクションでは、コミットする変更はないが、すべての読み取りが完了するまで、読み取り中のデータが変更されないようにする。

一実施形態では、トランザクションサービス１１０は、イベント１１２を分散トランザクションの一部として配信する。分散トランザクションは、個々の各クライアント１０４のサブシステムまたは「ダウンライン」システムを考慮している。例えば、クライアント１０４ａは２つ以上の独立したトランザクションリソースクライアントＡ’１２０およびクライアントＡ’’１２２を有し得る。これらは、例えば、２つの別個のデータベースを含み得る。トランザクションを首尾良くコミットするには、特定のクライアント１０４ａの個々のリソース１２０、１２２のすべてが首尾良くコミットしなければならない。クライアント１０４ａのダウンラインシステムクライアントＡ’１２０、クライアントＡ’’１２２のいずれかへのイベント１１２の配信が成功しない場合、トランザクションをすべてのリソースクライアントＡ’１２０、クライアントＡ’’１２２のすべてでロールバックしなければならない。

一実施形態では、トランザクションサービス１１０は、「２フェーズコミット」を利用して、イベント１１２をクライアント１０４に配信する。２フェーズコミットとは、分散トランザクションを２ステップでコミットする方法である。第１のステップにおいて、各リソース１０４、１２０、および１２２が、コミットの準備ができたか否かについて投票する。例えば、クライアント１０４ａに関連するリソースの場合、クライアントＡ１０２、クライアントＡ’１２０、およびクライアントＡ’’１２２のグループが、コミットする準備ができたか否かを判断する。ステップ２において、すべてのリソース１０２、１２０、および１２２の準備ができた場合、一度にすべてコミットする。グループコミット後、対応するリファレンス１１８ａがステージングテーブル１１６から削除され、クライアント１０２ａへのイベント１１２の配信をもはやロールバックすることはできない。２フェーズコミットにより、トランザクションコミット中にシステムの部分がクラッシュした場合であっても、分散トランザクションを常にコミットできるか、または常にロールバックできることが保証されることが当業者に理解されよう。各クライアント１０４ａ、１０４ｂ、および１０４ｃはそれぞれのトランザクションを受信するため、トランザクションサービス１１０が、クライアントＡ’１２０がイベント１１２を受信しなかったと判断した場合、ステージングテーブル１１５内でのイベント１１２配信のロールバックは、イベント１１２のクライアントＢ１０４ｂおよびクライアントＣ１０４ｃへの配信に影響しない。したがって、クライアントＢおよびＣ１０４ｂ、１０４ｃは、クラッシュがクライアントＡライン内で発生した場合であってもイベント１１２を利用または消費することができる。

一実施形態では、トランザクションサービス１１０は、ＸＡ仕様に合ったトランザクションでイベント１１２をクライアント１０４に配信する。ＸＡ仕様は、オープングループにより定められる分散トランザクション処理（ＤＴＰ：Ｄｉｓｔｒｉｂｕｔｅｄ ｔｒａｎｓａｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ）から利用可能である。

一実施形態では，ＸＡ仕様は、アダプタ１０６がトランザクションサービス１１０をどのように使用して、複数のリソース１０４、１２０、および１２２にわたる分散トランザクションを調整するかを規定する。一実施形態では、アダプタ１０６は、ＸＡ分散トランザクションを使用してＥＩＳ１０２と１つまたは複数のクライアント１０４との間でのイベントの配信を促進する。

これより図２を参照して、本発明の好ましい実施形態による装置またはアダプタ１０６を示す。アダプタ１０６は、イベントストア２０２、イベントマネージャ２０４、およびイベント分散モジュール２０６を含む。イベントマネージャ２０４は、イベントマネージャ２０４の制御を実行するコントローラ２０８を含むことができる。イベントマネージャ２０４は、イベント１１２を求めてのＥＩＳ１０２の一定間隔でのポーリングに役立つタイマ２１０を含むこともできる。イベントマネージャ２０４は、トランザクションサービス１１０とインタフェースするためのトランザクションマネージャ２１２を含むこともできる。

イベントストア２０２は、アダプタ１０６とＥＩＳ１０２との間のインタフェースとして機能する。ＥＩＳ１０２内で発生したイベント１１２は、イベントストア２０２に記憶することができる。一実施形態では、検出されたイベント１１２の記録がイベントストア２０２に記憶される。イベント１１２の詳細をＥＩＳ１０２に残すことができる。アダプタ１０６はイベントストア２０２を定期的にポーリングし、その中の情報を使用して関心のあるクライアント１０４に配信するデータへの変更を反映したイベントを構築する。一実施形態では、イベントストア２０２は、アダプタ１０６がＥＩＳ１０２との対話を実施するために使用するＪａｖａ（登録商標）コードで表される。イベントストア２０２は、ＥＩＳ１０２内のデータ構造およびアダプタ１０６内の処理ロジックを含むことができる。イベントストア２０２は、汎用タスクまたは「全イベントの生成」等のコマンドを実行するように構成される。イベントストア２０２は、このようなコマンドを１つまたは複数のＥＩＳコマンドに変換して、ＥＩＳ１０２内でコマンドを実際に実行する。したがって、イベントマネージャ２０４を任意の所与のＥＩＳ１０２に向けてカスタマイズする必要がない。

一実施形態では、イベントストア２０２は、ＥＩＳ１０２から受信する各イベント１１２についての情報を含む。イベントストア２０２は、イベント１１２のＩＤすなわち「イベントＩＤ」を含むことができる。イベントＩＤ１１９は、イベントマネージャ２０４がイベントストア２０２を通して任意の所与のイベント１１２にアクセスできるようにする鍵と考えることができる。一実施形態では、イベントＩＤ１１９は各イベント１１２に一意である。イベントストア２０２は、イベント１１２が発生したＥＩＳオブジェクトまたは全体のイベント１１２自体の鍵を含むこともできる。イベントストア２０２は、イベントが発生したオブジェクト型を含むこともできる。一実施形態では、イベントストア２０２は各イベント１１２の配信状態２０７を含む。一実施形態では、状態２０７は定数であり、以下のフラグのうちの１つを含む。
ＮＥＷ＿ＥＶＥＮＴ
ＩＮ＿ＰＲＯＧＲＥＳＳ
ＥＲＲＯＲ

状態２０７が各イベント１１２の現在の状態を説明する任意の数のアイテムまたは名称を含んでもよいことが当業者に理解されよう。

イベント分散モジュール２０６は、ＸＡデータソース１１４へのインタフェースである。イベント分散モジュール２０６により、イベントマネージャ２０４はＸＡデータソース１１４にアクセスすることができる。一実施形態では、イベント分散モジュール２０６はデータベースまたはデータベーステーブルである。イベント分散モジュール２０６が、ステージングテーブル１１６の構成に関わりなくイベントマネージャ２０４がステージングテーブル１１６と対話できるようにする、ＸＭＬファイルまたはフラットファイルを含む任意のデータ構造、コード、またはモジュールであってもよいことが当業者に理解されよう。一実施形態では、イベント分散モジュール２０６は、クライアントＩＤ１２１およびイベントＩＤ１１９を含む。

イベントマネージャ２０４は、イベントストア２０２を通してイベント１１２を検出するタスク、イベント分散モジュール２０６を通してイベント１１２をステージングテーブル１１４に書き込むまたはステージングするタスク、およびイベント１１２を１つまたは複数のクライアント１０４に配信するタスクを管理する。

センダ２１４は、イベントマネージャ２０４の一部を構成することができる。一実施形態では、イベントマネージャ２０４は、イベント１１２が配信されるあらゆるクライアント１０４にセンダ２１４を作成する。イベントマネージャ２０４は、センダ２１４を通して、個々の各イベント１１２を複数のクライアント１０４に送信することを担当する。センダ２１４は、複数のクライアント１０４と通信するフォーキング（ｆｏｒｋｉｎｇ）機能を提供する。

図３は、アダプタ１０６内のイベントマネージャ２０４として具現される装置３００を示す。別法として、装置３００は、アダプタ１０６自体として具現することもできる。装置３００は、イベント１１２を求めて少なくとも１つのＥＩＳ１０２をポーリングするように構成されるポーリングモジュール３０２を含む。装置３００は、少なくとも１つのクライアント１０４への配信に向けてイベント１１２をステージングするように構成されるステージングモジュール３０４も含む。装置３００は、イベント１１２を少なくとも１つのクライアント１０４に配信するように構成される配信モジュール３０６を含む。装置３００は、イベント１１２の１つだけのインスタンスが少なくとも１つの各クライアント１０４に配信されることを確認するように構成される確認モジュール３０８を含むこともできる。一実施形態では、装置３００は、消費されたイベント１１２をＥＩＳ１０２から除去するのに役立つ除去モジュール３１０を含む。

ポーリングモジュール３０２は、クライアント１０４に配信するイベント１１２を求めてＥＩＳ１０２を定期的に照会するように構成される。ポーリングモジュール３０２は、ユーザ構成パラメータに基づくポーリングを可能にすることができる。一実施形態では、パラメータは、ポーリングモジュール３０２がイベント１１２を求めてＥＩＳ１０２をポーリングするレートまたは頻度である。パラメータは、１つまたは複数のクライアント１０４に配信する前にステージングするイベント１１２の数量を含むこともできる。一実施形態では、ポーリングモジュール３０２は、イベント１１２がＥＩＳ１０２内で発生したことをポーリングモジュール３０２に警告する指定のトリガを探す。別法として、イベントストア２０２内に記録があることで、イベント１１２が発生したことを通知することができる。ポーリングモジュール３０２は、クライアント１０４がイベント１１２の受信に先立って利用可能ではなかったため保持されていたイベント１１２をリリースする準備ができたか否かを判断することもできる。ポーリングモジュール３０２は、新規クライアントがイベント１１２の受信に利用可能であるか否かを判断することもできる。一実施形態では、イベントマネージャ２０４は、新規クライアントをイベント受信に登録する。ポーリングモジュール３０２は、ポーリングステップおよび図４〜図６に関連してさらに考察する動作を実行するように構成される。

ステージングモジュール３０４は、少なくとも１つのクライアント１０４への配信に向けてイベント１１２をステージングするように構成される。ステージングモジュール３０４は、イベント１１２へのリファレンス１１８を、イベント受信に登録されている少なくとも１つのクライアントのそれぞれのステージングテーブル１１６に書き込むことができる。ステージングモジュール３０４は、各イベント１１２の配信状態２０７を調整することもできる。リファレンス１１８がステージングテーブル１１６に追加され、状態が設定されると、イベント１１２がステージングされる。

配信モジュール３０６は、イベント１１２を１つまたは複数のクライアント１０４に配信するように構成される。上述したように、「クライアント」なる用語は、クライアントの下位構成要素、中間構成要素、またはエンドポイントをすべて含む。一実施形態では、配信モジュール３０６は、Ｊ２ＥＥアプリケーションサーバと協働する。配信モジュール３０６は、好ましくは、トランザクションサービス１１０を使用してイベント１１２を送信してクライアント１０４に記憶する。イベント１１２がロールバックされる場合、配信モジュール３０６は、利用可能ではないクライアント１０４のイベント１１２を一時的に保持するのに役立てることができる。

さらに詳細に後述するように、クライアント１０４はまず、イベント１１２の受信に登録され、特定のクライアント１０４を登録時に永続サブスクライバとして指定することができる。これは、本発明の好ましい実施形態の１つのユーザ構成可能な特徴である。永続サブスクライバクライアントとは、欠落したイベントを保持し、後でクライアントが再び利用可能になったときにクライアント１０４に配信することを要求するクライアントである。

一実施形態では、配信モジュール３０６は、イベント１１２を永続サブスクライバとして指定されたクライアント１０４に配信または送信するように構成される。配信モジュール３０６は、ポーリングモジュール３０２によるポーリング中に受信する、クライアント１０４が利用可能になったことのインジケータに応答して、保持されていた１つまたは複数のイベント１１２を、利用できない期間後に利用可能になったクライアント１０４に配信することができる。この配信モジュール３０６による保持イベント１１２の再配信は、装置２０４、３００のクラッシュリカバリ特徴の一部である。

確認モジュール３０８は、イベント１１２の１つだけのインスタンスが各クライアント１０４に配信されることを確認するように構成される。確認モジュール３０８は、イベント１１２がクライアント１０４に配信されたか否かを確認することもできる。確認モジュール３０８は、トランザクションサービス１１０を使用してイベントの配信を確認する。一実施形態では、確認モジュール３０８はＸＡ分散トランザクションを使用してイベントの配信を確認する。

除去モジュール３１０は、リファレンス１１８に対応するイベント１１２のクライアント１０４への配信が完了したことの確認後、ステージングされたイベント１１２へのリファレンス１１８をステージングテーブル１１６から除去するように構成される。例えば、イベント１１２が配信されてクライアントＢ１０４ｂにより消費されると、リファレンス１１８ｂがステージングテーブル１１６から除去される。イベントリファレンスの除去およびイベントの消費は、原子動作で実現される。

一実施形態では、装置３００は、ＥＩＳ１０２で作成された順番にイベント１１２をクライアント１０４に配信するように構成される。別の実施形態では、装置３００は、イベント１１２の順番が１つまたは複数のクライアント１０４にとって重要ではない場合により素早くイベントを配信する。イベントマネージャ２０４は、順番が関係ないクライアント１０４に複数の実行スレッドを使用して、すべてのイベント１１２を所与のクライアント１０４に並列に配信することができる。さらに、ステージングテーブル１１６は、各クライアント１０４の個々のリファレンス記録１１８を記憶することができる。したがって、イベントマネージャ２０４または装置３００は、各クライアント１０４の固有のニーズに向けてサービス提供することができる。例えば、イベントマネージャ２０４または装置３００は、あるクライアントにはシーケンシャルイベント配信を提供し、別のクライアントには非シーケンシャルイベントを並列に提供することができる。

以下の概略フローチャート図は全般的に、論理フローチャート図として記される。したがって、示される順番および記されるステップは、提示される方法の一実施形態を示す。示される方法の１つまたは複数のステップまたはその部分と機能、論理、または影響が等価の他のステップおよび方法も考えられる。さらに、利用されるフォーマットおよび記号は方法の論理ステップを説明するために提供されており、方法の範囲を制限しないことが理解される。様々な矢印の種類および線種をフローチャート図に利用できるが、これらは対応する方法の範囲を制限しないことが理解される。実際に、方法の論理フローのみを示すために、いくつかの矢印または他のコネクタが使用され得る。例えば、矢印は、示される方法の列挙されたステップ間の未指定期間の待機中または監視中の期間を示し得る。さらに、特定の方法が行われる順番は、示される対応のステップの順番に厳密に従ってもよく、または従わなくてもよい。

図４は、本発明の好ましい実施形態によるＥＩＳ１０２とクライアント１０４との間の通信に役立つ方法４００を示す。方法が開始され（４０２）、イベント１１２を求めて少なくとも１つのＥＩＳ１０２がポーリングされる（４０４）。イベント１１２が見つけられた場合、イベント１１２はステージングされ（４０６）、少なくとも１つのクライアントに配信される（４０８）。イベントの配信（４０８）が確認され（４１０）、イベントがＥＩＳから除去される（４１２）。方法が終了する（４１４）。

方法またはプロセスの開始時（４０２）に、１つまたは複数のクライアント１０４をイベント受信に登録することができる。一実施形態では、アダプタ装置２０４、３００は１つまたは複数のＥＩＳ１０２および１つまたは複数のクライアント１０４と通信する。一実施形態では、ＥＩＳ１０２のポーリング（４０４）は、クライアント１０４が利用可能であるか否か、新規イベント１１２が存在するか否か、および保持イベント１１２の配信準備ができたか否かを判断することを含む。クライアント１０４がイベント１１２の受信に登録されると、クライアント１０４が利用可能になる。クライアント１０４は、クライアントシステムがクラッシュした、クライアントシステムがビジーである、クライアントシステムがオフラインである、またはクライアントシステムが単に応答してないことを含むがこれらに限定されない任意の数の理由により時に利用不可能になる。ポーリング（４０４）は、以前に登録したが利用不可能なクライアント１０４が利用可能になったか否かを判断すること（４０４）を含む。

ＥＩＳ１０２のポーリング（４０４）は、新規イベント１１２を探してＥＩＳ１０２を定期的に照会することを含む。ＥＩＳ１０２がポーリングされる（４０４）頻度は、ユーザまたはアダプタ管理者が判断することができる。ユーザまたはアダプタ管理者は、イベントの配信を開始する前に検索すべきイベントの数量を判断することもできる。ＥＩＳのポーリング（４０４）の多くの態様がユーザ構成可能なことが当業者により理解されよう。

一実施形態では、イベントは、ＥＩＳ１０２に常駐して、イベントが発生するとイベントを取り込み、イベントストア２０２に記憶するトリガメカニズムまたはロジックを使用して検出することができる。この実施形態では、上述したポーリング（４０４）は、イベントストア２０２のポーリング（４０４）にも適用される。

アダプタ２０４、３００は、少なくとも１つのクライアント１０４への配信（４０８）に向けて、ポーリングされたイベント１１２をステージングする（４０６）。ステージング（４０６）は、イベント１１２へのリファレンス１１８をステージングテーブル１１６に書き込むことを含む。イベント１１２の受信に登録した各クライアント１０４に、エントリが書かれる。ステージングテーブル１１６はＸＡデータソース１１４内のデータベースである。このデータベースは、少なくとも、イベント１１２およびイベント１１２が配信されるクライアント１０４を識別するフィールドを記憶する。

一実施形態では、ステージング（４０６）は、ＥＩＳ１０２のイベントストア２０２内の各イベント１１２の配信状態をマークすることを含む。配信状態２０７は、新規イベント１１２の存在、イベント配信が進行中であること、エラーが発生したこと等を示すことができる。イベント１１２はイベント分散モジュール２０６に記憶して、方法４００において後で使用することができる。イベント１１２が検出されたが、配信される前の場合、イベント１１２には「ＭＥＷ＿ＥＶＥＮＴ」状態を与えることができる。

新規イベントの順番は、要求された場合に、発生した順番にイベントを配信できるようにマークすることができる。別法として、イベント分散モジュール２０６内の記録は、先入れ先出し順に配信することができる。イベント１１２が配信され始めると、配信状態を「ＩＮ＿ＰＲＯＧＲＥＳＳ（進行中）」に変更することができる。「ＥＲＲＯＲ（エラー）」状態が、アダプタ１０２に送信するオブジェクトの構築中にエラーが発生したイベント１１２に添付され、イベント配信を無効にする。「エラー」状態は、一実施形態では、ＸＡトランザクションサービス下でロールバックイベントを発生させる発生以外の何かによってトリガされる。

イベント１１２は、少なくとも１つのクライアント１０４に配信される（４０８）。一実施形態では、装置２０４、３００は、ＸＡトランザクションサービス１１０を使用してイベント１１２を配信する。イベント１１２の配信（４０８）は、Ｊ２ＥＥアプリケーションサーバにより制御されるトランザクションサービス１１０を使用して、イベント１１２を送信して記憶することを含むことができる。トランザクションサービス１１０は、各イベントをＸＡ準拠分散トランザクションで送信する。各イベント１１２は、１つのＸＡトランザクションの一部として特定のクライアント１０４に配信される。トランザクションがエンドポイントに到達できなかった場合、エンドポイントがクライアント１０４であれ、それともクライアントのダウンラインシステムであれ、イベントは、トランザクションサービス１１０が使用するＸＡトランザクションプロトコル下でステージングテーブル１１６にロールバックする。

クライアント１０４が利用可能ではなく、かつ永続サブスクライバとして指定されている場合、イベントはイベント分散モジュール２０６内に保持される。永続サブスクライバであるクライアント１０４は、イベント１１２が最初にクライアント１０４に送信されたときにクライアント１０４が利用不可能であった場合であっても、イベント１１２を失わない。イベント１１２は、永続サブスクライバクライアントが利用可能になったときにそのクライアントに配信または送信される。この配信または再配信は、ポーリングモジュールからの、またはポーリングステップ（４０４）中に生成される、クライアント１０４が利用可能になったというインジケータに応答して行うことができる。

イベントの配信（４０８）は、そのイベント１１２の配信状態２０７を判断することを含むことができる。アダプタ２０４、３００は、クラッシュが任意の時点で発生した場合であっても配信を保証するのに十分ロバストである。一実施形態では、イベント分散モジュール２０６内の情報と組み合わせられた、イベントストア２０２内の任意の保持中のイベント１１２の配信状態値２０７が、イベント１１２を再配信する必要があるか否かを決める。一実施形態では、イベント１１２の配信または削除は、以下のロジックテーブルに基づいて判断することができる。

イベントストア２０２内のイベントが「ＮＥＷ＿ＥＶＥＮＴ」とマークされ、かつイベント分散モジュール２０６内にない場合、クライアントが永続サブスクライバであるか否かに関わらず、イベント１１２は配信される。したがって、新規イベントはすべて配信が試みられる。イベントストア２０２内のイベントが「ＮＥＷ＿ＥＶＥＮＴ」とマークされ、かつイベント分散モジュール２０６内にある場合、クライアント１０４が永続サブスクライバでなければ、イベント１１２は削除される。イベントがイベントストア２０２内で「ＮＥＷ＿ＥＶＥＮＴ」とマークされ、かつイベント分散モジュール２０６内にある場合、クライアントが永続サブスクライバであれば、イベントは配信される。保持されるイベントは、永続サブスクライバにのみ配信される。イベントストア２０２内のイベントが「ＩＮ＿ＰＲＯＧＲＥＳＳ」とマークされ、かつイベント分散モジュール２０６内にない場合、クライアントが永続サブスクライバでなければ、イベントは削除される。イベントストア２０２内のイベントが「ＩＮ＿ＰＲＯＧＲＥＳＳ」とマークされ、かつイベント分散モジュール２０６内にある場合、クライアントが永続サブスクライバでなければ、イベントは削除される。配信を試みられたイベント１１２は、そのイベント１１２の受信を意図されるクライアント１０４が永続サブスクライバでない限り保持されない。イベントストア２０２内のイベントが「ＩＮ＿ＰＲＯＧＲＥＳＳ」とマークされ、かつイベント分散モジュール２０６内にある場合、クライアントが永続サブスクライバであれば、イベントは配信される。イベントストア２０２内のイベントが「ＩＮ＿ＰＲＯＧＲＥＳＳ」とマークされ、かつイベント分散モジュール２０６内にない場合、クライアントが永続サブスクライバであれば、イベントは削除される。

イベントの配信に利用可能になったクライアント１０４への保持されているイベント１１２の配信（４０８）は、好ましくは、他のクライアント１０４に任意の新規の後続イベント１１２が配信される前に完了される。例えば、クライアントＢに保持中のイベントがある場合、そのイベントは、クライアントＢがオンラインになるときまでそのＸＡデータソース１１４に留まる。クライアントＡおよびＣはそれぞれのイベントを受信し、クライアントＡおよびＣに関連するそのイベントの任意の記録がＸＡデータソース１１４から除去されるが、クライアントＢの記録はＸＡデータソース１１４に残る。ＥＩＳ１０２にも残る。アダプタ装置１０６は、イベントを受信することになっているすべてのクライアントがイベントを受信するまで、コピーを保持する。

クライアントＢがオンラインに戻ると、保持されていたイベントはリカバリサイクルを経る。リカバリサイクルでは、クライアントＡおよびＣはいずれの情報も得ず、装置１０６は、クライアントＢに関してバックログされていたすべての情報を送信し、クライアントＢがクライアントＡおよびＣと同期をとれるようにする。

配信（４０８）は、イベント１１２が配信された個々の各クライアント１０４について、ダウンライン構成要素等のクライアント１０４がイベント１１２を送信した可能性のある場所がどこであれ、そこにイベント１１２が配信されたことを確認することを含む。例えば、クライアントＡのラインでは、ＸＡトランザクションがコミットする、またはその特定のクライアントラインへのイベント１１２の配信を完了するには、イベント１１２がエンドポイントクライアントＡ’’１２２まで達しなければならない。一実施形態では、トランザクションサービス１１０が、特定のクライアントライン全体を通るすべての配信の承認を取り扱う。

確認（４１０）は、イベント１１２が少なくとも１つのクライアント１０４に配信されたか否かを確認することを含む。一実施形態では、方法４００は、イベント１１２の１つだけのインスタンスが少なくとも１つの各クライアント１０４に配信されたことを確認すること（４１０）を含む。上述したようなイベント配信の確認（４１０）は、トランザクションサービス１１０を使用して実現される。

除去（４１２）は、特定のクライアント１０４へのイベント１１２の配信完了が確認された後、ステージングされたイベントへの、ステージングテーブル１１６内のリファレンス１１８を除去することを含む。除去（４１２）は、クライアント１０４によるイベント１１２の消費後、イベント１１２へのリファレンス１１８をステージングテーブル１１６から除去することも含む。除去および消費は原子動作を含む。除去（４１２）は、イベント１１２へのリファレンスがステージングテーブル１１６から除去されたことに応答して、ＥＩＳ１０２からイベントを削除することも含む。例えば、ステージングテーブル１１６内にイベント１１２に対応するリファレンス１１８がもうない場合、イベント１１２をＥＩＳ１０２から除去することができる。一実施形態では、特定のイベント１１２へのいずれのリファレンス１１８もないステージングテーブル１１６は、意図されるすべてのクライアント１０４がイベント１１２を受信したことの確認である。

方法は、コンピュータプログラムまたは信号をのせた媒体により実施することができる。一実施形態では、コンピュータプログラムは、ＥＩＳと１つまたは複数のクライアントとの間の通信に役立つコンピュータ使用可能プログラムコードを有するコンピュータ可読媒体を含むか、または有形に具現する。コンピュータプログラムは、上記方法を実施するコンピュータ使用可能プログラムコードを含む。方法および対応するプログラムコードは、上記方法の機能および以下の図５および図６に関連して説明するプロセスの実施に必要なステップを含むこともできる。

図５は、ＥＩＳ５０２とクライアント５０４との間の通信に役立つプロセス５００を示す。イベントマネージャ５０６が、アダプタ５０８の一部として、イベント５１０を検索する。記録またはリファレンス５１２が、各アクティブエンドポイント５１６のステージングテーブル５１４に追加される。イベントストア５２０が、アダプタ５０８とＥＩＳ５０２との間のインタフェースとして機能し、イベントマネージャ５０６によるＥＩＳ５０６の照会およびＥＩＳ５０６内のイベントの変更を可能にする。イベント分散モジュール５２２が、ＸＡデータソース５１８の一部であるステージングテーブル５１４への一般アクセスをイベントマネージャ５０６に提供する。

イベント５１０は進行中とマークされる。イベント５１０をどのクライアント５０４に配信するかのガイドとしてステージングテーブル５１４を使用して、イベント５１０はすべてのアクティブクライアント５０４に発行される。クライアント５０４によるイベント５０２の個々のコピーの消費ならびに個々の同じイベント記録５１２のステージングテーブル５１４からの除去は両方とも、１つのＸＡトランザクションの一部として実行される。

すべてのエンドポイント５１６がイベント５１０を受信すると、元のイベント５１０はＥＩＳ５０２から削除される。イベントマネージャ５０６は、ステージングテーブル５１４内にその特定のイベント５１０へのリファレンス５１２がもうないことから、イベント５１０がエンドポイント５１に配信されたことを識別することができる。プロセス５００は、ＥＩＳ５０２に記録されている各イベント１１２に対して繰り返される。

図６は、図５に示すプロセスフローのシーケンス図である。一実施形態では、プロセス６００での最初のステップは、エンドポイントを再計算すること（６０２）である。イベントマネージャ５０６が、最後のポーリングサイクルからオンラインに戻った新規の任意のクライアント５０４があるか否かを判断する。ポーリングサイクルは、イベントマネージャ５０６がＥＩＳ５０２またはイベントストア５２０をポーリングする時間期間である。新規クライアント５０４がある場合、イベントマネージャ５０６は、保持されていたイベントを配信するか、それとも新規の配信を開始するかを判断する。

次に、イベントマネージャ５０６は「進行中イベント」をリカバリする（６０４）。最後のポーリングサイクルから追加された新規の任意のクライアント５０４があった場合、イベントマネージャ５０６は、新規クライアント５０４に欠落している任意のイベントを配信し、それにより、イベント配信シーケンスを保持する。次に、イベントマネージャ５０６は新規イベントをイベントストア５２０から検索する（６０６）。イベントストア５２０は新規イベントリストを返す（６０８）。

イベントマネージャ５０６は分散マップを作成する（６１０）。分散マップは、どのイベントがどのクライアント５０４に行っているかを定義する。分散マップは、クライアント識別子またはエンドポイントＩＤ１２１をイベントリストにマッピングする。イベントマネージャ５０６は、イベント分散モジュール５２２を使用して記憶された（６１２）イベントリファレンス１１８、５１２を定義する。イベント状態２０７が設定され（６１４）、イベントはＥＩＳ５０２において「ＩＮ＿ＰＲＯＧＲＥＳＳ」とマークされる。

次に、イベントマネージャ５０６はセンダと通信して、イベント５１０の送信を開始する（６１６）。センダ２１４はイベント５１０を送信する。センダ２１４は、ＸＡ通信プロトコルに従って動作するように構成されるイベント分散モジュール５２２からＸＡリソースを検索する（６２０）。次に、センダ２１４は、Ｊ２ＥＥコンテナ１０８を呼び出して、エンドポイントファクトリ６２５を使用してエンドポイントオブジェクト６２３を作成する（６２２）。エンドポイントオブジェクト６２３は、イベントマネージャ５０６がクライアント５０４またはエンドポイント５１６にアクセスできるようにする。センダ２１４は、「ターゲットメソッド」を検索する（６２４）。イベントマネージャ５０６が何かをトランザクションに入れたい場合、イベントマネージャ５０６はコンテナ１０８にターゲットメソッドおよびＸＡリソースを与える。次に、センダ２１４は、所望のエンドポイントオブジェクト６２３で「ｂｅｆｏｒｅＤｅｌｉｖｅｒｙ」コマンドを呼び出し（６２６）、コンテナ１０８にトランザクションを開始するように教える。次に、センダ２１４は、イベントのオブジェクト５１０を検索する（６２８）。次に、イベントオブジェクト５１０は配信され（６３０）、イベントマネージャ５０６に通知される。次に、センダ２１４は、所定の関数を呼び出し、この場合「ｒｅｅｉｖｅＭｅｓｓａｇｅ」６３２を介してイベント５１０をエンドポイント５１６に送信する。

次に、イベントリファレンス１１８、５１２が削除され（６３４）、イベントが配信されたその特定のクライアント５０４の１つのリファレンス１１８、５１２が、イベント分散モジュール５２２によりステージングテーブル５１４から除去される。次に、エンドポイント５１６において、イベントマネージャがこのトランザクションを終了したことをコンテナ１０８に教える「Ａｆｔｅｒ Ｄｅｌｉｖｅｒｙ」コマンドが実行される（６３６）。その時点で、イベント５１０はクライアントのビジネスプロセスにより処理され、次に、トランザクションがコミットされる。最終ステップは、イベント５１０をＥＩＳ５０２から削除すること（６３８）である。

ステップ６２０〜６３６が、各イベント５１０、各オンラインメッセージエンドポイント５１６に繰り返される。これは、１エンドポイントファクトリ６２５につき１スレッド（シーケンシャル）、または１イベント、１エンドポイントファクトリ６２５につき１スレッド（順番なし）で行うことができる。

本発明の好ましい実施形態により教示されるプロセスの利用により、クライアントによるイベントの消費およびステージングテーブルからのイベントの削除が、好ましくは、１つのトランザクションの一部として行われるため、クライアントの１度だけのイベント配信が保証される。別法として、消費および配信は、１つの原子トランザクションを含み、リファレンスおよびイベントの削除が第２の原子トランザクションを含んでもよい。この手法は、トランザクションはクライアントおよびステージングテーブルにまたがり、ステージングテーブルは、ＸＡ対応ではない場合があるＥＩＳイベントテーブルではなくＸＡ対応であるため、土台をなすＥＩＳ１０２がトランザクションをサポートしない場合であっても可能である。さらに、クライアントのエンドポイントは、他のあらゆるものによるイベントの処理に干渉しない。各クライアントは、各自の分離されたトランザクションとの各自のデータベース接続でイベントを受信する。すべてのエンドポイントがイベントを受信する前にクライアント１０４またはアダプタ１０６が予期せずに終了した場合、ステージングテーブル１１６は、どのイベント１１２がまだ配信されていないかのリストを保持するため、アダプタ１０６は後の時点で配信を再試行することができる。

本発明の好ましい実施形態の教示の下、ＥＩＳ１０２内のイベント１１２を検出するトリガはクライアント１０４と関係する必要がなく、単にイベントのコピーをイベント分散モジュール２０６に書き込むだけであるため、クライアント１０４は動的に追加または除去することができる。さらに、イベントの複数のコピーを分散モジュール２０６に記憶する必要がないため、ポーリング性能が向上する。アダプタ１０６は、複数の記録１１８をステージングテーブル１１６に書き込むが、これらは単に、イベント分散モジュール２０６により管理されるイベント１１２へのリファレンス１１８であり、略同量のデータを含まない。本発明の実施形態の別の利点は、ＥＩＳ１０２システムがＸＡをサポートしない場合であっても２フェーズトランザクション（ＸＡ）の一部としてデータをＥＩＳ１０２から配信させるメカニズムを提供することである。

図７は、本発明の好ましい実施形態による顧客の複数のソフトウェアクライアントにＥＩＳを統合する方法７００を示す。方法７００は、デベロッパーまたはコンサルティンググループにより実施することができる。一実施形態では、方法７００が開始され（７０２）、ＥＩＳ１０２がクライアントとどのように協働すべきかを定義した統合要件セットを受信する（７０４）。次に、方法７００は、ソフトウェアクライアントがＥＩＳイベント１１２を受信するようにＥＩＳ１０２と複数のソフトウェアクライアント１０４を接続するように構成される統合アダプタを構築する（７０６）。ＥＩＳ１０２または１つまたは複数のソフトウェアクライアント１０４、あるいはこれら両方は、顧客に属することができる。統合アダプタ５０８は、イベントを求めて少なくとも１つのＥＩＳ１０２をポーリングし、少なくとも１つのクライアントへの配信に向けてイベントをステージングし、イベントを少なくとも１つのクライアントに配信し、イベントの１つだけのインスタンスが少なくとも１つの各クライアントに配信されることを確認するように構成される。次に、統合アダプタ５０８が顧客に配信される（７０８）。統合アダプタ５０８は、オプションとして、セットアップされるか（７１０）、またはインストールすることができ、プロセス７００は終了する（７１２）。

一実施形態では、統合アダプタのセットアップ（７１０）は、各クライアントをＥＩＳ１０２からのイベントの受信に登録することを含む。これは、イベントを求めて少なくとも１つのＥＩＳ１０２をポーリングする頻度および配信前にステージングするイベントの数量を判断することを含むこともできる。方法７００は、トランザクションサービスを統合アダプタに統合すること、および利用不可能なクライアントに対して、クライアントが利用可能になるまでイベントを保持すべきか否かを判断することを含むこともできる。

図８は、クライアントへの１度だけのイベント配信を保証する企業情報システム（ＥＩＳ）を複数のソフトウェアクライアントに統合するように構成されるコンピューティングインフラを導入する方法８００を示す。方法が開始され（８０２）、複数の拡張可能モジュールを含むソフトウェアツールキットが開発される（８０４）。モジュールは、イベントを求めて少なくとも１つのＥＩＳ１０２をポーリングし、少なくとも１つのクライアントへの配信に向けてイベントをステージングし、イベントを少なくとも１つのクライアントに配信し、イベントの１つだけのインスタンスが少なくとも１つの各クライアントに配信されることを確認するように構成される。トランザクションサービスは、好ましくは、ソフトウェアツールキットと統合される（８０６）。ソフトウェアツールキットは、オプションとして、各種手段を通して発行（８０８）するか、または公開することができ、プロセスが終了する（８１０）。一実施形態では、トランザクションサービスはＸＡ仕様下の分散トランザクションをサポートする。

本発明の好ましい実施形態による企業情報システム（ＥＩＳ）とクライアントとの間の通信に役立つシステムの一実施形態を示す概略ブロック図である。 図１のシステムで使用できるアダプタの一実施形態を示す概略ブロック図である。 図２のアダプタに使用できるイベントマネージャの一実施形態を示す概略ブロック図である。 本発明によるＥＩＳとクライアントとの間の通信に役立つ方法の一実施形態を示す概略フローチャート図である。 本発明の好ましい実施形態によるＥＩＳとクライアンとの間の通信に役立つシステムの一実施形態を示す概略ブロック図である。 本発明の好ましい実施形態によるＥＩＳとクライアントとの間の通信に役立つ方法の一実施形態を示す概略シーケンス図である。 本発明の好ましい実施形態によるＥＩＳ統合方法の一実施形態を示す概略フローチャート図である。 本発明の好ましい実施形態によるコンピューティングインフラを導入する方法の一実施形態を示す概略フローチャート図である。

Claims (26)

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. クライアントへの１度だけのイベント配信を保証する、複数のソフトウェアクライアントに企業情報システム（ＥＩＳ）を統合するように構成されるコンピューティングインフラを導入する方法であって、
    複数の拡張可能モジュールを含むソフトウェアツールキットを開発するステップであって、前記モジュールが、
    イベントを求めて少なくとも１つのＥＩＳをポーリングし、
    イベントを受信するために登録された複数のクライアントの各々についてステージングテーブルに前記イベントへのリファレンスを書き込むことにより、前記イベントを前記複数のクライアントへの配信に向けてステージングし、
    前記イベントを前記複数のクライアントに配信し、
    前記イベントの１つだけのインスタンスが前記複数の各クライアントに配信されたか否かを確認し、
    前記イベントが前記複数のクライアントのうちの特定のクライアントによって消費されたときに、前記特定のクライアントに対応する、前記イベントへのリファレンスを前記ステージングテーブルから除去する
    ように構成される、ステップと、
    トランザクションサービスを前記ソフトウェアツールキットに統合するステップと、
    前記ソフトウェアツールキットを発行するステップと、
    を含み、
    前記消費および前記除去が原子動作であるトランザクションの一部として実行される、方法。

Images