JP2004520640A - 非同期メッセージ交換システムで使用される方法および装置 - Google Patents

Abstract

【課題】非同期メッセージ交換システムで使用される方法および装置を提供すること。
【解決手段】非同期メッセージ交換システム内で使用されるコンピュータ・ベースの方法に、（ｉ）システム内で送信される少なくとも１つのメッセージに関する少なくとも１つのメッセージ送達結果状態を定義し、メッセージ送達結果状態をシステム内で送信されるメッセージに関連付けるステップと、（ｉｉ）システム内で、関連するメッセージ送達結果状態と共にメッセージを送信するステップと、（ｉｉｉ）メッセージの送信側が最終的な受信側へのメッセージの送達の結果に関して通知されることができるように、送信されたメッセージの送達を監視し、関連するメッセージ送達結果状態に関するメッセージの送達結果を評価するステップとが含まれる。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、非同期メッセージ交換を使用する分散ソフトウェア・システムおよび並行ソフトウェア・システムに関する。
【０００２】
【従来の技術】
分散ソフトウェア・システムおよび並行ソフトウェア・システムでは、異なる形の電子通信が使用される。メッセージ交換が、そのような通信モデルの１つである。メッセージ交換を用いて、システム構成要素が、メッセージを送ることによって互いに通信する。メッセージによって、あるアプリケーション固有データが運ばれる。
【０００３】
メッセージ交換は、システム構成要素がある時点でメッセージを送り、メッセージ送達およびメッセージの受信側と独立に計算を継続するという点で、本来非同期である。メッセージ送信側は、後の時点にメッセージに対する応答を受け取る場合がある。メッセージの送信側および受信側は、時間独立である、すなわち、これらは、ネットワーク上で同時に使用可能である必要がない。
【０００４】
分散ソフトウェア・システムおよび並行ソフトウェア・システムの多くが、非同期メッセージ交換に依存し、このためにメッセージ・ミドルウェアを使用する。メッセージ・ミドルウェアは、ソフトウェア・システムの構成要素の間でのメッセージ交換動作をもたらす１つまたは複数のソフトウェア・プログラムを指す。メッセージ・ミドルウェアを用いると、メッセージは、通常は、ある形の宛先、たとえばメッセージ・キューに送られ、そこから、メッセージ・ミドルウェアの他のクライアント、たとえば最終メッセージ受信側が、そのメッセージを読み取ることができる。したがって、メッセージの送信側および受信側は、必ずしも互いの存在を意識しない。
【０００５】
【発明が解決しようとする課題】
各メッセージ送達の失敗およびそれぞれの成功は、メッセージの送信側にとって重要であり、場合によってはクリティカルなことさえある。メッセージ送達失敗がそれによって判定されるアプリケーション固有の判断基準は、一般に、送信側によって、また、メッセージによって異なる。しかし、これらの判断基準を指定し、判断基準に従ってメッセージ送達を評価し、評価の結果に反応することは、行うことが困難であり、既存のメッセージ・ミドルウェアによって簡単にはサポートされない。
【０００６】
既存のメッセージ・ミドルウェア、たとえばＭＱＳｅｒｉｅｓ（ＩＢＭＣｏｒｐｏｒａｔｉｏｎ社の商標）またはＪａｖａ（Ｒ）Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ ＪＭＳ（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標）の実施形態は、メッセージ送達失敗の非常に限られたアイデア概念だけをサポートし、本来メッセージの送信側がメッセージ単位で定義することができても良い種々の失敗の概念を区別しない。メッセージの送信側は、メッセージの宛先を指定するだけであり、メッセージ送達が信頼性があると宣言することができる。メッセージ・ミドルウェアは、システム・クラッシュなどの失敗が存在する場合であっても、宛先へのメッセージの送達を保証する。既存のメッセージ・ミドルウェアは、メッセージ送達の失敗およびそれぞれの成功をそれに基づいて判定することができるアプリケーション固有の判断基準の定義をサポートしない。
【０００７】
【課題を解決するための手段】
本発明は、好ましくはメッセージ単位で、メッセージ送達結果を定義し、処理する方法および装置を提供する。結果は、「成功」または「失敗」のいずれかであることが好ましい。
【０００８】
本発明の一態様では、非同期メッセージ交換システムで使用されるコンピュータベースの方法であって、システム内で送信される少なくとも１つのメッセージに関する少なくとも１つのメッセージ送達結果状態を定義し、少なくとも１つのメッセージ送達結果状態をシステム内で送信されるメッセージに関連付けるステップと、関連する少なくとも１つのメッセージ送達結果状態と共にメッセージをシステム内で送信するステップと、メッセージの送信側がメッセージの送達結果に関して通知されることができるように、送信されたメッセージの送達を監視し、関連する少なくとも１つのメッセージ送達結果状態に関してメッセージの送達結果を評価するステップとを含む方法。
【０００９】
本発明のもう１つの態様では、（ｉ）メッセージ単位でメッセージ送達結果状態を指定するステップと、（ｉｉ）メッセージとメッセージ結果状態のオブジェクト表現を関連付けるステップと、（ｉｉｉ）これらの結果状態と共にメッセージを送出するステップと、（ｉｖ）結果状態に関してメッセージ送達の状況に関して照会するステップと、（ｖ）メッセージについて指定された結果状態の修正または置換を可能にするステップと、（ｖｉ）評価結果通知を受け取るオブジェクトを指定するステップとを実行するためにメッセージの送信側によって使用されるアプリケーション・プログラミング・インターフェースが提供される。
【００１０】
本発明のもう１つの態様では、（ｉ）永続オブジェクトとしてメッセージ結果状態を表現し、（ｉｉ）メッセージ送達を観察し、（ｉｉｉ）メッセージ結果状態を評価し、（ｉｖ）結果状態に関するメッセージ送達の状況に関する照会に答え、（ｖ）送信された各メッセージの評価結果に関してメッセージ送信側または送信側が指定するオブジェクトに通知する：動作の１つまたは複数を実行する、コンピュータベースの装置が提供される。この装置は、本明細書に記載の発明的教示を実施するように適合された既存のメッセージ・ミドルウェアを使用して実施することができる。
【００１１】
添付図面と共に読まれるべき、本発明の例示的実施形態の詳細な説明を、これから示す。
【００１２】
【発明の実施の形態】
本発明を、非同期メッセージ交換を使用する例示的ソフトウェア・システムに関して下で説明する。このシステムは、分散並行システムであることが好ましい。既知のように、分散ソフトウェア・システムは、システムの構成要素が、通信ネットワークによって結合された複数のコンピュータ・システムに常駐することができるシステムであり、並行ソフトウェア・システムは、複数の計算タスクを並行に、すなわち同時に処理することができるシステムである。しかし、本発明が、特定のソフトウェア・システム・アーキテクチャに制限されないことを理解されたい。そうではなく、本発明は、メッセージ送達結果を定義し、処理することが望ましい、すべてのソフトウェア・システム・アーキテクチャに、より一般的に適用可能である。下で説明する例示的実施形態では、「成功」および「失敗」が結果状態になると見なすが、本発明はこれに制限されない。
【００１３】
前に述べたように、非同期メッセージ交換は、時間依存ソフトウェア処理の間のメッセージの交換を指す。通常、メッセージの送信側が、メッセージ・ミドルウェアを使用して、ミドルウェアによって管理されるある形の宛先、たとえばリモート・メッセージ・キューにメッセージを送る。メッセージの最終的な受信側は、宛先からメッセージを読み取るメッセージ・ミドルウェアの他のクライアントである。
【００１４】
また、前に述べたように、各メッセージ送達の失敗およびそれぞれの成功は、メッセージの送信側にとって重要であり、場合によってはクリティカルである。メッセージ送達失敗がそれによって判定されるアプリケーション固有の判断基準は、一般に、送信側によって、また、メッセージによって異なる可能性がある。たとえば、メッセージｍ１がそれぞれ時間ウィンドウｔ１およびｔ２内に特定の最終受信側ｒ１およびｒ２に到達する場合に限って、メッセージｍ１を「成功」とみなすことができる。また、もう１つのメッセージｍ２は、時間ウィンドウｔ３内にｍ２を受け取る異なる匿名の最終受信側が５つ未満である場合に、「失敗」とみなすことができる。
【００１５】
しかし、前に述べたように、そのような判断基準を指定し、判断基準に従ってメッセージ送達を評価し、評価の結果に反応することは、行うことが困難であり、既存のメッセージ・ミドルウェアによって簡単にはサポートされない。
【００１６】
既存のメッセージ・ミドルウェア・システムは、メッセージ送達失敗の非常に限られた概念だけをサポートするが、メッセージの送信側がメッセージ単位で定義することができる種々の失敗の概念を区別しない。メッセージの送信側は、メッセージの宛先、たとえばメッセージ・キューを指定するだけである。メッセージの最終的な受信側は、通常は指定されない。メッセージ・ミドルウェアは、中間宛先へのメッセージの信頼性のある送達を保証することができるが、最終受信側によるメッセージ受信の肯定応答は、アプリケーション側でコーディングされなければならず、ミドルウェアによって直接にはサポートされない。
【００１７】
本発明は、メッセージ送達失敗の定義および管理のためのより洗練されたレベルを導入する。本明細書で教示されるように、メッセージ送達失敗の種々の概念を、簡単にプログラムすることができ、メッセージ送達失敗を管理するという重荷が、送信側からミドルウェアにシフトされる。１特定の応用例が、処置が異なる失敗状態を有することのできる、個々の処置の結果に関して、送信側が、処置のグループの全体的な結果すなわち送られたメッセージを定義できることである。そのような特別なケースが、トランザクションの成功がメッセージ送達の成功に依存するトランザクションである。
【００１８】
下で詳細に説明するように、本発明の好ましい態様では、メッセージの送信側によって、（ｉ）メッセージ単位でメッセージ送達失敗状態を指定し、（ｉｉ）メッセージとメッセージ失敗状態（のオブジェクト表現）を関連付け、（ｉｉｉ）これらの失敗状態と共にメッセージを送出し、（ｉｖ）失敗状態に関してメッセージ送達の状況に関して照会し、（ｖ）メッセージについて指定された失敗状態の修正または置換を可能にし、（ｖｉ）失敗評価結果通知を受け取るオブジェクトを指定する：のに使用されるアプリケーション・プログラミング・インターフェースが提供される。
【００１９】
さらに、やはり下で詳細に説明するように、本発明のもう１つの好ましい態様では、（ｉ）永続オブジェクトとしてメッセージ失敗状態を表現し、（ｉｉ）メッセージ送達を観察し、（ｉｉｉ）メッセージ失敗状態を評価し、（ｉｖ）失敗状態に関するメッセージ送達の状況に関する照会に答え、（ｖ）送信された各メッセージの評価結果に関してメッセージ送信側に通知する：コンピュータベースの装置が提供される。この装置は、本明細書に記載の発明的教示を実施するように適合された既存のメッセージ・ミドルウェアを使用して実施することができる。
【００２０】
メッセージ送達失敗状態を表す永続オブジェクトでセットされる値には、たとえば、必須または任意選択の受信側、宛先（メッセージ・キューなど）および最終的な受信側（宛先からメッセージを読み取る他のアプリケーション・オブジェクトなど）の両方のリスト、特定のまたは不特定の最終受信側によるメッセージ読取のタイムアウトおよび必要な時間ウィンドウの指定、メッセージを受信しなければならない最終受信側の数または範囲の基数指定、および送信側から使用可能であるかメッセージ送達システムによって公開される他の値が含まれる。
【００２１】
メッセージ失敗状態の表現は、さまざまな形で互いに関係することができる。これには、たとえば、一般化−特殊化階層およびツリー、またはリンク・リストの形の順序付けが含まれる。
【００２２】
本発明の好ましい実施形態を、下で例示的に詳細に説明する。
【００２３】
まず図１を参照すると、ブロック図に、本発明の実施形態によるメッセージ交換を使用するシステムが示されている。このシステムには、メッセージ送信側１０２、たとえばメッセージを送るメッセージ・ミドルウェアのクライアントが含まれる。メッセージ送信側１０２は、３つのモジュールを使用する。失敗定義モジュール１０４は、メッセージ送達失敗状態を定義するのに使用される。メッセージ送達モジュール１０６は、失敗状態と共にメッセージを送るのに使用される。失敗評価モジュール１０８は、失敗状態に関してメッセージ送達の状況に関して照会するのに使用される。
【００２４】
失敗定義モジュール１０４は、失敗状態の表現を作成し、管理する。これらの表現は、上で説明したものなどの値を担持する永続オブジェクトである。
【００２５】
メッセージ送達モジュール１０６は、関連する失敗状態と共にメッセージを送り、宛先および最終受信側へのメッセージの送達を観察する。このモジュールは、ＭＱＳｅｒｉｅｓまたはＪＭＳの実装など、既存のメッセージ・ミドルウェア１１０を使用する。
【００２６】
失敗評価モジュール１０８は、メッセージに関連する失敗状態に従って、メッセージ送達モジュール１０６によって観察される実際のメッセージ送達に基づいてメッセージ送達を成功または失敗として評価する。評価の状況は、メッセージを送信した後ならばいつでも照会することができ、失敗評価モジュール１０８は、メッセージ送信側または送信側が指定したオブジェクトに、評価の結果に関して通知する。アプリケーション・プログラミング・インターフェース（ＡＰＩ）の一部としてのインターフェースが、この目的のためにシステムによって定義される。このインターフェースは、アプリケーションの一部として、メッセージ送信側（または指定されたオブジェクト）によって実装され、提供される。
【００２７】
用語「インターフェース」が、本明細書で、ソフトウェア工学の技術用語として使用され、インターフェースによって、あるサービス・プロバイダ（たとえばオブジェクト）が提供する動作（機能）の組がグループ化されることを諒解されたい。したがって、インターフェースには、動作の定義が含まれ、インターフェースは、ソフトウェア構成要素によって実装される。ソフトウェア構成要素は、アプリケーションの構成要素または、たとえば図１に示されたものなどのメッセージ送達システムの構成要素のいずれかとすることができる。
【００２８】
既存のメッセージ・ミドルウェア１１０は、メッセージ・キューまたはＪＭＳ Ｔｏｐｉｃオブジェクトなどの宛先１１２への（信頼性のある）メッセージ送達に使用される。最終的なメッセージ受信側１１４へのメッセージ送達を観察するために、最終的な受信側が、宛先１１２からメッセージを読み取る前に、メッセージ送達モジュール１０６に登録し、観察のためにメッセージ送達モジュール１０６が使用することのできるインターフェースを提供することができる。このインターフェースは、ＡＰＩの一部としてシステムによって定義され、システムとの通信のためにアプリケーション（この例では最終的な受信側）によって実装される。代替案では、最終的な受信側１１４が、宛先からメッセージを読み取るための特定のインターフェースおよびオブジェクトを使用し、その結果、メッセージ送達モジュール１０６が、最終的な受信側が宛先からメッセージを読む時に、必ずそのオブジェクトによって自動的に通知されるようにすることができる。
【００２９】
ソフトウェア・システムが分散される時に、失敗定義モジュール１０４、メッセージ送達モジュール１０６、失敗評価モジュール１０８、およびメッセージ・ミドルウェア１１０が、１つまたは複数のコンピュータ・システムに常駐することができるが、メッセージ送信側１０２、宛先１１２、および最終的なメッセージ受信側１１４が、それら自体の別々のコンピュータ・システムに常駐することを諒解されたい。コンピュータ・システムのそれぞれを、適当な通信ネットワークを介して結合することができる。
【００３０】
図２を参照すると、流れ図に、本発明の実施形態によるメッセージ交換処理が示されている。具体的に言うと、図２は、別々の図に詳細に示されたステップ、すなわち、メッセージ失敗定義および送られたメッセージ（図４、この図４は図３を参照する）、メッセージ送達観察（図５）、メッセージ失敗評価（図６）、およびメッセージ失敗状態修正（図７）に関係する。
【００３１】
処理２００は、ステップ２０２で、障害状態と共にメッセージを送信することによって開始される（図４に記載されているように）。メッセージが送信された後に、ステップ２０４でメッセージの送達を観察し（図５）、それと並列に、ステップ２０６で失敗状態を評価する（図６）。任意選択として、ステップ２０８で、メッセージの失敗状態を修正することができる（図７）。送達観察および失敗評価は、メッセージが送信された直後に平行して行うことができる。失敗状態は、メッセージが送信された後のいつでも修正することができ、失敗評価処理の結果に影響する。
【００３２】
図３を参照すると、本発明の実施形態によるメッセージ失敗定義を示す流れ図が示されている。処理３００は、ステップ３０２で、特殊な（アプリケーション固有の）メッセージ失敗状態が望まれるかどうかを判定することによって開始される。特殊な失敗状態が望まれない場合には、ステップ３０４で、標準の事前定義の失敗モデルの表現を作成するか、別のオブジェクトまたは永続ストアから取得し、失敗定義の処理が終了する。特殊な失敗状態が望まれる場合には、ステップ３０６で、メッセージ送信側が失敗定義モジュールを使用して失敗状態を定義する。状態が定義された後に、ステップ３０８で特殊な失敗モデルの表現を作成し、処理が終了する。失敗状態の表現は、永続オブジェクトである。
【００３３】
図４を参照すると、流れ図に、本発明の実施形態による失敗状態を伴うメッセージ送信の処理が示されている。
【００３４】
処理４００は、ステップ４０２でメッセージ失敗を定義することによって（図３に関して上で説明したように）、またはステップ４０４で送信されるメッセージを作成することによって、開始される。この２つのステップの順序は、どれでもよいが、ステップ４０６でのメッセージを失敗表現に関連付ける次の処理ステップのために、この両方を完了する必要がある。その後、失敗表現に関連付けられたメッセージを、ステップ４０８でメッセージ送達モジュールを使用して送信することができる。
【００３５】
図５を参照すると、流れ図に、本発明の実施形態によるメッセージ送達観察が示されている。
【００３６】
処理５００は、ステップ５０２で、メッセージ送達モジュール（またはメッセージ送達モジュールによって指定されるエンティティ）が、最終的なメッセージ受信側によるメッセージ受信の肯定応答の受信を待っている時に開始される。そのような肯定応答は、最終的な受信側によってメッセージ送達モジュールに直接に、または最終的な受信側が宛先からの読取に使用する特殊なインターフェースおよびオブジェクトの使用を介して間接的に、通信することができる。直接通信の場合には、メッセージの読取およびメッセージ送達モジュールへの受信の肯定応答の送信が、２つの別々の別個の処置になる。間接的な場合には、肯定応答の送信が、受信側がメッセージを読み取る時にシステムによって暗黙のうちに自動的に実行される。受信側は、この場合には、システムによって提供される特定の読取動作を使用する。
【００３７】
１つの肯定応答を受信した時に、ステップ５０４で、最終的な受信側の識別が、判定され、メッセージ送達ログに記録される。メッセージ送達ログは、送信されたメッセージの最終的なメッセージ受信側の永続的記録である。その後、この処理は、ステップ５０６で、観察を継続するか否かを判定することによって継続される。この判断では、外部および内部のタイムアウトを考慮に入れる。内部タイムアウトは、システム内で指定される、メッセージに関連するタイムアウトである。外部タイムアウトは、システムの外部で（場合によってはアプリケーションによって）管理され、単一のメッセージに関連しないイベントである。外部タイムアウトは、処理を終了させる外部イベントである。観察を継続する場合には、処理は、肯定応答を受信するステップすなわちステップ５０２から繰り返される。観察を停止する場合には、処理が終了する。
【００３８】
図６を参照すると、本発明の実施形態によるメッセージ失敗評価の処理を示す流れ図が示されている。
【００３９】
処理６００は、ステップ６０２で、送信されたメッセージｍの評価されない失敗状態のすべてが、失敗表現（図３に関して上で説明した）およびメッセージ送達ログ（図５に関して上で説明した）を使用して評価される時に開始される。たとえば、タイムアウト発生、または最終的なメッセージ受信側によって読み取られたメッセージの肯定応答がメッセージ送達ログに入れられるなど、評価を判定する判断基準が使用可能になれば、状態を真または偽と評価することができる。そのようなイベントならびに他のイベントによって、状態の評価にトリガをかけることができる。
【００４０】
１つの条件が評価されるや否や、処理が継続して、ステップ６０４で特定の失敗状態が真と評価されるかどうかを検査する。真と評価される失敗状態は、メッセージ送達が失敗したことを暗示する。そうである場合には、ステップ６０６で、メッセージ送達失敗の結果通知が、失敗評価モジュールによってメッセージ送信側、または結果通知の受信についてメッセージ送信側によって指定されたオブジェクトに送られる。
【００４１】
メッセージ送達失敗の結果通知を送信した後に、または、条件が偽と評価された場合に、処理は、ステップ６０８で、評価を継続するか、評価を停止するかを決定することによって継続される。この決定では、上で説明したように外部タイムアウトおよび内部タイムアウトを考慮に入れる。評価を継続する場合には、処理は、メッセージｍのすべての評価されていない失敗条件を評価するステップすなわち、ステップ６０２から繰り返される。
【００４２】
決定が、失敗評価を停止することである場合には、ステップ６１０で、すべての失敗状態を評価し、かつ、すべての条件が偽と評価されたかどうかを判定する。そうである場合には、ステップ６１２で、メッセージ送達成功の結果通知をメッセージ送信側または指定された通知オブジェクトに送信する。そうでない場合、およびメッセージ送達成功の通知を送信した後に、処理が終了する。
【００４３】
失敗評価モジュール１０８（図１）は、たとえば、どの状態がこれまでに評価されたか、または最終的な受信側から受信された受信の肯定応答の数など、評価の状況に関する照会を、メッセージ送信側が行うのにいつでも使用することができるインターフェースを提供する。
【００４４】
図７を参照すると、流れ図に、本発明の実施形態による送信メッセージの失敗状態の修正または置換もしくはその両方の処理が示されている。
【００４５】
処理７００は、ステップ７０２で、失敗状態修正すなわち、それぞれの置換が望まれるかどうかを判定することによって開始される。この決定は、メッセージ送信側が行うことができる。状態を修正することが望まれる場合には、ステップ７０４で、図３に関して上で説明した処理に従って失敗状態を定義し、ステップ７０６で、結果の修正された失敗表現または新規の失敗表現を、送信されたメッセージに関連付ける。処理は、失敗状態修正の最初の判断状態すなわちステップ７０２に戻ることによって継続される。修正なしに関する決定が行われる場合には、処理が終了する。
【００４６】
上の詳細な説明では、本発明を実践する好ましい方法を説明した。当業者は、本明細書に記載の教示を与えられれば、複数の変形形態を実現するであろう。
【００４７】
たとえば、失敗定義、失敗評価、およびメッセージ送達という３つのモジュール（図１）を、単一のモジュールとして実施することができ、さらに多数の別々のモジュールに分割することができる（たとえば、別のメッセージ送達観察モジュール）。
【００４８】
メッセージ失敗状態に加えてまたはその代わりに、メッセージ成功状態を指定することができる。メッセージ成功状態は、失敗に関して定義する、すなわち、対応する失敗状態にマッピングすることができ、その結果、上で説明した本発明を実施する好ましい形が、すべての態様での成功状態に適用可能になる。
【００４９】
もう１つの変形形態が、メッセージ送信の前のメッセージ失敗定義およびメッセージ作成の可変順序、最終的な受信側によって読み取られるメッセージを観察する異なる形、およびメッセージに関する評価結果に関してメッセージ送信側に通知する異なる形を含めることができる。
【００５０】
図８を参照すると、図に示され本明細書で詳細に説明されたメッセージ交換処理を使用するシステムのさまざまな機能構成要素／モジュールの１つまたは複数を実施するのに適するコンピュータ・システムの一般化されたハードウェア・アーキテクチャを示すブロック図が示されている。たとえば図１に関して図示され説明されたものなどのメッセージ交換システムの個々の構成要素を、１つのそのようなコンピュータ・システムで、または複数の別々のそのようなコンピュータ・システムで実施することができることを理解されたい。
【００５１】
図からわかるように、コンピュータ・システムは、プロセッサ８００、メモリ８１０、および入出力装置８２０に従って実施することができる。本明細書で使用される用語「プロセッサ」が、たとえばＣＰＵ（中央処理装置）または他の処理回路もしくはその両方を含むものなど、すべての処理装置を含むことが意図されていることを了解されたい。本明細書で使用される用語「メモリ」は、たとえばＲＡＭ、ＲＯＭ、固定メモリ・デバイス（たとえばハード・ドライブ）、取外し可能メモリ・デバイス（たとえばディスケット）、フラッシュ・メモリなど、プロセッサまたはＣＰＵに関連するメモリを含むことが意図されている。さらに本明細書で使用される用語「入出力装置」は、たとえば、処理装置にデータを入力するための、たとえばキーボードなどの１つまたは複数の入力装置、または処理装置に関連する結果を提示するための、たとえばＣＲＴディスプレイまたはプリンタなどの１つまたは複数の出力装置、あるいはその両方を含むことが意図されている。用語「プロセッサ」が、複数の処理装置を指す場合があることと、処理装置に関連するさまざまな要素を、他の処理装置が共用できることを理解されたい。
【００５２】
したがって、本明細書に記載の本発明の方法を実行する命令またはコードを含むソフトウェア構成要素を、１つまたは複数の関連するメモリ・デバイス（たとえばＲＯＭ、固定メモリ、または取外し可能メモリ）に保管することができ、使用の準備ができた時に、一部または全体を（たとえばＲＡＭに）ロードし、ＣＰＵによって実行することができる。
【００５３】
添付図面に関して本発明の例示的実施形態を説明してきたが、本発明が、これらの正確な実施形態に制限されず、当業者が、さまざまな他の変更および修正を行うことができることを理解されたい。
【図面の簡単な説明】
【図１】
本発明の実施形態によるメッセージ交換を使用するシステムのブロック図である。
【図２】
図４、図５、図６、および図７の流れ図に関係する、本発明の実施形態によるメッセージ交換処理の流れ図である。
【図３】
本発明の実施形態によるメッセージ失敗定義処理の流れ図である。
【図４】
本発明の実施形態によるメッセージ送信処理の流れ図である。
【図５】
本発明の実施形態によるメッセージ送達観察処理の流れ図である。
【図６】
本発明の実施形態によるメッセージ失敗評価処理の流れ図である。
【図７】
本発明の実施形態によるメッセージ失敗状態修正処理の流れ図である。
【図８】
本発明によるメッセージ交換システムを実施するのに適するコンピュータ・システムの一般化されたハードウェア・アーキテクチャを示すブロック図である。

