JP2009531879A - メッセージ再伝送のための方法およびシステム並びにシステム間メッセージ配信のための方法およびシステム - Google Patents

Abstract

本発明は、最小の再試行回数かつ最高の配信適時性で受信者にメッセージを再送信するための方法およびシステムを開示する。該方法は、再送信する必要のあるメッセージに再試行期間を決定し、該再試行期間に従って、再試行時刻を設定し、該再試行時刻に到達した後、該メッセージを送信する。該再試行期間は、再試行回数が増加するとともに増加する。該方法および該システムは、通知メッセージの信頼性のある配信を保証することができ、異なるシステム間の多くの伝送プロトコルをサポートし、通知メッセージを確実に受信するために、該受信者が複雑な対話プロトコルを実装することを必要とせず、インターネットでの普及に適している。さらに、本開示は、複数のトランザクション処理をサポートし、業務トランザクションアプリケーションの共通プラットフォームとして使用することができ、複数のトランザクションおよび複数のプロトコルの柔軟な拡張を可能にする。

Description

本発明は、データ伝送の分野、特にメッセージ再伝送およびシステム間メッセージ配信のための方法およびシステムに関する。

本願は、２００６年３月３０日に出願された、中国特許出願、出願第２００６１００６６３６７．９号、名称「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＯＦ ＭＥＳＳＡＧＥ ＲＥＴＲＡＮＳＭＩＳＳＩＯＮ」の優先権を主張し、該中国特許出願の全体を参照として組み込む。

データ伝送の分野では、それらの対話形式としてメッセージ通知を使用するアプリケーションシステムの数が増加している。メッセージの伝送中、伝送リンクまたはシステムの障害のため、伝送中にメッセージが紛失し、適時に、または確実に配信されない場合がある。この問題を解決するために、正常に配信されなかったメッセージを再送信するための様々なメッセージ再送信機構が開発され、使用されている。これらの再送信機構では、最初の配信に失敗した場合、メッセージを再度送信する試みが行われる。これは、大体において、配信不可メッセージの問題を解決することができる。しかしながら、中期間および長期間通信障害で、過度に多くの再送信が試みられる場合があり、これは、時間を無駄にするだけでなく、システム資源を消費し、低配信効率の原因にもなる。

ネットワークプロトコルの設計において、データ伝送の失敗を対象とする、多くの再伝送バックオフアルゴリズムが開発されてきた。最も一般的なものは、Ｂｉｎａｒｙ Ｅｘｐｏｎｅｎｔｉａｌ Ｂａｃｋｏｆｆ（ＢＥＢ）アルゴリズムである。以下では、このアルゴリズムを詳細に例示するために、例としてＥｔｈｅｒｎｅｔ（登録商標）８０２．３プロトコルを使用する。

８０２．３プロトコルは、ＣＳＭＡ／ＣＤ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ）アルゴリズムを使用して、共有チャンネルでのデータ衝突の問題を解決する。該アルゴリズムは、チャンネルがアイドル状態になるまで、常にチャンネルをリッスンする。一度チャンネルがアイドル状態になると、即時にデータが送信される。データ衝突が発生した場合、送信が直ちに停止される。そして再試行期間後、再送信が試みられる。再試行期間は、Ｂｉｎａｒｙ Ｅｘｐｏｎｅｎｔｉａｌ Ｂａｃｋｏｆｆアルゴリズムを使用して計算される。アルゴリズムは、最初に、それぞれのタイムスライスがｔ（５１．２ミリ秒長）のスライスに時間を分割する。ｉ回目の衝突で、０から（２ⁱ−１）^*ｔの間でランダムに選択された時間として、ｔの整倍数の時間長を有する再試行期間が設定される。

Ｂｉｎａｒｙ Ｅｘｐｏｎｅｎｔｉａｌ Ｂａｃｋｏｆｆアルゴリズムは、データ伝送で障害が発生した際に、再試行時刻間隔（期間）を指数関数的に増加することができる。しかしながら、不規則な障害パターンに基づき、再試行時刻間隔を計算するためのこのようなアルゴリズムは、インターネットシステム間メッセージ通知の規則的な障害パターンに適しておらず、多くの場合、障害回復により長い時間がかかる原因となる。通常、インターネットシステム間メッセージ通知における障害の原因とは、混み合ったネットワークのためのオーバータイム伝送、ネットワークシステムにおける障害、アプリケーションシステムにおける障害、またはメンテナンスのための予定されたシステムのシャットダウン等である。これらの障害の発生は不規則であるが、障害回復には、人による検出およびメンテナンスが介入するため、障害回復は、不規則ではなく、特定のパターンを有する。さらに、インターネット上の障害回復の時間は、通常、時間または日数で示される。該期間中、大量な未送信メッセージが蓄積される場合がある。従って、メッセージの保管、管理、および再伝送スケジューリングに非常に効率的かつ柔軟なアルゴリズムおよびシステムが必要である。インターネットを介したメッセージ再伝送に適していると同時に、システム資源の占有とメッセージ通知の適時回復との間の柔軟なバランスを達成する方法およびシステムを開発することにが、非常に重要である。

本発明は、再試行回数を最小化する一方、受信者へのメッセージ送信の適時性を最適化することができる、メッセージ再伝送の方法およびシステムの技術的解決策を提供することを目的とする。

