ポリシーベースのメッセージ集約フレームワーク
送信元アプリケーションによって作成されたメッセージが、構成ポリシーに基づいてバッチへと集約される。この構成ポリシーは、メッセージをバッチへと集約するために使用されるビジネスロジックを含む。バッチは、完成すると、単一のストリーム出力へとフォーマットされ、それらのメッセージを受信するように設計されている送信先アプリケーションへ送信される。メッセージは、送信元アプリケーションによってコントロールされるバッチへと集約することもできる。それらのメッセージは、バッチが完成するときに知らせるように送信元アプリケーションによって設定されたインジケータを含む。バッチは、完成すると、単一のストリーム出力へとフォーマットされ、それらのメッセージを受信するように設計されている送信先アプリケーションへ送信される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ポリシーベースのメッセージ集約フレームワークに関する。
【背景技術】
【０００２】
今日のグローバル経済においては、企業は、多くの場合、様々なソースからアプリケーション、システム、およびテクノロジーを統合する必要がある。通常、これらの企業は、合意されたメッセージ標準によって、あるコンピュータアプリケーションから別のコンピュータアプリケーションへ電子的な手段によって、かつ人間の介入を最小限に抑えて、構造化された情報をコンピュータどうしでやり取りするためのシステムを作成する。メッセージ標準の例としては、ヘルスケア関連の臨床データおよび管理データのためのＨＬ７（Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ）、製品、資産、サービス、および場所に関する情報を識別および通信するためのＧＳ１システム、金融データのためのＳＷＩＦＴ、および様々なビジネス取引データを転送するための合意されたメッセージ標準によって、構造化された情報をやり取りするためのＥＤＩが含まれる。
【０００３】
図１に示されているように、ある企業は、様々なメッセージフォーマットで様々な提携先と通信する可能性がある。例えば、その企業は、ＸＭＬフォーマットで顧客と通信する可能性があり、その企業は、ＥＤＩまたはＦｌａｔ Ｆｉｌｅメッセージフォーマットでサプライヤアプリケーションと通信する可能性があり、その企業は、ＳＷＩＦＴメッセージフォーマットで金融アプリケーションと通信する可能性があり、またその企業は、その他の何らかの業界標準メッセージフォーマットでロジスティクスアプリケーションと通信する可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
残念なことに、メッセージの数が増えて多様になると、典型的な企業においては、通信が複雑になり、非効率がもたらされる。メッセージを集約するためのソリューションをカスタムソフトウェアコードで書くことができるが、そのようなソリューションは、企業における複雑さおよびコストを増大させるものであり、また特定の状況に適しているにすぎない。
【課題を解決するための手段】
【０００５】
本発明の態様は、構造化されたメッセージをコンピュータどうしでやり取りする公知の形態における１つまたは複数の欠陥を克服する。拡張可能な、ポリシーベースのメッセージ集約フレームワークが、メッセージをバッチへと集約し、それによって、複数のメッセージを単一の出力ストリームとして送信先アプリケーション（ｄｅｓｔｉｎａｔｉｏｎ ａｐｐｌｉｃａｔｉｏｎ）へ伝送することができる。
【０００６】
一態様においては、本発明は、ポリシーベースのメッセージ集約を含み、ここでの集約は、メッセージをバッチへと集約するために使用されるビジネスロジックを含むポリシーに基づく。別の態様においては、本発明は、アプリケーションベースのメッセージ集約を含み、この集約では、送信元アプリケーション（ｓｏｕｒｃｅ ａｐｐｌｉｃａｔｉｏｎ）が、メッセージ内にインジケータを設定し、それらのインジケータは、バッチにまとめるべきメッセージを識別し、そのバッチが完成するときに知らせる。
【０００７】
典型的な企業は、重要なビジネス上のコミュニケーションに関連する多くのメッセージを作成するため、本発明の態様を具体化するメッセージ集約システムは、信頼性および拡張性が高い。また、メッセージを蓄積し、そしてそれらのメッセージを伝送するのに使用される通信媒体に関するコストが最も低いときにそれらのメッセージを送信することによってコストを下げるために、およびメッセージの束を一度に伝送して、単一のメッセージを送信することに関連するオーバヘッドを低減することによってパフォーマンスを高めるために、メッセージの集約を実施することもできる。
【０００８】
メッセージ集約のためのコンピュータ実行可能命令を有するコンピュータ可読媒体が、本発明のさらなる態様を具体化する。あるいは本発明の実施形態は、その他の様々な方法および装置を含むこともできる。
【０００９】
この概要は、以降の「発明を実施するための最良の形態」においてさらに説明するコンセプトから抜粋したものを、簡略化された形式で紹介するために提供されている。この「課題を解決するための手段」は、特許請求されている主題の鍵となる特徴や必要不可欠な特徴を特定することを意図するものではなく、特許請求されている主題の範囲を確定する際の補助として使用されることを意図するものでもない。
【００１０】
その他の特徴については、一部は明らかであろうし、また一部は以降で指摘する。
【００１１】
対応する参照文字は、複数の図面を通じて、対応する部分を指す。
【発明を実施するための最良の形態】
【００１２】
図面を参照すると、図２は、メッセージ集約のためのコンピューティングシステム環境の一実施形態を示している。複数のビジネスニーズを満たすためにメッセージの集約を実施することができる。例えば、ある企業は、様々なメッセージフォーマットで様々な提携先と通信する。メッセージの集約によって、指定の時点において通信を提供しながら、より低いコストでパフォーマンスを高めることができる。この例においては、この企業は、毎週１回サプライヤに用品を注文するというポリシーを有しているかもしれない。あるアプリケーションは、この企業が、サプライヤに宛てたメッセージを作成することによってその週の間中用品を注文することを可能にすることができる。本発明の実施形態は、これらのメッセージを、実行処理のためにサプライヤのアプリケーションへ毎週１回伝送するための、企業における１つのバッチへと集約することができる。
【００１３】
別の例として、ある企業が、顧客から多数の購入注文を受けていると想像していただきたい。それぞれの顧客の購入注文を実行するために、この企業は、提携先企業に品物を注文し、そしてこの企業は、ＥＤＩを使用してその提携先に注文を伝達する。しかし、その提携先企業への接続は、１日の特定の時間にしか利用できない。したがって、この企業は、その提携先に関するすべての注文を蓄積して、それらの注文を１日の適切な時間中に送信する必要がある。さらに企業は、多くの場合、提携先への接続時間の代金を支払わなければならない。この場合、すべてのメッセージを束ねて、数時間ごとに１回程度接続を開き、メッセージの単一の束を一度に伝送することが有利である。さらに本発明の態様は、ＸＭＬ、ＥＤＩ、Ｆｌａｔ Ｆｉｌｅ、ＳＷＩＦＴ、あるいはその他の何らかの業界標準メッセージフォーマットなど、様々なメッセージフォーマットでメッセージを集約することができる。
【００１４】
図２に示されているように、送信元アプリケーション２０２が、メッセージを作成し、送信する。送信ポートに宛てられたメッセージを送信することは、当業者にはよく知られている。メッセージングエンジン２０４が、それぞれのメッセージを受信し、メッセージアドレスにおいて送信ポートに関連付けられている１つまたは複数のバッチャー（ｂａｔｃｈｅｒ）２０６が、本発明の態様に従ってメッセージを受信し、集約する。一実施形態においては、送信元アプリケーション２０２および送信先アプリケーション２１２は、エンドポイントを介してメッセージングエンジン２０４と通信する。エンドポイントとは、ある場所の（例えば、ＵＲＬ形式で表された）論理的な表示であり、受信または送信されるデータのための物理アドレスを提供する。この実施形態におけるエンドポイントは、双方向のものであり、メッセージングエンジン２０４内へメッセージをくみ上げるために、ならびにメッセージングエンジン２０４からメッセージを出すために使用される。
【００１５】
別の実施形態においては、メッセージングエンジン２０４はまた、メッセージをデータストア２０８へ書き込む。バッチ内のメッセージどうしが相互に独立している場合には、本発明の態様は、ビジネス構成ポリシー（ｂｕｓｉｎｅｓｓ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｏｌｉｃｙ）によって定義されている選択されたパラメータに基づいてそれらのメッセージを組み立てることができる。例えばバッチ構成ポリシー（ｂａｔｃｈ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｏｌｉｃｙ）は、バッチ内のメッセージの数、バッチ内の累積バイト数、バッチ内のメッセージのタイプ、および／またはメッセージを蓄積するための時間を決定するために使用されるビジネスロジックを含む。
【００１６】
一実施形態においては、バッチャー２０６は、送信ポート上に構成される（例えば、ＢａｔｃｈｅｒＴｙｐｅ ＆ ＢａｔｃｈｅｒＬｏｃａｔｉｏｎ）。例えば、このためにアダプタフレームワークコードベース（ａｄａｐｔｅｒ ｆｒａｍｅｗｏｒｋ ｃｏｄｅ ｂａｓｅ）を活用することができ、そしてそのアダプタフレームワークコードベースによって、この構成およびその他の送信ポート構成情報を保存するためのインターフェースが実装される。付録Ａは、バッチャーインターフェース（ｂａｔｃｈｅｒ ｉｎｔｅｒｆａｃｅ）を含む、本発明の態様を具体化するアウトバウンドバッチング（ｏｕｔｂｏｕｎｄ ｂａｔｃｈｉｎｇ）のためのメッセージングフレームワークの例示的な一実装形態を示している。
【００１７】
別の実施形態においては、メッセージングエンジン２０４は、１つまたは複数のバッチャー２０６に関するインスタンス状態４０２（図４を参照されたい）を保持する。インスタンス状態４０２は、バッチャー２０６に関連付けられている送信ポートと、その送信ポートに宛てられているメッセージのリストとを含む。インスタンス状態４０２は、データストア２０８内に保存することができる。それらのインスタンス状態は、システム障害の場合にそれぞれのバッチャーインスタンスに対応するメッセージを検索するために使用される。
【００１８】
特定の送信ポートに関連付けられているバッチャー２０６が存在しない場合には、メッセージングエンジン２０４が、そのバッチャー２０６を作成することになる。それぞれのバッチャー２０６を動的に作成することによって、必要に応じてバッチャーが作成され、それによって、このメッセージ集約システムの拡張性が促進される。さらに、バッチャー２０６を動的に作成することは、使用されていないバッチャーのオーバヘッドをなくすこと、およびメッセージングエンジン２０４が、アクティブなバッチャー２０６に関してのみインスタンス状態４０２を管理できるようにすることによって、システムパフォーマンスを補助する。
【００１９】
インスタンス状態４０２およびメッセージをデータストア２０８内に保存することによって、システム障害の場合にバッチを回復することができる。一実施形態においては、再開後に、メッセージングエンジン２０４は、障害時に進行していたバッチのインスタンス状態４０２にアクセスすることができる。それぞれのインスタンス状態４０２ごとに、メッセージングエンジン２０４は、バッチャー２０６のインスタンスを作成する。インスタンス状態４０２のメッセージリスト内のそれぞれのメッセージごとに、メッセージングエンジン２０４は、それらのメッセージをバッチャー２０６に再送する。リスト内のそれらのメッセージがバッチャー２０６に再送されると、そのバッチは、障害時と同じ状態になる。
【００２０】
例えばインスタンス状態４０２は、アプリケーションインスタンス（この場合は、Ａｓｓｅｍｂｌｅｒ／Ｂａｔｃｈｅｒ Ｉｎｓｔａｎｃｅ）の状態を保存するための場所である。アプリケーションインスタンスに対応するメッセージは、データストア内に保存されるが、アプリケーションがインスタンス情報を検索して障害後に処理を継続できるように、アプリケーションインスタンスの状態に関する情報を保存する必要もある。サブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）は、インスタンス状態とは無関係である。サブスクリプションテーブルは、特定の条件を満たすメッセージを受信する（Ｓｅｒｖｉｃｅ ＩＤによって識別される）サービスのリストを定義する。メッセージがメッセージボックス（例えばデータストア１０８）に発行されると、メッセージボックスは、条件を評価し、どのサービスがそのメッセージを受信することになるかを識別する。そしてメッセージボックスは、そのサービスの論理インスタンスを「Ｉｎｓｔａｎｃｅｓ」テーブル内に作成し、そのメッセージ上に「ＩｎｓｔａｎｃｅＩＤ」をスタンプしてからそのメッセージをメッセージングエンジン２０４へ送信する。
【００２１】
別の実施形態においては、メッセージは、バッチャー２０６に関連付けられているバッチャー識別子を含む。この実施形態においては、メッセージボックスは、特定の条件を満たすメッセージを受信する（Ｓｅｒｖｉｃｅ ＩＤによって識別される）サービスのリストを定義するサブスクリプションテーブル４０８を保持する。メッセージボックスは、送信元アプリケーション２０２からメッセージを受信する。そのメッセージがメッセージボックスに発行されると、メッセージボックスは、条件を評価し、どのサービスがそのメッセージを受信することになるかを判断する。そして、そのサービスのためのバッチャー２０６のインスタンスが存在しない場合には、メッセージボックスがそのインスタンスを作成する。次いでメッセージボックスは、そのメッセージをメッセージングエンジン２０４へ送信する。メッセージングエンジン２０４は、バッチ識別子をハッシュして、バッチャー２０６の正しいインスタンスを特定する。そしてメッセージングエンジン２０４は、特定したバッチャー２０６にメッセージを送信する。
【００２２】
バッチャー２０６は、メッセージを受信すると、メッセージのバッチが完成しているかどうかを判断する。一実施形態においては、バッチャー２０６は、バッチ構成ポリシーに関してそのバッチが完成しているかどうかを判断する。バッチ構成ポリシーは、いつバッチが完成するかを判断するために使用されるビジネスロジックを含む。このビジネスロジックは、バッチ内のメッセージの数、バッチ内の累積バイト数、バッチ内のメッセージのタイプ、およびメッセージを蓄積するための時間のうちの１つまたは複数を含むことができる。別の実施形態においては、ビジネスロジックは、バッチ内のメッセージに関する所望のソート順序を含むことができ、これによってバッチャー２０６は、バッチ内のメッセージをソートすることができる。
【００２３】
メッセージアドレスにおいて送信ポートに関連付けられているバッチャー２０６が、本発明の態様に従ってメッセージを受信し、集約する。上述のように、バッチ内のメッセージどうしは、相互に独立することができる。別の実施形態においては、バッチ内のメッセージどうしは相互に依存し、それらのメッセージを作成しているコードは、新たなバッチがいつ開始されることになるか、そしてそのバッチがいつ完成するべきかを把握している。この実施形態においては、メッセージは、バッチ完成インジケータ（ｂａｔｃｈ ｅｎｄ ｉｎｄｉｃａｔｏｒ）を含む。そのバッチが完成していることをバッチ完成インジケータが示しているならば、バッチャー２０６は、そのバッチを完成したことになる。
【００２４】
バッチャー２０６は、バッチが完成していると判断すると、そのバッチをメッセージングエンジン２０４へ返す。メッセージングエンジン２０４は、そのバッチをアセンブラ２１０へ送信する。次にアセンブラ２１０は、そのバッチ内のすべてのメッセージを順番に並べて、単一の出力ストリームにする。ある代替実施形態においては、バッチャー２０６が自ら、バッチにまとめられたすべてのメッセージを順番に並べて、単一の出力ストリームにする。アセンブラ２１０は、そのメッセージストリームを、それらのメッセージを受信するように設計されているアプリケーションに関連付けられている送信先アプリケーション２１２へ送信する。
【００２５】
図３は、メッセージ集約の一実施形態の態様を示す例示的な流れ図である。３０２において、メッセージングエンジン２０４は、送信ポートに宛てられているメッセージを送信元アプリケーション２０２から受信する。３０４において、メッセージングエンジン２０４は、送信ポートに関連付けられているバッチャー２０６のインスタンスが存在することを確認する。送信ポートに関連付けられているバッチャー２０６のインスタンスが存在する場合には、その関連付けられているバッチャー２０６が、共通の送信ポートに宛てられているメッセージを集約する。一方、送信ポートに関連付けられているバッチャー２０６が存在しない場合には、そのバッチャーのインスタンスが、３０６において作成される。
【００２６】
別の実施形態においては、メッセージは、特定のバッチャー２０６に関連付けられているバッチャー識別子を含む。この実施形態においては、本発明の態様は、そのバッチ識別子に関連付けられているバッチャー２０６のインスタンスが存在することを確認するためにチェックを実行する。バッチ識別子に関連付けられているバッチャー２０６が存在しない場合には、そのバッチャーのインスタンスが、３０６において作成される。
【００２７】
図３をさらに参照すると、メッセージングエンジン２０４は、３０８において、メッセージアドレスにおいて送信ポートに関連付けられているバッチャー２０６へメッセージを送信する。３１０において、バッチャー２０６は、メッセージのバッチが完成しているかどうかを判断する。一実施形態においては、バッチャー２０６は、バッチ構成ポリシーに関してそのバッチが完成しているかどうかを判断し、そのバッチ構成ポリシーは、この判断を行うために使用されるビジネスロジックを含む。上述のように、このビジネスロジックは、バッチ内のメッセージの数、バッチ内の累積バイト数、バッチ内のメッセージのタイプ、およびメッセージを蓄積するための時間のうちの１つまたは複数を含むことができる。有利なことに、顧客は、バッチ構成ポリシーによってメッセージをバッチにまとめるための独自の基準を設定することができる。さらにバッチャー２０６は、バッチ構成ポリシーによって定義されている所望のソート順序に従ってバッチ内のメッセージをソートすることができる。
【００２８】
３１０において、バッチが完成していないとバッチャー２０６が判断した場合には、そのバッチのインスタンス状態４０２が、３１２において更新されることになる。インスタンス状態４０２は、バッチャー２０６に関連付けられている送信ポートと、その送信ポートに宛てられているメッセージのリストとを含む。インスタンス状態４０２は、データストア２０８内に保存することができる。一方、３１０において、バッチが完成しているとバッチャー２０６が判断した場合には、３１４において、そのバッチからメッセージセットが作成される。３１６において、バッチャー２０６は、そのメッセージセットをアセンブラへ送信し、そのアセンブラでは、メッセージが、送信先アプリケーション２１２へ単一の出力ストリームで送信される。送信先アプリケーション２１２は、例えば顧客アプリケーション、サプライヤアプリケーション、あるいは金融アプリケーションとすることができる。出力ストリームは、送信先アプリケーション２１２により指定されたように、ＥＤＩフォーマット、ＳＷＩＦＴフォーマット、ＧＳ１システム、ＨＬ７、あるいはその他の何らかの業界標準フォーマットのものとすることができる。出力ストリームが送信されると、３１２において、バッチャーのインスタンス状態４０２が更新される。
【００２９】
一実施形態においては、メッセージングエンジン２０４が、３１４においてバッチャーのためのメッセージセットを作成している間に、または３１６においてそのメッセージセットをアセンブラへ送信している間に、３０２においてバッチャー２０６のための新たなメッセージが受信された場合には、メッセージングエンジン２０４は、３０８においてバッチャー２０６の新たなインスタンスを作成することになる。処理は、バッチャー２０６のこの新たなインスタンスに関して３０６から続くことになる。これによって、メッセージングエンジン２０４は、並行バッチ（ｃｏｎｃｕｒｒｅｎｔ ｂａｔｃｈｅｓ）を処理することができ、ここでバッチャー２０６の新たなインスタンスに関して新たなバッチが開始される一方、１つのバッチがアセンブラ２１０へ送信される。
【００３０】
例えば、バッチが完成しているとバッチャー２０６が判断した場合には、メッセージングエンジン２０４は、そのことに留意し、単一の出力ストリームをアセンブラ２１０に渡す。しかし、その間にメッセージングエンジン２０４が、その同じ送信ポートのための新たなメッセージを受信した場合には、メッセージングエンジン２０４は、前のバッチが完成していることを認識し、新たなバッチャー２０６を、したがって新たなバッチを作成することになる。複数のインフライトバッチャー（ｉｎｆｌｉｇｈｔ ｂａｔｃｈｅｒ）２０６が、「ｂａｔｃｈｅｒＩＤ」によって識別される。
【００３１】
図４は、汎用コンピューティングデバイスの一例をサーバ４３０の形態で示している。本発明の一実施形態においては、サーバ４３０などのサーバは、本明細書で例示および説明されているその他の図において使用することにも適している。サーバ４３０は、１つまたは複数のプロセッサまたは処理装置と、システムメモリとを有する。図示されている実施形態においては、システムバスは、システムメモリを含む様々なシステムコンポーネントをプロセッサに結合している。
【００３２】
サーバ４３０は通常、少なくとも何らかの形態のコンピュータ可読媒体を有する。コンピュータ可読媒体は、揮発性媒体および不揮発性媒体、ならびに取り外し可能な媒体および固定の媒体の双方を含み、サーバ４３０によってアクセスできる利用可能な任意の媒体とすることができる。例えばコンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むが、これらには限定されない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータなどの情報を記憶するための任意の方法や技術において実装される揮発性媒体および不揮発性媒体、ならびに取り外し可能な媒体および固定の媒体を含む。例えばコンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、またはその他の光ディスクストレージ、磁気カセット、磁気テープ、データストア１０８などの磁気ディスクストレージ、またはその他の磁気ストレージデバイス、あるいは所望の情報を記憶するために使用可能で、サーバ４３０によってアクセス可能なその他の任意の媒体を含む。通信媒体は通常、搬送波やその他の伝送メカニズムなどの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータを具体化し、任意の情報伝達媒体を含む。変調されたデータ信号とは、当業者にはよく知られたものであり、情報をその信号内でコード化するような方法で設定または変更されたその特性のうちの１つまたは複数を有する。有線ネットワークや直接有線接続などの有線媒体、および音響媒体、ＲＦ媒体、赤外線媒体、その他の無線媒体などの無線媒体は、通信媒体の例である。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。
【００３３】
サーバ４３０は、その他の取り外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。この例示的な動作環境において使用することができるその他の取り外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これらには限定されない。
【００３４】
図４に示されている上述のドライブ、またはその他のマスストレージデバイス、およびそれらに関連付けられているコンピュータ記憶媒体は、サーバ４３０のためのコンピュータ可読命令、データ構造、プログラムモジュール１０２、１０４、１０６、１１０、およびその他のデータ４０２、４０４の記憶を提供する。
【００３５】
サーバ４３０は、リモートサーバ４０６Ａ、４０６Ｂ、４０６Ｃなどの１つまたは複数のリモートサーバへの論理接続を使用して、ネットワーク化された環境内で機能することができる。リモートサーバは、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいはその他の一般的なネットワークノードとすることができ、通常は、サーバ４３０に関連する上述の要素の多くまたはすべてを含む。図４に示されている論理接続は、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）およびＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）を含むが、その他のネットワークを含むこともできる。ＬＡＮおよび／またはＷＡＮは、有線ネットワーク、無線ネットワーク、それらの組合せなどとすることができる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、および全世界規模のコンピュータネットワーク（例えばインターネット）においてよく見受けられる。
【００３６】
ローカルエリアネットワーキング環境において使用する場合には、サーバ４３０は、ネットワークインターフェースまたはアダプタを通じてＬＡＮに接続される。ワイドエリアネットワーキング環境において使用する場合には、サーバ４３０は通常、インターネットなどのＷＡＮ上で通信を確立するためのモデムやその他の手段を含む。モデムは、内蔵型とすることもでき、あるいは外付け型とすることもでき、ユーザ入力インターフェースやその他の適切なメカニズムを介してシステムバスに接続される。ネットワーク化された環境においては、コンピュータ１３０に関連して示されているプログラムモジュールやそれらの一部をリモートメモリストレージデバイス（図示せず）内に格納することができる。示されているネットワーク接続は例示的なものであり、コンピュータどうしの間に通信リンクを確立するその他の手段を使用することもできる。
【００３７】
一般にサーバ４３０のデータプロセッサは、別々の時点でコンピュータの様々なコンピュータ可読記憶媒体内に格納された命令によってプログラムされる。プログラムおよびオペレーティングシステムは通常、例えばフロッピー（登録商標）ディスクやＣＤ−ＲＯＭで配布される。そこから、これらはコンピュータの２次メモリ内へインストールまたはロードされる。実行時には、これらは少なくとも一部がコンピュータの１次電子メモリ内へロードされる。これらおよびその他の様々なタイプのコンピュータ可読記憶媒体が、後述のステップを実施するための命令やプログラムをマイクロプロセッサやその他のデータプロセッサと共に含む場合には、そのような媒体は、本明細書に記載されている本発明の態様に含まれる。さらに、コンピュータが、本明細書に記載の方法および技術に従ってプログラムされる場合には、そのコンピュータ自体も本発明の態様に含まれる。
【００３８】
例示の目的から、オペレーティングシステムなどのプログラムおよびその他の実行可能なプログラムコンポーネントは、本明細書では別個のブロックとして示されている。しかし、そのようなプログラムおよびコンポーネントは、様々な時点においてコンピュータの別々のストレージコンポーネント内に存在し、コンピュータの（１つまたは複数の）データプロセッサによって実行されるということを認識されたい。
【００３９】
サーバ４３０を含む例示的なコンピューティングシステム環境との関連から説明したが、本発明の実施形態は、その他の多くの汎用または専用のコンピューティングシステム環境または構成と共に使用することができる。このコンピューティングシステム環境は、本発明のいかなる態様の使用や機能の範囲に関しても何らかの限定を提示することを意図するものではない。さらに、このコンピューティングシステム環境は、この例示的な動作環境内に示されているコンポーネントのうちの任意の１つまたは組合せに関して何らかの依存性や必要性を有すると解釈すべきではない。本発明の態様と共に使用するのに適する可能性のあるよく知られているコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスやラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電化製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムやデバイスのうちのいずれかを含む分散コンピューティング環境などを含むが、これらには限定されない。
【００４０】
本発明の実施形態については、１つまたは複数のコンピュータやその他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明することができる。一般にプログラムモジュールは、特定のタスクを実行したり特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含むが、これらには限定されない。本発明の態様は、通信ネットワークを通じてリンクされているリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境においては、プログラムモジュールは、メモリストレージデバイスを含むローカルコンピュータ記憶媒体およびリモートコンピュータ記憶媒体の双方に配置することができる。
【００４１】
ソフトウェアアーキテクチャーのコンテキストにおけるインターフェースは、コンピュータ実行可能命令のソフトウェアモジュール、コンポーネント、コード部分、あるいはその他のシーケンスを含む。このインターフェースは、例えば、第２のモジュールにアクセスする第１のモジュールを含み、この第２のモジュールは、第１のモジュールのためにコンピューティングタスクを実行する。第１のモジュールおよび第２のモジュールは、一例においては、オペレーティングシステムによって提供されるようなＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）、（例えば、ピアツーピアのアプリケーション通信のための）ＣＯＭ（ｃｏｍｐｏｎｅｎｔ ｏｂｊｅｃｔ ｍｏｄｅｌ）インターフェース、および（例えば、ウェブサービスどうしの間における通信のための）ＸＭＩ（extensible markup language metadata interchange format）インターフェースを含む。
【００４２】
このインターフェースは、Ｊ２ＥＥ（Ｊａｖａ（登録商標） ２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）、ＣＯＭまたはＤＣＯＭ（ｄｉｓｔｒｉｂｕｔｅｄ ＣＯＭ）の例におけるような密結合の同期的な実装形態とすることができる。別法として、あるいは追加として、このインターフェースは、（例えばシンプルオブジェクトアクセスプロトコルを使用する）ウェブサービスにおけるような疎結合の非同期的な実装形態とすることもできる。一般に、このインターフェースは、密結合、疎結合、同期、および非同期という特性の任意の組合せを含む。さらに、このインターフェースは、標準的なプロトコル、独自のプロトコル、あるいは標準的なプロトコルと独自のプロトコルとの任意の組合せに準拠することができる。
【００４３】
本明細書に記載されているインターフェースは、すべてを単一のインターフェースの一部とすることもでき、あるいは別々のインターフェースやそれらの任意の組合せとして実装することもできる。これらのインターフェースは、ローカルまたはリモートで実行して、機能を提供することができる。さらに、これらのインターフェースは、本明細書において例示または説明されている機能よりも多い機能を含むこともでき、あるいは少ない機能を含むこともできる。
【００４４】
サーバ４３０は、作動中に、本発明の態様を実施するための、図に示されているようなコンピュータ実行可能命令を実行する。
【００４５】
特段の指定がない限り、本明細書において例示および説明されている本発明の実施形態における動作を実行または実施する順序は、必須ではない。すなわち、これらの動作は、特段の指定がない限り、任意の順序で実施することができ、本発明の実施形態は、本明細書に開示されているよりも多くの動作を含むこともでき、あるいは少ない動作を含むこともできる。例えば特定の動作を、別の動作の前に、別の動作と同時に、あるいは別の動作の後に実行または実施することは、本発明の態様の範囲内に収まるものと考えられる。
【００４６】
本発明の実施形態は、コンピュータ実行可能命令と共に実装することができる。それらのコンピュータ実行可能命令は、コンピュータによって実行可能な１つまたは複数のコンポーネントやモジュールへと編成することができる。本発明の態様は、任意の数および編成のそのようなコンポーネントやモジュールと共に実装することができる。例えば本発明の態様は、本明細書において図示および説明されている特定のコンピュータ実行可能命令や特定のコンポーネントまたはモジュールには限定されない。本発明のその他の実施形態は、本明細書において例示および説明されているよりも多くの機能または少ない機能を有する別のコンピュータ実行可能命令またはコンポーネントを含むことができる。
【００４７】
本発明の態様やその実施形態の要素を紹介する際に、「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞は、それらの要素が１つまたは複数存在するということを意味することを意図している。「ｃｏｍｐｒｉｓｉｎｇ」、「ｉｎｃｌｕｄｉｎｇ」、および「ｈａｖｉｎｇ」という用語は、包括的な意味を意図しており、記載されている要素のほかにさらなる要素が存在しうるということを意味している。
【００４８】
本発明の態様の範囲から逸脱することなく、上述の構造、製品、および方法に様々な変更を行うことができるため、上述の説明に含まれ、添付の図面に示されているすべての内容は、例示として解釈すべきであり、限定的な意味に解釈すべきではないということが意図されている。
【００４９】
付録Ａ
アウトバウンドバッチング：バッチャーコンポーネントは、バッチをカット（ｃｕｔ）するために、すなわちいつバッチが完成するかを判断するために使用されるロジックを含む。またバッチャーコンポーネントは、バッチ内でのメッセージの順序を決めるためなどに使用されるその他の任意のロジックをカプセル化している。メッセージングエンジンコンポーネントは、バッチャーコンポーネント、パイプライン、およびデータベースと対話する役割を果たすコードを含む。
【００５０】
バッチャーコンポーネントは、下記のインターフェースを実装することができる。
【００５１】
【表１】
【００５２】
【表２】
【００５３】
これらのインターフェースに示されているように、スタンダード（ｓｔａｎｄａｒｄ）およびハイパフォーマンス（ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ）という２つのタイプのバッチャーが存在することができる。
【００５４】
スタンダードバッチャーは、メッセージングエンジンが、バッチャーの対話を伴わずにすべてのメッセージパーシスタンスを取り扱えるようにする。バッチャーのタイプは、Ｉｎｉｔｉａｌｉｚｅ（）への呼び出しにおけるｐｒｏｐｅｒｔｙＢａｇでメッセージングエンジンに返される。スタンダードバッチャーの場合には、メッセージングエンジンは、バッチが満たされるまでＡｄｄＭｅｓｓａｇｅ（）へのそれぞれの呼び出しの後にメッセージをインスタンス状態へ自動的にパーシストする。
【００５５】
ハイパフォーマンスバッチャーは、純粋なメモリ内でのバッチングを行うことができ、メッセージをいつパーシストすべきかをメッセージングエンジンに伝える。これらのバッチャーの場合には、メッセージングエンジンは、ＡｄｄＭｅｓｓａｇｅ（）へのそれぞれの呼び出しの後にメッセージをインスタンス状態へパーシストしない。その代わりに、このバッチャーは、メッセージをメモリ内に蓄積することができる。この方法では、バッチが満たされると、バッチャーは、メッセージングエンジン上でＢａｔｃｈＣｏｍｐｌｅｔｅ（）を呼び出し、ＩＢａｓｅＭｅｓｓａｇｅＳｅｔを与えることができる。そしてメッセージングエンジンは、インスタンス状態からメッセージを読み取る必要なしに、パイプラインを直接実行することができる。これらのバッチャーは、メッセージをメモリ内に保持する設定されたしきい値を有することもできる。このバッチャーは、メッセージをディスクにフラッシュ／パーシストしたいときはいつでも、ＰｅｒｓｉｓｔＭｅｓｓａｇｅｓ（）ＡＰＩを呼び出して、メッセージをディスクにフラッシュ／パーシストことができる。このバッチャーがＰｅｒｓｉｓｔＭｅｓｓａｇｅｓ（）を呼び出すと、ＭｅｓｓａｇｅＩＤを用いてＢａｔｃｈＣｏｍｐｌｅｔｅ（）を呼び出すまではメモリ内のすべてのメッセージが必ずパーシストされるようになる。
【００５６】
メッセージングエンジンの対話：
メッセージングエンジンは、バッチ処理の対象とされている送信ポートへ向かうメッセージを得ると、内部のハッシュテーブルを見ることによって、この送信ポート用にバッチャーコンポーネントが既に作成されているかどうかをチェックする。既に作成されているバッチャーコンポーネントがない場合には、メッセージングエンジンは、新たなバッチャーコンポーネントを作成し、そのバッチャーコンポーネント上でＩｎｉｔｉａｌｉｚｅ（）を呼び出す。
【００５７】
そしてエンジンは、そのメッセージ用のバッチャーコンポーネント上でＡｄｄＭｅｓｓａｇｅ（）を呼び出す。このバッチャーコンポーネントは、そのメッセージを見て、バッチが満たされているかどうかを判断する。バッチが満たされている場合には、このバッチャーコンポーネントは、エンジンをコールバックして（ＩＣａｌｌｂａｃｋ）、成功のバッチステータスを示す。バッチが満たされていない場合には、このバッチャーコンポーネントは、その内部状態を更新した後でＡｄｄＭｅｓｓａｇｅ（）から返る。
【００５８】
スタンダードバッチャーの場合、ＡｄｄＭｅｓｓａｇｅが返って、バッチが満たされていないときには、エンジンは、そのメッセージをインスタンス状態に書き込む。その一方で、バッチが完成している場合には、このバッチャーは、ＩＭｅｓｓａｇｅＳｅｔをメッセージングエンジンに返す。エンジンは、ＭｅｓｓａｇｅＩＤＬｉｓｔへのアクセスを試み、このＭｅｓｓａｇｅＩＤＬｉｓｔは、メッセージのメッセージＩＤを正しい順序で有する（このリストに関しては、バッチャーによって任意の種類のソーティングが行われる）。ＭｅｓｓａｇｅＩＤＬｉｓｔが与えられると、エンジンは、メッセージを正しい順序でインスタンス状態から引き出すことを開始することができる。エンジンは、これらのドキュメントからメッセージセットを作成し、そしてパイプラインを実行するためのパイプラインマネージャーにこのメッセージセットを与える。
【００５９】
ハイパフォーマンスバッチャーは、スタンダードバッチャーとは対照的に、ＩＣａｌｌｂａｃｋ上でＰｅｒｓｉｓｔＭｅｓｓａｇｅｓ（）を定期的に呼び出して、メッセージをインスタンス状態へフラッシュする。このバッチに関してさらに多くのメッセージが着信した場合には、エンジンは、以前に作成されたバッチャーコンポーネント上でＡｄｄＭｅｓｓａｇｅ（）を呼び出す。コールバック（ＩＣａｌｌｂａｃｋ）は、ＡｄｄＭｅｓｓａｇｅ（）から同期的に呼び出すこともでき、あるいはバッチャーコンポーネントによって非同期的に呼び出すこともできる。時間に基づいてバッチをカットしなければならない場合には、バッチャーコンポーネントは、そのバッチのためのウィンドウズ（登録商標）タイマを待つ。すなわち、タイムアウトが生じた場合には、エンジンをコールバックして、バッチが完成している旨をエンジンに告げる。バッチが完成している場合には、バッチャーは、ＩＭｅｓｓａｇｅｓｅｔをエンジンに返す。エンジンは、（スタンダードバッチャーの場合と同様に）まずＭｅｓｓａｇｅＩＤＬｉｓｔへのアクセスを試みる。ＭｅｓｓａｇｅＩＤＬｉｓｔが空である場合には、エンジンは、ＭｅｓｓａｇｅＬｉｓｔを読み取ることを試みる。このＭｅｓｓａｇｅＬｉｓｔは、バッチャーがメモリ内でのバッチングを行っている場合には、有効な値を有する。ＭｅｓｓａｇｅＬｉｓｔが存在する場合には、エンジンは、ＩＢａｓｅＭｅｓｓａｅｇＳｅｔを作成し、パイプラインを実行する。
【００６０】
パイプラインの実行：パイプラインマネージャー内のインターフェースによって、エンジンは、メッセージセットを実行用としてパイプラインに与えることができる。そしてパイプラインマネージャーは、メッセージセット内のすべてのメッセージのためにアセンブラ上でＡｄｄＤｏｃｕｍｅｎｔを呼び出し、次いでそれらのメッセージを組み立てる。
【００６１】
独立メッセージバッチング：
メッセージングエンジンは、（独立バッチング用に構成されている）送信ポートのための最初のメッセージがエージェントから受信されると、ダミーのインスタンスを作成する。エンジンは、ＳｅｎｄＰｏｒｔＩＤをバッチャーパイプラインポインタにマップするハッシュテーブルを保持する。任意の時点で、アクティブなバッチャーコンポーネントが１つ存在し、送信ポートへ向かういかなる新たなメッセージも、そのアクティブなバッチャーコンポーネントだけに送られる。その他のバッチャーコンポーネントは、例えばフェイルオーバのシナリオにおいては、非アクティブにすることができる。
【００６２】
従属的メッセージバッチング：
従属的メッセージバッチングの場合には、下記のものが、送信ポート上に構成される。送信ポートは、従属的バッチを形成するために使用されるプロパティをユーザが選択することができるオプションを有する。例えば、選択されたメッセージコンテキストプロパティがＢＴＳ．ＢａｔｃｈＩＤである場合には、その送信ポート用にコンボイサブスクリプション（ｃｏｎｖｏｙ ｓｕｂｓｃｒｉｐｔｉｏｎ）が作成される。それぞれのメッセージは、（ａ）コンボイ用に使用されるプロパティ（ＢＴＳ．ＢａｔｃｈＩＤ）、（ｂ）バッチャーによって使用されるＢＴＳ．ＢａｔｃｈＥｎｄ＝ｔｒｕｅ／ｆａｌｓｅ、（ｃ）やはりバッチャーによって使用されるＢＴＳ．ＢａｔｃｈＳｔａｒｔ＝ｔｒｕｅ／ｆａｌｓｅという特別なメッセージコンテキストプロパティのうちの少なくとも２つを有する。プロパティ（ｂ）および（ｃ）は、Ｂａｔｃｈｅｒプロパティページ内に構成され、送信ポートプロパティ内には現れない。
【００６３】
メッセージの作成元（ワークフロースケジュールやパイプラインサービス）は、自分がこの送信ポート用に発行しているそれぞれのメッセージごとにＢＴＳ．ＢａｔｃｈＩＤをプロモート（ｐｒｏｍｏｔｅ）する。同じＢＴＳ．ＢａｔｃｈＩＤを有するメッセージどうしは、バッチにまとめるために送信ポートの同じインスタンスへ送信される。メッセージの作成元は、いつバッチが完成するかを把握し、ＢＴＳ．ＢａｔｃｈＥｎｄを書き込むことになる。
【００６４】
新たなバッチを開始するために、メッセージの発行者は、（一意の）ＢＴＳ．ＢａｔｃｈＩＤをプロモートし、メッセージを発行する。コンボイテーブル（ｃｏｎｖｏｙ Ｔａｂｌｅ）をチェックした後に、メッセージボックスによって新たなインスタンスが作成される。
【００６５】
同じＢＴＳ．ＢａｔｃｈＩＤを有する後続のメッセージは、メッセージボックスによって同じインスタンス上に送達される。これらのメッセージがメッセージングエンジンに送達される際には、メッセージングエンジンは、それらのメッセージが、従属的メッセージバッチ（送信ポートの構成）であることを既に知っている。エンジンは、ＢＴＳ．ＢａｔｃｈＩＤを正しいバッチャーポインタにハッシュする。
【００６６】
バッチャーは、従属的バッチのために次のことを実行することができる。（ａ）バッチャーは、ＢＴＳ．ＢａｔｃｈＥｎｄプロパティを見て、いつバッチをカットするかを判断する。（ｂ）バッチャーは、障害の場合、例えばユーザがタイムアウトを有することを望む場合を取り扱う。（ｃ）バッチャーは、メッセージをソートする。
【００６７】
エンジンは、上述のようにスタンダードバッチャーかハイパフォーマンスバッチャーかに応じてメッセージを現在のインスタンスのインスタンス状態に書き込むことができる。
【００６８】
バッチが完成すると、エンジンは、アセンブラを実行し、メッセージを送信する。組み立てられたメッセージが首尾よく送信されると（ｄｅｌｅｔｅＭｅｓｓａｇｅ（））、フレームワークインスタンスは、コンボイに応じて作成されたインスタンスを完了する。retries/movetonextTransport/catastrophic failureなど、その他のすべての点については、独立メッセージバッチングと同様である。
【００６９】
インスタンス状態との間における読み出しおよび書き込み：
メッセージがインスタンス状態に書き込まれる際には、フレームワークは、まずｍｅｓｓａｇｅＩＤをインスタンスストリームに書き込む。そして、エージェントＡＰＩ ＡｄｄＭｅｓｓａｇｅＯｂｊｅｃｔ（）を呼び出す。
【００７０】
また、メッセージをインスタンス状態に書き込んでいるときに、フレームワークは、同じトランザクション内でＣｏｍｐｌｅｔｅ（） ｔｈｅ ｏｒｉｇｉｎａｌ ｍｅｓｓａｇｅを受け取って、オリジナルメッセージをＡｐｐｌｉｃａｔｉｏｎＱから削除する。
【００７１】
インスタンス状態からメッセージを読み出すために、フレームワークは、ｍｅｓｓａｇｅＩＤを使用する。すなわちフレームワークは、まずインスタンスストリームを読み取ってｍｅｓｓａｇｅＩＤを入手し、次いでそれらのｍｅｓｓａｇｅＩＤを使用してメッセージを入手する。ｍｅｓｓａｇｅＩＤによってメッセージを引き出すステップは、順序も保持する。
【００７２】
インスタンスのフェイルオーバ：
プロセスが何らかの壊滅的な障害のために機能しなくなった場合には、メッセージボックスは、次にそのプロセスが復活したあたりでダミーのメッセージを作成する。メッセージングエンジンは、このダミーのメッセージを受信し、このメッセージが、バッチ処理の対象とされている送信ポートに対応していることを識別することができる。すなわち、そのインスタンスに関する最初のメッセージについてインスタンス状態に書き込みを行う前に、メッセージングエンジンは、送信先のＳｅｎｄＰｏｒｔＩＤおよびその他の関連する情報をインスタンス状態ストリームに書き込む。
【００７３】
送信ポートが、独立メッセージバッチ用に構成されている場合には、あるインスタンスがフェイルオーバすると、そのインスタンスは、使用中のアクティブなバッチャーを既に有しているメッセージングエンジンインスタンスに返すことができる。したがって、生きている／ダミーのメッセージがメッセージングエンジンによって受信されると、メッセージングエンジンは、同じスレッド内でインスタンス状態の中に保存されているバッチ全体を空にする。メッセージングエンジンは、新たなバッチャーオブジェクトを作成し、そのバッチャーオブジェクトを初期化する。メッセージングエンジンによってバッチャーに渡されるｐｒｏｐｅｒｔｙｂａｇは、これが、フェイルオーバされたインスタンスであるということを示す。また、可能な場合には、メッセージングエンジンは、バッチ内のメッセージの数も提供する。そしてメッセージングエンジンは、インスタンス状態からすべてのメッセージを読み出し、バッチャー上でＡｄｄＭｅｓｓａｇｅ（）を呼び出す。バッチャーは、最後のメッセージを受信すると、メッセージングエンジン上でＢａｔｃｈＣｏｍｐｌｅｔｅ（）を呼び出す。
【００７４】
バッチャーがどのように構成されているかに応じて、バッチを合格または不合格にすることができる。バッチが不合格にされた場合には、メッセージングエンジンは、そのバッチ内のすべてのメッセージを一時停止する。
【００７５】
送信移送機能：
伝送の成功：アダプタは、パイプラインから来たメッセージ上でＤｅｌｅｔｅＭｅｓｓａｇｅ（）を呼び出す。Ｑからのメッセージは、ｃｏｍｐｌｅｔｅｄ（）を既に受け取られているため、ＩｎｓｔａｎｃｅＳｔａｔｅ内のメッセージは削除される。インスタンス状態からメッセージを削除するために、フレームワークは、エージェントＡＰＩ ＲｅｌｅａｓｅＭｅｓｓａｇｅ（）を呼び出す。
【００７６】
再送信：Ｑからのメッセージは、ｃｏｍｐｌｅｔｅｄ（）を既に受け取られているため、フレームワークは、ＩｎｓｔａｎｃｅＳｔａｔｅ内にあるメッセージの再送を試みる。再試行間隔の後に戻るタイマメッセージが通知される。メッセージングエンジンがそのタイマメッセージを見ると、インスタンス状態からメッセージを読み出すステップが再始動し、処理が再開する。再び、ｍｅｓｓａｇｅＩＤがインスタンスストリームから順に読み出され、そしてメッセージがインスタンス状態から引き出される。
【００７７】
ＭｏｖｅＴｏＮｅｘｔＴｒａｎｓｐｏｒｔ：メッセージングエンジンは、メッセージをインスタンスに通知する。このメッセージのバックアップになると、メッセージングエンジンは、このメッセージがバックアップトランスポート（ｂａｃｋｕｐ ｔｒａｎｓｐｏｒｔ）に移動されてきていることを認識し、インスタンス状態からメッセージを排出しようと試み、バッチを処理する。
【００７８】
ＳｕｓｐｅｎｄＭｅｓｓａｇｅ：ＩｎｓｔａｎｃｅＳｔａｔｅの内部のメッセージは、インスタンス状態から引き出され、ＳｕｓｐｅｎｄＭｅｓｓａｇｅｓ（ＭｅｓｓａｇｅＩｄ［］）ＡＰＩを使用して一時停止され、そのＳｕｓｐｅｎｄＭｅｓｓａｇｅｓ（ＭｅｓｓａｇｅＩｄ［］）ＡＰＩは、これらのメッセージをインスタンス状態からｓｕｓｐｅｎｄＱに移動させる。あるいは、メッセージをダミーのインスタンスに通知して、そのダミーのインスタンスを一時停止することもできる。メッセージが再開されると、インスタンス状態は空にされる。
【００７９】
バッチ処理の対象とされている送信ポートはまた、順序付けられた送達のためにマークされる：これが行われる際には、メッセージングエンジンは、独立したバッチの場合でさえ、その送信ポートのためのダミーのインスタンスを作成しない。メッセージングエンジンは、その順序付けられた送信ポートのためのデフォルトのインスタンスに対応するインスタンス状態を自動的に使用する。エージェント送達スレッド（ａｇｅｎｔ ｄｅｌｉｖｅｒｙ ｔｈｒｅａｄ）を断念する前に、メッセージングエンジンは、そのメッセージが送信されたかまたは失敗したかをアダプタが確認できるようにブロックを行う（バッチ上でのコールバック）という事実において、動作がわずかに変化するかもしれない。
【００８０】
トラッキング：送信パイプラインへの入力メッセージと、出力メッセージとの間にリンクを保持することができる。あるメッセージがａｐｐｌｉｃａｔｉｏｎＱからインスタンス状態へ移動されると、そのメッセージ上でＲｅｃｅｉｖｅＣｏｍｐｌｅｔｅ（）を呼び出すと、そのメッセージは、ａｐｐｌｉｃａｔｉｏｎＱから削除される。これが行われる際のＨＡＴにおけるステータスは、メッセージが完全に処理される際に示されるステータスとは区別することができる（すなわち、ＤｅｌｅｔｅＭｅｓｓａｇｅ（）−がＲｅｃｅｉｖｅＣｏｍｐｌｅｔｅ（）に変わる）。
【図面の簡単な説明】
【００８１】
【図１】従来技術による構造化されたメッセージのコンピュータどうしでのやり取りを示す流れ図である。
【図２】本発明の一実施形態によるメッセージ集約のためのコンピューティングシステム環境を示すブロック図である。
【図３】本発明の一実施形態によるメッセージ集約を示す例示的な流れ図である。
【図４】本発明を実装することができる適切なコンピューティングシステム環境の一例を示すブロック図である。
【技術分野】
【０００１】
本発明は、ポリシーベースのメッセージ集約フレームワークに関する。
【背景技術】
【０００２】
今日のグローバル経済においては、企業は、多くの場合、様々なソースからアプリケーション、システム、およびテクノロジーを統合する必要がある。通常、これらの企業は、合意されたメッセージ標準によって、あるコンピュータアプリケーションから別のコンピュータアプリケーションへ電子的な手段によって、かつ人間の介入を最小限に抑えて、構造化された情報をコンピュータどうしでやり取りするためのシステムを作成する。メッセージ標準の例としては、ヘルスケア関連の臨床データおよび管理データのためのＨＬ７（Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ）、製品、資産、サービス、および場所に関する情報を識別および通信するためのＧＳ１システム、金融データのためのＳＷＩＦＴ、および様々なビジネス取引データを転送するための合意されたメッセージ標準によって、構造化された情報をやり取りするためのＥＤＩが含まれる。
【０００３】
図１に示されているように、ある企業は、様々なメッセージフォーマットで様々な提携先と通信する可能性がある。例えば、その企業は、ＸＭＬフォーマットで顧客と通信する可能性があり、その企業は、ＥＤＩまたはＦｌａｔ Ｆｉｌｅメッセージフォーマットでサプライヤアプリケーションと通信する可能性があり、その企業は、ＳＷＩＦＴメッセージフォーマットで金融アプリケーションと通信する可能性があり、またその企業は、その他の何らかの業界標準メッセージフォーマットでロジスティクスアプリケーションと通信する可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
残念なことに、メッセージの数が増えて多様になると、典型的な企業においては、通信が複雑になり、非効率がもたらされる。メッセージを集約するためのソリューションをカスタムソフトウェアコードで書くことができるが、そのようなソリューションは、企業における複雑さおよびコストを増大させるものであり、また特定の状況に適しているにすぎない。
【課題を解決するための手段】
【０００５】
本発明の態様は、構造化されたメッセージをコンピュータどうしでやり取りする公知の形態における１つまたは複数の欠陥を克服する。拡張可能な、ポリシーベースのメッセージ集約フレームワークが、メッセージをバッチへと集約し、それによって、複数のメッセージを単一の出力ストリームとして送信先アプリケーション（ｄｅｓｔｉｎａｔｉｏｎ ａｐｐｌｉｃａｔｉｏｎ）へ伝送することができる。
【０００６】
一態様においては、本発明は、ポリシーベースのメッセージ集約を含み、ここでの集約は、メッセージをバッチへと集約するために使用されるビジネスロジックを含むポリシーに基づく。別の態様においては、本発明は、アプリケーションベースのメッセージ集約を含み、この集約では、送信元アプリケーション（ｓｏｕｒｃｅ ａｐｐｌｉｃａｔｉｏｎ）が、メッセージ内にインジケータを設定し、それらのインジケータは、バッチにまとめるべきメッセージを識別し、そのバッチが完成するときに知らせる。
【０００７】
典型的な企業は、重要なビジネス上のコミュニケーションに関連する多くのメッセージを作成するため、本発明の態様を具体化するメッセージ集約システムは、信頼性および拡張性が高い。また、メッセージを蓄積し、そしてそれらのメッセージを伝送するのに使用される通信媒体に関するコストが最も低いときにそれらのメッセージを送信することによってコストを下げるために、およびメッセージの束を一度に伝送して、単一のメッセージを送信することに関連するオーバヘッドを低減することによってパフォーマンスを高めるために、メッセージの集約を実施することもできる。
【０００８】
メッセージ集約のためのコンピュータ実行可能命令を有するコンピュータ可読媒体が、本発明のさらなる態様を具体化する。あるいは本発明の実施形態は、その他の様々な方法および装置を含むこともできる。
【０００９】
この概要は、以降の「発明を実施するための最良の形態」においてさらに説明するコンセプトから抜粋したものを、簡略化された形式で紹介するために提供されている。この「課題を解決するための手段」は、特許請求されている主題の鍵となる特徴や必要不可欠な特徴を特定することを意図するものではなく、特許請求されている主題の範囲を確定する際の補助として使用されることを意図するものでもない。
【００１０】
その他の特徴については、一部は明らかであろうし、また一部は以降で指摘する。
【００１１】
対応する参照文字は、複数の図面を通じて、対応する部分を指す。
【発明を実施するための最良の形態】
【００１２】
図面を参照すると、図２は、メッセージ集約のためのコンピューティングシステム環境の一実施形態を示している。複数のビジネスニーズを満たすためにメッセージの集約を実施することができる。例えば、ある企業は、様々なメッセージフォーマットで様々な提携先と通信する。メッセージの集約によって、指定の時点において通信を提供しながら、より低いコストでパフォーマンスを高めることができる。この例においては、この企業は、毎週１回サプライヤに用品を注文するというポリシーを有しているかもしれない。あるアプリケーションは、この企業が、サプライヤに宛てたメッセージを作成することによってその週の間中用品を注文することを可能にすることができる。本発明の実施形態は、これらのメッセージを、実行処理のためにサプライヤのアプリケーションへ毎週１回伝送するための、企業における１つのバッチへと集約することができる。
【００１３】
別の例として、ある企業が、顧客から多数の購入注文を受けていると想像していただきたい。それぞれの顧客の購入注文を実行するために、この企業は、提携先企業に品物を注文し、そしてこの企業は、ＥＤＩを使用してその提携先に注文を伝達する。しかし、その提携先企業への接続は、１日の特定の時間にしか利用できない。したがって、この企業は、その提携先に関するすべての注文を蓄積して、それらの注文を１日の適切な時間中に送信する必要がある。さらに企業は、多くの場合、提携先への接続時間の代金を支払わなければならない。この場合、すべてのメッセージを束ねて、数時間ごとに１回程度接続を開き、メッセージの単一の束を一度に伝送することが有利である。さらに本発明の態様は、ＸＭＬ、ＥＤＩ、Ｆｌａｔ Ｆｉｌｅ、ＳＷＩＦＴ、あるいはその他の何らかの業界標準メッセージフォーマットなど、様々なメッセージフォーマットでメッセージを集約することができる。
【００１４】
図２に示されているように、送信元アプリケーション２０２が、メッセージを作成し、送信する。送信ポートに宛てられたメッセージを送信することは、当業者にはよく知られている。メッセージングエンジン２０４が、それぞれのメッセージを受信し、メッセージアドレスにおいて送信ポートに関連付けられている１つまたは複数のバッチャー（ｂａｔｃｈｅｒ）２０６が、本発明の態様に従ってメッセージを受信し、集約する。一実施形態においては、送信元アプリケーション２０２および送信先アプリケーション２１２は、エンドポイントを介してメッセージングエンジン２０４と通信する。エンドポイントとは、ある場所の（例えば、ＵＲＬ形式で表された）論理的な表示であり、受信または送信されるデータのための物理アドレスを提供する。この実施形態におけるエンドポイントは、双方向のものであり、メッセージングエンジン２０４内へメッセージをくみ上げるために、ならびにメッセージングエンジン２０４からメッセージを出すために使用される。
【００１５】
別の実施形態においては、メッセージングエンジン２０４はまた、メッセージをデータストア２０８へ書き込む。バッチ内のメッセージどうしが相互に独立している場合には、本発明の態様は、ビジネス構成ポリシー（ｂｕｓｉｎｅｓｓ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｏｌｉｃｙ）によって定義されている選択されたパラメータに基づいてそれらのメッセージを組み立てることができる。例えばバッチ構成ポリシー（ｂａｔｃｈ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｏｌｉｃｙ）は、バッチ内のメッセージの数、バッチ内の累積バイト数、バッチ内のメッセージのタイプ、および／またはメッセージを蓄積するための時間を決定するために使用されるビジネスロジックを含む。
【００１６】
一実施形態においては、バッチャー２０６は、送信ポート上に構成される（例えば、ＢａｔｃｈｅｒＴｙｐｅ ＆ ＢａｔｃｈｅｒＬｏｃａｔｉｏｎ）。例えば、このためにアダプタフレームワークコードベース（ａｄａｐｔｅｒ ｆｒａｍｅｗｏｒｋ ｃｏｄｅ ｂａｓｅ）を活用することができ、そしてそのアダプタフレームワークコードベースによって、この構成およびその他の送信ポート構成情報を保存するためのインターフェースが実装される。付録Ａは、バッチャーインターフェース（ｂａｔｃｈｅｒ ｉｎｔｅｒｆａｃｅ）を含む、本発明の態様を具体化するアウトバウンドバッチング（ｏｕｔｂｏｕｎｄ ｂａｔｃｈｉｎｇ）のためのメッセージングフレームワークの例示的な一実装形態を示している。
【００１７】
別の実施形態においては、メッセージングエンジン２０４は、１つまたは複数のバッチャー２０６に関するインスタンス状態４０２（図４を参照されたい）を保持する。インスタンス状態４０２は、バッチャー２０６に関連付けられている送信ポートと、その送信ポートに宛てられているメッセージのリストとを含む。インスタンス状態４０２は、データストア２０８内に保存することができる。それらのインスタンス状態は、システム障害の場合にそれぞれのバッチャーインスタンスに対応するメッセージを検索するために使用される。
【００１８】
特定の送信ポートに関連付けられているバッチャー２０６が存在しない場合には、メッセージングエンジン２０４が、そのバッチャー２０６を作成することになる。それぞれのバッチャー２０６を動的に作成することによって、必要に応じてバッチャーが作成され、それによって、このメッセージ集約システムの拡張性が促進される。さらに、バッチャー２０６を動的に作成することは、使用されていないバッチャーのオーバヘッドをなくすこと、およびメッセージングエンジン２０４が、アクティブなバッチャー２０６に関してのみインスタンス状態４０２を管理できるようにすることによって、システムパフォーマンスを補助する。
【００１９】
インスタンス状態４０２およびメッセージをデータストア２０８内に保存することによって、システム障害の場合にバッチを回復することができる。一実施形態においては、再開後に、メッセージングエンジン２０４は、障害時に進行していたバッチのインスタンス状態４０２にアクセスすることができる。それぞれのインスタンス状態４０２ごとに、メッセージングエンジン２０４は、バッチャー２０６のインスタンスを作成する。インスタンス状態４０２のメッセージリスト内のそれぞれのメッセージごとに、メッセージングエンジン２０４は、それらのメッセージをバッチャー２０６に再送する。リスト内のそれらのメッセージがバッチャー２０６に再送されると、そのバッチは、障害時と同じ状態になる。
【００２０】
例えばインスタンス状態４０２は、アプリケーションインスタンス（この場合は、Ａｓｓｅｍｂｌｅｒ／Ｂａｔｃｈｅｒ Ｉｎｓｔａｎｃｅ）の状態を保存するための場所である。アプリケーションインスタンスに対応するメッセージは、データストア内に保存されるが、アプリケーションがインスタンス情報を検索して障害後に処理を継続できるように、アプリケーションインスタンスの状態に関する情報を保存する必要もある。サブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）は、インスタンス状態とは無関係である。サブスクリプションテーブルは、特定の条件を満たすメッセージを受信する（Ｓｅｒｖｉｃｅ ＩＤによって識別される）サービスのリストを定義する。メッセージがメッセージボックス（例えばデータストア１０８）に発行されると、メッセージボックスは、条件を評価し、どのサービスがそのメッセージを受信することになるかを識別する。そしてメッセージボックスは、そのサービスの論理インスタンスを「Ｉｎｓｔａｎｃｅｓ」テーブル内に作成し、そのメッセージ上に「ＩｎｓｔａｎｃｅＩＤ」をスタンプしてからそのメッセージをメッセージングエンジン２０４へ送信する。
【００２１】
別の実施形態においては、メッセージは、バッチャー２０６に関連付けられているバッチャー識別子を含む。この実施形態においては、メッセージボックスは、特定の条件を満たすメッセージを受信する（Ｓｅｒｖｉｃｅ ＩＤによって識別される）サービスのリストを定義するサブスクリプションテーブル４０８を保持する。メッセージボックスは、送信元アプリケーション２０２からメッセージを受信する。そのメッセージがメッセージボックスに発行されると、メッセージボックスは、条件を評価し、どのサービスがそのメッセージを受信することになるかを判断する。そして、そのサービスのためのバッチャー２０６のインスタンスが存在しない場合には、メッセージボックスがそのインスタンスを作成する。次いでメッセージボックスは、そのメッセージをメッセージングエンジン２０４へ送信する。メッセージングエンジン２０４は、バッチ識別子をハッシュして、バッチャー２０６の正しいインスタンスを特定する。そしてメッセージングエンジン２０４は、特定したバッチャー２０６にメッセージを送信する。
【００２２】
バッチャー２０６は、メッセージを受信すると、メッセージのバッチが完成しているかどうかを判断する。一実施形態においては、バッチャー２０６は、バッチ構成ポリシーに関してそのバッチが完成しているかどうかを判断する。バッチ構成ポリシーは、いつバッチが完成するかを判断するために使用されるビジネスロジックを含む。このビジネスロジックは、バッチ内のメッセージの数、バッチ内の累積バイト数、バッチ内のメッセージのタイプ、およびメッセージを蓄積するための時間のうちの１つまたは複数を含むことができる。別の実施形態においては、ビジネスロジックは、バッチ内のメッセージに関する所望のソート順序を含むことができ、これによってバッチャー２０６は、バッチ内のメッセージをソートすることができる。
【００２３】
メッセージアドレスにおいて送信ポートに関連付けられているバッチャー２０６が、本発明の態様に従ってメッセージを受信し、集約する。上述のように、バッチ内のメッセージどうしは、相互に独立することができる。別の実施形態においては、バッチ内のメッセージどうしは相互に依存し、それらのメッセージを作成しているコードは、新たなバッチがいつ開始されることになるか、そしてそのバッチがいつ完成するべきかを把握している。この実施形態においては、メッセージは、バッチ完成インジケータ（ｂａｔｃｈ ｅｎｄ ｉｎｄｉｃａｔｏｒ）を含む。そのバッチが完成していることをバッチ完成インジケータが示しているならば、バッチャー２０６は、そのバッチを完成したことになる。
【００２４】
バッチャー２０６は、バッチが完成していると判断すると、そのバッチをメッセージングエンジン２０４へ返す。メッセージングエンジン２０４は、そのバッチをアセンブラ２１０へ送信する。次にアセンブラ２１０は、そのバッチ内のすべてのメッセージを順番に並べて、単一の出力ストリームにする。ある代替実施形態においては、バッチャー２０６が自ら、バッチにまとめられたすべてのメッセージを順番に並べて、単一の出力ストリームにする。アセンブラ２１０は、そのメッセージストリームを、それらのメッセージを受信するように設計されているアプリケーションに関連付けられている送信先アプリケーション２１２へ送信する。
【００２５】
図３は、メッセージ集約の一実施形態の態様を示す例示的な流れ図である。３０２において、メッセージングエンジン２０４は、送信ポートに宛てられているメッセージを送信元アプリケーション２０２から受信する。３０４において、メッセージングエンジン２０４は、送信ポートに関連付けられているバッチャー２０６のインスタンスが存在することを確認する。送信ポートに関連付けられているバッチャー２０６のインスタンスが存在する場合には、その関連付けられているバッチャー２０６が、共通の送信ポートに宛てられているメッセージを集約する。一方、送信ポートに関連付けられているバッチャー２０６が存在しない場合には、そのバッチャーのインスタンスが、３０６において作成される。
【００２６】
別の実施形態においては、メッセージは、特定のバッチャー２０６に関連付けられているバッチャー識別子を含む。この実施形態においては、本発明の態様は、そのバッチ識別子に関連付けられているバッチャー２０６のインスタンスが存在することを確認するためにチェックを実行する。バッチ識別子に関連付けられているバッチャー２０６が存在しない場合には、そのバッチャーのインスタンスが、３０６において作成される。
【００２７】
図３をさらに参照すると、メッセージングエンジン２０４は、３０８において、メッセージアドレスにおいて送信ポートに関連付けられているバッチャー２０６へメッセージを送信する。３１０において、バッチャー２０６は、メッセージのバッチが完成しているかどうかを判断する。一実施形態においては、バッチャー２０６は、バッチ構成ポリシーに関してそのバッチが完成しているかどうかを判断し、そのバッチ構成ポリシーは、この判断を行うために使用されるビジネスロジックを含む。上述のように、このビジネスロジックは、バッチ内のメッセージの数、バッチ内の累積バイト数、バッチ内のメッセージのタイプ、およびメッセージを蓄積するための時間のうちの１つまたは複数を含むことができる。有利なことに、顧客は、バッチ構成ポリシーによってメッセージをバッチにまとめるための独自の基準を設定することができる。さらにバッチャー２０６は、バッチ構成ポリシーによって定義されている所望のソート順序に従ってバッチ内のメッセージをソートすることができる。
【００２８】
３１０において、バッチが完成していないとバッチャー２０６が判断した場合には、そのバッチのインスタンス状態４０２が、３１２において更新されることになる。インスタンス状態４０２は、バッチャー２０６に関連付けられている送信ポートと、その送信ポートに宛てられているメッセージのリストとを含む。インスタンス状態４０２は、データストア２０８内に保存することができる。一方、３１０において、バッチが完成しているとバッチャー２０６が判断した場合には、３１４において、そのバッチからメッセージセットが作成される。３１６において、バッチャー２０６は、そのメッセージセットをアセンブラへ送信し、そのアセンブラでは、メッセージが、送信先アプリケーション２１２へ単一の出力ストリームで送信される。送信先アプリケーション２１２は、例えば顧客アプリケーション、サプライヤアプリケーション、あるいは金融アプリケーションとすることができる。出力ストリームは、送信先アプリケーション２１２により指定されたように、ＥＤＩフォーマット、ＳＷＩＦＴフォーマット、ＧＳ１システム、ＨＬ７、あるいはその他の何らかの業界標準フォーマットのものとすることができる。出力ストリームが送信されると、３１２において、バッチャーのインスタンス状態４０２が更新される。
【００２９】
一実施形態においては、メッセージングエンジン２０４が、３１４においてバッチャーのためのメッセージセットを作成している間に、または３１６においてそのメッセージセットをアセンブラへ送信している間に、３０２においてバッチャー２０６のための新たなメッセージが受信された場合には、メッセージングエンジン２０４は、３０８においてバッチャー２０６の新たなインスタンスを作成することになる。処理は、バッチャー２０６のこの新たなインスタンスに関して３０６から続くことになる。これによって、メッセージングエンジン２０４は、並行バッチ（ｃｏｎｃｕｒｒｅｎｔ ｂａｔｃｈｅｓ）を処理することができ、ここでバッチャー２０６の新たなインスタンスに関して新たなバッチが開始される一方、１つのバッチがアセンブラ２１０へ送信される。
【００３０】
例えば、バッチが完成しているとバッチャー２０６が判断した場合には、メッセージングエンジン２０４は、そのことに留意し、単一の出力ストリームをアセンブラ２１０に渡す。しかし、その間にメッセージングエンジン２０４が、その同じ送信ポートのための新たなメッセージを受信した場合には、メッセージングエンジン２０４は、前のバッチが完成していることを認識し、新たなバッチャー２０６を、したがって新たなバッチを作成することになる。複数のインフライトバッチャー（ｉｎｆｌｉｇｈｔ ｂａｔｃｈｅｒ）２０６が、「ｂａｔｃｈｅｒＩＤ」によって識別される。
【００３１】
図４は、汎用コンピューティングデバイスの一例をサーバ４３０の形態で示している。本発明の一実施形態においては、サーバ４３０などのサーバは、本明細書で例示および説明されているその他の図において使用することにも適している。サーバ４３０は、１つまたは複数のプロセッサまたは処理装置と、システムメモリとを有する。図示されている実施形態においては、システムバスは、システムメモリを含む様々なシステムコンポーネントをプロセッサに結合している。
【００３２】
サーバ４３０は通常、少なくとも何らかの形態のコンピュータ可読媒体を有する。コンピュータ可読媒体は、揮発性媒体および不揮発性媒体、ならびに取り外し可能な媒体および固定の媒体の双方を含み、サーバ４３０によってアクセスできる利用可能な任意の媒体とすることができる。例えばコンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むが、これらには限定されない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータなどの情報を記憶するための任意の方法や技術において実装される揮発性媒体および不揮発性媒体、ならびに取り外し可能な媒体および固定の媒体を含む。例えばコンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、またはその他の光ディスクストレージ、磁気カセット、磁気テープ、データストア１０８などの磁気ディスクストレージ、またはその他の磁気ストレージデバイス、あるいは所望の情報を記憶するために使用可能で、サーバ４３０によってアクセス可能なその他の任意の媒体を含む。通信媒体は通常、搬送波やその他の伝送メカニズムなどの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータを具体化し、任意の情報伝達媒体を含む。変調されたデータ信号とは、当業者にはよく知られたものであり、情報をその信号内でコード化するような方法で設定または変更されたその特性のうちの１つまたは複数を有する。有線ネットワークや直接有線接続などの有線媒体、および音響媒体、ＲＦ媒体、赤外線媒体、その他の無線媒体などの無線媒体は、通信媒体の例である。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。
【００３３】
サーバ４３０は、その他の取り外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。この例示的な動作環境において使用することができるその他の取り外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これらには限定されない。
【００３４】
図４に示されている上述のドライブ、またはその他のマスストレージデバイス、およびそれらに関連付けられているコンピュータ記憶媒体は、サーバ４３０のためのコンピュータ可読命令、データ構造、プログラムモジュール１０２、１０４、１０６、１１０、およびその他のデータ４０２、４０４の記憶を提供する。
【００３５】
サーバ４３０は、リモートサーバ４０６Ａ、４０６Ｂ、４０６Ｃなどの１つまたは複数のリモートサーバへの論理接続を使用して、ネットワーク化された環境内で機能することができる。リモートサーバは、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいはその他の一般的なネットワークノードとすることができ、通常は、サーバ４３０に関連する上述の要素の多くまたはすべてを含む。図４に示されている論理接続は、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）およびＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）を含むが、その他のネットワークを含むこともできる。ＬＡＮおよび／またはＷＡＮは、有線ネットワーク、無線ネットワーク、それらの組合せなどとすることができる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、および全世界規模のコンピュータネットワーク（例えばインターネット）においてよく見受けられる。
【００３６】
ローカルエリアネットワーキング環境において使用する場合には、サーバ４３０は、ネットワークインターフェースまたはアダプタを通じてＬＡＮに接続される。ワイドエリアネットワーキング環境において使用する場合には、サーバ４３０は通常、インターネットなどのＷＡＮ上で通信を確立するためのモデムやその他の手段を含む。モデムは、内蔵型とすることもでき、あるいは外付け型とすることもでき、ユーザ入力インターフェースやその他の適切なメカニズムを介してシステムバスに接続される。ネットワーク化された環境においては、コンピュータ１３０に関連して示されているプログラムモジュールやそれらの一部をリモートメモリストレージデバイス（図示せず）内に格納することができる。示されているネットワーク接続は例示的なものであり、コンピュータどうしの間に通信リンクを確立するその他の手段を使用することもできる。
【００３７】
一般にサーバ４３０のデータプロセッサは、別々の時点でコンピュータの様々なコンピュータ可読記憶媒体内に格納された命令によってプログラムされる。プログラムおよびオペレーティングシステムは通常、例えばフロッピー（登録商標）ディスクやＣＤ−ＲＯＭで配布される。そこから、これらはコンピュータの２次メモリ内へインストールまたはロードされる。実行時には、これらは少なくとも一部がコンピュータの１次電子メモリ内へロードされる。これらおよびその他の様々なタイプのコンピュータ可読記憶媒体が、後述のステップを実施するための命令やプログラムをマイクロプロセッサやその他のデータプロセッサと共に含む場合には、そのような媒体は、本明細書に記載されている本発明の態様に含まれる。さらに、コンピュータが、本明細書に記載の方法および技術に従ってプログラムされる場合には、そのコンピュータ自体も本発明の態様に含まれる。
【００３８】
例示の目的から、オペレーティングシステムなどのプログラムおよびその他の実行可能なプログラムコンポーネントは、本明細書では別個のブロックとして示されている。しかし、そのようなプログラムおよびコンポーネントは、様々な時点においてコンピュータの別々のストレージコンポーネント内に存在し、コンピュータの（１つまたは複数の）データプロセッサによって実行されるということを認識されたい。
【００３９】
サーバ４３０を含む例示的なコンピューティングシステム環境との関連から説明したが、本発明の実施形態は、その他の多くの汎用または専用のコンピューティングシステム環境または構成と共に使用することができる。このコンピューティングシステム環境は、本発明のいかなる態様の使用や機能の範囲に関しても何らかの限定を提示することを意図するものではない。さらに、このコンピューティングシステム環境は、この例示的な動作環境内に示されているコンポーネントのうちの任意の１つまたは組合せに関して何らかの依存性や必要性を有すると解釈すべきではない。本発明の態様と共に使用するのに適する可能性のあるよく知られているコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスやラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電化製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムやデバイスのうちのいずれかを含む分散コンピューティング環境などを含むが、これらには限定されない。
【００４０】
本発明の実施形態については、１つまたは複数のコンピュータやその他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明することができる。一般にプログラムモジュールは、特定のタスクを実行したり特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含むが、これらには限定されない。本発明の態様は、通信ネットワークを通じてリンクされているリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境においては、プログラムモジュールは、メモリストレージデバイスを含むローカルコンピュータ記憶媒体およびリモートコンピュータ記憶媒体の双方に配置することができる。
【００４１】
ソフトウェアアーキテクチャーのコンテキストにおけるインターフェースは、コンピュータ実行可能命令のソフトウェアモジュール、コンポーネント、コード部分、あるいはその他のシーケンスを含む。このインターフェースは、例えば、第２のモジュールにアクセスする第１のモジュールを含み、この第２のモジュールは、第１のモジュールのためにコンピューティングタスクを実行する。第１のモジュールおよび第２のモジュールは、一例においては、オペレーティングシステムによって提供されるようなＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）、（例えば、ピアツーピアのアプリケーション通信のための）ＣＯＭ（ｃｏｍｐｏｎｅｎｔ ｏｂｊｅｃｔ ｍｏｄｅｌ）インターフェース、および（例えば、ウェブサービスどうしの間における通信のための）ＸＭＩ（extensible markup language metadata interchange format）インターフェースを含む。
【００４２】
このインターフェースは、Ｊ２ＥＥ（Ｊａｖａ（登録商標） ２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）、ＣＯＭまたはＤＣＯＭ（ｄｉｓｔｒｉｂｕｔｅｄ ＣＯＭ）の例におけるような密結合の同期的な実装形態とすることができる。別法として、あるいは追加として、このインターフェースは、（例えばシンプルオブジェクトアクセスプロトコルを使用する）ウェブサービスにおけるような疎結合の非同期的な実装形態とすることもできる。一般に、このインターフェースは、密結合、疎結合、同期、および非同期という特性の任意の組合せを含む。さらに、このインターフェースは、標準的なプロトコル、独自のプロトコル、あるいは標準的なプロトコルと独自のプロトコルとの任意の組合せに準拠することができる。
【００４３】
本明細書に記載されているインターフェースは、すべてを単一のインターフェースの一部とすることもでき、あるいは別々のインターフェースやそれらの任意の組合せとして実装することもできる。これらのインターフェースは、ローカルまたはリモートで実行して、機能を提供することができる。さらに、これらのインターフェースは、本明細書において例示または説明されている機能よりも多い機能を含むこともでき、あるいは少ない機能を含むこともできる。
【００４４】
サーバ４３０は、作動中に、本発明の態様を実施するための、図に示されているようなコンピュータ実行可能命令を実行する。
【００４５】
特段の指定がない限り、本明細書において例示および説明されている本発明の実施形態における動作を実行または実施する順序は、必須ではない。すなわち、これらの動作は、特段の指定がない限り、任意の順序で実施することができ、本発明の実施形態は、本明細書に開示されているよりも多くの動作を含むこともでき、あるいは少ない動作を含むこともできる。例えば特定の動作を、別の動作の前に、別の動作と同時に、あるいは別の動作の後に実行または実施することは、本発明の態様の範囲内に収まるものと考えられる。
【００４６】
本発明の実施形態は、コンピュータ実行可能命令と共に実装することができる。それらのコンピュータ実行可能命令は、コンピュータによって実行可能な１つまたは複数のコンポーネントやモジュールへと編成することができる。本発明の態様は、任意の数および編成のそのようなコンポーネントやモジュールと共に実装することができる。例えば本発明の態様は、本明細書において図示および説明されている特定のコンピュータ実行可能命令や特定のコンポーネントまたはモジュールには限定されない。本発明のその他の実施形態は、本明細書において例示および説明されているよりも多くの機能または少ない機能を有する別のコンピュータ実行可能命令またはコンポーネントを含むことができる。
【００４７】
本発明の態様やその実施形態の要素を紹介する際に、「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞は、それらの要素が１つまたは複数存在するということを意味することを意図している。「ｃｏｍｐｒｉｓｉｎｇ」、「ｉｎｃｌｕｄｉｎｇ」、および「ｈａｖｉｎｇ」という用語は、包括的な意味を意図しており、記載されている要素のほかにさらなる要素が存在しうるということを意味している。
【００４８】
本発明の態様の範囲から逸脱することなく、上述の構造、製品、および方法に様々な変更を行うことができるため、上述の説明に含まれ、添付の図面に示されているすべての内容は、例示として解釈すべきであり、限定的な意味に解釈すべきではないということが意図されている。
【００４９】
付録Ａ
アウトバウンドバッチング：バッチャーコンポーネントは、バッチをカット（ｃｕｔ）するために、すなわちいつバッチが完成するかを判断するために使用されるロジックを含む。またバッチャーコンポーネントは、バッチ内でのメッセージの順序を決めるためなどに使用されるその他の任意のロジックをカプセル化している。メッセージングエンジンコンポーネントは、バッチャーコンポーネント、パイプライン、およびデータベースと対話する役割を果たすコードを含む。
【００５０】
バッチャーコンポーネントは、下記のインターフェースを実装することができる。
【００５１】
【表１】
【００５２】
【表２】
【００５３】
これらのインターフェースに示されているように、スタンダード（ｓｔａｎｄａｒｄ）およびハイパフォーマンス（ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ）という２つのタイプのバッチャーが存在することができる。
【００５４】
スタンダードバッチャーは、メッセージングエンジンが、バッチャーの対話を伴わずにすべてのメッセージパーシスタンスを取り扱えるようにする。バッチャーのタイプは、Ｉｎｉｔｉａｌｉｚｅ（）への呼び出しにおけるｐｒｏｐｅｒｔｙＢａｇでメッセージングエンジンに返される。スタンダードバッチャーの場合には、メッセージングエンジンは、バッチが満たされるまでＡｄｄＭｅｓｓａｇｅ（）へのそれぞれの呼び出しの後にメッセージをインスタンス状態へ自動的にパーシストする。
【００５５】
ハイパフォーマンスバッチャーは、純粋なメモリ内でのバッチングを行うことができ、メッセージをいつパーシストすべきかをメッセージングエンジンに伝える。これらのバッチャーの場合には、メッセージングエンジンは、ＡｄｄＭｅｓｓａｇｅ（）へのそれぞれの呼び出しの後にメッセージをインスタンス状態へパーシストしない。その代わりに、このバッチャーは、メッセージをメモリ内に蓄積することができる。この方法では、バッチが満たされると、バッチャーは、メッセージングエンジン上でＢａｔｃｈＣｏｍｐｌｅｔｅ（）を呼び出し、ＩＢａｓｅＭｅｓｓａｇｅＳｅｔを与えることができる。そしてメッセージングエンジンは、インスタンス状態からメッセージを読み取る必要なしに、パイプラインを直接実行することができる。これらのバッチャーは、メッセージをメモリ内に保持する設定されたしきい値を有することもできる。このバッチャーは、メッセージをディスクにフラッシュ／パーシストしたいときはいつでも、ＰｅｒｓｉｓｔＭｅｓｓａｇｅｓ（）ＡＰＩを呼び出して、メッセージをディスクにフラッシュ／パーシストことができる。このバッチャーがＰｅｒｓｉｓｔＭｅｓｓａｇｅｓ（）を呼び出すと、ＭｅｓｓａｇｅＩＤを用いてＢａｔｃｈＣｏｍｐｌｅｔｅ（）を呼び出すまではメモリ内のすべてのメッセージが必ずパーシストされるようになる。
【００５６】
メッセージングエンジンの対話：
メッセージングエンジンは、バッチ処理の対象とされている送信ポートへ向かうメッセージを得ると、内部のハッシュテーブルを見ることによって、この送信ポート用にバッチャーコンポーネントが既に作成されているかどうかをチェックする。既に作成されているバッチャーコンポーネントがない場合には、メッセージングエンジンは、新たなバッチャーコンポーネントを作成し、そのバッチャーコンポーネント上でＩｎｉｔｉａｌｉｚｅ（）を呼び出す。
【００５７】
そしてエンジンは、そのメッセージ用のバッチャーコンポーネント上でＡｄｄＭｅｓｓａｇｅ（）を呼び出す。このバッチャーコンポーネントは、そのメッセージを見て、バッチが満たされているかどうかを判断する。バッチが満たされている場合には、このバッチャーコンポーネントは、エンジンをコールバックして（ＩＣａｌｌｂａｃｋ）、成功のバッチステータスを示す。バッチが満たされていない場合には、このバッチャーコンポーネントは、その内部状態を更新した後でＡｄｄＭｅｓｓａｇｅ（）から返る。
【００５８】
スタンダードバッチャーの場合、ＡｄｄＭｅｓｓａｇｅが返って、バッチが満たされていないときには、エンジンは、そのメッセージをインスタンス状態に書き込む。その一方で、バッチが完成している場合には、このバッチャーは、ＩＭｅｓｓａｇｅＳｅｔをメッセージングエンジンに返す。エンジンは、ＭｅｓｓａｇｅＩＤＬｉｓｔへのアクセスを試み、このＭｅｓｓａｇｅＩＤＬｉｓｔは、メッセージのメッセージＩＤを正しい順序で有する（このリストに関しては、バッチャーによって任意の種類のソーティングが行われる）。ＭｅｓｓａｇｅＩＤＬｉｓｔが与えられると、エンジンは、メッセージを正しい順序でインスタンス状態から引き出すことを開始することができる。エンジンは、これらのドキュメントからメッセージセットを作成し、そしてパイプラインを実行するためのパイプラインマネージャーにこのメッセージセットを与える。
【００５９】
ハイパフォーマンスバッチャーは、スタンダードバッチャーとは対照的に、ＩＣａｌｌｂａｃｋ上でＰｅｒｓｉｓｔＭｅｓｓａｇｅｓ（）を定期的に呼び出して、メッセージをインスタンス状態へフラッシュする。このバッチに関してさらに多くのメッセージが着信した場合には、エンジンは、以前に作成されたバッチャーコンポーネント上でＡｄｄＭｅｓｓａｇｅ（）を呼び出す。コールバック（ＩＣａｌｌｂａｃｋ）は、ＡｄｄＭｅｓｓａｇｅ（）から同期的に呼び出すこともでき、あるいはバッチャーコンポーネントによって非同期的に呼び出すこともできる。時間に基づいてバッチをカットしなければならない場合には、バッチャーコンポーネントは、そのバッチのためのウィンドウズ（登録商標）タイマを待つ。すなわち、タイムアウトが生じた場合には、エンジンをコールバックして、バッチが完成している旨をエンジンに告げる。バッチが完成している場合には、バッチャーは、ＩＭｅｓｓａｇｅｓｅｔをエンジンに返す。エンジンは、（スタンダードバッチャーの場合と同様に）まずＭｅｓｓａｇｅＩＤＬｉｓｔへのアクセスを試みる。ＭｅｓｓａｇｅＩＤＬｉｓｔが空である場合には、エンジンは、ＭｅｓｓａｇｅＬｉｓｔを読み取ることを試みる。このＭｅｓｓａｇｅＬｉｓｔは、バッチャーがメモリ内でのバッチングを行っている場合には、有効な値を有する。ＭｅｓｓａｇｅＬｉｓｔが存在する場合には、エンジンは、ＩＢａｓｅＭｅｓｓａｅｇＳｅｔを作成し、パイプラインを実行する。
【００６０】
パイプラインの実行：パイプラインマネージャー内のインターフェースによって、エンジンは、メッセージセットを実行用としてパイプラインに与えることができる。そしてパイプラインマネージャーは、メッセージセット内のすべてのメッセージのためにアセンブラ上でＡｄｄＤｏｃｕｍｅｎｔを呼び出し、次いでそれらのメッセージを組み立てる。
【００６１】
独立メッセージバッチング：
メッセージングエンジンは、（独立バッチング用に構成されている）送信ポートのための最初のメッセージがエージェントから受信されると、ダミーのインスタンスを作成する。エンジンは、ＳｅｎｄＰｏｒｔＩＤをバッチャーパイプラインポインタにマップするハッシュテーブルを保持する。任意の時点で、アクティブなバッチャーコンポーネントが１つ存在し、送信ポートへ向かういかなる新たなメッセージも、そのアクティブなバッチャーコンポーネントだけに送られる。その他のバッチャーコンポーネントは、例えばフェイルオーバのシナリオにおいては、非アクティブにすることができる。
【００６２】
従属的メッセージバッチング：
従属的メッセージバッチングの場合には、下記のものが、送信ポート上に構成される。送信ポートは、従属的バッチを形成するために使用されるプロパティをユーザが選択することができるオプションを有する。例えば、選択されたメッセージコンテキストプロパティがＢＴＳ．ＢａｔｃｈＩＤである場合には、その送信ポート用にコンボイサブスクリプション（ｃｏｎｖｏｙ ｓｕｂｓｃｒｉｐｔｉｏｎ）が作成される。それぞれのメッセージは、（ａ）コンボイ用に使用されるプロパティ（ＢＴＳ．ＢａｔｃｈＩＤ）、（ｂ）バッチャーによって使用されるＢＴＳ．ＢａｔｃｈＥｎｄ＝ｔｒｕｅ／ｆａｌｓｅ、（ｃ）やはりバッチャーによって使用されるＢＴＳ．ＢａｔｃｈＳｔａｒｔ＝ｔｒｕｅ／ｆａｌｓｅという特別なメッセージコンテキストプロパティのうちの少なくとも２つを有する。プロパティ（ｂ）および（ｃ）は、Ｂａｔｃｈｅｒプロパティページ内に構成され、送信ポートプロパティ内には現れない。
【００６３】
メッセージの作成元（ワークフロースケジュールやパイプラインサービス）は、自分がこの送信ポート用に発行しているそれぞれのメッセージごとにＢＴＳ．ＢａｔｃｈＩＤをプロモート（ｐｒｏｍｏｔｅ）する。同じＢＴＳ．ＢａｔｃｈＩＤを有するメッセージどうしは、バッチにまとめるために送信ポートの同じインスタンスへ送信される。メッセージの作成元は、いつバッチが完成するかを把握し、ＢＴＳ．ＢａｔｃｈＥｎｄを書き込むことになる。
【００６４】
新たなバッチを開始するために、メッセージの発行者は、（一意の）ＢＴＳ．ＢａｔｃｈＩＤをプロモートし、メッセージを発行する。コンボイテーブル（ｃｏｎｖｏｙ Ｔａｂｌｅ）をチェックした後に、メッセージボックスによって新たなインスタンスが作成される。
【００６５】
同じＢＴＳ．ＢａｔｃｈＩＤを有する後続のメッセージは、メッセージボックスによって同じインスタンス上に送達される。これらのメッセージがメッセージングエンジンに送達される際には、メッセージングエンジンは、それらのメッセージが、従属的メッセージバッチ（送信ポートの構成）であることを既に知っている。エンジンは、ＢＴＳ．ＢａｔｃｈＩＤを正しいバッチャーポインタにハッシュする。
【００６６】
バッチャーは、従属的バッチのために次のことを実行することができる。（ａ）バッチャーは、ＢＴＳ．ＢａｔｃｈＥｎｄプロパティを見て、いつバッチをカットするかを判断する。（ｂ）バッチャーは、障害の場合、例えばユーザがタイムアウトを有することを望む場合を取り扱う。（ｃ）バッチャーは、メッセージをソートする。
【００６７】
エンジンは、上述のようにスタンダードバッチャーかハイパフォーマンスバッチャーかに応じてメッセージを現在のインスタンスのインスタンス状態に書き込むことができる。
【００６８】
バッチが完成すると、エンジンは、アセンブラを実行し、メッセージを送信する。組み立てられたメッセージが首尾よく送信されると（ｄｅｌｅｔｅＭｅｓｓａｇｅ（））、フレームワークインスタンスは、コンボイに応じて作成されたインスタンスを完了する。retries/movetonextTransport/catastrophic failureなど、その他のすべての点については、独立メッセージバッチングと同様である。
【００６９】
インスタンス状態との間における読み出しおよび書き込み：
メッセージがインスタンス状態に書き込まれる際には、フレームワークは、まずｍｅｓｓａｇｅＩＤをインスタンスストリームに書き込む。そして、エージェントＡＰＩ ＡｄｄＭｅｓｓａｇｅＯｂｊｅｃｔ（）を呼び出す。
【００７０】
また、メッセージをインスタンス状態に書き込んでいるときに、フレームワークは、同じトランザクション内でＣｏｍｐｌｅｔｅ（） ｔｈｅ ｏｒｉｇｉｎａｌ ｍｅｓｓａｇｅを受け取って、オリジナルメッセージをＡｐｐｌｉｃａｔｉｏｎＱから削除する。
【００７１】
インスタンス状態からメッセージを読み出すために、フレームワークは、ｍｅｓｓａｇｅＩＤを使用する。すなわちフレームワークは、まずインスタンスストリームを読み取ってｍｅｓｓａｇｅＩＤを入手し、次いでそれらのｍｅｓｓａｇｅＩＤを使用してメッセージを入手する。ｍｅｓｓａｇｅＩＤによってメッセージを引き出すステップは、順序も保持する。
【００７２】
インスタンスのフェイルオーバ：
プロセスが何らかの壊滅的な障害のために機能しなくなった場合には、メッセージボックスは、次にそのプロセスが復活したあたりでダミーのメッセージを作成する。メッセージングエンジンは、このダミーのメッセージを受信し、このメッセージが、バッチ処理の対象とされている送信ポートに対応していることを識別することができる。すなわち、そのインスタンスに関する最初のメッセージについてインスタンス状態に書き込みを行う前に、メッセージングエンジンは、送信先のＳｅｎｄＰｏｒｔＩＤおよびその他の関連する情報をインスタンス状態ストリームに書き込む。
【００７３】
送信ポートが、独立メッセージバッチ用に構成されている場合には、あるインスタンスがフェイルオーバすると、そのインスタンスは、使用中のアクティブなバッチャーを既に有しているメッセージングエンジンインスタンスに返すことができる。したがって、生きている／ダミーのメッセージがメッセージングエンジンによって受信されると、メッセージングエンジンは、同じスレッド内でインスタンス状態の中に保存されているバッチ全体を空にする。メッセージングエンジンは、新たなバッチャーオブジェクトを作成し、そのバッチャーオブジェクトを初期化する。メッセージングエンジンによってバッチャーに渡されるｐｒｏｐｅｒｔｙｂａｇは、これが、フェイルオーバされたインスタンスであるということを示す。また、可能な場合には、メッセージングエンジンは、バッチ内のメッセージの数も提供する。そしてメッセージングエンジンは、インスタンス状態からすべてのメッセージを読み出し、バッチャー上でＡｄｄＭｅｓｓａｇｅ（）を呼び出す。バッチャーは、最後のメッセージを受信すると、メッセージングエンジン上でＢａｔｃｈＣｏｍｐｌｅｔｅ（）を呼び出す。
【００７４】
バッチャーがどのように構成されているかに応じて、バッチを合格または不合格にすることができる。バッチが不合格にされた場合には、メッセージングエンジンは、そのバッチ内のすべてのメッセージを一時停止する。
【００７５】
送信移送機能：
伝送の成功：アダプタは、パイプラインから来たメッセージ上でＤｅｌｅｔｅＭｅｓｓａｇｅ（）を呼び出す。Ｑからのメッセージは、ｃｏｍｐｌｅｔｅｄ（）を既に受け取られているため、ＩｎｓｔａｎｃｅＳｔａｔｅ内のメッセージは削除される。インスタンス状態からメッセージを削除するために、フレームワークは、エージェントＡＰＩ ＲｅｌｅａｓｅＭｅｓｓａｇｅ（）を呼び出す。
【００７６】
再送信：Ｑからのメッセージは、ｃｏｍｐｌｅｔｅｄ（）を既に受け取られているため、フレームワークは、ＩｎｓｔａｎｃｅＳｔａｔｅ内にあるメッセージの再送を試みる。再試行間隔の後に戻るタイマメッセージが通知される。メッセージングエンジンがそのタイマメッセージを見ると、インスタンス状態からメッセージを読み出すステップが再始動し、処理が再開する。再び、ｍｅｓｓａｇｅＩＤがインスタンスストリームから順に読み出され、そしてメッセージがインスタンス状態から引き出される。
【００７７】
ＭｏｖｅＴｏＮｅｘｔＴｒａｎｓｐｏｒｔ：メッセージングエンジンは、メッセージをインスタンスに通知する。このメッセージのバックアップになると、メッセージングエンジンは、このメッセージがバックアップトランスポート（ｂａｃｋｕｐ ｔｒａｎｓｐｏｒｔ）に移動されてきていることを認識し、インスタンス状態からメッセージを排出しようと試み、バッチを処理する。
【００７８】
ＳｕｓｐｅｎｄＭｅｓｓａｇｅ：ＩｎｓｔａｎｃｅＳｔａｔｅの内部のメッセージは、インスタンス状態から引き出され、ＳｕｓｐｅｎｄＭｅｓｓａｇｅｓ（ＭｅｓｓａｇｅＩｄ［］）ＡＰＩを使用して一時停止され、そのＳｕｓｐｅｎｄＭｅｓｓａｇｅｓ（ＭｅｓｓａｇｅＩｄ［］）ＡＰＩは、これらのメッセージをインスタンス状態からｓｕｓｐｅｎｄＱに移動させる。あるいは、メッセージをダミーのインスタンスに通知して、そのダミーのインスタンスを一時停止することもできる。メッセージが再開されると、インスタンス状態は空にされる。
【００７９】
バッチ処理の対象とされている送信ポートはまた、順序付けられた送達のためにマークされる：これが行われる際には、メッセージングエンジンは、独立したバッチの場合でさえ、その送信ポートのためのダミーのインスタンスを作成しない。メッセージングエンジンは、その順序付けられた送信ポートのためのデフォルトのインスタンスに対応するインスタンス状態を自動的に使用する。エージェント送達スレッド（ａｇｅｎｔ ｄｅｌｉｖｅｒｙ ｔｈｒｅａｄ）を断念する前に、メッセージングエンジンは、そのメッセージが送信されたかまたは失敗したかをアダプタが確認できるようにブロックを行う（バッチ上でのコールバック）という事実において、動作がわずかに変化するかもしれない。
【００８０】
トラッキング：送信パイプラインへの入力メッセージと、出力メッセージとの間にリンクを保持することができる。あるメッセージがａｐｐｌｉｃａｔｉｏｎＱからインスタンス状態へ移動されると、そのメッセージ上でＲｅｃｅｉｖｅＣｏｍｐｌｅｔｅ（）を呼び出すと、そのメッセージは、ａｐｐｌｉｃａｔｉｏｎＱから削除される。これが行われる際のＨＡＴにおけるステータスは、メッセージが完全に処理される際に示されるステータスとは区別することができる（すなわち、ＤｅｌｅｔｅＭｅｓｓａｇｅ（）−がＲｅｃｅｉｖｅＣｏｍｐｌｅｔｅ（）に変わる）。
【図面の簡単な説明】
【００８１】
【図１】従来技術による構造化されたメッセージのコンピュータどうしでのやり取りを示す流れ図である。
【図２】本発明の一実施形態によるメッセージ集約のためのコンピューティングシステム環境を示すブロック図である。
【図３】本発明の一実施形態によるメッセージ集約を示す例示的な流れ図である。
【図４】本発明を実装することができる適切なコンピューティングシステム環境の一例を示すブロック図である。
【特許請求の範囲】
【請求項１】
メッセージを集約するコンピュータ化された方法であって、
少なくとも１つのアプリケーション（２０２）から複数のメッセージを受信するステップ（３０２）と、
前記受信したメッセージ上でバッチ構成ポリシーを実行するステップ（３０６）と、
前記受信したメッセージを前記バッチ構成ポリシーに関して１つのバッチ内に集約するステップ（３１０）と、
単一のストリームメッセージ出力の中に前記バッチを組み立てるステップ（３１６）とを含むことを特徴とする方法。
【請求項２】
前記単一のストリームメッセージ出力は、１つのエンドポイント（４０８）に宛てられていることを特徴とする請求項１に記載の方法。
【請求項３】
前記実行するステップは、前記バッチに関連付けられているインスタンス状態（４０２）を保持するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記インスタンス状態（４０２）をデータストア（１０８）内に保存するステップをさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記受信するステップ、実行するステップ、および保持するステップは、第１のコンピュータに関連付けられており、前記データストア（１０８）は、第２のコンピュータに関連付けられていることを特徴とする請求項４に記載の方法。
【請求項６】
前記受信するステップは、前記受信したメッセージ（４０４）をデータストア（１０８）内に保存するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記バッチ構成ポリシーは、前記アプリケーション（１０２）のための前記メッセージをバッチにまとめるためのビジネスロジックを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ビジネスロジックは、前記バッチ内での前記メッセージのソート順序、前記バッチ内のメッセージの数、前記バッチ内の累積バイト数、前記バッチ内のメッセージの１つまたは複数のタイプ、およびメッセージを蓄積するための時間というポリシーパラメータのうちの少なくとも１つを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記集約するステップは、前記構成ポリシーに関して前記メッセージをソートするステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記メッセージは、ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）標準に準拠することを特徴とする請求項１に記載の方法。
【請求項１１】
１つまたは複数のコンピュータ可読媒体が、請求項１に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項１に記載の方法。
【請求項１２】
メッセージを集約するコンピュータ化された方法において、
少なくとも１つのアプリケーションから複数のメッセージを受信するステップ（３０２）であって、前記メッセージは、バッチ識別子およびバッチ終了インジケータを含むステップと、
前記受信したメッセージを前記バッチ識別子に関して１つのバッチ内に集約するステップ（３０８）と、
前記バッチ終了インジケータに関して前記集約するステップを完了するステップ（３１０）と、
単一のストリームメッセージ出力の中に前記バッチを組み立てるステップ（３１６）とを含むことを特徴とする方法。
【請求項１３】
前記メッセージを集約するためのバッチャーの前記インスタンスを特定するために前記バッチ識別子をハッシュするステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記バッチ完成インジケータは、前記バッチが完成するときに知らせることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記単一のストリームメッセージ出力は、１つのエンドポイントに宛てられていることを特徴とする請求項１２に記載の方法。
【請求項１６】
前記バッチに関連付けられているインスタンス状態（４０２）を保持するステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１７】
前記インスタンス状態（４０２）をデータストア（１０８）内に保存するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
１つまたは複数のコンピュータ可読媒体が、請求項１２に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項１２に記載の方法。
【請求項１９】
アプリケーション（１０２）のためのメッセージを集約するためのシステムにおいて、前記メッセージは送信ポートに宛てられているシステムであって、
前記アプリケーションからメッセージを受信するためのメッセージエンジンコンポーネント（１０４）と、
前記アプリケーションのための前記メッセージをバッチにまとめるためのビジネスロジックを含むバッチ構成ポリシー（１０６）と、
メッセージを前記バッチ構成ポリシー（１０６）に関して１つのバッチへと集約するためのバッチャーコンポーネント（１０６）において、前記送信ポートに関連付けられているバッチャーコンポーネント（１０６）であって、前記送信ポートに宛てられているメッセージを前記メッセージエンジン（１０４）から受信するバッチャーコンポーネント（１０６）とを含む、コンピュータによって実行可能な１つまたは複数のコンポーネントを含み、
前記メッセージエンジンコンポーネント（１０４）は、前記送信ポートに関連付けられている前記バッチャーコンポーネント（１０６）が存在しない場合には、前記送信ポートに関連付けられている前記バッチャー（１０６）の新たなインスタンスを作成することを特徴とするシステム。
【請求項２０】
前記メッセージエンジンコンポーネント（１０４）は、第１のコンピュータに関連付けられており、第２のコンピュータに関連付けられているデータストア内に保存されている前記バッチのインスタンス状態（４０２）を保持し、前記インスタンス状態（４０２）は、メッセージ識別子および送信ポート識別子を含み、
前記メッセージエンジンコンポーネント（１０２）は、第１のコンピュータに関連付けられており、前記メッセージを、前記第２のコンピュータに関連付けられている前記データストア（１０８）内に保存することを特徴とする請求項１９に記載のシステム。
【請求項１】
メッセージを集約するコンピュータ化された方法であって、
少なくとも１つのアプリケーション（２０２）から複数のメッセージを受信するステップ（３０２）と、
前記受信したメッセージ上でバッチ構成ポリシーを実行するステップ（３０６）と、
前記受信したメッセージを前記バッチ構成ポリシーに関して１つのバッチ内に集約するステップ（３１０）と、
単一のストリームメッセージ出力の中に前記バッチを組み立てるステップ（３１６）とを含むことを特徴とする方法。
【請求項２】
前記単一のストリームメッセージ出力は、１つのエンドポイント（４０８）に宛てられていることを特徴とする請求項１に記載の方法。
【請求項３】
前記実行するステップは、前記バッチに関連付けられているインスタンス状態（４０２）を保持するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記インスタンス状態（４０２）をデータストア（１０８）内に保存するステップをさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記受信するステップ、実行するステップ、および保持するステップは、第１のコンピュータに関連付けられており、前記データストア（１０８）は、第２のコンピュータに関連付けられていることを特徴とする請求項４に記載の方法。
【請求項６】
前記受信するステップは、前記受信したメッセージ（４０４）をデータストア（１０８）内に保存するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記バッチ構成ポリシーは、前記アプリケーション（１０２）のための前記メッセージをバッチにまとめるためのビジネスロジックを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ビジネスロジックは、前記バッチ内での前記メッセージのソート順序、前記バッチ内のメッセージの数、前記バッチ内の累積バイト数、前記バッチ内のメッセージの１つまたは複数のタイプ、およびメッセージを蓄積するための時間というポリシーパラメータのうちの少なくとも１つを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記集約するステップは、前記構成ポリシーに関して前記メッセージをソートするステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記メッセージは、ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）標準に準拠することを特徴とする請求項１に記載の方法。
【請求項１１】
１つまたは複数のコンピュータ可読媒体が、請求項１に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項１に記載の方法。
【請求項１２】
メッセージを集約するコンピュータ化された方法において、
少なくとも１つのアプリケーションから複数のメッセージを受信するステップ（３０２）であって、前記メッセージは、バッチ識別子およびバッチ終了インジケータを含むステップと、
前記受信したメッセージを前記バッチ識別子に関して１つのバッチ内に集約するステップ（３０８）と、
前記バッチ終了インジケータに関して前記集約するステップを完了するステップ（３１０）と、
単一のストリームメッセージ出力の中に前記バッチを組み立てるステップ（３１６）とを含むことを特徴とする方法。
【請求項１３】
前記メッセージを集約するためのバッチャーの前記インスタンスを特定するために前記バッチ識別子をハッシュするステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記バッチ完成インジケータは、前記バッチが完成するときに知らせることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記単一のストリームメッセージ出力は、１つのエンドポイントに宛てられていることを特徴とする請求項１２に記載の方法。
【請求項１６】
前記バッチに関連付けられているインスタンス状態（４０２）を保持するステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１７】
前記インスタンス状態（４０２）をデータストア（１０８）内に保存するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
１つまたは複数のコンピュータ可読媒体が、請求項１２に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項１２に記載の方法。
【請求項１９】
アプリケーション（１０２）のためのメッセージを集約するためのシステムにおいて、前記メッセージは送信ポートに宛てられているシステムであって、
前記アプリケーションからメッセージを受信するためのメッセージエンジンコンポーネント（１０４）と、
前記アプリケーションのための前記メッセージをバッチにまとめるためのビジネスロジックを含むバッチ構成ポリシー（１０６）と、
メッセージを前記バッチ構成ポリシー（１０６）に関して１つのバッチへと集約するためのバッチャーコンポーネント（１０６）において、前記送信ポートに関連付けられているバッチャーコンポーネント（１０６）であって、前記送信ポートに宛てられているメッセージを前記メッセージエンジン（１０４）から受信するバッチャーコンポーネント（１０６）とを含む、コンピュータによって実行可能な１つまたは複数のコンポーネントを含み、
前記メッセージエンジンコンポーネント（１０４）は、前記送信ポートに関連付けられている前記バッチャーコンポーネント（１０６）が存在しない場合には、前記送信ポートに関連付けられている前記バッチャー（１０６）の新たなインスタンスを作成することを特徴とするシステム。
【請求項２０】
前記メッセージエンジンコンポーネント（１０４）は、第１のコンピュータに関連付けられており、第２のコンピュータに関連付けられているデータストア内に保存されている前記バッチのインスタンス状態（４０２）を保持し、前記インスタンス状態（４０２）は、メッセージ識別子および送信ポート識別子を含み、
前記メッセージエンジンコンポーネント（１０２）は、第１のコンピュータに関連付けられており、前記メッセージを、前記第２のコンピュータに関連付けられている前記データストア（１０８）内に保存することを特徴とする請求項１９に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００９−５３２８０３（Ｐ２００９−５３２８０３Ａ）
【公表日】平成２１年９月１０日（２００９．９．１０）
【国際特許分類】
【出願番号】特願２００９−５０４１８８（Ｐ２００９−５０４１８８）
【出願日】平成１９年３月８日（２００７．３．８）
【国際出願番号】ＰＣＴ／ＵＳ２００７／００５７６５
【国際公開番号】ＷＯ２００７／１２０４１０
【国際公開日】平成１９年１０月２５日（２００７．１０．２５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＥＰＲＯＭ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２１年９月１０日（２００９．９．１０）
【国際特許分類】
【出願日】平成１９年３月８日（２００７．３．８）
【国際出願番号】ＰＣＴ／ＵＳ２００７／００５７６５
【国際公開番号】ＷＯ２００７／１２０４１０
【国際公開日】平成１９年１０月２５日（２００７．１０．２５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＥＰＲＯＭ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]