Claims (35)

1. 非同期メッセージ交換システムで使用されるコンピュータベースの方法であって、
   システム内で送信される少なくとも１つのメッセージに関する少なくとも１つのメッセージ送達結果状態を定義し、少なくとも１つのメッセージ送達結果状態をシステム内で送信されるメッセージに関連付けるステップと、
   関連する少なくとも１つのメッセージ送達結果状態と共にメッセージをシステム内で送信するステップと、
   メッセージの送信側がメッセージの送達結果に関して通知されることができるように、送信されたメッセージの送達を監視し、関連する少なくとも１つのメッセージ送達結果状態に関してメッセージの送達結果を評価するステップと
   を含む方法。
2. 送達結果が、成功および失敗の１つである、請求項１に記載の方法。
3. 少なくとも１つのメッセージ送達結果状態が、特定のメッセージと独立に定義される、請求項２に記載の方法。
4. メッセージ送達結果状態が、永続オブジェクトとして表現される、請求項１ないし３のいずれか一項に記載の方法。
5. 特定のメッセージ送達結果状態表現が、関連するオブジェクトの組である、請求項４に記載の方法。
6. 送信されるメッセージが、１つまたは複数の永続オブジェクトの形のメッセージ送達結果状態の表現に関連付けられる、請求項１ないし３のいずれか一項に記載の方法。
7. メッセージ送達結果状態の特定の表現が、異なるメッセージの組と関連付けられる、請求項６に記載の方法。
8. 送達を監視するステップが、１つまたは複数の宛先および１つまたは複数の最終的なメッセージ受信側の少なくとも１つに従って実行される、請求項１ないし７のいずれか一項に記載の方法。
9. 送達を監視するステップが、メッセージ受信を永続メッセージ送達ログに記録するステップを含む、請求項１ないし８のいずれか一項に記載の方法。
10. 送達結果が、結果表現オブジェクトと、メッセージ受信が記録されるメッセージ送達ログとを使用することによって評価される、請求項１ないし９のいずれか一項に記載の方法。
11. 送達結果評価の状況が、メッセージ送信側によって照会される、請求項１ないし１０のいずれか一項に記載の方法。
12. 送達結果が、メッセージ送信側に送信される、請求項１ないし１１のいずれか一項に記載の方法。
13. 送達結果が、メッセージ送信側が結果通知を受け取るために指定したオブジェクトに送信される、請求項１ないし１１のいずれか一項に記載の方法。
14. メッセージ送達監視および送達結果評価の少なくとも１つが、タイムアウトをそれに関連付けられる、請求項１ないし１３のいずれか一項に記載の方法。
15. メッセージが送出された後に、メッセージに関連する１つまたは複数のメッセージ送達結果状態を修正するステップをさらに含む、請求項１ないし１４のいずれか一項に記載の方法。
16. メッセージが送出された後に、メッセージに関連する１つまたは複数のメッセージ送達結果状態を置換するステップをさらに含む、請求項１ないし１４のいずれか一項に記載の方法。
17. 非同期メッセージ交換システムで使用される装置であって、
    （ｉ）システム内で送信される少なくとも１つのメッセージに関する少なくとも１つのメッセージ送達結果状態を定義し、メッセージ送達結果状態をシステム内で送信されるメッセージに関連付け、（ｉｉ）関連するメッセージ送達結果状態と共にメッセージをシステム内で送信し、（ｉｉｉ）メッセージの送信側がメッセージの送達結果に関して通知されることができるように、送信されたメッセージの送達を監視し、関連するメッセージ送達結果状態に関してメッセージの送達結果を評価する：ように機能する１つまたは複数のプロセッサ
    を含む装置。