この目的を達成するために、本発明は、
再送信する必要のあるメッセージに再試行期間を設定し、該再試行期間を使用して、再試行時刻を決定するステップと、
再試行回数が増加するとともに、再試行期間を増加するステップと、
該再試行時刻に到達した後、該メッセージを送信するステップと、を含む、メッセージ再伝送の方法を提供する。

好ましくは、再試行期間を使用して再試行時刻を決定するステップは、現在の時刻に該再試行期間を加算したものになるように該再試行時刻を設定するステップを含む。

好ましくは、再試行回数が設定値に到達する、または設定値を超過した際、自動再送信は、中止される。

好ましくは、再試行期間が設定値に到達する、または設定値を超過した際、自動再送信は、中止される。

好ましくは、再試行期間の増分は、再試行回数が増加するとともに変化し、増分のサイズは、異なる外部システムに従って設定することができる。

また本発明は、システム間メッセージ通知のシステムも提供する。該システムは、
送信待ちメッセージを保管するために使用されるデータベースと、
該メッセージを送信および再送信するために使用される通知実行ユニットであって、通知メッセージの送信に失敗した際、該通知実行ユニットは、該メッセージに再施行期間を設定し、該再試行期間に従って、該データベース内のメッセージの再試行時刻を更新し、再試行期間は、再試行回数が増加するとともに増加する、通知実行ユニットと、
再送信待ちのいずれの通知メッセージの再試行時刻が期限であるかどうかを確認するために使用される通知回復ユニットであって、いずれかの通知メッセージの再試行時刻が期限である場合、該通知回復ユニットは、特定されたメッセージを再送信するように該通知実行ユニットの開始を引き起こす、通知回復ユニットと、を含む。

好ましくは、通知回復ユニットは、設定された時刻に起動する。

また本発明は、システム間メッセージ通知の方法も提供し、該方法は、
通知メッセージを保管するステップと、
該保管された通知メッセージを送信するステップと、
該通知メッセージの送信に失敗した場合、該通知メッセージに再試行期間を設定し、該再試行期間を使用して、再試行時刻を決定するステップであって、該再試行期間は、再試行回数が増加するとともに増加する、ステップと、
該再試行時刻に到達した後、該通知メッセージを送信するステップと、を含む。

好ましくは、通知メッセージは、業務アプリケーションで対向側に送信する必要のあるメッセージである。通知メッセージの送信の失敗には、返信メッセージが対向側から受信されない、または対向側から業務トランザクション成功のメッセージが受信されない等の状態を含む。

好ましくは、通知メッセージを再送信するステップは、設定期間で、再試行の期限である通知メッセージを特定するステップと、特定された通知メッセージを再送信するステップと、を含む。

好ましくは、システム間メッセージ通知の方法は、対応する通知メッセージが正常に送信された場合、保管された通知メッセージを削除するステップも含む。

また本発明は、メッセージ再伝送のシステムであって、再送信する必要のあるメッセージに再試行期間を設定するために使用される再試行期間ユニットであって、該再試行期間は、再試行回数が増加するとともに増加する、再試行期間ユニットと、該再試行期間に従って、再試行時刻を決定するために使用される再試行時刻ユニットと、該再試行時刻に到達した後、該メッセージを送信するために使用される送信ユニッと、を含む、システムを提供する。

本発明の方法およびシステムは、短期間および中長期間のパターンを対象に、タイムアウトおよびメッセージ再送信処理の実用的かつ効率的な方法を提供する。再試行回数が増加するとともに、再試行時刻間の間隔が増加する。再試行時刻間隔の変更は、同時に、通知回復の適時性と効率のバランスの取れた考慮を示す。本発明は、短期間通信障害に対して、障害から回復した後、対向側にメッセージを適時に送信することができる一方、中長期間障害の場合には、多すぎる不要な再試行を行うコストを回避できる場合がある。

インターネットに基づく電子商取引は、今日の社会で、より重要な位置を占め、より多くの企業体がインターネットを介した情報フロー、資金フロー、および物流を組織化するようになってきている。対話形式としてメッセージ通知を使用するインターネットアプリケーションシステムの数は、上昇中である。一例は、バンキングである。ユーザが銀行で支払いを完了した後、銀行は、通知メッセージを使用して、販売業者のシステムにユーザの支払い状況を知らせる必要がある。別の例は、第３者の安全なトランザクションプラットフォームである。ユーザがトランザクションプラットフォーム上で業務トランザクションを進行した後、トランザクションプラットフォームは、関係する外部の販売業者のシステムに業務トランザクションの現在の状態を知らせる必要がある。これらは、インターネットベースのメッセージ通知の典型的な例である。本発明は、あらゆる協働システム間での使用に適しているが、設計は、インターネットを介したメッセージ通知の失敗の共通原因を、特に対象としている。従って、以下で、説明のための一例として、メッセージ通知の好ましい実施形態を使用する。

インターネットを介したシステム間メッセージ通知の失敗のいくつかの考えられる原因は、ネットワークが一時的に混み合い、伝送プロトコルのオーバータイムの原因になっている、ネットワークが一時的に切断されている、対向側のサーバが一時的に混み合い、要求に応答できない、対向側にバグがあり、要求に応答できない、または要求を不適切に処理する、対向側のサーバがハングアップし、従って要求に応答できない、ネットワークの長期間障害が数時間またはさらには数日間の侵害の原因となっている、対向側の長期間障害が数時間またはさらには数日間利用できない原因となっている、および対向側が存在しない、または恒久的にシャットダウンしている、である。

