(57)【要約】  本発明は、通知メッセージの信頼性のある配信を保証することができる信頼性のあるシステム間メッセージ通知のための方法およびシステムを開示する。該方法は、以下のステップ、通知メッセージを永続的に保管するステップと、新たに保管された通知メッセージまたは再試行通知メッセージを送信するステップと、該通知メッセージが正常に送信されなかった場合に、該通知メッセージを再送信するステップとを含む。該方法およびシステムは、異なるシステム間の数多くの伝送プロトコルをサポートする。受信者は、複雑な対話プロトコルを実装する必要なく、確実に通知メッセージを受信することができる。従って本発明は、インターネットでの普及に適している。さらに、該方法およびシステムは、多重トランザクション処理をサポートし、共通業務トランザクションのアプリケーションのプラットフォームとして使用することができると同時に、多重トランザクションおよび多重プロトコルの柔軟な拡張を可能にする。
2009531749.tif 000002
【特許請求の範囲】
【請求項１】
システム間メッセージ通知の方法であって、
通知メッセージを保管するステップと、
前記保管された通知メッセージを送信するステップと、
前記通知メッセージの送信に失敗した場合、前記通知メッセージを再送信するステップと
を含むことを特徴とする方法。
【請求項２】
前記通知メッセージは、業務アプリケーションによって反対側に送信され、前記通知メッセージの送信の失敗には、返信メッセージが前記反対側から受信されないこと、またはトランザクション成功のメッセージが前記反対側から受信されないことを含むことを特徴とする、請求項１に記載のシステム間メッセージ通知の方法。
【請求項３】
前記保管された通知メッセージを送信するステップの前に、
前記通知メッセージに関連する業務トランザクションが完了しているかどうかを判断するステップと、
前記業務トランザクションが完了している場合、前記通知メッセージの送信をトリガするか、または前記業務トランザクションが完了するのを待って前記通知メッセージの送信をトリガするステップと
をさらに含むことを特徴とする、請求項２に記載のシステム間メッセージ通知の方法。
【請求項４】
前記業務トランザクションは、ユーザによってオンラインバンクを介して行われた支払いであり、前記通知メッセージは、前記ユーザの支払い結果を含み、前記反対側の前記業務トランザクションの完了は、販売業者の配信情報を含むメッセージによって示されることを特徴とする、請求項３に記載のシステム間メッセージ通知の方法。
【請求項５】
前記保管された通知メッセージを送信するステップは、
前記通知メッセージのトランザクションの種類に従って、前記反対側のアドレスおよび伝送プロトコルを判断するステップと、
前記伝送プロトコルを使用して、前記アドレスに前記通知メッセージを送信するステップと
を含むことを特徴とする、請求項２から４のいずれかに記載のシステム間メッセージ通知の方法。
【請求項６】
前記通知メッセージを再送信するステップの前に、
前記通知メッセージを再送信する時刻間隔を決定し、前記時刻間隔に従って再試行時刻を計算するステップであって、前記通知メッセージを再送信するステップは、前記再試行時刻に到達すると実行されるステップを、さらに含むことを特徴とする、請求項１から４のいずれかに記載のシステム間メッセージ通知の方法。
【請求項７】
前記通知メッセージを再送信するステップは、
再試行の期限になっている通知メッセージを定期的に特定するステップと、
前記特定された通知メッセージを再送信するステップと
を含むことを特徴とする、請求項６に記載のシステム間メッセージ通知の方法。
【請求項８】
前記再試行時刻の間隔は、実行される再試行回数が増加するにつれて増加することを特徴とする、請求項６に記載のシステム間メッセージ通知の方法。
【請求項９】
前記通知メッセージが正常に送信された場合、前記保管された通知メッセージを削除するステップをさらに含むことを特徴とする、請求項１から４のいずれかに記載のシステム間メッセージ通知の方法。
【請求項１０】
システム間メッセージ通知のシステムであって、
通知メッセージを保管するために使用される、データベースと、
前記通知メッセージを前記データベースに保管し、前記通知メッセージの送信をトリガするために使用される、通知クライアントと、
前記通知メッセージを送信するため、および前記通知メッセージの送信が失敗した場合に前記通知メッセージを再送信するために使用される、通知サーバと
を備えることを特徴とするシステム。
【請求項１１】
前記通知メッセージは、業務アプリケーションによって反対側に知らせるために使用され、前記業務アプリケーションから前記通知クライアントに送信され、前記通知メッセージの送信の失敗には、返信メッセージが前記反対側から受信されないこと、またはトランザクション成功のメッセージが前記反対側から受信されないことを含む、請求項１０に記載のシステム間メッセージ通知のシステム。
【請求項１２】
前記システムは、前記通知メッセージに関連する業務トランザクションが完了した後に前記通知メッセージの送信をトリガするために使用されるトランザクションシンクロナイザを、前記通知クライアント内にさらに含むことを特徴とする、請求項１１に記載のシステム間メッセージ通知のシステム。
【請求項１３】
前記通知サーバは、
前記通知メッセージを送信して、前記メッセージ通知の送信に失敗した場合は前記データベース内の前記通知メッセージの再試行時刻を設定するために使用される、通知実行ユニットと、
再試行時刻の期限となっている通知メッセージを特定し、前記通知実行ユニットが前記特定された通知メッセージを再送信するようにトリガするために使用される、通知リカバリーユニットと
をさらに備えることを特徴とする、請求項１０から１２のいずれかに記載のシステム間メッセージ通知のシステム。
【請求項１４】
前記通知リカバリーユニットは、設定された時刻に起動することを特徴とする、請求項１３に記載のシステム間メッセージ通知のシステム。
【請求項１５】
前記システムは、メッセージキューも含み、前記メッセージキューにより、前記通知クライアントは、前記特定された通知メッセージを即座に再送信するように前記通知実行ユニットをトリガすることを特徴とする、請求項１３に記載のシステム間メッセージ通知のシステム。
【請求項１６】
前記システムは、
トランザクションの種類の前記反対側のアドレスおよびプロトコルを前記通知実行ユニットに提供するため、および前記反対側から受信されるメッセージに基づいて、業務トランザクションが正常に行われているかどうかを判断するために使用され、且つ前記トランザクションの種類に対応する、少なくとも１つの業務トランザクションプラグイン
をさらに備えることを特徴とする、請求項１３に記載のシステム間メッセージ通知のシステム。
【請求項１７】
前記通知サーバは、
伝送プロトコルを使用して前記通知サーバから前記通知メッセージを伝送するために使用され、且つ前記伝送プロトコルに対応する、少なくとも１つのプロトコルアダプタ
をさらに備えることを特徴とする、請求項１３に記載のシステム間メッセージ通知のシステム。
【請求項１８】
前記再試行時刻は、実行される前記再試行回数が増加するにつれて増加する再試行間隔を有することを特徴とする、請求項１３に記載のシステム間メッセージ通知のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ伝送の分野、特に、信頼性のあるシステム間メッセージ通知のための方法およびシステムに関する。
【背景技術】
【０００２】
本出願は、２００６年３月２７日に出願された、中国特許出願第２００６１００６７４５６．５号、名称「ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＲＥＬＩＡＢＬＥ  ＩＮＴＥＲＳＹＳＴＥＭ  ＭＥＳＳＡＧＥ  ＮＯＴＩＦＩＣＡＴＩＯＮ」の優先権を主張し、該中国特許出願の全体を参照として組み込む。
【０００３】
インターネット技術の急速な発達に伴い、それらの対話形式としてメッセージ通知を使用するインターネットアプリケーションシステムの数が増加している。現在のメッセージ通知の典型的なアプリケーションの１つは、オンラインバンクと販売業者との間のメッセージ通知である。あるアプリケーションのシナリオでは、ユーザが販売業者のウェブサイトからオンラインバンクに取引オーダーを提出し、ユーザが実際の支払いを完了した後、オンラインバンクは、メッセージ通知の形式で、販売業者に正常に行われた支払いの結果を知らせる。販売業者は、次いで、ユーザに商品を配達する等の残りの処理を完了する。支払い結果のメッセージ通知が確実に販売業者に届くかどうかが、ユーザの取引の流れに直接影響する。従って、このメッセージ通知の到着の信頼性は、非常に重要である。
【０００４】
しかしながら、インターネットには、信頼性がない。ネットワーク接続性および時間遅延が予測不可能であることから、信頼性がないことが明白である。この信頼性の欠如は、インターネットを介して接続されているハードウェアおよびソフトウェアの可用性からも明白である。従って、インターネットベースのメッセージ通知には、一定の損失率が存在する。しかしながら、電子商取引は、非常に信頼性のあるメッセージフローを必要とする。重要なメッセージ通知の紛失は、業務活動の円滑なプロセスを妨害するだけでなく、業務活動の関係者に金銭上の損失までもたらし得る。現在の状況の実際的見地から、依然として銀行と販売業者のシステム間のメッセージ通知には、信頼性のある配信が存在しない。ｉＲｅｓｅａｒｃｈが２００５年に行った統計資料によると、中国の第三者の支払いプラットフォームの大半において、メッセージ損失率がかなり高い。具体的には、オンラインバンクを介して正常に行われたユーザの支払い結果の多くが、適時に第三者の支払いプラットフォームに通知されず、その中でも、オンライン支払いプラットフォームのオーダー損失率は、２０％と高い。
【０００５】
ＷＳ−Ｒｅｌｉａｂｌｅ  Ｍｅｓｓａｇｉｎｇ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｒｅｌｉａｂｌｅ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）およびＷＳ−Ｒｅｌｉａｂｉｌｉｔｙ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｒｅｌｉａｂｉｌｉｔｙ）は、ウェブサービス用の信頼性のあるメッセージングプロトコルの２つである。ＷＳ−Ｒｅｌｉａｂｌｅ  Ｍｅｓｓａｇｉｎｇは、分散システムで信頼性のあるメッセージ伝送を実行するためにＩＢＭ社、ＢＥＡ社、Ｍｉｃｒｏｓｏｆｔ社、およびＴＩＢＣＯ社等の企業によって提案されたプロトコルである。一方、ＷＳ−Ｒｅｌｉａｂｉｌｉｔｙは、ＯＡＳＩＳのＷｅｂ−Ｓｅｒｖｉｃｅ  Ｒｅｌｉａｂｌｅ  Ｍｅｓｓａｇｉｎｇ  （ＷＳＲＭ）  Ｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｔｔｅｅによって提案された。ＷＳ−Ｒｅｌｉａｂｉｌｉｔｙは、確実に配信され、複製されないことが保証されるものにＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）のメッセージを交換するためのＳＯＡＰベースのプロトコルである。本質的に、これら２つのプロトコルは両方とも、信頼性のあるメッセージ伝送を達成するために、メッセージオーダリングに基づき、メッセージの認証にＳｌｉｄｉｎｇ  Ｗｉｎｄｏｗ  Ｐｒｏｔｏｃｏｌを採用する。
【０００６】
ＨＴＴＰＬＲプロトコルは、メッセージの伝送が保証されたメッセージ伝送サービスおよびメッセージの単一伝送をＨＴＴＰプロトコルに提供するために、２００５年にアイルランドのＰｒｏｐｙｌｏｎ社によって提案された、ＨＴＴＰプロトコルに構築されたアプリケーションプロトコルである。ＨＴＴＰＬＲは、メッセージの上方への流れ（クライアントからサーバへ）およびメッセージの下方への流れ（サーバからクライアントへ）に信頼性のあるメッセージ伝送機構を提供する。しかしながら、この機構は、メッセージ送信側およびメッセージ受信側の可用性、コンポーネントのロバスト性、メッセージの永続的保管、およびメッセージの再試行ならびにタイムアウトを対象としない。該機構は、メッセージを交換する両者が、メッセージが正常に配信されたかどうかに対する一致した理解をどのように達成するかということのみを対象とする。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
実際面では、ＷＳ−Ｒｅｌｉａｂｌｅ  Ｍｅｓｓａｇｉｎｇ、ＷＳ−Ｒｅｌｉａｂｌｉｔｉｌｙ、およびＨＴＴＰＬＲプロトコルのいずれもインターネット上で普及していない。主な理由は以下のとおりである。第１に、これらのプロトコルは、依然として未完成であり、設計段階のものさえある。第２に、信頼性のあるメッセージ伝送機構は理論的には説明されるが、これらのプロトコルは、実際面でどのようにこれらの機構を達成するかを説明しない。第３に、これらのプロトコルは、アプリケーション環境を制限している。例えば、ＨＴＴＰＬＲは、ＨＴＴＰプロトコルの上で使用されるが、ＷＳ−Ｒｅｌｉａｂｌｅ  ＭｅｓｓａｇｉｎｇおよびＷＳ−Ｒｅｌｉａｂｉｌｉｔｙプロトコルは、ウェブサービスに使用される。第４に、これらのプロトコルは、クライアントおよびサーバに、比較的複雑な実装を要求する。例えば、両通信側のシステムは、同一の信頼性のあるメッセージ伝送機構をサポートする必要がある。現在のインターネット環境では、メッセージ交換する両者に同一の複雑なプロトコルを有するように要求することは、通常、非常に困難である。
【課題を解決するための手段】
【０００８】
本発明は、あらゆる協働システム間に適した信頼性のあるシステム間メッセージ通知の方法およびシステムを提供する。該方法およびシステムは、反対側がいずれかの信頼性のあるメッセージング伝送プロトコルをサポートしていない場合、ネットワーク、サーバ、およびソフトウェアシステムの不安定な性質による、リカバリー不可能なメッセージ損失の問題解決に特に有用である。
【０００９】
本発明は、信頼性のあるシステム間メッセージ通知の方法を提供する。該方法は、以下のステップ、
通知メッセージを保管するステップと、
該保管された通知メッセージを送信するステップと、
該通知メッセージの送信に失敗した場合、該通知メッセージを再送信するステップと、を含む。
【００１０】
好ましくは、通知メッセージは、業務アプリケーションで反対側に送信する必要のあるメッセージである。通知メッセージの送信の失敗には、返信メッセージが反対側から受信されない、または反対側から業務トランザクション成功のメッセージが受信されない等の状態を含む。
【００１１】
好ましくは、該方法は、保管された通知メッセージを送信する前に、通知メッセージに関連する業務トランザクションが完了しているかどうかを判断するステップと、業務トランザクションが完了している場合、該通知メッセージの送信をトリガする、または該業務トランザクションが完了するのを待って該通知メッセージの送信をトリガするステップと、をさらに含む。
【００１２】
好ましくは、該業務トランザクションは、オンラインバンクを介してユーザが行う支払いである。通知メッセージは、ユーザの支払い結果である。反対側での業務トランザクションの正常な完了は、販売業者の配信情報を含むメッセージによって示される。
【００１３】
好ましくは、該保管された通知メッセージを送信するステップは、通知メッセージのトランザクションの種類に従って、反対側のアドレスおよび伝送プロトコルを判断するステップと、該伝送プロトコルを使用して、該アドレスに該通知メッセージを送信するステップと、を含む。
【００１４】
好ましくは、該方法は、通知メッセージを再送信する前に、通知メッセージを再送信する時刻間隔を決定し、該時刻間隔に従って、再試行時刻を計算するステップも含む。通知メッセージの再送信は、再試行時刻に到達した際に実行される。
【００１５】
好ましくは、該通知メッセージを再送信するステップは、設定時刻で、再試行の期限となっている通知メッセージを特定するステップと、特定された通知メッセージを再送信するステップと、を含む。
【００１６】
好ましくは、再試行時刻間隔は、再送信の回数が増加するとともに増加する。
【００１７】
好ましくは、該方法は、対応するメッセージ通知が成功した場合、保管された通知メッセージを削除するステップも含む。
【００１８】
また本発明は、システム間メッセージ通知のシステムも提供する。該システムは、通知メッセージを保管するために使用されるデータベースと、該通知メッセージをデータベースに保存し、該通知メッセージの送信をトリガするために使用される通知クライアントと、該通知メッセージの送信のため、および該通知メッセージの配信に失敗した場合に該通知メッセージを再送信するために使用される通知サーバと、を備える。
【００１９】
好ましくは、該通知メッセージは、業務アプリケーションで反対側に知らせる必要がある、業務アプリケーションから通知クライアントに送信されるメッセージである。通知メッセージの送信の失敗には、返信メッセージが反対側から受信されない状態、または反対側から業務トランザクション成功を示すメッセージが受信されない状態を含む。
【００２０】
好ましくは、該システムは、通知クライアント内にトランザクションシンクロナイザをさらに備え、該トランザクションシンクロナイザは、通知メッセージに関連する業務トランザクションが完了した後、通知メッセージの送信をトリガするために使用される。
【００２１】
好ましくは、該通知サーバは、通知メッセージを送信するため、および通知メッセージの送信が失敗した場合にデータベース内の通知メッセージの再試行時刻を設定するために使用される通知実行ユニットと、再試行時刻の期限となっているいずれかの通知メッセージを特定するため、および特定された通知メッセージを再送信するように通知実行ユニットをトリガするために使用される通知リカバリーユニットと、を備える。
【００２２】
好ましくは、該通知リカバリーユニットは、設定された時刻に起動する。
【００２３】
好ましくは、該システムは、メッセージキューも含む。メッセージキューにより、通知クライアントは、通知メッセージを即座に再送信するように通知実行ユニットをトリガする。
【００２４】
好ましくは、該システムは、それぞれのトランザクションの種類に対応する少なくとも１つの業務トランザクションプラグインも備える。業務トランザクションプラグインは、対応するトランザクションの種類の反対側のアドレスおよびプロトコルを通知実行ユニットに提供するために使用される。また業務トランザクションプラグインは、反対側から受信したメッセージに基づいて、業務トランザクションが正常に行われたかどうかを判断する。
【００２５】
好ましくは、該通知サーバは、それぞれの伝送プロトコルに対応する少なくとも１つのプロトコルアダプタも備える。プロトコルアダプタは、対応する伝送プロトコルを使用して通知サーバから通知メッセージを伝送するために、使用される。
【００２６】
好ましくは、再試行間の時刻間隔は、再試行回数が増加するとともに増加する。
【００２７】
本発明は、あらゆる協働システム間に有用である。通知メッセージを保管すること、および通知が失敗した場合は通知メッセージを反対側に再送信することによって、本発明は、特定の信頼性のあるメッセージング伝送プロトコルに依存することから、反対側からのメッセージ通知を解放する。代わりに、通知メッセージを確実に受信するために、反対側は、業務トランザクション要件に従い、メッセージの処理結果を返すだけでよい。メッセージが正常に送信されるまで、通知メッセージは永続的に保管されるため、本発明は、反対側のネットワークならびにハードウェアまたはソフトウェアの障害による通知メッセージの損失を防ぐことができ、従って、通知メッセージの信頼性のある配信を保証することができる。
【００２８】
さらに、本発明は、業務トランザクションの完了後、通知メッセージを送信するプロセスをトリガし、反対側の業務トランザクションの結果に基づいて通知メッセージの再送信が必要かどうかを判断する。これは、伝送層またはそれ以下の層で障害が生じた際に、信頼性のあるメッセージ通知を提供するだけでなく、アプリケーション層の業務トランザクション処理にエラーが生じた際にも、信頼性のあるメッセージ通知を提供する。従って、業務トランザクション処理とメッセージ通知との間の一貫性が達成される。
【００２９】
さらに、インターネット上で短期間および中期間の通信障害を対象に、本発明の方法およびシステムは、タイムアウトおよびメッセージの再送信を処理する、実用的かつ効率的な方法を提供する。再試行回数が増加するとともに、再試行の間の時刻間隔が増加する。再試行の時刻間隔の変更は、通知リカバリーの適時性と効率性とのバランスが取れた考慮を同時に提供する。短期間の通信障害に対して、本発明は、障害が修正された後、メッセージ通知を反対側に適時に送信することができ、一方、中期間の障害では、多くの不必要な再試行を行うコストを回避できる可能性がある。
【００３０】
さらに、プロトコルアダプタを拡張することによって、本発明は、インターネットの広範なニーズを満足するために、異なるメッセージング伝送プロトコルで使用することができる。
【００３１】
さらに本発明の方法およびシステムは、新規事業の柔軟な開発を可能にするために、業務トランザクションプラグインの拡張により、異なる業務アプリケーションの動作をサポートするユニバーサルプラットフォームとして使用することができる。
【発明を実施するための最良の形態】
【００３２】
本発明は、図面および例示的な実施形態を使用して、さらに詳細に説明される。
【００３３】
インターネットに基づく電子商取引は、今日の社会で、より重要な位置を占め、より多くの企業体がインターネットを介した情報フロー、資金フロー、および物流を組織するようになってきている。メッセージ通知を対話形式として使用するインターネットアプリケーションシステムの数が、増加している。一例は、バンキングである。ユーザが銀行での支払いを完了した後、銀行は、販売業者のシステムに、ユーザの支払い状況について通知メッセージを使用して知らせる必要がある。別の例は、第三者のセキュアなトランザクションプラットフォームである。ユーザがトランザクションプラットフォーム上で業務トランザクションを進行した後、トランザクションプラットフォームは、関係する外部の販売業者のシステムに、業務トランザクションの現在の状態を知らせる必要がある。これらは、インターネットベースのメッセージ通知の典型的な実施例である。本発明は、あらゆる協働システム間、特に流行のインターネットでの使用に適している。
【００３４】
図１は、本発明による、信頼性のあるシステム間メッセージ通知のための装置およびシステムの概略図を示す。業務アプリケーション１１は、任意の販売業者アプリケーションとすることができる、メッセージ通知プロセスの開始プログラムである。外部システム１７は、任意の販売業者のシステムとすることができ、通知メッセージの受信者の役割を果たす。本発明における通知システムを、業務アプリケーション１１から受信した通知メッセージを配信するため、およびインターネットを介した外部システム１７への通知メッセージの信頼性のある配信を保証するために使用される。通知システムは、以下のものを含んでもよい。
【００３５】
送信される通知メッセージを保管するために使用される、データベース１３。送信される通知メッセージは、まだ送信されていない新しい通知メッセージ、および再送信待ちの通知メッセージを含む。
【００３６】
通知メッセージをデータベースに保存し、メッセージキュー１４により、通知メッセージの即時配信をトリガするために使用される、通知クライアント１２。
【００３７】
新しい通知メッセージまたは再送信が必要な通知メッセージを送信するために使用される、通知実行ユニット１５２。通知メッセージの配信が正常に行われた場合、通知実行ユニット１５２は、この通知メッセージをデータベース１３から削除する。あるいは、通知実行ユニット１５２は、通知メッセージの再試行時刻を設定し、データベース１３内の通知メッセージの対応するパラメータを更新する（例えば、データベース１３内の通知メッセージの再試行時刻を更新する）。
【００３８】
再送信待ちのいずれかの通知メッセージの再試行時刻になっているかどうかを確認するために使用される、通知リカバリーユニット１５１。いずれかの通知メッセージの再試行時刻になっている場合、通知リカバリーユニット１５１は、通知実行ユニット１５２に通知する。
【００３９】
図示されるように、データベース１３は、任意の一般的に使用される関係データベースとすることができ、配信待ちの新しい通知メッセージ、および以前に配信に失敗して現在再送信待ちの通知メッセージを保管するために使用される。通知クライアント１２は、業務アプリケーション１１によって使用されるクライアントモジュールとすることができ、業務アプリケーションシステムに組み込まれてもよい。業務アプリケーション１１は、通知クライアント１２を使用して、通知メッセージを登録することができる。通知メッセージの登録が正常に行われると、通知システムは、メッセージの受信者がオフラインであるか、またはネットワークが一時的に切断されている場合であっても、通知メッセージがメッセージの受信者に確実に配信されるようにすることができる。通知メッセージの登録プロセスは、業務アプリケーション１１から受信される通知メッセージをデータベース１３に保管する、通知クライアント１２を有し、メッセージキュー１４によって、通知メッセージの即時配信をトリガすることができる。業務アプリケーションシステムは、業務アプリケーション１１に関連して、関連トランザクションを処理するシステムを指す。一実施例として、オンラインバンクと販売業者との間のメッセージ通知を用いて図示される、通知メッセージに関連する業務トランザクションは、ユーザがオンラインバンクで実際の支払いを行うことを指す。支払いが完了した場合、業務トランザクションは、完了として提出される。あるいは、業務トランザクションは、依然として進行中である。通知メッセージは、支払いが完了したかどうかを示す、ユーザの支払い結果を指す。トランザクションは、専門用語であり、ＡＣＩＤ特性を有する操作の一群を示す。トランザクションを生成する際、トランザクションがいくつかの自己管理特性を確実に有するようにすることが望ましい。これらの特性は、ＡＣＩＤと呼ばれる。ＡＣＩＤは、原子性（Ａｔｏｍｉｃｉｔｙ）、一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）、独立性（Ｉｓｏｌａｔｉｏｎ）、および耐久性（Ｄｕｒａｂｉｌｉｔｙ）を意味する。トランザクションのＡＣＩＤ特性は、メッセージ通知と業務作業との間の１００％の一貫性を達成するための重要な要素である。
【００４０】
通知クライアント１２を業務アプリケーションシステムに組み込むことにより、業務トランザクション処理を完了すること、および通知メッセージを同一データベースのトランザクションに登録することができ、従って、業務トランザクション処理とメッセージ通知との間の不一致を完全に回避することができる。ここで、一貫性は、通知メッセージを正常に登録し、対応する業務トランザクションの完了後のみ、即時に送信することができることを意味する。データベーストランザクションで使用されるデータベースは、通知メッセージを保管する、システムのデータベースとすることができる。通常、このデータベースは、業務トランザクションデータを保管するための業務アプリケーションシステム内の同一データベースである。同一データベースを使用することによって、複雑で低効率な分散トランザクション機構を使用することなく、同一データベーストランザクション内で、通知メッセージの登録および業務トランザクションデータの処理を実行することが可能となる。しかしながら、通知メッセージの登録と業務トランザクションデータの処理との間の一貫性は、異なるデータベースを使用する分散トランザクション機構により、維持することができる。
【００４１】
メッセージキュー１４は、システム間の非同期情報通信のための標準ミドルウェアである。メッセージキュー１４を使用することによって、メッセージの送信および受信プロセスを非同期にすることができ、一方、メッセージの送信者および受信者は、メッセージキュー１４によって間接的に通信することができる。これは、メッセージの送信者と受信者との間の相互依存を最小化し、従って、両者が比較的独立して、それぞれのタスクを実行できるようにする。一般にメッセージキューは、メッセージを受信すると、メッセージの受信者が通常の動作状態である限り、即時にメッセージを受信者に送信する。例示的な本実施形態では、メッセージキュー１４を使用して、通知メッセージの即時配信をトリガする。
【００４２】
通知サーバ１５は、通知メッセージの送信および再送信に関与する、サーバまたは別個のサーバのグループとすることができる。通知サーバ１５は、通知リカバリーユニット１５１、通知実行ユニット１５２、および様々なプロトコルアダプタ１５３を含んでもよい。通知リカバリーユニット１５１は、配信に失敗した通知メッセージを設定時刻に再送信するためのスケジューリングに関与するモジュールである。通知実行ユニット１５２は、通知メッセージの実際の配信を実行するモジュールである。様々なプロトコルアダプタ１５３の各プロトコルアダプタは、伝送プロトコルをサポートし、インターネットを介した外部システム１７への実際のデータ伝送を完了する。業務トランザクションプラグインライブラリ１６は、異なる業務トランザクションプラグイン１６１を含む。業務トランザクションプラグイン１６１は、異なるトランザクションの種類に対応し、通知メッセージの配信前の前処理、および返信結果メッセージの処理に関与する。前処理および返信処理は、業務アプリケーションと密接に関係する。異なる業務アプリケーションは、異なる処理プロセスを有するであろう。
【００４３】
図２は、本発明による、信頼性のあるシステム間メッセージ通知方法のフローチャートを示す。業務アプリケーションが通知メッセージを外部システムに送信する必要がある場合、通知メッセージの信頼性のある配信は、以下のステップを実行することによって達成することができる。
【００４４】
ステップＳ１で、業務アプリケーションは、その通知ニーズをメッセージ通知要求にパッケージし、本要求を通知システムの通知クライアントに送信する。
【００４５】
ステップＳ２で、通知クライアントは、通知メッセージを登録する。通知メッセージの登録が行われると、業務アプリケーションは、その他のトランザクションの実行を継続することができる。通知システムは、メッセージの受信者がオフラインであるか、またはその時点で一時的に切断されていたとしても、通知メッセージを受信者に確実に配信する。
【００４６】
ステップＳ３で、通知メッセージが正常に登録された後、通知システムは、通知メッセーを送信する。反対側に正常に通知された場合、メッセージ通知のタスクが完了される。そうでない場合、該プロセスは、ステップＳ４に続く。本発明では、正常なメッセージ通知には、反対側へのメッセージの正常な配信、および反対側から業務トランザクション成功のメッセージを受信することを含む。
【００４７】
ステップＳ４は、メッセージ配信のリカバリーを実行し、正常に配信されなかった通知メッセージを適時に再送信するためのスケジュールを組む。該プロセスは、次いでステップＳ３に戻る。
【００４８】
本プロセスでは、ステップＳ４は、ステップＳ１、Ｓ２、またはＳ３と同時に実行することができる。以下で、ステップＳ２、Ｓ３、およびＳ４は、それぞれさらに詳細に記載される。
【００４９】
図３は、開示されるメッセージ通知方法における、登録プロセスのフローチャートを示す。登録は、以下のステップを含む。
【００５０】
ステップＡ１で、通知クライアントは、メッセージ通知要求を業務アプリケーションから受信する。メッセージ通知要求は、通知メッセージのコンテンツを含んでもよい。
【００５１】
ステップＡ２で、通知クライアントは、関連する通知メッセージが正常に送信されるまで、メッセージ通知要求をデータベースに保管する。これによって、ネットワーク、サーバ、またはソフトウェアシステムの不安定な性質による、リカバリー不可能な通知メッセージの損失を回避することができる。
【００５２】
ステップＡ３で、通知クライアントは、通知メッセージに関連する業務トランザクションが完了しているかどうかを判断する。業務トランザクションが依然として進行中の場合、該プロセスは、ステップＡ４、Ａ５、およびＡ６に続く。業務トランザクションを完了すると、通知クライアントは、自動的にメッセージキューをトリガし、該プロセスは、直接ステップＡ６に進む。オンラインバンクと販売業者との間のメッセージ通知を例に取ると、通知メッセージに関連する業務トランザクションは、ユーザがオンラインバンクを使用して行う支払いとすることができる。支払いが正常に行われた場合、業務トランザクションは完了する。そうでない場合は、業務トランザクションは、依然として進行中である。通知メッセージは、支払いが完了しているかどうかを示す、ユーザの支払い結果を含むことができる。本例示的な実施形態では、通知クライアントが業務アプリケーションシステムに組み込まれているため、メッセージ通知要求を業務トランザクション内のデータベースに登録することができる。これにより、複雑な機構を使用することなく、業務トランザクション処理と通知要求の登録との間の一貫性を達成することができる。
【００５３】
ステップＡ４で、通知クライアントは、トランザクションシンクロナイザをトランザクション管理ユニットに登録する。トランザクション管理ユニットは、トランザクションを管理するためのソフトウェアを指し、トランザクションシンクロナイザを含んでもよい。登録されたトランザクションシンクロナイザは、通知クライアント内に設置され、関連するトランザクションが提出された後、メッセージキューを介して通知メッセージの即時配信要求を通知サーバに送信するために使用される。これによって、通知の適時性を保証することができる。
【００５４】
ステップＡ５で、トランザクションが完了した後、トランザクションシンクロナイザは、メッセージキューを自動的にトリガする。
【００５５】
ステップＡ６で、メッセージキューは、通知メッセージの即時配信要求を通知実行ユニットに送信し、通知サーバの配信の実行を促し、従って、通知の即時性を保証する。
【００５６】
図４は、通知メッセージ配信プロセスのフローチャートを示す。該配信プロセスは、以下のステップを含む。
【００５７】
ステップＢ１で、通知実行ユニットは、通知クライアントからメッセージキューを介して送信された新しいメッセージ通知要求、または通知リカバリーユニットから送信されたメッセージ通知再試行要求を受信する。メッセージキューからの新しいメッセージ通知要求と、通知リカバリーユニットからのメッセージ通知再試行要求とが、同時に受信される場合、通知実行ユニットは、好ましくは、マルチスレッド処理を実行し、新しい通知メッセージと再試行通知メッセージの両方を同時に送信する。代替的には、通知実行ユニットは、該通知メッセージを、優先順位に基づいて別々に送信することができる。
【００５８】
ステップＢ２で、通知実行ユニットは、メッセージ通知要求の種類に従って、業務トランザクションプラグインライブラリから業務トランザクションプラグインを選択し、前処理のために、メッセージ通知要求を業務トランザクションプラグインに送信して、外部システムの実際の通知アドレス、通知プロトコル、および通知パラメータを取得する。
【００５９】
ステップＢ３で、通知実行ユニットは、適切なプロトコルアダプタを通知プロトコルに基づいて選択し、実際のメッセージ配信のために、通知メッセージのコンテンツである通知アドレスおよび通知パラメータを、プロトコルアダプタに提供する。
【００６０】
ステップＢ４で、両者のネットワーク、サーバ、およびシステムが通常動作状態の場合、メッセージは、インターネットを介して外部システムに送信される。メッセージが受信および処理されると、外部システムは、処理結果を返す。そうでない場合は、通知実行ユニットは、通知メッセージが外部システムに到達しなかったことを自動的に検出し、該プロセスは、ステップＢ８およびＢ９に進む。
【００６１】
ステップＢ５で、通知実行ユニットは、返信結果を業務トランザクションプラグインに送信し、業務トランザクションプラグインに、対応する業務トランザクション処理を完了させる。上記の実施例では、業務トランザクションプラグインは、外部システムの返信結果を受信すると、取引状況を「出荷済み品」に更新し、納品書の詳細を記録し、ユーザに出荷状況について通知する必要がある場合がある。通知サーバは、共用するために共有され、業務トランザクションのいずれかの特定の種類に関係しないため、上記の処理は、適切な業務トランザクションプラグインによって実行される。
【００６２】
ステップＢ６で、業務トランザクションプラグインは、メッセージ配信の再試行が必要かどうかを判断する。業務トランザクションプラグインは、返信結果があるかどうか、ならびに返信結果のフォーマットおよびコンテンツが有効であるかどうかに基づいて、判断する。説明のために上記の実施例をさらに使用すると、返信結果が、有効な販売業者の出荷情報を有する場合、業務トランザクションプラグインは、メッセージ通知が正常に行われたと見なす。返信結果が受信されないか、または返信結果が無効なフォーマットである場合、あるいは、販売業者が、一時的に処理が不可能であり再試行に一定の期間が必要であることを、返信結果において明示的に示す場合、業務トランザクションプラグインは、このメッセージ通知が正常に行われておらず、再試行が必要であると見なす。
【００６３】
メッセージ通知の失敗は、ネットワークまたはシステムの障害だけに起因するとは限らず、業務トランザクション自体が正常に行われるかどうかにも依存することから、判断責任は、業務トランザクションプラグインが担う。これは、汎用の通知サーバが、ネットワークおよびシステムに障害があるかどうかを判断することしかできず、業務トランザクション自体が正常に行われたかどうかを判断できないためである。そうは言うものの、通知サーバは、ネットワークおよびシステムの明らかな障害を判断することができるため、該状況下で、通知サーバは、再試行が必要であるかどうかを直接判断してもよい。
【００６４】
ステップＢ７で、業務トランザクションプラグインが再試行は必要ないと判断する場合、通知サーバは、対応するメッセージ通知要求をデータベースから削除し、通知メッセージの配信を正常に完了する。
【００６５】
ステップＢ８で、通知メッセージが、ネットワークの問題等の様々な理由により外部システムに到達できない場合、または業務トランザクションプラグインが、メッセージの再試行が必要であることを示す場合、通知サーバは、再試行戦略に従って次の再試行の時刻間隔を計算し、現在の時刻に、計算された時刻間隔を加算して、次の再試行の時刻を設定する。
【００６６】
ステップＢ９で、通知サーバは、再送信待ちの通知メッセージに対して、計算された再試行時刻に従ってデータベース内の対応するメッセージ通知要求の送信時刻を更新し、通知リカバリーユニットが再スケジュールするのを待つ。
【００６７】
業務トランザクションプラグインを拡張することによって、通知メッセージを送信する上記のプロセスは、同一のメッセージ通知システムを使用する、様々な種類のトランザクション通知に対するサポートを提供することができる。プロトコルプロセッサ／アダプタを拡張することによって、同一のメッセージ通知システム内の異なるプロトコルの通知に関するサポートを、提供することができる。さらに、通知メッセージの受信者は、いかなる特別なセキュアなメッセージング伝送プロトコルも実装する必要がなく、メッセージ通知の送信者から確実にメッセージを受信するために、業務トランザクション要件に従ってメッセージ処理結果を返すだけでよい。
【００６８】
図５は、メッセージ通知をリカバリーするフローチャートを示す。通知メッセージを再送信する必要がある場合、通知プロセスは、通知リカバリーに入る。好ましくは、通知リカバリーユニットは、設定された時刻に起動する。起動毎に、以下のステップが実行される。
【００６９】
ステップＣ１で、通知リカバリーユニットは、設定時刻に到達するのを待ち、時刻に到達した際に、動作を開始する。
【００７０】
ステップＣ２で、通知リカバリーユニットは、データベース内の再試行時刻の期限であるメッセージ通知要求を探す。通知リカバリーユニットは、再試行が必要なメッセージ通知要求を確認し、ステップＢ８で計算された再試行時刻を、現在の起動の設定時刻と比較する。いずれかの再試行時刻が設定時刻と同等以下の場合、再試行時刻の期限であるメッセージ要求が存在し、通知プロセスはステップＣ３に続く。そうでない場合は、再試行の現在の起動が中止され、プロセスはステップＣ４に進む。
【００７１】
ステップＣ３で、通知リカバリーユニットは、再試行時刻の期限である通知メッセージに対して、再試行要求を通知実行ユニットに送信して、配信のために通知メッセージを１つずつ通知実行ユニットに提供する。
【００７２】
ステップＣ４で、通知リカバリーユニットは、次の起動のために、次の設定時刻まで待機する。
【００７３】
通常、通知リカバリープロセスを起動する設定時刻の間隔は、例えば、１分間に１回などと固定される。設定時刻の間の間隔のサイズは、通知リカバリーの適時性に影響する。従って、時刻間隔を可能な限り小さく設定することが望ましいが、通知サーバの許容範囲内でなければいけない。設定される時刻間隔は、メッセージ通知の再試行間隔と同一ではないことに留意されたい。メッセージ通知の再試行時刻の間隔は、再試行間隔の決定方法により、各通知メッセージに対して個別に計算され、設定される。
【００７４】
通知メッセージを送信するプロセスのステップＢ８で、上述の再試行戦略は、一般的に使用される固定の再試行時刻間隔を導入することができる。しかしながら、本発明は、好ましくは、再試行時刻間隔を決定するために、以下に記載される再試行間隔決定方法を導入する。再試行間隔決定方法は、インターネットを介したメッセージ通知が失敗する典型的な原因に合わせることによって、メッセージの受信者に通知メッセージを配信する際の適時性を最大化する一方、再試行回数を最小化するように設計される。
【００７５】
インターネットを介したシステム間メッセージ通知における失敗には、以下のようにいくつか考えられる原因がある。すなわち、ネットワークが一時的に混み合い、伝送プロトコルのオーバータイムの原因となっていること、ネットワークが一時的に切断されていること、反対側のサーバが一時的に混み合い、要求に応答できないこと、反対側に不具合があり、従って要求に応答できないか、または要求を不正確に処理すること、反対側のサーバがハングアップしているため、要求に応答できない、ネットワークの長期間の障害が、数時間またはさらには数日間に渡る侵害を引き起こしていること、反対側の長期間障害が、数時間またはさらには数日間に渡って利用できない原因となっていること、ならびに、反対側が存在しないか、または恒久的にシャットダウンされていること、がある。
【００７６】
上記に記載の理由から、メッセージ通知の失敗の原因は、数分以内に消滅するか、取り除かれる可能性があるが、数時間およびさらには数日間持続する場合もある。従って、メッセージ通知の好ましい再試行戦略は、次のことを達成することを目標とするべきである。原因が数分以内に消滅するか取り除かれる場合は、メッセージ通知を適時に相手に送信すること、原因が消滅するまでに数時間またはさらには数日間必要な場合は、システムは、過度に多くの不必要な再試行を行わずに、依然としてメッセージ通知を相手方に送信できること、を達成することを目標とするべきである。従って、本発明は、再試行時刻間隔を決定するために、好ましくは、以下の再試行間隔決定方法を導入する。
【００７７】
図６は、通知メッセージを送信する再試行間隔を決定する方法の概念図を示す。再試行間隔決定方法を、以下に説明する。
【００７８】
１からｎ＋１の番号が付いた複数のボックスがあり、１からｎまで番号の付いたボックスは、それぞれタイマーに関連すると仮定する。それぞれのタイマーは、設定時刻を有し、該設定時刻は、ボックスの番号が増加すると増加する。例えば、ボックス番号１の設定時刻は、２分間であり、ボックス番号２は、５分間であり、ボックス番号３は、１０分間等である。ｎ＋１の番号の付いたボックスには、タイマーがなく、メッセージがメッセージの受信者に到達することはなく、自動の再試行を中止し、手動のリカバリーを待つべきであることを示す。
【００７９】
動作中、メッセージ通知は、ｉ回失敗した後は、番号ｉの付いたボックス内に置かれる。番号ｉの付いたボックスのタイマーの設定時刻に到達した後、再試行するようにボックス内のすべてのメッセージ通知がトリガされる。メッセージ通知は、ｎ＋１回失敗した後は、番号ｎ＋１の付いたボックス内に置かれる。番号ｎ＋１のボックスには、タイマーがないため、システムは、このメッセージ通知の自動の再試行を中止し、このメッセージ通知を手動の処理に渡す。
【００８０】
本発明の通知システムは、対応する外部システムの失敗パターンに適合するために、外部システムの異なる種類の特性に従って、それぞれのボックスのタイマーを調節することもできる。
【００８１】
図６に示されるような再試行間隔決定方法では、メッセージ通知の再試行回数が少ない場合、通知メッセージの送信における障害の原因が、短時間に消滅したことを示す。この場合、それぞれの再試行間の時刻間隔が小さいため、原因が解消されると、適時に通知メッセージが配信されること保証することができる。しかしながら、メッセージ通知の再試行回数が大きい場合、通知メッセージの配信が正常に行われない原因となる、長期間の通信障害が生じていたことを示す。結果として、再試行時刻間隔が次第に長くなり、これは、依然として通知メッセージの配信を保証しつつ、多くの不必要な再試行を効果的に回避し、システム資源の使用を減少させる。従って、説明した再試行間隔決定方法は、短期間の通信障害におけるメッセージ通知の適時リカバリーと、長期間の通信障害中の多くの不要な再試行の回避の両方を保証することができる。このように、説明した再試行間隔決定方法は、通知リカバリーの適時性および効率性の両方を同時に達成することができる。
【００８２】
本発明の信頼性のあるシステム間メッセージ通知のための方法およびシステムは、あらゆる協働システム間での使用に適している。特に、インターネットを介したシステム間でメッセージ通知が実行される際に、本発明は、ネットワークの信頼性の欠如、ならびにハードウェアおよびソフトウェアの障害による、通知メッセージの回復不能な損失の問題を解決することができ、メッセージの適時かつ信頼性のある配信を保証する。本発明は、異なるシステム間の様々な伝送プロトコルをサポートする。受信者は、複雑な対話プロトコルを実装する必要なく、通知メッセージを確実に受信することができ、本発明をインターネットでの普及に適したものにする。また本方法およびシステムは、複数の業務トランザクション処理をサポートし、ユニバーサル業務トランザクションアプリケーションとして機能し、複数の業務トランザクションおよびプロトコルに柔軟に拡張される。
【００８３】
本発明の信頼性のあるシステム間メッセージ通知のための方法およびシステムは、上記に詳細に記載される。例示的な実施形態を使用して、本文書において本発明の概念を説明した。特に、本発明の方法およびシステムは、あらゆる協働システム間での使用に適しているが、インターネットベースのシステム間での使用に制限されない。本発明は、インターネットを介した信頼性のあるシステム間メッセージ通知を保証するために最適化することができ、特にインターネットでの普及に適しているが、本選択は、本発明の特許請求の範囲に対する制限として解釈されるべきではない。例示的な実施形態は、本発明の方法および核となる概念を、より良く理解するためだけに使用される。本発明の概念に基づいて、当業者は、実用的な実装および適用領域に修正を行ってもよい。結論として、本記述の文脈は、本発明に対する制限として解釈されるべきではない。
【図面の簡単な説明】
【００８４】
【図１】本発明にかかる信頼性のあるシステム間メッセージ通知のための装置およびシステムの概略図である。
【図２】本発明にかかる信頼性のあるシステム間メッセージ通知の方法のフローチャートである。
【図３】開示されるメッセージ通知方法における登録プロセスのフローチャートである。
【図４】開示されるメッセージ通知方法にしたがって通知メッセージを送信するフローチャートである。
【図５】開示されるメッセージ通知方法にしたがってメッセージ通知を受信するフローチャートである。
【図６】本発明にかかる、通知メッセージを送信するための再試行間隔を決定する方法の概念図である。
【図１】
2009531749.tif 000003
【図２】
2009531749.tif 000004
【図３】
2009531749.tif 000005
【図４】
2009531749.tif 000006
【図５】
2009531749.tif 000007
【図６】
2009531749.tif 000008
【国際調査報告】
2009531749.tif 000009
2009531749.tif 000010
2009531749.tif 000011
2009531749.tif 000012