18. メッセージ送達結果が、成功および失敗の１つである、請求項１７に記載の装置。
19. 少なくとも１つのメッセージ送達結果が、特定のメッセージと独立に定義される、請求項１７または１８に記載の装置。
20. メッセージ送達結果状態が、永続オブジェクトとして表現される、請求項１７ないし１９のいずれか一項に記載の装置。
21. 特定のメッセージ送達結果状態表現が、関連するオブジェクトの組である、請求項２０に記載の装置。
22. 送信されるメッセージが、１つまたは複数の永続オブジェクトの形のメッセージ結果状態の表現に関連付けられる、請求項１７ないし１９のいずれか一項に記載の装置。
23. メッセージ送達結果状態の特定の表現が、異なるメッセージの組と関連付けられる、請求項２２に記載の装置。
24. メッセージ送達監視動作が、１つまたは複数の宛先および１つまたは複数の最終的なメッセージ受信側の少なくとも１つに従って実行される、請求項１７ないし２３のいずれか一項に記載の装置。
25. メッセージ送達監視動作が、メッセージ受信を永続メッセージ送達ログに記録することを含む、請求項１７ないし２４のいずれか一項に記載の装置。
26. 送達結果が、結果表現オブジェクトと、メッセージ受信が記録されるメッセージ送達ログとを使用することによって評価される、請求項１７ないし２５のいずれか一項に記載の装置。
27. 送達結果評価の状況が、メッセージ送信側によって照会される、請求項１７ないし２６のいずれか一項に記載の装置。
28. 送達結果が、メッセージ送信側に送信される、請求項１７ないし２７のいずれか一項に記載の装置。
29. 送達結果が、メッセージ送信側が結果通知を受け取るために指定したオブジェクトに送信される、請求項１７ないし２７のいずれか一項に記載の装置。
30. メッセージ送達結果監視および送達結果評価の少なくとも１つが、タイムアウトをそれに関連付けられる、請求項１７ないし２９のいずれか一項に記載の装置。
31. １つまたは複数のプロセッサが、さらに、メッセージが送出された後に、メッセージに関連する１つまたは複数のメッセージ送達結果状態を修正するように機能する、請求項１７ないし３０のいずれか一項に記載の装置。
32. １つまたは複数のプロセッサが、さらに、メッセージが送出された後に、メッセージに関連する１つまたは複数のメッセージ送達結果状態を置換するように機能する、請求項１７ないし３０のいずれか一項に記載の装置。
33. データ処理システムで実行される時に、前記システムに請求項１ないし１６のいずれか一項に記載の方法を実行させる命令を含むコンピュータ・プログラム。
34. 非同期メッセージ交換システムに関連するアプリケーション・プログラミング・インターフェースであって、実行される時に、
    メッセージ単位でメッセージ送達結果状態を指定するステップと、
    メッセージとメッセージ結果状態を関連付けるステップと、
    関連付けられた結果状態と共にメッセージを送信するステップと、
    結果状態に関してメッセージ送達の状況に関して照会するステップと、
    メッセージについて指定された結果状態の修正および置換の少なくとも１つを可能にするステップと、
    評価結果通知を受け取るオブジェクトを指定するステップと
    の実施を可能にするソフトウェア・コードを含む、アプリケーション・プログラミング・インターフェース。
35. 非同期メッセージ交換システム内で使用される装置であって、
    （ｉ）永続オブジェクトとしてメッセージ結果状態を表現し、（ｉｉ）メッセージ送達を観察し、（ｉｉｉ）メッセージ結果状態を評価し、（ｉｖ）結果状態に関するメッセージ送達の状況に関する照会に答え、（ｖ）送信された各メッセージの評価結果に関してメッセージ送信側または送信側が指定するオブジェクトに通知する：ように機能する１つまたは複数のプロセッサ
    を含む装置。

Images