上記に記載の理由から、メッセージ通知の失敗は、数分以内に解消する、または解放される場合があるが、数時間およびさらには数日間持続する場合もある。従って、メッセージ通知の好ましい再試行戦略は、数分以内に原因が解消する、または解放される場合、メッセージ通知が適時に相手方に送信され、原因が解消するまでに数時間またはさらには数日間必要な場合、システムは、多すぎる不要な再試行を行わずに、依然としてメッセージ通知を相手方に送信できることを達成することを目標とするべきである。従って、本発明は、再試行時刻間隔を決定するために、好ましくは、以下に記載される再試行間隔決定方法を導入する。本説明では、再試行時刻間隔は、再試行期間を指す。

図１は、再試行時刻間隔を決定するための方法の概念ダイアグラムを示す。再試行間隔決定方法は、以下に記載される。

１からｎ＋１の番号が付いた複数のボックスがあり、１からｎまで番号の付いたボックスは、それぞれタイマーに関連すると仮定する。それぞれのタイマーは、設定時刻を有し、該設定時刻は、ボックスの番号が増加するとともに増加する。例えば、ボックス番号１の設定時刻は、２分間であり、ボックス番号２は、５分間であり、ボックス番号３は、１０分間等である。ｎ＋１の番号の付いたボックスには、タイマーがなく、メッセージがメッセージの受信者に決して到達せず、自動再試行を中止し、手動回復を待つべきであることを示す。

動作中、メッセージ通知がｉ回だけ失敗した後、番号ｉの付いたボックスに置かれ、番号ｉの付いたボックスのタイマーの設定時刻に到達した後、再試行するようにボックス内のすべてのメッセージ通知の開始が引き起こされ、メッセージ通知がｎ＋１回失敗した後、番号ｎ＋１のついたボックスに置かれる。番号ｎ＋１のボックスには、タイマーが無いため、システムは、このメッセージ通知の自動再試行を中止し、このメッセージ通知を手動処理に渡す。

本発明の通知システムは、対応する外部システムの失敗パターンに適合するために、外部システムの異なる種類の特性に従い、それぞれのボックスのタイマーを調節することもできる。

上記に記載されるように、本発明のメッセージ再送信方法の核となる構想は、再試行回数が増加するとともに再試行期間を増加することである。図１に示されるような再試行間隔決定方法では、メッセージ通知の再試行回数が少ない場合、通知メッセージの送信における障害が短時間に消失したことを示す。この場合、それぞれの再試行間の時刻間隔が小さいため、原因が解消された際に、適時に通知メッセージが配信されることを保証することができる。しかしながら、メッセージ通知の再試行の回数が大きい場合、長期間通信障害が生じており、通知メッセージの配信が正常に行われない原因となっていることを示す。以降の再試行時刻間隔が次第に長くなるため、これは、依然として通知メッセージの配信を保証しつつ、不要な再試行を効果的に回避し、システム資源の使用を減少する。従って、記載される再試行間隔決定方法は、短期間通信障害におけるメッセージ通知の適時な回復、および長期間通信障害中の多くの不用な再試行の回避の両方を保証することができる。このように、記載される再試行間隔決定方法は、通知回復の適時性および効率性の両方を同時に達成することができる。

上記に記載の自動再試行を中止する判断基準は、再試行回数が設定値に到達することで表される。しかしながら、本発明は、この種類の判断基準に制限されない。例えば、自動再試行は、再試行期間が設定値に達した際に中止することもできる。異なるアプリケーションシステムまたは異なるトランザクション条件により、無限に再送信を試みることを回避するための設定値を設定するために、あらゆる方法を選択してもよい。

本発明の再試行期間終了方法では、好ましくは、再試行期間の増分は、再試行回数が増加するとともに変化する。つまり、現在の再試行期間と以前の再試行期間との間の差は、次の再試行期間と現在の再試行期間との間の差と同一でなくてもよい。図１に示されるように、番号が３と２のボックスの設定時刻の間隔は、５分間である一方、番号が４と３のボックスの設定時刻の間隔は、２０分間である。従って、再試行期間の増分は、それぞれ５分間および２０分間であり、一定ではない。一方、再試行期間に一定増分を使用する方法も、使用することができる。好ましい方法では、再試行期間の増分の変化は、対向側の異なるシステムに従って設定することができる。対向側のシステムの異なる種類の特性を調整することによって、再試行期間に異なる増分を設定し、再試行時刻に異なる時刻間隔を設定することができる。該設定は、メッセージ送信の適時性および効率の考慮のバランスを取り、アプリケーションのニーズをより満足する。

図２は、信頼性のあるシステム間メッセージ通知のための装置およびシステムの概略ダイアグラムを示す。該メッセージ通知システムは、本発明に開示されるメッセージ再送信方法を使用することができる。メッセージ通知システムは、以下を含んでもよい。

送信される通知メッセージを保管するために使用されるデータベース１３。送信される通知メッセージには、未だ送信されていない新しい通知メッセージおよび再送信待ちの通知メッセージを含む。

新しい通知メッセージまたは再送信する必要のある通知メッセージを送信するために使用される、通知実行ユニット１５２。該通知メッセージが正常に配信された場合、該通知実行ユニット１５２は、この通知メッセージをデータベース１３から削除する。そうでない場合、通知実行ユニット１５２は、通知メッセージに再試行期間を設定し、現在の時刻に再試行期間を加算したものになるように、再試行時刻を設定し、該データベース１３内の該通知メッセージの対応するパラメータを更新する（例えば、該データベース１３内の該通知メッセージの再試行時刻を更新する）。再試行期間は、再試行回数が増加するとともに増加する。

再送信待ちのいずれの通知メッセージの再試行時刻が期限であるかどうかを確認するために使用される、通知回復ユニット１５１。いずれかの通知メッセージの再試行時刻が期限である場合、通知回復ユニット１５１は、通知実行ユニット１５２に通知する。

図２に示されるように、業務アプリケーション１１は、いずれの販売業者アプリケーションであってもよい、メッセージ通知プロセスの開始プログラムである。外部システム１７は、いずれの販売業者のシステムであってもよく、通知メッセージの受信者の役割を果たす。本発明の通知システムは、業務アプリケーション１１から受信した通知メッセージを配信するため、およびインターネット上の外部システム１７への通知メッセージの信頼性のある配信を保証するために使用される。

データベース１３は、いずれの一般的な関係データベースであってもよく、配信待ちの新しい通知メッセージ、および以前に配信に失敗した、現在再送信待ちの通知メッセージを保管するために使用される。通知クライアント１２は、業務アプリケーション１１によって使用されるクライアントモジュールであってもよく、業務アプリケーションシステムに組み込まれてもよい。業務アプリケーション１１は、通知メッセージを登録するために、通知クライアント１２を使用することができる。一度通知メッセージの登録が正常に行われると、通知システムは、メッセージの受信者がオフラインである、またはネットワークが一時的に切断されていたとしても、通知メッセージがメッセージの受信者に確実に配信されるようにすることができる。通知メッセージの登録プロセスは、業務アプリケーション１１から受信される通知メッセージをデータベース１３に保管する、通知クライアント１２を有し、メッセージキュー１４によって、通知メッセージの即時配信の開始を引き起こすことができる。業務アプリケーションシステムは、業務アプリケーション１１に関連して、関連トランザクションを処理するシステムを指す。一例として、オンラインバンクと販売業者との間のメッセージ通知を用いて例示される通知メッセージに関連する業務トランザクションは、ユーザがオンラインバンクで実際の支払いを行うことを指す。支払いが完了した場合、業務トランザクションは、完了に提出される。そうでない場合、業務トランザクションは、依然として進行中である。通知メッセージは、支払いが完了したかどうかを示す、ユーザの支払い結果を指す。トランザクションは、専門用語であり、ＡＣＩＤ特性を有する操作の一群を示す。トランザクションが生成される際、トランザクションが確実にいくつかの自己管理特性を有するようにすることが望ましい。これらの特性は、ＡＣＩＤと呼ばれる。ＡＣＩＤは、原子性（Ａｔｏｍｉｃｉｔｙ）、一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）、独立性（Ｉｓｏｌａｔｉｏｎ）、および耐久性（Ｄｕｒａｂｉｌｉｔｙ）を意味する。

通知クライアント１２を業務アプリケーションシステムに組み込むことにより、業務トランザクション処理の完了および通知メッセージを同一データベースのトランザクションに登録することが可能となり、従って、業務トランザクション処理とメッセージ通知との間の不一致を完全に回避することができる。ここで、一貫性は、通知メッセージを正常に登録し、対応する業務トランザクションの完了後にのみ、即時に送信することができることを意味する。データベーストランザクションで使用されるデータベースは、通知メッセージを保管する、システムのデータベースであってもよい。通常、このデータベースは、業務トランザクションデータを保管するための業務アプリケーションシステム内の同一データベースである。同一データベースを使用することによって、複雑で効率が低い分散トランザクション機構を使用することなく、同一データベーストランザクション内で、通知メッセージの登録および業務トランザクションデータの処理を実行できるようになる。しかしながら、通知メッセージの登録と業務トランザクションデータの処理との間の一貫性は、異なるデータベースを使用する分散トランザクション機構により、維持することができる。

メッセージキュー１４は、システム間の非同期情報通信のための標準ミドルウェアである。メッセージキュー１４を使用することによって、メッセージの送信および受信プロセスを非同期にすることができ、一方、メッセージの差出人および受信者は、メッセージキュー１４によって間接的に通信することができる。これは、メッセージの差出人および受信者との間の相互依存を最小化し、従って、両者が比較的に独立して、それぞれのタスクを実行することを可能にする。一般にメッセージキューは、メッセージの受信を受け、メッセージの受信者が通常動作状態である限り、即時にメッセージを受信者に送信する。本例示的な実施形態では、メッセージキュー１４は、通知メッセージの即時配信の開始を引き起こすために使用される。

通知サーバ１５は、通知メッセージの送信および再送信に関与する、サーバまたは別個のサーバのグループであってもよい。通知サーバ１５は、通知回復ユニット１５１、通知実行ユニット１５２、および様々なプロトコルアダプタ１５３を含んでもよい。通知回復ユニット１５１は、配信に失敗した通知メッセージを設定時刻に再送信するためのスケジューリングに関与するモジュールである。通知実行ユニット１５２は、通知メッセージの実際の配信を実行するモジュールである。様々なプロトコルアダプタ１５３のそれぞれのプロトコルアダプタは、伝送プロトコルをサポートし、インターネット上の外部システム１７への実際のデータ伝送を完了する。業務トランザクションプラグインライブラリ１６は、異なる業務トランザクションプラグイン１６１を含む。業務トランザクションプラグイン１６１は、異なるトランザクションの種類に対応し、通知メッセージの配信前の前処理、および返信結果メッセージの処理に関与する。前処理および返信処理は、業務アプリケーションに密接に関係する。異なる業務アプリケーションは、異なる処理プロセスを有してもよい。

図３は、本発明による、メッセージを再送信する方法のフローチャートを示す。このプロセスは、図２に示される通知システムによって使用される、メッセージ再送信プロセスである。いずれの当業者も、該メッセージ再送信方法が、その他の種類の送信実装を利用する、また、あらゆるインターネットノードでの使用にも適していることを理解するべきである。

メッセージの送信に失敗した場合、メッセージを再送信するプロセスは、以下の手順に入る。

ステップＧ１は、該メッセージの次の再試行時刻を計算する。通知実行ユニットは、再試行期間終了方法に従って、次の再試行の時刻間隔を計算し、現在の時刻に該計算された再試行期間を加算したものになるように、メッセージを再送信する次の再試行時刻を設定する。該再試行期間は、再試行回数が増加するとともに増加する。

ステップＧ２は、データベース内の関連情報を更新する。該通知実行ユニットは、計算された再試行期間に基づき、データベース内のメッセージを送信する時刻が再試行時刻になるように更新し、通知回復ユニットがスケジュールを組み直すのを待つ。

ステップＧ３で、通知回復ユニットは、メッセージの送信を回復し、タイムスケジュールを設定し、再試行時刻の期限であるメッセージを送信する。

図４は、メッセージ通知を回復するフローチャートを示す。通知メッセージを再送信する必要がある場合、通知プロセスは、通知回復に入る。好ましくは、通知回復ユニットは、設定された時刻に起動する。起動毎に、以下のステップが実行される。

ステップＣ１で、通知回復ユニットは、設定時刻が来るのを待ち、該時刻に到達した際に、動作を開始する。

ステップＣ２で、通知回復ユニットは、データベース内の再試行時刻の期限であるメッセージ通知要求を探す。通知回復ユニットは、再試行が必要なメッセージ通知要求を確認し、通知実行ユニットによって計算された再試行時刻を現在の起動の設定時刻と比較する。いずれかの再試行時刻が設定時刻と同等以下の場合、再試行時刻の期限であるメッセージ要求が存在し、通知プロセスは、ステップＣ３を継続する。そうでない場合、再試行の現在の起動が中止され、プロセスは、ステップＣ４に進む。

ステップＣ３で、通知回復ユニットは、通知実行ユニットに再試行時刻の期限である通知メッセージに関する再試行要求を送信し、配信するために、通知メッセージを１つずつ通知実行ユニットに提供する。

ステップＣ４で、通知回復ユニットは、次の起動のために、次の設定時刻まで待機する。

通常、通知回復プロセスを起動する設定される時刻間隔は、例えば、１分間に１回固定される。設定時刻間の間隔の大きさは、通知回復の適時性に影響する。従って、時刻間隔を可能な限り小さく設定することが望ましいが、通知サーバの許容範囲内でなければいけない。設定される時刻間隔は、メッセージ通知の再試行時刻間隔と同一ではないことに注意する。メッセージ通知の再試行時刻間隔は、再試行間隔決定方法により、それぞれの通知メッセージに対して、個別に計算され、設定される。

図３のステップＧ３を参照し、ステップＣ３での送信が正常に行われた場合、該メッセージの再送信が完了する。そうでない場合、プロセスはＧ１に進む。

また本発明は、図２に示される通知システムで使用することができる、信頼性のあるシステム間メッセージ通知の方法も提供する。図５は、信頼性のあるシステム間メッセージ通知の方法のフローチャートを示す。業務アプリケーションが通知メッセージを外部システムに送信する必要がある場合、通知メッセージの信頼性のある配信は、以下のステップによって達成することができる。

ステップＳ１で、業務アプリケーションは、その通知必要性をメッセージ通知要求にパッケージし、本要求を通知システムの通知クライアントに送信する。

ステップＳ２で、通知クライアントは、通知メッセージを登録する。一度通知メッセージの登録が行われると、業務アプリケーションは、その他のトランザクションを継続して実行することができる。通知システムは、メッセージの受信者がオフラインである、またはその時点で一時的に切断されていたとしても、通知メッセージを受信者に確実に配信する。

ステップＳ３で、通知メッセージが正常に登録された後、通知システムは、通知メッセージを送信する。対向側に正常に通知された場合、メッセージ通知のタスクが完了する。そうでない場合、プロセスは、ステップＳ４を継続する。本発明では、正常なメッセージ通知には、対向側へのメッセージの正常な配信、および対向側からの業務トランザクション成功のメッセージの受信を含む。

ステップＳ４は、メッセージ配信の回復を実行し、正常に配信されなかった通知メッセージを適時に再送信するためにスケジュールを組む。プロセスは、次いでステップＳ３に戻る。

本プロセスでは、ステップＳ４は、ステップＳ１、Ｓ２、またはＳ３と同時に実行することができる。ステップＳ４は、上記に記載されるステップＧ３と同一であり、その詳細は、図４のメッセージ通知を回復するフローチャートに記載される。以下で、ステップＳ２およびＳ３がそれぞれさらに詳細に記載される。

図６は、開示されるメッセージ通知方法における、登録プロセスのフローチャートを示す。登録は、以下のステップを含む。

ステップＡ１で、通知クライアントは、業務アプリケーションからメッセージ通知要求を受信する。メッセージ通知要求は、通知メッセージのコンテンツを含んでもよい。

ステップＡ２で、通知クライアントは、関連する通知メッセージが正常に送信されるまで、メッセージ通知要求をデータベースに保管する。これによって、ネットワーク、サーバ、またはソフトウェアシステムの不安定な性質による、回復不可能な通知メッセージの損失を回避することができる。

ステップＡ３で、通知クライアントは、通知メッセージに関連する業務トランザクションが完了しているかどうかを判断する。業務トランザクションが依然として進行中の場合、プロセスは、ステップＡ４、Ａ５、およびＡ６を継続する。業務トランザクションが完了すると、通知クライアントは、自動的にメッセージキューの開始を引き起こし、プロセスは、直接ステップＡ６に進む。オンラインバンクと販売業者との間のメッセージ通知を例に取る。通知メッセージに関連する業務トランザクションは、ユーザがオンラインバンクを使用して行う支払いであってもよい。支払いが正常に行われた場合、業務トランザクションは、完了する。そうでない場合、業務トランザクションは、依然として進行中である。通知メッセージは、支払いが完了しているかどうかを示す、ユーザの支払い結果を含むことができる。現行の例示的な実施形態では、通知クライアントが業務アプリケーションシステムに組み込まれているため、業務トランザクション内のデータベースにメッセージ通知要求を登録してもよい。これは、複雑な機構を使用することなく、業務トランザクション処理と通知要求の登録との間の一貫性を達成することができる。

ステップＡ４で、通知クライアントは、トランザクション管理ユニット内にトランザクションシンクロナイザを登録する。トランザクション管理ユニットは、トランザクションを管理するためのソフトウェアを指し、トランザクションシンクロナイザを含んでもよい。登録されたトランザクションシンクロナイザは、通知クライアント内に設置され、関連するトランザクションが提出された後、メッセージキューを介して通知メッセージの即時配信要求を通知サーバに送信するために使用される。これにより、通知の適時性を保証することができる。

ステップＡ５で、トランザクションシンクロナイザは、トランザクションが完了した後、メッセージキューの開始を自動的に引き起こす。

ステップＡ６で、メッセージキューは、通知メッセージの即時送信要求を通知実行ユニットに送信し、通知サーバがメッセージ伝送を実行するように促し、従って、通知の即時性を保証する。

図７は、通知メッセージ配信プロセスのフローチャートを示す。配信プロセスは、以下のステップを含む。

ステップＢ１で、通知実行ユニットは、通知クライアントからメッセージキューを介して送信された新しいメッセージ通知要求、または通知回復ユニットから送信されたメッセージ通知再試行要求を受信する。メッセージキューからの新しいメッセージ通知要求および通知回復ユニットからのメッセージ通知再試行要求が同時に受信された場合、通知実行ユニットは、好ましくは、マルチスレッド処理を実行し、新しい通知メッセージおよび再試行通知メッセージの両方を同時に送信する。あるいは、通知実行ユニットは、優先順位に基づき、別々に通知メッセージを送信することができる。

ステップＢ２で、通知実行ユニットは、メッセージ通知要求の種類に従い、業務トランザクションプラグインライブラリから業務トランザクションプラグインを選択し、外部システムの実際の通知アドレス、通知プロトコル、および通知パラメータを取得するための前処理のために、メッセージ通知要求を業務トランザクションプラグインに送信する。

ステップＢ３で、通知実行ユニットは、通知プロトコルに基づき、適したプロトコルアダプタを選択し、実際のメッセージ配信のために、通知メッセージのコンテンツである通知アドレスおよび通知パラメータをプロトコルアダプタに提供する。

ステップＢ４で、両者のネットワーク、サーバ、およびシステムが通常動作状態の場合、メッセージは、インターネットを介して外部システムに送信される。メッセージの受信および処理を受けて、外部システムは、処理結果を返す。そうでない場合、通知実行ユニットは、自動的に通知メッセージが外部システムに到達しなかったことを検出し、プロセスは、ステップＢ８およびＢ９に進む。

ステップＢ５で、通知実行ユニットは、返信結果を業務トランザクションプラグインに送信し、業務トランザクションプラグインに対応する業務トランザクション処理を完了させる。上記の実施例では、外部システムの返信結果の受信を受けて、業務トランザクションプラグインは、取引状況を「出荷済み品」に更新し、納品書の詳細を記録し、ユーザに出荷状況について通知する必要がある場合がある。通知サーバは、共用するために共有され、業務トランザクションのいずれの特定の種類に関係しないことから、上記の処理は、適した業務トランザクションプラグインによって実行される。

ステップＢ６で、業務トランザクションプラグインは、メッセージ配信の再試行が必要であるかどうかを判断する。業務トランザクションプラグインは、返信結果があるかどうか、ならびに返信結果のフォーマットおよびコンテンツが有効であるかどうかに基づき、判断する。例として、さらに上記の実施例を使用し、返信結果が有効な販売業者の出荷情報を有する場合、業務トランザクションプラグインは、メッセージ通知が正常に行われたと見なす。返信結果が受信されない、または返信結果が無効なフォーマットである場合、もしくは販売業者が、返信結果内に、一時的に処理することが不可能であり、再試行に一定の期間が必要であることを明確に示す場合、業務トランザクションプラグインは、このメッセージ通知が正常に行われておらず、再試行が必要であると見なす。

メッセージ通知の失敗がネットワークまたはシステムの障害だけに起因するとは限らず、業務トランザクション自体が正常に行われるかどうかにも依存することから、判断責任は、業務トランザクションプラグインが担う。これは、汎用の通知サーバが、ネットワークおよびシステムに障害があるかどうかを判断することしかできず、業務トランザクション自体が正常に行われたかどうかを判断できないためである。そうは言うものの、通知サーバが、ネットワークおよびシステムの障害を判断できることが明らかであることから、該状況下で、通知サーバは、再試行が必要であるかどうかを直接判断してもよい。

ステップＢ７で、業務トランザクションプラグインが再試行は必要ないと判断する場合、通知サーバは、データベースから対応するメッセージ通知要求を削除し、通知メッセージの配信を正常に完了する。

ステップＢ８で、ネットワーク問題等の様々な理由により、通知メッセージが外部システムに到達できない場合、または業務トランザクションプラグインがメッセージの再試行が必要であることを示す場合、通知サーバは、再試行戦略に従って次の再試行時刻間隔を計算し、現在の時刻に計算された時刻間隔を加算し、次の再試行の時刻を設定する。

ステップＢ９で、通知サーバは、再送信待ちの通知メッセージに対して、計算された再試行時刻に従ってデータベース内の対応するメッセージ通知要求の送信時刻を更新し、通知回復ユニットがスケジュールを組み直すのを待つ。

通知メッセージを送信する上記のプロセスは、業務トランザクションプラグインを拡張することによって、同一メッセージ通知システムを使用する、様々な種類のトランザクション通知に対するサポートを提供することができる。プロトコルプロセッサ／アダプタを拡張することによって、同一メッセージ通知システム内の異なるプロトコルの通知をサポートすることができる。さらに、通知メッセージの受信者は、いずれの特別な安全なメッセージング伝送プロトコルを実装する必要がなく、メッセージ通知の差出人から確実にメッセージを受信するために、業務トランザクション要件に従って、メッセージ処理結果を返すだけでよい。

図８は、本発明による、メッセージ再送信システムの概略ダイアグラムを示す。メッセージ再送信システムは、再試行期間ユニット８１、再試行時刻ユニット８２、および送信ユニット８３を含む。再試行期間ユニットは、再送信する必要のあるメッセージのそれぞれに再試行期間を設定する。該再試行期間は、再試行回数が増加するとともに増加する。再試行期間の値を設定する方法は、上記に記載されており、ここでは繰り返さない。再試行期間ユニット８１は、再試行期間の値を再試行時刻ユニット８２に送信する。次いで再試行時刻ユニットは、該再試行期間に従って、再試行時刻を決定する。再試行時刻を設定する簡単な方法の１つは、現在の時刻に再試行期間を加算することである。結果として送信ユニットは、該再試行時刻に到達した後、メッセージを送信する。

またメッセージ再送信システムは、再試行終了ユニット８４を含んでもよい。再試行終了ユニット８４は、再試行期間ユニット８１によって記録される再試行回数または再試行期間を監視する。ユーザは、再試行回数が設定値と同等以上である場合、または再試行期間が設定値と同等以上である場合、メッセージの再送信を中止するために、再試行終了ユニット８４を設置することができる。

本発明のメッセージ再伝送のための方法およびシステムは、再試行回数を最小化する一方、メッセージの受信者へのメッセージ配信の適時性を最適化することができる。さらに、インターネット上の短期間および中長期間通信障害のパターンを対象とすることで、本発明の方法およびシステムは、実用的かつ効率的なタイムアウトおよびメッセージ再送信処理の方法を提供する。再試行回数が増加するとともに、再試行時刻間の間隔が増加する。再試行時刻間隔の変更は、通知回復の適時性と効率性とのバランスが取れた考慮を同時に与える。本発明は、短期間通信障害に対して、障害から回復した後、対向側にメッセージを適時に送信することができる一方、中長期間障害の場合には、過度に多くの不要な再試行を行うコストを回避できる場合がある。

また本発明は、可能な限り少ない再試行を行う一方、可能な限り適時にメッセージをメッセージの受信者に配信することを試みる、信頼性のあるシステム間メッセージ通知のための方法およびシステムも提供する。本発明の信頼性のあるシステム間メッセージ通知のための方法およびシステムは、あらゆる協働システム間での使用に適している。特に、インターネット上のシステム間でメッセージ通知が実行される際に、本発明は、ネットワークの信頼性の欠如、ならびにハードウェアおよびソフトウェアの障害による、通知メッセージの回復不可能な損失の問題を解決し、メッセージの適時かつ信頼性のある配信を保証する。本発明は、異なるシステム間の様々な伝送プロトコルをサポートする。受信者は、複雑な対話プロトコルを実装する必要なく、通知メッセージを確実に受信することができ、本発明をインターネットでの普及に適したものにする。また該方法および該システムは、複数の業務トランザクション処理をサポートし、ユニバーサル業務トランザクションアプリケーションとしての役目を果たし、複数の業務トランザクションおよびプロトコルに対して、柔軟に拡張される。

本発明のメッセージ伝送および信頼性のあるシステム間メッセージ通知のための方法およびシステムは、上記に詳細に記載される。例示的な実施形態は、本文献の本発明の概念を例示するために採用される。本発明の方法およびシステムは、あらゆる協働システム間での使用に特に適しているが、インターネットベースのシステム間での使用に制限されない。本発明は、インターネットを介した信頼性のあるシステム間メッセージ通知を保証するために最適化することができ、特にインターネットでの普及に適しているが、本選好は、本発明の特許請求の範囲に対する制限として解釈されるべきではない。例示的な実施形態は、本発明の方法および核となる概念を、より理解するためだけに使用される。本発明の概念に基づき、当業者は、実用的な実装およびアプリケーション領域を修正してもよい。結論として、本記載の文脈は、本発明の制限として解釈されるべきではない。

本発明による、再試行期間を決定するための方法の概念ダイアグラムを示す。 システム間メッセージ通知のためのシステムの概略ダイアグラムを示す 本発明による、メッセージを再送信する方法のフローチャートを示す。 開示されるメッセージ再送信方法における、メッセージ通知を回復するフローチャートを示す。 信頼性のあるシステム間メッセージ通知の方法のフローチャートを示す。 開示されるメッセージ通知方法における、登録プロセスのフローチャートを示す。 開示されるメッセージ通知方法における、通知メッセージを送信するフローチャートを示す。 本発明による、メッセージ再送信システムの概略ダイアグラムを示す。

Claims (15)

1. メッセージ再伝送の方法であって、
   再送信が必要なメッセージの再試行期間を設定し、前記再試行期間に基づき、再試行時刻を決定するステップであって、前記再試行期間は、実行される再試行回数が増加するとともに増加する、ステップと、
   前記再試行時刻に到達した際に、前記メッセージを送信するステップと、
   を含むことを特徴とする、メッセージ再伝送の方法。
2. 前記再試行期間に基づき、再試行時刻を決定するステップは、現行の時刻に前記再試行期間を加算したものとなるように、前記再試行時刻を設定するステップを含むことを特徴とする、請求項１に記載のメッセージ再伝送の方法。
3. 再試行回数が設定値に到達する、または設定値を超過した際、自動再試行を中止するステップをさらに含むことを特徴とする、請求項１または２に記載のメッセージ再伝送の方法。
4. 前記再試行期間が設定値に到達する、または設定値を超過した際、自動再試行を中止するステップをさらに含むことを特徴とする、請求項１または２に記載のメッセージ再伝送の方法。
5. 前記再試行期間は、実行される再試行回数が増加するとともに増加する、可変増分を有することを特徴とする、請求項１に記載のメッセージ再伝送の方法。
6. システム間メッセージ通知のシステムであって、
   送信されるメッセージを保管するために使用されるデータベースと、
   前記メッセージを送信および再送信し、前記メッセージの送信に失敗した際、前記メッセージの再試行期間を設定し、前記再試行時刻に基づき、前記データベース内の前記メッセージの再試行時刻を更新するために使用される通知実行ユニットであって、前記再試行期間は、再試行回数が増加するとともに増加する、通知実行ユニットと、
   再試行時刻が期限であるメッセージを特定し、前記通知実行ユニットを、前記特定されたメッセージを再送信するように、開始を引き起こすために使用される通知回復ユニットと、
   を備えることを特徴とする、システム間メッセージ通知のシステム。
7. 前記通知回復ユニットは、設定時刻に起動することを特徴とする、請求項６に記載のシステム間メッセージ通知のシステム。
8. システム間メッセージ通知の方法であって、
   通知メッセージを保管するステップと、
   前記保管された通知メッセージを送信するステップと、
   前記通知メッセージの再試行期間を設定し、前記通知メッセージの送信に失敗した場合、前記再試行期間に従って、再試行時刻を決定するステップであって、前記再試行期間は、再試行回数が増加するとともに増加する、ステップと、
   前記再試行時刻に到達した際、前記通知メッセージを再送信するステップと、
   を含むことを特徴とする、システム間メッセージ通知の方法。
9. 前記通知メッセージは、業務アプリケーションによって対向側に送信され、前記通知メッセージの送信の失敗には、前記対向側から返信メッセージが受信されないこと、またはトランザクション成功のメッセージが前記対向側から受信されないことを含むことを特徴とする、請求項８に記載のシステム間メッセージ通知の方法。
10. 前記保管された通知メッセージを送信するステップは、
    前記通知メッセージのトランザクションの種類に従って、前記対向側のアドレスおよび伝送プロトコルを判断するステップと、
    前記伝送プロトコルを使用して、前記アドレスに前記通知メッセージを送信するステップと、
    を含むことを特徴とする、請求項９に記載のシステム間メッセージ通知の方法。
11. 前記通知メッセージを再送信するステップは、
    再試行の期限である通知メッセージを定期的に特定するステップと、
    前記特定された通知メッセージを再送信するステップと、
    を含むことを特徴とする、請求項９に記載のシステム間メッセージ通知の方法。
12. 前記通知メッセージが正常に送信された場合、前記保管された通知メッセージを削除するステップをさらに含むことを特徴とする、請求項８に記載のシステム間メッセージ通知の方法。
13. メッセージ再送信システムであって、
    再送信されるメッセージの再試行期間を設定するために使用される再試行期間ユニットであって、前記再試行期間は、再試行回数が増加するとともに増加する、再試行期間ユニットと、
    前記再試行期間に従って、再試行時刻を決定するために使用される再試行時刻ユニットと、
    前記再試行時刻に到達した後、前記メッセージを送信するために使用される送信ユニットと、
    を備えることを特徴とする、メッセージ再送信システム。
14. 再試行回数が設定値以上の場合、または前記再試行期間が設定値以上の場合、前記メッセージの再送信を終了するために使用される再試行終了ユニットをさらに備えることを特徴とする、請求項１３に記載のメッセージ再送信システム。
15. 前記再試行期間の増分は、実行される再試行回数が増加するとともに変化することを特徴とする、請求項１３に記載のメッセージ再送信システム。

Images