JP2016533546A - ネットワーク通信環境における仲介主体のための信頼できるメッセージングのための手法 - Google Patents

Abstract

この開示は一般に、メッセージ通信の信頼性を向上させるための手法に関する。ある実施形態では、仲介通信ハンドラシステムを介したソース（たとえば、クライアントシステム）と宛先（たとえば、ターゲットシステム）との間のメッセージの信頼できる通信を容易にするための手法が説明される。ある実施形態では、メッセージは、ターゲットサービスについて宛先に通信されるべき要求を含み得る。仲介通信ハンドラシステムは、信頼できる通信を保証するために、メッセージについての配信ステータスを示す情報を格納できる。メッセージについての配信ステータスを示す情報は、メッセージに対応するユニーク識別子に関連付けて管理され得る。メッセージについての配信ステータスを示す情報はまた、メッセージの通信に使用される通信プロトコルについて特定された信頼性パラメータ（たとえば、ＱｏＳ基準）を満たすメッセージの通信を再試行すべきか否かを判断するために使用されてもよい。

Description

関連出願との相互参照
本願は、「ネットワーク通信環境における仲介主体のための信頼できるメッセージングのための手法」（TECHNIQUES FOR RELIABLE MESSAGING FOR AN INTERMEDIARY IN A NETWORK COMMUNICATION ENVIRONMENT）と題され、２０１４年７月８日に出願された米国非仮出願第１４／３２５，８３４号からの優先権および利益を主張し、当該出願は、以下の出願からの優先権および利益を主張する：
１）「ウェブサービス環境における仲介主体のための信頼できるメッセージングのためのシステム」（SYSTEM FOR RELIABLE MESSAGING FOR AN INTERMEDIARY IN A WEB SERVICE ENVIRONMENT）と題され、２０１３年９月２０日に出願された米国仮出願第６１／８８０，８１９号；
２）「ネットワーク通信環境における仲介主体のための信頼できるメッセージングのための手法」と題され、２０１４年５月２３日に出願された米国仮出願第６２／００２，６３５号；および
３）「ネットワーク通信環境における仲介主体のための信頼できるメッセージングのための手法」と題され、２０１４年６月２５日に出願された米国仮出願第６２／０１７，０６８号
上に特定された特許出願の各々の内容全体は、すべての意図および目的のためにここに引用により援用される。

技術分野
この開示は一般にネットワーク通信の管理に関し、より具体的には、ネットワーク通信の信頼性を向上させるためのさまざまな手法に関する。

発明の背景
ネットワーク通信システムは、ネットワーク（たとえば、インターネット）を介した２つの電子装置間の電子メッセージの通信を可能にする。そのような通信システムは、装置同士が互いにやりとりすることを規定し、配置し、実現し、および／または可能にするために使用できるネットワーキングプロトコルおよび他のプロトコルをサポートするプロトコルスタックを利用する場合がある。メッセージは、２つの電子装置間の通信を容易にするためのさまざまなプロトコルを使用して、ネットワーク通信システムを介して通信され得る。

ソース（たとえば、クライアント装置）と宛先（たとえば、ターゲットサービス）との間でのメッセージの交換中、ソースから宛先に通信されたあるメッセージについて、ソースは、そのメッセージについて受理確認が受信されたか否かを判断しようとすることがある。そのような受理確認が受信されていない場合、またはメッセージはなくなったと考えられるとソースが判断した場合、ソースは、宛先へのメッセージの再送信を検討することがある。メッセージを再配信するための次の送信が、メッセージを送信するために使用される通信プロトコルによって妨害されることがある。また、メッセージの過剰な再送信により、ネットワーク通信システムが複製メッセージでいっぱいになるおそれがあり、メッセージの配信をさらに妨害する。加えて、複製メッセージを送信すると、ネットワーク通信システムのコンピューティングリソースおよびメモリリソースが、オリジナルメッセージの通信にとって望まれるものをはるかに上回る不均衡な量、消費されることがある。

簡単な概要
この開示は一般に、メッセージ通信の信頼性を向上させるための手法に関する。ある実施形態では、仲介通信ハンドラシステムを介したソース（たとえば、クライアントシステム）と宛先（たとえば、ターゲットシステム）との間のメッセージの信頼できる通信を容易にするための手法が説明される。メッセージは、宛先からターゲットサービスを要求するために通信されてもよい。

ある実施形態では、仲介通信ハンドラシステムは、信頼できる通信を保証するために、メッセージについての配信ステータスを示す情報を格納できる。ある実施形態では、仲介通信ハンドラシステムは、ＱｏＳ基準と一致する信頼できる配信を保証するために、メッセージについての配信ステータスを示す情報を使用してもよい。

ある実施形態では、宛先へのメッセージの配信時に遅延および／またはエラーに遭遇した場合、メッセージについての配信ステータスを示す情報は、仲介通信ハンドラシステムが、いつ、どのアクション（たとえば、メッセージ再送および配信結果の通信）を行なうべきかを判断できるようにしてもよい。たとえば、仲介通信ハンドラシステムは、宛先に送信されるべき要求（たとえば、ネットワークサービスの要求）に対応する複製メッセージを許可すべきか否かを、宛先に送信された同じ要求に対応する以前のメッセージの配信ステータスに基づいて判断してもよい。配信ステータスを維持することにより、仲介通信ハンドラは、メッセージの配信を確実に取扱うことができる。仲介通信ハンドラは、メッセージを配信するための複製の試みを防止するために、配信ステータスを使用できる。そうすることで、仲介通信ハンドラは、メッセージの再配信を管理しなければならないことを回避してもよい。配信を再試行すべきか否かを判断するための負担をソースにシフトすることができる。メッセージについての配信ステータスを示す情報は、ユニーク識別子に関連付けて管理され得る。ユニーク識別子は、メッセージのデジタル署名、または宛先に関連付けられたメッセージ識別子に基づき得る。ある実施形態では、ユニーク識別子は、メッセージに対応するメッセージ識別子に関連付けられ得る。メッセージ識別子をユニーク識別子に関連付けることにより、仲介通信ハンドラは、メッセージに関連付けられたメッセージ識別子を有する同一のメッセージを配信するようにという次の要求を判断し、防止することができる。メッセージについての配信ステータスを示す情報はまた、メッセージの通信に使用される通信プロトコルについて特定された信頼性パラメータ（たとえば、ＱｏＳ基準）を満たすメッセージの通信を再試行すべきか否かを判断するために、仲介通信ハンドラシステムによって使用されてもよい。

いくつかの実施形態では、仲介通信ハンドラシステムは、メッセージが配信された場合に仲介通信ハンドラシステムが受理確認を受信できるようにする１つ以上の呼出し可能インターフェイスを提供できる。１つ以上の呼出し可能インターフェイスは、仲介通信ハンドラシステムが、メッセージのステータスにおける変化の通知を受信できるようにしてもよい。インターフェイス通信ハンドラシステムは、ソースと宛先との間のメッセージの通信に関連する情報を管理することによって、仲介サービスシステム（たとえば、企業サービスバス）に対する負担を減らし得る。また、仲介通信ハンドラは、通信環境および／またはプロトコルにおける制限または差異に関係なく、各コンポーネントが独立して動作できるようにソースと宛先との間の独立性を促進し得る。

ある実施形態では、ソースから宛先へのメッセージの信頼できる通信を容易にするために、１つ以上の手法が提供される。１つのそのような手法は、仲介通信ハンドラシステムを含むなどのコンピューティングシステムによって行なわれ得る方法であり得る。コンピューティングシステムは、ソースから、ターゲットサービスに送信すべきメッセージを受信できる。コンピューティングシステムは、メッセージに関連付けられたメッセージ識別子を判断できる。コンピューティングシステムは、メッセージ識別子に基づいて、メッセージが以前にターゲットサービスに送信されたと判断できる。いくつかの実施形態では、メッセージ識別子の存在は、複製メッセージが以前にターゲットサービスに送信されたことを示すことができる。コンピューティングシステムは、メッセージ識別子がデータストアに格納されているか否かを判断してもよい。メッセージ識別子がデータストアに格納された識別子に関連付けられていると判断することは、メッセージが以前にターゲットサービスに送信されたことを示してもよい。コンピューティングシステムは、複製メッセージがターゲットサービスに送信されるのを防止するように、メッセージがターゲットサービスに送信されるのを防止してもよい。メッセージが以前に送信されていなかったと判断すると、コンピューティングシステムは、メッセージのためのメッセージ識別子を格納できる。また、メッセージが以前にターゲットサービスに配信されていなかったという判断に応答して、コンピューティングシステムは、メッセージの配信に関連する１つ以上のアクションを行なってもよい。１つ以上のアクションは、ソースのためにメッセージをターゲットサービスに送信することを含み得る。コンピューティングシステムは、メッセージがターゲットサービスに配信されたか否かを判断できる。たとえば、コンピューティングシステムは、受理確認が受信されたか否かを判断するために、メッセージの配信ステータスを調べることができる。受理確認が受信されていないと判断すると、コンピューティングシステムは、メッセージの配信に関連する１つ以上のアクションを行なうことができる。そのようなアクションは、メッセージをターゲットサービスに送信することを含んでいてもよい。メッセージは、元々送信されたメッセージのシーケンス番号および識別子を示す情報を用いてターゲットサービスに再配信されてもよい。受理確認が受信されたと判断すると、コンピューティングシステムは、メッセージ識別子に関連付けてメッセージの配信ステータスを格納し、次にメッセージの配信ステータスについてソースに通知することができる。コンピューティングシステムは、メッセージがターゲットサービスに再配信されるのを防止することができる。

いくつかの実施形態では、メッセージ識別子が識別子に関連付けられていないと判断すると、コンピューティングシステムは、メッセージのメッセージ識別子に関連付けられるべき識別子を生成してもよい。識別子は、コンピューティングシステムにアクセス可能なデータストアに格納されてもよい。コンピューティングシステムは、メッセージのフォーマットを使用して、メッセージのシーケンス番号および識別子を判断してもよい。フォーマットは通信プロトコルに基づいていてもよい。メッセージに関連付けられた識別子は、メッセージのシーケンス番号および識別子に基づいて生成されてもよい。

いくつかの実施形態では、ターゲットサービスに送信されるべきメッセージは、ウェブサービス・リライアブルメッセージング（web services reliable messaging：ＷＳ−ＲＭ）プロトコルに対応するフォーマットを有していてもよい。

上述の手法では、コンピューティングシステムは、配信ステータスインターフェイスを介して、仲介サービスシステムから、メッセージがターゲットサービスに配信されたことを示す情報を受信してもよい。そのような情報は、メッセージがターゲットサービスに配信されたことをメッセージの配信ステータスが示すように更新するために使用されてもよい。コンピューティングシステムは、メッセージがターゲットサービスに配信されたことを示す情報をソースに送信してもよい。

いくつかの実施形態では、上述のコンピューティングシステムは、メッセージが以前にターゲットサービスに送信されていないと判断すると、メッセージをメッセージ識別子に関連付けてもよい。コンピューティングシステムは次に、メッセージをターゲットサービスに送信してもよい。

少なくとも１つの例によれば、ソースから宛先へのメッセージの信頼できる通信を容易にするために、機器が提供されてもよい。機器は、コンピューティングシステムによって、ソースから、ターゲットサービスに送信すべきメッセージを受信するための手段と、コンピューティングシステムによって、メッセージに関連付けられたメッセージ識別子を判断するための手段と、コンピューティングシステムによって、メッセージ識別子に基づいて、メッセージが以前にターゲットサービスに送信されたと判断するための手段と、コンピューティングシステムによって、メッセージがターゲットサービスに配信されたか否かを判断するための手段と、メッセージがターゲットサービスに配信されたと判断すると、コンピューティングシステムによって、ターゲットサービスへのメッセージの配信を防止するための手段と、メッセージがターゲットサービスに配信されていないと判断すると、ターゲットサービスへのメッセージの配信に関連する１つ以上のアクションを行なうための手段とを含んでいてもよい。一局面では、メッセージは、ウェブサービス・リライアブルメッセージング（ＷＳ−ＲＭ）プロトコルに対応するフォーマットを有する。一局面では、機器はさらに、メッセージ識別子がデータストアに格納された識別子に関連付けられているか否かを判断するための手段を含んでいてもよく、メッセージ識別子がデータストアに格納された識別子に関連付けられていると判断することは、メッセージが以前にターゲットサービスに送信されたことを示す。一局面では、機器はさらに、メッセージ識別子が識別子に関連付けられていないと判断すると、メッセージ識別子に関連付けられるべき識別子を生成するための手段を含んでいてもよく、識別子はメッセージからの情報に基づいて生成され、さらに、識別子をデータストアに格納するための手段を含んでいてもよい。一局面では、機器はさらに、メッセージのフォーマットを使用して、メッセージのシーケンス番号および識別子を判断するための手段を含んでいてもよく、フォーマットは通信プロトコルに基づいており、メッセージに関連付けられた識別子は、メッセージのシーケンス番号および識別子に基づいて生成される。一局面では、メッセージの配信に関連するアクションを行なうことは、メッセージをターゲットサービスに送信することを含む。一局面では、メッセージは、メッセージのシーケンス番号および識別子を示す情報を用いてターゲットサービスに再配信される。一局面では、機器はさらに、配信ステータスインターフェイスを介して、仲介サービスシステムから、メッセージがターゲットサービスに配信されたことを示す情報を受信するための手段と、メッセージがターゲットサービスに配信されたことを示す情報を使用して、メッセージの配信ステータスを更新するための手段と、メッセージがターゲットサービスに配信されたことを示す情報をソースに送信するための手段とを含む。一局面では、機器はさらに、メッセージが以前にターゲットサービスに送信されていないと判断すると、メッセージをターゲットサービスに送信するための手段を含む。

以下の詳細な説明は、添付図面とともに、この発明の実施形態の性質および利点のよりよい理解を提供するであろう。

この発明の一実施形態に従った通信システムを示す図である。 この発明の一実施形態に従った通信システムを示す図である。 この発明の一実施形態に従った、ソースとターゲットサービスとの間の通信を管理するためのプロセスを示すフローチャートである。 この発明の一実施形態に従った、ソースとターゲットサービスとの間の通信を管理するためのプロセスを示すシーケンス図である。 実施形態のうちの１つを実現するための分散型システムの簡略図である。 この開示の一実施形態に従った、実施形態システムのコンポーネントによって提供されるサービスをクラウドサービスとして提供し得るシステム環境のコンポーネントの簡略ブロック図である。 この発明のさまざまな実施形態が実現され得る例示的なコンピュータシステムを示す図である。

さまざまな図面における同じ参照番号および名称は、同じ要素を示す。

詳細な説明
以下の記載では、説明の目的のため、この発明の実施形態の完全な理解を提供するために特定の詳細が述べられる。しかしながら、これらの特定の詳細がなくてもさまざまな実施形態は実践され得る、ということは明らかであろう。図および説明は、限定的であるよう意図されてはいない。

図のいくつかに示すシステムは、さまざまな構成で提供されてもよい。いくつかの実施形態では、システムは、システムの１つ以上のコンポーネントがクラウドコンピューティングシステムにおける１つ以上のネットワークを介して分散される分散型システムとして構成されてもよい。

この開示は一般に、メッセージ通信の信頼性を向上させるための手法に関する。ある実施形態では、仲介通信ハンドラシステムを介したソース（たとえば、クライアントシステム）と宛先（たとえば、ターゲットシステム）との間のメッセージの信頼できる通信を容易にするための手法が説明される。メッセージは、宛先からターゲットサービスを要求するために通信されてもよい。

ある実施形態では、仲介通信ハンドラシステムは、信頼できる通信を保証するために、メッセージについての配信ステータスを示す情報を格納できる。ある実施形態では、仲介通信ハンドラシステムは、ＱｏＳ基準と一致する信頼できる配信を保証するために、メッセージについての配信ステータスを示す情報を使用してもよい。

ある実施形態では、宛先へのメッセージの配信時に遅延および／またはエラーに遭遇した場合、メッセージについての配信ステータスを示す情報は、仲介通信ハンドラシステムが、いつ、どのアクション（たとえば、メッセージ再送および配信結果の通信）を行なうべきかを判断できるようにしてもよい。たとえば、仲介通信ハンドラシステムは、宛先に送信されるべき要求（たとえば、ネットワークサービスの要求）に対応する複製メッセージを許可すべきか否かを、宛先に送信された同じ要求に対応する以前のメッセージの配信ステータスに基づいて判断してもよい。配信ステータスを維持することにより、仲介通信ハンドラは、メッセージの配信を確実に取扱うことができる。仲介通信ハンドラは、メッセージを配信するための複製の試みを防止するために、配信ステータスを使用できる。そうすることで、仲介通信ハンドラは、メッセージの再配信を管理しなければならないことを回避してもよい。配信を再試行すべきか否かを判断するための負担をソースにシフトすることができる。メッセージについての配信ステータスを示す情報は、ユニーク識別子に関連付けて管理され得る。ユニーク識別子は、メッセージのデジタル署名、または宛先に関連付けられたメッセージ識別子に基づき得る。ある実施形態では、ユニーク識別子は、メッセージに対応するメッセージ識別子に関連付けられ得る。メッセージ識別子をユニーク識別子に関連付けることにより、仲介通信ハンドラは、メッセージに関連付けられたメッセージ識別子を有する同一のメッセージを配信するようにという次の要求を判断し、防止することができる。メッセージについての配信ステータスを示す情報はまた、メッセージの通信に使用される通信プロトコルについて特定された信頼性パラメータ（たとえば、ＱｏＳ基準）を満たすメッセージの通信を再試行すべきか否かを判断するために、仲介通信ハンドラシステムによって使用されてもよい。

いくつかの実施形態では、仲介通信ハンドラシステムは、メッセージが配信された場合に仲介通信ハンドラシステムが受理確認を受信できるようにする１つ以上の呼出し可能インターフェイスを提供できる。１つ以上の呼出し可能インターフェイスは、仲介通信ハンドラシステムが、メッセージのステータスにおける変化の通知を受信できるようにしてもよい。インターフェイス通信ハンドラシステムは、ソースと宛先との間のメッセージの通信に関連する情報を管理することによって、仲介サービスシステム（たとえば、企業サービスバス）に対する負担を減らし得る。また、仲介通信ハンドラは、通信環境および／またはプロトコルにおける制限または差異に関係なく、各コンポーネントが独立して動作できるようにソースと宛先との間の独立性を促進し得る。

図１は、この発明の一実施形態に従った通信システム１００を示す。図示されるように、通信システム１００は、ソース１０２と、複数のターゲットサービス（たとえば、ターゲットサービス１０４およびターゲットサービス１０６）と、仲介通信ハンドラ１１０とを含む。仲介通信ハンドラ１１０は、ソース１０２と１つ以上の宛先との間のメッセージ（たとえば、メッセージ１０８）の信頼できる通信を容易にする。各ターゲットサービス（たとえば、ターゲットサービス１０４およびターゲットサービス１０６）は、宛先であってもよい。図１に示す通信システム１００はまた、仲介通信ハンドラ１１０によってアクセス可能な１つ以上のデータストア１６０を含む。データストア１６０は、データベース（たとえば、文書データベース、リレーショナルデータベース、または他のタイプのデータベース）、ファイルストア、それらの組合せ、または何らかの他の情報ストアを使用して実現され得る。

通信システム１００とは異なり得る、さまざまな異なるシステム構成が可能である、ということが理解されるべきである。図１に示す実施形態はこのため、この発明の一実施形態を実現するための通信システムの一例であり、限定的であるよう意図されてはいない。例示の目的のため、特定の実施形態が、ソース１０２とターゲットサービス１０４、１０６との間のメッセージの信頼できる通信を容易にするための手法としてここに説明される。この発明の実施形態によれば、どのソース（たとえば、ソース１０２）も、仲介通信ハンドラ１１０を介して、ターゲットサービス（たとえば、ターゲットサービス１０４またはターゲットサービス１０６）と通信可能である。

ソース１０２、仲介通信ハンドラ１１０、およびターゲットサービス１０４、１０６は、異なるコンピューティングシステムで実現され得る。ある実施形態では、通信システム１００の要素のすべてまたはいくつかが、単一のコンピューティングシステムに含まれ得る。異なるコンピューティングシステム上で実現される場合、ソース１０２、仲介通信ハンドラ１１０、およびターゲットサービス１０４、１０６は、１つ以上のネットワーク（図示せず）を介して互いに通信してもよい。通信ネットワークの例は、インターネット、モバイルネットワーク、無線ネットワーク、セルラーネットワーク、ローカルエリアネットワーク（local area network：ＬＡＮ）、ワイドエリアネットワーク（wide area network：ＷＡＮ）、他の通信ネットワーク、またはそれらの組合せを含んでいてもよい。

ソース１０２（たとえば「ソース」）は、コンピューティングシステムを含んでいてもよい。ソース１０２は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。ソース１０２は、ターゲットサービス１０４、１０６のうちの１つ以上への配信のために、メッセージ（たとえば、メッセージ１０８）を仲介通信ハンドラ１１０に通信してもよい。いくつかの実施形態では、ターゲットサービスに送信されたメッセージは、サービスの要求を含んでいてもよい。ソース１０２は、携帯情報端末（personal digital assistant：ＰＤＡ）、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、ウェアラブルコンピュータ、ポケットベルなどを含んでいてもよい。ソース１０２は、１つ以上のメモリ記憶装置と１つ以上のプロセッサとを含み得る。メモリ記憶装置はプロセッサにアクセス可能であり、また、プロセッサによって実行されるとここに開示された１つ以上の動作をプロセッサに実現させる、格納された命令を含み得る。さまざまな実施形態では、ソース１０２は、ウェブブラウザ、専用クライアントアプリケーションなどのアプリケーションを実行し、動作させるように構成されてもよい。

ターゲットサービス（たとえば、ターゲットサービス１０４およびターゲットサービス１０６）は、コンピューティングシステムにおいて実現され、または含まれてもよい。ターゲットサービスは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。ターゲットサービスは、仲介通信ハンドラ１１０を介してソース１０２と通信してもよい。たとえば、ソース１０２で作成されたメッセージ（たとえば、メッセージ１０８）は、ターゲットサービス１０４、１０６のうちの１つ以上をメッセージの宛先として識別してもよい。メッセージの宛先であるターゲットサービスは、ソース１０２から送信されたメッセージ１０８を、仲介通信ハンドラ１１０を介して受信してもよく、１つ以上の応答（たとえば、メッセージ１１２）をクライアントリソース１０２に通信してもよい。メッセージ１０８は、要求されているターゲットサービスを示してもよい。いくつかの実施形態では、メッセージ１０８、１１２のうちの１つ以上は、インターネットを介した２つの電子装置間の通信用に意図されたウェブメッセージである場合がある。

ターゲットサービスは、サービスを要求するメッセージの受信に応答して、さまざまなサービスを提供できる。サービスは、アプリケーションの実行、ファンクションの実行、データの検索、情報の通信などを含んでいてもよい。

ターゲットサービス１０４、１０６は、ＰＤＡ、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、ウェアラブルコンピュータ、ポケットベルなどのコンピューティング装置で実現されてもよい。ターゲットサービス１０４、１０６は、１つ以上のメモリ記憶装置と１つ以上のプロセッサとを使用して実現され得る。メモリ記憶装置はプロセッサにアクセス可能であり、また、プロセッサによって実行されるとここに開示された１つ以上の動作をプロセッサに実現させる、格納された命令を含み得る。さまざまな実施形態では、ターゲットサービス１０４、１０６は、サービスを提供するために、アプリケーション（たとえば、ウェブブラウザ、専用クライアントアプリケーションなど）を実行し、動作させるように構成されてもよい。

いくつかの実施形態では、ターゲットサービス１０４に通信されたメッセージ（たとえば、メッセージ１０８）は、ソース１０２で実行されたアプリケーションによって生成されてもよい。たとえば、ソースで実行されたアプリケーションは、そのアプリケーションの動作のために、ターゲットサービス１０６を使用してアクションを行なうようにという要求などのメッセージ１０８を、仲介通信ハンドラ１１０を介してターゲットサービス１０６に送信してもよい。たとえば、ソース１０２は、ローンアプリケーションである場合があり、それは、顧客の信用格付けをつきとめるためにターゲットサービス１０６からサービスを要求するためにメッセージ１０８を通信する。別の例では、クライアントアプリケーションは、ターゲットサービス１０６によって提供されるリソースを要求するために簡易オブジェクトアクセスプロトコル（simple object access protocol：ＳＯＡＰ）を使用してメッセージ１０８を通信するウェブブラウザである場合がある。いくつかの実施形態では、ソース１０２は、異なるアプリケーションを実行しているターゲットサービスにメッセージ１０８を通信するアプリケーションを実行する。いくつかの実施形態では、双方のアプリケーションが、ウェブサービス・リライアブルメッセージング（ＷＳ−ＲＭ）プロトコルを通信用に使用してもよい。

仲介通信ハンドラ１１０は、ソース１０２とターゲットサービス１０４、１０６との間の通信プロキシサービスとして作用できる。メッセージ（たとえば、メッセージ１０８）を配信するためにターゲットサービス１０４、１０６と直接通信するのではなく、ソース１０２は、ターゲットサービス１０４、１０６へのメッセージの配信のために、仲介通信ハンドラ１１０にメッセージを通信してもよい。仲介通信ハンドラ１１０は、ターゲットサービス１０４、１０６のうちの１つ以上に通信されるべきメッセージ（たとえば、メッセージ１０８）を、ソース１０２から受信できる。仲介通信ハンドラ１１０は、ソース１０２に通信されるべき１つ以上のメッセージ（たとえば、メッセージ１１２）を、ターゲットサービス（たとえば、ターゲットサービス１０６）から受信できる。ターゲットサービス１０６から仲介通信ハンドラ１１０によって受信されたメッセージ（たとえば、メッセージ１１２）は、ソース１０２から仲介通信ハンドラ１１０によって受信され、ターゲットサービス１０６に通信されたメッセージ（たとえば、メッセージ１０８）に応答するものであってもよい。たとえば、ターゲットサービスから受信されたメッセージ１１２は、メッセージ１０８がターゲットサービスによって受信されたか否かといった、ターゲットサービスへのメッセージ１０８の配信ステータスを示す情報を含んでいてもよい。別の例として、メッセージ１１２は、メッセージ１０８において要求されたサービスに関連する情報を含んでいてもよい。

仲介通信ハンドラ１１０を介して通信することにより、ソース１０２およびターゲットサービス１０４、１０６は、ソースから宛先へのメッセージ（たとえば、メッセージ１０８）の配信ステータスに関する信頼できる情報を確認することができる。仲介通信ハンドラ１１０は、ソース１０２およびターゲットサービス１０４、１０６に、通信されたメッセージの配信ステータスを示す情報を提供してもよい。仲介通信ハンドラ１１０は、ソース１０２またはターゲットサービス１０４、１０６によって使用される通信プロトコルがメッセージの配信、送信、受理確認などを保証するためのメカニズムを提供しない場合に、メッセージの信頼できる配信を可能にしてもよい。

仲介通信ハンドラ１１０は、サーバコンピュータなどのコンピューティング装置を１つ以上使用して実現されてもよい。いくつかの実施形態では、仲介通信ハンドラ１１０は、ソースサーバコンピュータ１４０および宛先サーバコンピュータ１５０などの複数のサーバコンピュータを含み得る。ある実施形態では、ソースサーバコンピュータ１４０または宛先サーバコンピュータ１５０の一方または双方は、ネットワーク通信サーバコンピュータであり得る。ソースサーバコンピュータ１４０は、ターゲットサービスに送信するためにソース１０２から受信されたメッセージを処理するように構成されてもよい。メッセージ（たとえば、メッセージ１０８）は、ソース１０２によってサポートされるプロトコルに従って処理されてもよい。宛先サーバコンピュータ１５０は、ソースサーバコンピュータによって処理されたメッセージの配信を取扱ってもよい。宛先サーバコンピュータ１５０は、ターゲットサービス１０４、１０６のうちの１つなどの宛先にメッセージを配信するように構成されてもよい。いくつかの実施形態では、ソースサーバコンピュータ１４０または宛先サーバコンピュータ１５０の一方または双方は、アプリケーションおよびサービスがソース１０２およびターゲットサービス１０４、１０６の一方または双方に提供され得るようにするアプリケーションサーバとして動作可能である。

仲介通信ハンドラ１１０は、１つ以上のメモリ記憶装置と１つ以上のプロセッサとを含み得る。メモリ記憶装置はプロセッサにアクセス可能であり、また、プロセッサによって実行されるとここに開示された１つ以上の動作をプロセッサに実現させる、格納された命令を含み得る。さまざまな実施形態では、仲介通信ハンドラ１１０は、ウェブブラウザ、専用クライアントアプリケーションなどのサービスアプリケーションを実行し、動作させるように構成されてもよい。

いくつかの実施形態では、ソース１０２とターゲットサービス１０４、１０６との間でのメッセージ（たとえば、メッセージ１０８）の交換は、サーバコンピュータ１４０、１５０のうちの１つ以上によって容易にされてもよい。たとえば、メッセージがＷＳ−ＲＭプロトコルを使用してソース１０２からターゲットサービス１０６に通信される場合、ＷＳ−ＲＭプロトコルに従ったメッセージ１０８の交換を容易にするために、ソースサーバコンピュータ１４０はリライアブルメッセージングソース（reliable messaging source：ＲＭＳ）として動作するように構成され、宛先サーバコンピュータ１５０はリライアブルメッセージング宛先（reliable messaging destination：ＲＭＤ）として動作するように構成されてもよい。ソースサーバコンピュータ１４０は、メッセージの通信を管理するために宛先サーバコンピュータ１５０と通信可能である。メッセージの通信を管理することは、配信されるべきメッセージのための通信のシーケンスを維持することを含んでいてもよい。一実施形態では、メッセージ配信のために、ＱｏＳパラメータが（たとえば、プロトコル自体、システムアドミニストレータなどによって）規定されてもよい。そのような実施形態では、ソースサーバコンピュータ１４０および宛先サーバコンピュータ１５０は、メッセージ通信プロトコル（たとえば、ＷＳ−ＲＭプロトコル）のＱｏＳパラメータに従い、それに準拠してメッセージの配信を保証するように構成されてもよい。

いくつかの実施形態では、仲介通信ハンドラ１１０は、ソース１０２と１つ以上のターゲットサービス１０４、１０６との間でのメッセージの交換を容易にするために、仲介サービスシステム１２０を含み得る。たとえば、仲介サービスシステム１２０は企業サービスバスを含み、またはそれを実現することができる。ソース１０２およびターゲットサービス１０４、１０６といった１つ以上の異種コンピューティングシステムは、仲介サービスシステム１２０を通して通信可能に接続され得る。仲介サービスシステム１２０は、ソース１０２とターゲットサービス１０４、１０６との間のメッセージのルーティングを監視し、制御することができる。仲介サービスシステム１２０は、ターゲットサービスとの通信のための複数のソース間の競合解除を含め、ターゲットサービス１０４、１０６へのアクセスを制御することができる。仲介サービスシステム１２０は、イベント取扱い、通信中のメッセージのためのデータ変換、およびメッセージプロトコル変換を行なうことができる。

仲介サービスシステム１２０は、とりわけ、ＳＯＡＰ、ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol：ＨＴＴＰ）、Ｊａｖａ（登録商標）メッセージングサービス（Java Messaging Service：ＪＭＳ）プロトコル、インターネットＯｒｂ間プロトコル上のＪａｖａリモートメソッド呼出しインターフェイス（Remote Method Invocation interface over the Internet Inter-Orb Protocol：ＲＭＩ−ＩＩＯＰ）、電子メール通信プロトコル（たとえば、簡易メール転送プロトコル）、ファイル転送プロトコル（File Transfer Protocol：ＦＴＰ）、ＷＳ−ＲＭプロトコルを含む、さまざまな異なる通信プロトコルをサポートでき、それらのいずれも、通信のためにソース１０２および／またはターゲットサービス１０４、１０６によって実現され得る。ある実施形態では、ソースで生じ、特定のターゲットに向けられるメッセージについて、ソースと仲介通信ハンドラ１１０との間の通信に使用される通信プロトコルは、仲介通信ハンドラ１１０と特定のターゲットとの間の通信に使用される通信プロトコルと異なっていてもよい。そのようなシナリオでは、ターゲットサービス１０４、１０６などの宛先への配信のためにソース１０２から仲介通信ハンドラ１１０によって受信されたメッセージ１０８は、第１の通信プロトコルに従った第１のフォーマットの仲介通信ハンドラ１１０によって受信されてもよい。仲介通信ハンドラ１１０は次に、意図される宛先によってサポートされる、第１の通信プロトコルとは異なる第２の通信プロトコルに従って、受信されたメッセージを第１のフォーマットとは異なる第２のフォーマットに変換し、変換されたメッセージを宛先に通信してもよい。

仲介通信ハンドラ１１０は、ソース１０２とターゲットサービス１０４、１０６の１つ以上との間の通信のステータスを管理するように構成された通信マネージャ１３０を含み得る。一実施形態では、仲介通信ハンドラ１１０を介して通信される別個のメッセージ（たとえば、メッセージ１０８またはメッセージ１１２）ごとに、情報が、そのメッセージに関連する１つ以上のデータストア（たとえば、データストア１６０）に格納されてもよい。格納された情報は、ユニークなメッセージごとのユニークメッセージ識別子１６２、またはメッセージの状態についての他の情報を含んでいてもよい。メッセージのメッセージ識別子は、ユニークメッセージ識別子１６２として使用されてもよく、または、ユニーク識別子１６２として使用される別の識別子に関連付けられてもよい。メッセージのメッセージ識別子を格納することにより、仲介通信ハンドラ１１０は、新しいメッセージが、保留中の配信であるメッセージの複製であるか否かを判断することができる。複製メッセージは、前のメッセージと同一のメッセージ識別子を有していてもよい。整合が見つかるか否か判断するために、入来メッセージのメッセージ識別子は、ユニーク識別子１６２、またはユニーク識別子１６２に関連付けられたメッセージ識別子と比較されてもよい。メッセージ識別子に関連付けられたユニーク識別子１６２の存在は、複製メッセージを示してもよい。また、メッセージに関連する情報をデータストアに格納することにより、この発明のある実施形態は、クラスタ化コンピューティング環境などのコンピューティング環境において、クラスタのすべてのノードにおけるメッセージ状態の格納を可能にするように実現されてもよい。たとえば、データストア１６０などのデータストアは、通信される過程にあったメッセージのシステム回復を容易にし、または可能にしてもよい。

メッセージ識別子ごとに、関連付けられた格納された情報はまた、メッセージ識別子に対応するメッセージの、そのメッセージの意図された宛先への配信ステータスを示す情報を含んでいてもよい。たとえば、ソース１０２から仲介通信ハンドラ１１０によって受信されたメッセージ１０８について、仲介通信ハンドラ１１０は、メッセージ１０８のためのメッセージ識別子を格納し、また、メッセージ１０８のその意図された宛先への配信ステータスに関する情報も格納してもよい。仲介通信ハンドラ１１０が配信ステータスにおける（たとえば「通信保留」から「ターゲットによるメッセージ受信」への）変化についての情報を受信すると、この配信ステータス情報は更新されてもよい。ある実施形態では、宛先サーバコンピュータ１５０による宛先へのメッセージの配信に関連付けられたメッセージ識別子または他の識別子に関連付けて、別個のメッセージ識別子が格納されてもよい。宛先サーバコンピュータ１５０のためのメッセージ識別子が、メッセージ識別子に対応するメッセージの配信のための再試行を管理するために、宛先リソースマネージャによって使用されてもよい。宛先サーバコンピュータ１５０によって使用されるメッセージ識別子は、メッセージの配信ステータスに関連付けて格納されてもよい。

メッセージのためのメッセージ識別子を生成するために、さまざまな異なる手法を使用してもよい。一実施形態では、メッセージのためのメッセージ識別子は、メッセージの内容の一部に基づいて生成されてもよい。たとえば、メッセージの一部が選択され、選択された一部にファンクションを適用することによってメッセージ識別子が生成されてもよい。別の例では、メッセージ識別子は、受信されたメッセージにすでに含まれる情報に対応していてもよい。別の実施形態では、メッセージ識別子を生成するために、シーケンス番号スキームを使用してもよい。そのような一実施形態では、仲介通信ハンドラ１１０は、ソースとターゲットサービスとの間の通信のシーケンスを追跡し、通信のシーケンスにおけるメッセージの順序に基づいてメッセージ識別子をメッセージに割当ててもよい。

メッセージ識別子は、さまざまな異なる目的のために、仲介通信ハンドラ１１０によって使用されてもよい。たとえば、一実施形態では、通信マネージャ１３０は、複製メッセージを識別するためにメッセージ識別子を使用してもよい。通信マネージャ１３０は、メッセージ識別子がすでに格納されているか否かを判断するために、メッセージ識別子がないかデータストア１６０をサーチしてもよい。メッセージ識別子の存在は、そのメッセージ識別子に関連付けられたメッセージの配信について要求が受信されたことを示してもよい。いくつかの実施形態では、メッセージ識別子は、ソースサーバコンピュータ１４０から受信されたメッセージのメッセージ識別子に関連付けて格納されてもよい。メッセージ識別子との関連付けの存在は、仲介通信ハンドラ１１０が、要求された新しいメッセージが複製か否かを判断できるようにするのに有用であり得る。メッセージがオリジナルメッセージであるかまたは複製メッセージであるかの判断が、仲介通信ハンドラ１１０によるメッセージの配信に関連する１つ以上の異なるアクションをトリガしてもよい。たとえば、メッセージが複製であると判断された場合、仲介通信ハンドラ１１０は、オリジナルメッセージに関連付けられた配信ステータスを判断し、その配信ステータスに基づいて、複製メッセージの通信を許可するか否かを判断してもよい。

通信マネージャ１３０は、ソース１０２とターゲットサービス１０４、１０６との間で通信されたメッセージ（たとえば、メッセージ１０８またはメッセージ１１２）の配信ステータス１６４を格納できる。配信ステータス１６４は、メッセージ識別子１６２に関連付けて格納され得る。いくつかの実施形態では、配信ステータス１６４は、宛先サーバコンピュータ１５０に対応する別のメッセージ識別子に関連付けて格納されてもよい。宛先サーバコンピュータ１５０は、宛先サーバコンピュータ１５０のためのメッセージ識別子に関連付けられた配信ステータスに基づいて、メッセージの配信を再試行するか否かを判断してもよい。配信ステータス１６４は、メッセージが配信された（たとえば、配信の受理確認が受信された）か否か、メッセージが送信されたか否か、メッセージの配信中にエラーに遭遇したか否か、またはメッセージの配信に関連付けられた他のステータスを示すことができる。通信マネージャ１３０は、ソースサーバコンピュータ１４０、宛先サーバコンピュータ１５０、仲介サービスシステム１２０、またはそれらの組合せが、メッセージの配信ステータスにおける変化について通信マネージャ１３０に通知できるようにするインターフェイスを含み得る。

通信マネージャ１３０は、メッセージのためのメッセージ識別子１６２に基づいて、配信ステータス１６４を判断できる。メッセージが以前のメッセージの複製であるか否かを判断するために、配信ステータス１６４が通信マネージャ１３０によって使用され得る。複製メッセージがターゲットサービス１０４、１０６の１つ以上に送信されたか否かを判断するために、通信マネージャ１３０は配信ステータス１６４を使用できる。通信マネージャ１３０は、複製メッセージをターゲットサービス１０６に通信すべきか否かを判断でき、通信すべきでない場合には、複製メッセージがターゲットサービス１０６に通信されるのを防止できる。メッセージのための通信のステータス（たとえば、メッセージの配信ステータス）は、通信マネージャ１３０が通信システム１００における通信を管理できるようにし得る。たとえば、通信マネージャ１３０は、メッセージを再送することによって、ターゲットサービス１０４、１０６のうちの１つへのメッセージの配信の再試行を試みることができる。

図２〜４を参照して、仲介通信ハンドラ１１０を以下にさらに説明する。図２は、この発明の一実施形態に従った通信システム２００を示す。通信システム２００は、同じ参照番号および名称によって表わされる図１の同じ要素を含み得る。通信システム２００は、１つ以上のソース（たとえば、ソース１０２）と、１つ以上のターゲットサービス（たとえば、ターゲットサービス１０４またはターゲットサービス１０６）と、仲介通信ハンドラ１１０と、データストア１６０とを含み得る。通信システム２００は、ソース１０２とターゲットサービス１０４、１０６との間のメッセージ（たとえば、ウェブメッセージ）の信頼できる通信を容易にすることができる。

仲介サービスシステム１２０は、１つ以上のソース（たとえば、ソース１０２）を、１つ以上のターゲットサービス（たとえば、ターゲットサービス１０４およびターゲットサービス１０６）と通信可能に接続することができる。仲介サービスシステム１２０は、ソース１０２とターゲットサービス１０４、１０６との間のメッセージの交換を容易にするために、１つ以上のインターフェイスを含み、またはそれを実現することができる。仲介サービスシステム１２０は、ソースサーバコンピュータ１４０および／または宛先サーバコンピュータ１５０に、メッセージの配信ステータスについて通知することができる。

仲介サービスシステム１２０は、ソース（たとえば、ソース１０２）と宛先（たとえば、ターゲットサービス１０４またはターゲットサービス１０６）との間のメッセージの通信のためにさまざまな動作を行なうように構成された１つ以上のファンクションブロックまたはモジュールとして実現され得る。仲介サービスシステム１２０は、入力インターフェイス２２２と、出力インターフェイス２２４とを含み得る。仲介サービスシステム１２０は、メッセージを非同期に処理し、各メッセージが配信され得る宛先によってサポートされるプロトコルを使用してそれらを配信することができる。たとえば、入力インターフェイス２２２は、ソース１０２からメッセージ（たとえば、メッセージ１０８）を受信し、それらのメッセージを、出力インターフェイス２２４を介してターゲットサービス１０６に配信することができる。

ある実施形態では、入力インターフェイス２２２は、仲介サービスシステム１２０がターゲットサービス１０４、１０６への通信のためにソース１０２からメッセージを受信できるようにするためにソース１０２によって呼出され得る呼出し可能インターフェイス（たとえば、アプリケーションプログラミングインターフェイス）を提供できる。入力インターフェイス２２２は、メッセージの送信元（たとえば、ソース１０２、ターゲットサービス１０４、またはターゲットサービス１０６）によってサポートされる１つ以上のメッセージ通信プロトコルと一致するフォーマットで、メッセージを受信できる。メッセージを受信すると、入力インターフェイス２２２は、メッセージプロトコル特有の処理のために、ソースサーバコンピュータ１４０の通信プロトコルスタックにメッセージを配置できる。ある実施形態では、入力インターフェイス２２２は、メッセージの宛先へのアウトバウンド配信のために、宛先サーバコンピュータ１５０の通信プロトコルスタックにメッセージを配置できる。

出力インターフェイス２２４は、宛先へのメッセージの配信のために呼出され得る呼出し可能出力インターフェイスを提供できる。ある実施形態では、出力インターフェイス２２４は、宛先（たとえば、ターゲットサービス１０４またはターゲットサービス１０６）にメッセージを送信するために、仲介通信ハンドラ１１０のウェブサーバ（たとえば、宛先サーバコンピュータ１５０）によって呼出され得る。出力インターフェイス２２４は、メッセーが配信されるべき宛先によってサポートされる１つ以上のメッセージ通信プロトコルと一致するフォーマットで、メッセージを送信できる。

ソースサーバコンピュータ１４０は、メッセージの送信元によってサポートされるプロトコルに従って、受信されたメッセージを処理できる。ある実施形態では、メッセージは、仲介サービスシステム１２０に宛先への配信のためにメッセージを処理するよう要求する前に処理され得る。ソースサーバコンピュータ１４０は、ソース（たとえばソース）からインバウンドメッセージを受信し、管理して処理することができる通信プロトコルスタックを実現できる。通信プロトコルスタックは、サービストランスポートプロトコル（たとえば、ＨＴＴＰ、ＳＭＴＰ、およびＦＴＰ）、ＳＯＡＰプロトコル、またはＷＳ−ＲＭメッセージングプロトコルなどの通信プロトコルをサポートしてもよい。メッセージの配信を要求するために、ソースサーバコンピュータ１４０は、宛先へのメッセージの配信を予定するようにという仲介サービスシステム１２０への要求を起動できる。ソースサーバコンピュータ１４０は、例外を示すための、または他の態様でメッセージの配信ステータスについてソースに通知するための機能性を提供できる。ソースサーバコンピュータ１４０は、通信マネージャ１３０から、メッセージの配信ステータスについての情報を要求できる。ある実施形態では、ソースサーバコンピュータ１４０は、配信ステータスに基づいてメッセージの配信を試みるようにという追加の要求を仲介サービスシステム１２０に通信できる。

ある実施形態では、ソースサーバコンピュータ１４０は、メッセージの配信を要求する前に、ソース（たとえば、ソース１０２）と宛先（たとえば、ターゲットサービス１０４）との間の通信シーケンスを起動するようにという要求を、宛先サーバコンピュータ１５０に送信することができる。ある実施形態では、この要求は、仲介サービスシステム１２０を介して通信され得る。宛先サーバコンピュータ１５０は、ソースサーバコンピュータ１４０と仲介通信ハンドラ１１０との間の通信に割当てるべきシーケンス識別子を判断してもよい。通信シーケンスを作成するようにという要求は、ソース１０２とターゲットサービス（たとえば、ターゲットサービス１０６）との間の通信シーケンスにおける第１のメッセージのために起動され得る。宛先に通信されたメッセージ（たとえば、メッセージ１０８）のための識別子に、シーケンス番号が割当てられ得る。シーケンス番号および識別子は、ターゲットサービスに通信されたメッセージに関連付けられ得る。仲介通信ハンドラ１１０およびターゲットサービス１０４、１０６によるメッセージの通信中、ソースサーバコンピュータ１４０は、宛先サーバコンピュータ１５０に、通信に対応するシーケンス識別子を求めてもよい。

宛先サーバコンピュータ１５０は、宛先に送信されるべきメッセージを処理できる。ある実施形態では、メッセージは、宛先によってサポートされるプロトコルに従って処理され得る。いくつかの実施形態では、宛先ウェブサーバ１５０は、仲介サービスシステム１２０から、配信のためにメッセージを処理するようにという要求を受信できる。メッセージは、仲介サービスシステム１２０が、メッセージを宛先に送信するようにという要求を受信する前に処理され得る。宛先サーバコンピュータ１５０は、宛先に配信されることを管理する通信プロトコルスタックを実現できる。通信プロトコルスタックは、サービストランスポートプロトコル（たとえば、ＨＴＴＰ、ＳＭＴＰ、およびＦＴＰ）、ＳＯＡＰプロトコル、またはＷＳ−ＲＭメッセージングプロトコルなどの通信プロトコルをサポートしてもよい。

ある実施形態では、メッセージの配信を管理するために、宛先サーバコンピュータ１５０は、トランザクションをメッセージに関連付けることができる。配信のための別個のメッセージを受信すると、宛先サーバコンピュータ１５０は、配信されるべきメッセージのためのトランザクションを作成できる。宛先サーバコンピュータ１５０は、メッセージに対応するトランザクション（たとえば、コミットまたはロールバック）のステータスに基づいて、そのメッセージの配信のための処理のステータスを管理できる。メッセージが配信されたと判断すると、宛先サーバコンピュータ１５０は、配信のためのトランザクションを完了するために、メッセージに関連付けられたトランザクションをコミットしようとすることができる。メッセージが配信できないと判断すると、メッセージが配信されなかったことを示すために、メッセージに関連付けられたトランザクションはロールバックされ得る。

配信のステータスに基づいて、宛先サーバコンピュータ１５０は、メッセージまたは任意の複製メッセージの配信に関連する追加のアクションを行なうべきか否かを判断できる。いくつかの実施形態では、宛先サーバコンピュータ１５０は、メッセージの配信を要求しようとすべきか否かを判断するために、通信マネージャ１３０からステータスを得ることができる。ステータスは、複製メッセージの配信をどのように管理するかを判断するために使用可能である。ある実施形態では、宛先サーバコンピュータ１５０は、配信ステータスに基づいてメッセージの再配信を試みるようにという追加の要求を仲介サービスシステム１２０に通信できる。ある実施形態では、宛先サーバコンピュータ１５０は、メッセージの配信ステータスを提供するために、仲介サービスシステム１２０を介してソースサーバコンピュータ１４０と通信できる。宛先サーバコンピュータ１５０は、メッセージの配信についての情報の管理のために、宛先から受信された応答を通信マネージャ１３０に通信できる。

通信マネージャ１３０は、メッセージを配信するようにという要求についての情報（たとえば、配信ステータス）を管理できる。通信マネージャ１３０は、ソースと宛先との間のメッセージの通信のためにさまざまな動作を行なうように構成された１つ以上のファンクションブロックまたはモジュールとして実現され得る。通信マネージャ１３０は、配信ステータスインターフェイスモジュール２３２と、メッセージマネージャ２３６と、ステータス判断部２３８とを含み得る。通信マネージャ１３０は、そのファンクションブロックまたはモジュールのうちの１つ以上を介して呼出され得る。

メッセージマネージャ２３６は、データストア１６０におけるメッセージについての情報（たとえば、メッセージ識別子１６２）およびそれらのステータス（たとえば、配信ステータス１６４）を管理できる。メッセージマネージャ２３６は、宛先に送信されるべき別個のメッセージごとにメッセージ識別子を生成できる。ある実施形態では、メッセージマネージャ２３６は、別個のメッセージのためにメッセージ識別子を生成できる。いくつかの実施形態では、メッセージ識別子は、ソースサーバコンピュータ１４０と宛先サーバコンピュータ１５０との間の通信のシーケンスのためにソースサーバコンピュータ１４０から受信されたメッセージのシーケンス識別子または識別子の一方または双方に基づき得る。

メッセージマネージャ２３６は、データストア１６０におけるメッセージのための配信ステータス１６４を管理できる。配信ステータス１６４は、メッセージ識別子１６２に関連付けて維持され得る。たとえば、メッセージの配信ステータス１６４は、そのメッセージが配信のために受入れられたか否か、メッセージが配信されたか否か、宛先がメッセージの受信を確認したか否か、またはメッセージを再配信する試みがなされたか否かを示す情報を含み得る。配信ステータスにより、通信マネージャ１３０は、メッセージが実際に宛先に配信されたか否かを判断することができる。メッセージとのトランザクションの関連付けにより、メッセージの配信ステータスは維持され、正確であり得る。そうすることにより、ソースサーバコンピュータ１４０は、成功した配信ステータスを仲介サービスシステム１２０に通信することができる。また、メッセージの実際の配信が生じると、仲介サービスシステム１２０は、メッセージに対応するトランザクションがコミットされ得るように、配信ステータスを通知されてもよい。

ステータス判断部２３８は、メッセージの通信のステータスについての情報を判断できる。メッセージのメッセージ識別子に基づいて、ステータス判断部２３８は、データストア１６０からメッセージに関連付けられた配信ステータス１６４を識別し、検索することができる。

配信ステータスインターフェイスモジュール２３２は、呼出されるとメッセージのための配信ステータスに関連する情報を通信マネージャ１３０に提供できる１つ以上の呼出し可能インターフェイス２３４（たとえば、アプリケーションプログラミングインターフェイス）を含み得る。配信ステータスインターフェイスモジュール２３２は、通信マネージャ１３０の１つ以上のモジュールを実行でき、および／または、呼出し可能インターフェイス２３４が呼出されると実行される１つ以上のファンクションを実現できる。たとえば、呼出し可能インターフェイス２３４が呼出されると、呼出し可能インターフェイス２３４によって識別されたメッセージのための配信ステータスを格納するために、メッセージマネージャ２３６が実行され得る。呼出し可能インターフェイス２３４は、配信ステータスを示す情報（たとえば、真値または偽値）を特定するパラメータを受入れることができる。パラメータは、配信の受理確認が受信されたか否か、配信が失敗したか否か、またはメッセージを配信する試みの数といった、配信ステータスについての情報を含み得る。

いくつかの実施形態では、呼出し可能インターフェイス２３４のインスタンスが、ある特定のメッセージとの関連付けのために作成され得る。呼出し可能インターフェイス２３４のインスタンスは、通信マネージャ１３０がメッセージのステータスについて通知され得るように、メッセージのステータスを示すパラメータを用いて呼出され得る。いくつかの実施形態では、呼出し可能インターフェイス２３４は、呼出し可能インターフェイス２３４を介して提供されるステータスが、トランザクションに対応するメッセージに関連付けられ得るように、メッセージに関連付けられたトランザクションのために呼出され得る。たとえば、ソースサーバコンピュータ１４０は、呼出し可能インターフェイス２３４のインスタンスを作成でき、それは仲介サービスシステム１２０に渡され得る。仲介サービスシステム１２０は、メッセージのための配信ステータスについての通知を宛先サーバコンピュータ１５０から受信すると、呼出し可能インターフェイス２３４を呼出すことができる。いくつかの実施形態では、メッセージのステータスについての情報を通信マネージャ１３０に提供するために、呼出し可能インターフェイス２３４のインスタンスは、宛先サーバコンピュータ１５０に渡され、宛先サーバコンピュータ１５０によって呼出され得る。

図１および２に示す仲介通信ハンドラ１１０は、ソース（たとえば、ソース１０２）および宛先（たとえば、ターゲットサービス１０６）が、より確実に通信を交換できるようにし得る。仲介サービスシステム（たとえば、仲介サービスシステム１２０）および１つ以上のサーバコンピュータ（たとえば、サーバコンピュータ１４０、１５０）と通信できる通信マネージャ（たとえば、通信マネージャ１３０）を実現することにより、メッセージの配信ステータスを効果的に管理することができる。配信ステータスは、過剰送信および／または通信殺到を防止できないまでも減少できるように、複製メッセージが検出されることを可能にし得る。呼出し可能インターフェイスにより、ソースとターゲットサービスとの間の通信を容易にするさまざまな当事者は、再送信が必要か否かを判断するためにメッセージの配信ステータスを確実に判断できるようになる。メッセージ識別子および通信シーケンスに関連付けられた識別子にメッセージの配信を関連付けることにより、仲介通信ハンドラ１１０は、配信の信頼性のためのさらなる保証を提供できる。メッセージが受入れられ配信される際に仲介通信ハンドラ１１０が引き続き通知されることを可能にするインターフェイスを有することにより、仲介主体は、メッセージの配信のために通信のソースシーケンスを通信の宛先シーケンスとリンクさせることによって、メッセージのための通信の信頼性を保証することができる。

仲介通信ハンドラによって実現され得るプロセスの例をこれから説明する。図３は、この発明の一実施形態に従った、ソースと１つ以上のターゲットサービスとの間の通信を管理するためのプロセス３００を示すフローチャートを示す。

プロセス３００は、ブロック３０５で、ソースから、ターゲットサービスに送信すべきメッセージを受信することによって開始可能である。たとえば、仲介通信ハンドラは、クライアント装置から、ターゲットサービスに送信すべきメッセージを受信できる。クライアント装置上で動作するローンアプリケーションの例では、ローンアプリケーションは、宛先（たとえば、あるアプリケーションによって提供されるローンサービス）に送信すべきメッセージを仲介通信ハンドラに送信できる。そのメッセージは、ローンサービスによって提供されるサービス（たとえば、ローン計算）の要求を示すことができる。ソースによって通信されるメッセージは、ソースによってサポートされるメッセージ通信プロトコル（たとえば、ＷＳ−ＲＭプロトコル）と一致するフォーマットに従って構成され得る。メッセージ通信プロトコルは、宛先によってサポートされるメッセージ通信プロトコルに類似している場合があり、またはそれとは異なっている場合がある。いくつかの実施形態では、メッセージは、ソースによってサポートされるメッセージ通信プロトコルによってサポートされるサービス品質パラメータを示すことができる。

ブロック３１０で、プロセス３００は、メッセージに関連付けられたメッセージ識別子を判断してもよい。たとえば、受信されたメッセージがＷＳ−ＲＭプロトコルに従ってフォーマット化される場合、仲介通信ハンドラは、メッセージのためのメッセージ識別子を判断できる。メッセージ識別子は、メッセージのメッセージシーケンス番号および／または識別子に基づいて判断可能であり、それらの組合せは、ターゲットサービスへのメッセージをユニークに識別できる。別の例では、仲介通信ハンドラは、メッセージをユニークに識別するメッセージのデジタル署名に基づいて、メッセージのためのメッセージ識別子を判断できる。いくつかの実施形態では、デジタル署名は、整合する署名を有することに基づいて複製メッセージが検出されることを可能にしつつ、あるユニークメッセージを別のものと区別するために使用可能である。

ブロック３１５で、メッセージを受信すると、プロセス３００は、メッセージが以前にターゲットサービスに送信されたか否かを判断してもよい。たとえば、プロセス３００は、メッセージが、仲介通信ハンドラによって受信された以前のメッセージの複製であるか否かを判断できる。いくつかの実施形態では、仲介通信ハンドラにアクセス可能なストレージに、判断されたメッセージ識別子に関連付けて格納された識別子の存在は、複製メッセージが以前に受信されたこと、および、仲介通信ハンドラが以前にターゲットサービスにメッセージを送信しようとしたことを示すことができる。メッセージが以前にターゲットサービスに送信されていないと判断すると、プロセス３００は、ターゲットサービスへのメッセージの配信に関連する１つ以上のアクションを行なうためにブロック３２０に進む。メッセージが以前に送信されたと判断すると、プロセス３００は、ターゲットサービスへのメッセージの配信ステータスを判断するためにブロック３３０に進む。

ブロック３２０で、プロセス３００は、ターゲットサービスへのメッセージの配信に関連する１つ以上のアクションを行なう。たとえば、アクションは、ソースのためにターゲットサービスにメッセージを送信することを含んでいてもよい。ブロック３２５で、プロセス３００は、メッセージのためのメッセージ識別子を格納してもよい。たとえば、仲介通信ハンドラは、メッセージのフォーマットを使用して、メッセージのシーケンス番号および識別子を判断してもよい。フォーマットは、通信プロトコルに基づいている。メッセージ識別子に関連付けられるべき識別子は、メッセージのシーケンス番号および／または識別子に基づいて生成されてもよい。識別子は、データストアに格納されてもよい。いくつかの実施形態では、識別子は、メッセージの配信ステータスに関連付けて格納され得る。メッセージのメッセージ識別子に関連付けられた識別子の存在は、メッセージがターゲットサービスへの配信のために送信されたと判断するために使用されてもよい。

ブロック３３０で、プロセス３００は、ターゲットサービスへのメッセージの配信に関するメッセージの配信ステータスを判断する。たとえば、仲介通信ハンドラは、メッセージのためのメッセージ識別子に関連付けて格納された識別子に関連付けられた、配信ステータスなどの情報をつきとめ、検索することができる。ある実施形態では、プロセス３００は、メッセージの配信ステータスを周期的にまたは断続的に判断できる。プロセス３００は、メッセージを送信した直後に、またはメッセージが送信された後のある期間に周期的に、ステータスを判断できる。

ブロック３３５で、プロセス３００は、メッセージの配信についての受理確認が受信されたか否かを判断するために、メッセージのステータスを使用できる。メッセージの送信に続くある期間の後で、プロセス３００は、ターゲットサービスから受理確認が受信されたか否かを判断するために、ステータスを使用できる。いくつかの実施形態では、ターゲットサービスからの受理確認の受信は、メッセージの配信を示すことができる。

受理確認が受信されたと判断すると、プロセス３００は、生成された識別子に関連付けて配信のステータスを格納するために、ブロック３４５に進むことができる。受理確認が受信されていないと判断すると、プロセス３００はブロック３４０に進むことができ、そこでそれは、ターゲットサービスへのメッセージの配信に関連する１つ以上のアクションを行なうことができる。たとえば、メッセージの配信に関連するアクションは、ターゲットサービスにメッセージを再送することによって、ターゲットサービスへのメッセージの配信を再試行しようとすることを含み得る。いくつかの実施形態では、仲介通信ハンドラは、ターゲットサービスのために、仲介通信ハンドラに含まれるかまたはそれにより実現されるネットワーク通信サーバに配信ステータスを通信してもよい。ネットワーク通信サーバは、ターゲットサービスによってサポートされる通信プロトコルに関連付けられたサービス品質規格に基づいて、メッセージのさらなる通信を取扱う態様を判断するために、配信ステータスを使用できる。ブロック３４０でプロセス３００を行なった後、プロセス３００はブロック３５５で終了可能である。

ブロック３４５に戻って、メッセージのための配信ステータスを格納した後で、プロセス３００は、メッセージのための配信ステータスについてソースに通知するために、ブロック３５０に進むことができる。たとえば、仲介通信ハンドラは、メッセージが配信されたことを示すために、情報（たとえば、受理確認メッセージ）をソースに送信できる。プロセス３００はブロック３５５で終了可能である。

ある実施形態では、プロセス３００は、図１の仲介通信ハンドラ１１０のある実施形態によって実現され得る。ソース１０２からメッセージを受信すると、仲介通信ハンドラ１１０は、受信されたメッセージが以前にターゲットサービスに送信されたか否かを判断できる。通信マネージャ１３０は、識別子が、受信されたメッセージのメッセージ識別子に関連付けられているか否かを判断できる。通信マネージャ１３０は、メッセージのために識別子がデータストア１６０に存在するか否かに基づいて、メッセージが以前に送信されたか否かを判断できる。メッセージが以前に送信されなかったと判断すると、通信マネージャ１３０は、仲介サービスシステム１２０を介して、メッセージをターゲットサービス１０６に送信できる。以前にすでに送信されていない場合、通信マネージャ１３０は、メッセージが送信されたことを示すために、メッセージのメッセージ識別子を格納できる。

メッセージが以前に送信されていなかった場合にそれが送信されることを保証することに続き、仲介通信ハンドラ１１０は、周期的に、またはソース１０２からの要求（たとえば、「ＡＣＫ」要求メッセージ）に応答して、メッセージのための配信ステータスを判断できる。受理確認が受信されていないと判断すると、仲介通信ハンドラ１１０は、ターゲットサービス１０６へのメッセージの配信に関連する１つ以上のアクションを行なうことができる。一方、メッセージの配信についての受理確認が受信されている場合、仲介通信ハンドラ１１０は配信ステータスを格納し、配信ステータスについてソースに通知することができる。

プロセス３００は、ソースから受信されるメッセージごとに繰り返し行なわれ得る。それに代えて、またはそれに加えて、ブロック３３０〜３５５は、メッセージが送信された後のある期間中に行なわれ得る。特に、ブロック３３５は、受理確認が実際には受信されていなかったと判断されるまで、周期的にまたは断続的に行なわれ得る。いくつかの実施形態では、受理確認が受信されたか否かについての判断は、仲介通信ハンドラがターゲットサービスへの配信ステータスについて通知されたか否かに基づいて判断され得る。いくつかの実施形態では、配信のステータスは、ある期間の後でターゲットサービスから応答が受信されたか否かに基づいて判断され得る。応答がないことは、受理確認が受信されていないことを示し得る。メッセージの配信についての受理確認に関する判断に基づいて、仲介通信ハンドラは、どのアクションを行なうべきかを判断できる（たとえば、メッセージの配信を待ち続けるか、配信を再試行するか、またはメッセージの配信を待つことをやめるか否かを判断する）。

プロセス３００は例示的であること、ならびに、変形および修正が可能であることが理解されるであろう。シーケンシャルであるとしてプロセス３００について説明されたアクションまたは動作は、並行して実行されてもよく、および／または動作の順序が変更されてもよく、動作は修正され、組合わされ、追加され、または省略されてもよい。

図４は、この発明の一実施形態に従った、ソース４９０（たとえば、ソース１０２）とサービス４７０（たとえば、ターゲットサービス１０６）との間の通信を管理するためのプロセス４００を示すシーケンス図を示す。ある実施形態では、プロセス４００は、仲介通信ハンドラ１１０によって実現され得る。

仲介通信ハンドラ１１０は、サービス４７０に配信されるべきメッセージ（たとえば、メッセージ１０８）の配信ステータスについての信頼できる情報を、メッセージのための配信ステータスに関連する情報を仲介通信ハンドラ１１０に提供し得る１つ以上の呼出し可能インターフェイスおよび／または仲介サービスシステムを使用して、ソース４９０に提供してもよい。配信ステータスは、追加のアクション（たとえば、配信の再試行）が行なわれるべきか否か、または、ソースはメッセージの配信のための配信ステータスについて通知されるべきか否かを判断するために、仲介通信ハンドラ１１０によって使用可能である。配信ステータスはさらに、仲介通信ハンドラ１１０が、宛先への複製メッセージの通信を管理し防止できるようにする。配信ステータスは、宛先サーバコンピュータが、サービス４７０によってサポートされる通信プロトコルに関連付けられたＱｏＳパラメータが満たされているか否かを判断できるようにしてもよい。

例示の目的のため、図４に提示する例を、通信プロトコル、たとえばＷＳ−ＲＭプロトコルを使用した、ソース４９０とサービス４７０との間のメッセージ通信に関して説明する。ソース４９０は、リライアブルメッセージングソース（ＲＭＳ）として作用してもよい。サービス４７０は、リライアブルメッセージング宛先（ＲＭＤ）（たとえば、ウェブサービス・リライアブルメッセージング宛先）として作用してもよい。クライアントリソースマネージャ（たとえば、「Ｃ／ＲＭ」）４５５は、ソースサーバコンピュータ（たとえば、ソースサーバコンピュータ１４０）として動作してもよい。宛先リソースマネージャ（たとえば、「Ｓ／ＲＭ」）４０５は、宛先サーバコンピュータ（たとえば、宛先サーバコンピュータ１５０）として動作してもよい。ＲＭＳ４９０からＲＭＤ４７０へのメッセージ（たとえば、メッセージ４０２）の通信は、仲介サービスシステム、たとえば企業サービスバス（enterprise service bus：ＥＳＢ）４８０を介して生じてもよい。プロセス４００が以下に説明され、ＲＭＳ４９０からＲＭＤ４７０へのメッセージの通信に関するさらなる詳細を提供する。

ある実施形態では、ＷＳ−ＲＭプロトコルなどの通信プロトコルは、信頼できるメッセージ通信のためのサービス品質（quality of service：ＱｏＳ）パラメータを規定する１つ以上のパラメータをサポートしてもよい。ＱｏＳパラメータは、下記のうちの１つ以上を含んでいてもよい：
・少なくとも１回（“AtLeastOnce”）−各メッセージは宛先に少なくとも１回配信される。メッセージを配信できない場合、ＲＭＳおよび／またはＲＭＤによってエラーが生じ得る。メッセージは、宛先に２回以上配信される場合がある（すなわち、宛先は複製メッセージを受信する場合がある）；
・せいぜい１回（“AtMostOnce”）−各メッセージは宛先にせいぜい１回配信される。宛先は、複製メッセージを受信しない場合がある；
・まさしく１回（“ExactlyOnce”）−各メッセージは宛先にまさしく１回配信される。メッセージを配信できない場合、ＲＭＳおよび／またはＲＭＤによってエラーが生じ得る。宛先は、複製メッセージを受信しない場合がある；
・順番に（“InOrder”）−メッセージは、それらがソースからＲＭＳに送信される順序で、ＲＭＤから宛先に配信されるであろう。この保証は、上述の保証のうちのいずれかと組合わされ得る。

プロセス４００は、Ｓ／ＲＭ４０５が、サービス４７０によって提供されるサービスのために、ソース４９０からメッセージ４０２を受信することによって開始可能である。メッセージ４０２は、仲介サービスシステム、たとえば企業サービスバス（ＥＳＢ）４８０を介して受信され得る。ＥＳＢ４８０は、仲介サービスシステム１２０に含まれ、またはそれにより実現されてもよい。メッセージ４０２を送信する前に、ソース４９０は、シーケンスを作成する（たとえば“CREATE_SEQUENCE”）ようにＳ／ＲＭ４０５に要求してもよい。シーケンスは、ソース４９０とＳ／ＲＭ４０５との間の信頼できる通信を保証するために作成される。Ｓ／ＲＭ４０５は、ソース４９０とＳ／ＲＭ４０５との間の通信のシーケンスのためのシーケンス番号を割当ててもよい。メッセージ４０２は、Ｓ／ＲＭ４０５によって作成されたシーケンス番号を使用して送信されてもよい。いくつかの実施形態では、ソース４９０は、メッセージ４０２との関連付けのためのユニーク識別子を判断してもよい。シーケンス番号およびメッセージ識別子は、メッセージ４０２とともに通信されてもよい。

メッセージ４０２を受信すると、プロセス４００は、トランザクションファンクション４１０が行なわれることを要求できる（４０４）。トランザクションファンクション（transaction function：ＴＸ）４１０は、Ｓ／ＲＭ４０５によって行なわれ得る。要求４０４のために、トランザクションが、メッセージ４０２に関連付けられるように作成され得る。トランザクションは、ソース４９０へのサービス４７０の配信を管理するために使用可能である。いくつかの実施形態では、トランザクションは、サービス４７０の要求に対応するユニークメッセージ（たとえば、メッセージ４０２）ごとに作成され得る。トランザクションのコンテキストは、メッセージに関連付けられたトランザクションがコミットされるまでソース４９０が受理確認を受信しないことを保証するようにメッセージ４０２の配信を管理するために使用されてもよい。

トランザクションの作成後、Ｓ／ＲＭ４０５は、メッセージ４０２についての情報がデータストア４１５に格納されることを要求できる（４０６）。ある実施形態では、Ｓ／ＲＭ４０５は、図１の通信マネージャ１３０（図４に図示せず）に、メッセージ４０２に関連するメタデータ（たとえば、メッセージ識別子）をデータストア１６０に格納するように要求してもよい。メッセージ識別子は、メッセージ４０２をソース４９０によって通信される他のメッセージと区別するユニーク識別子を含み得る。メタデータは、通信マネージャ１３０がサービス４７０への複製メッセージの通信を防止できるようにするために格納され得る。ある実施形態では、データストア４１５は、Ｃ／ＲＭ４５５によって使用されるデータストア４６０とは異なるデータストアに、データを格納できる。データストア４１５およびデータストア４６０は、データストア１６０などの１つ以上のデータストアにおいて実現され、またはそれに含まれ得る。

メッセージ４０２についての情報を格納するためのファンクションを行なった後で、プロセス４００は、Ｓ／ＲＭ４０５が、生成されるべき配信ステータスインターフェイスモジュール２３２の呼出し可能インターフェイス（たとえば、呼出し可能インターフェイス２３４）のインスタンスを作成するようにという要求４０８を送信することを含み得る。ある実施形態では、呼出し可能インターフェイス２３４は、インバウンド受入れ（inbound accepted）インターフェイス４２０を含み得る。インバウンド受入れインターフェイス４２０は、メッセージ４０２が受入れられたか否かを示すステータスを特定するためのパラメータを含み得る。いくつかの実施形態では、メッセージが受入れられているというステータスは、メッセージが配信されたことも示すことができる。インバウンド受入れインターフェイス４２０のインスタンスは、呼出されると、配信ステータスインターフェイスモジュール２３２の実行を起動でき、それは、インバウンド受入れインターフェイス４２０のパラメータによって示されたメッセージ４０２のステータスについての情報を格納するためのインバウンド受入れルーチンを行なうことができる。

プロセス４００は、Ｓ／ＲＭ４０５が、ＥＳＢ４８０の要求ファンクション４２５に要求４１１（たとえば、要求ファンクションを提供すること）を送信することを含み得る。要求４１１は、メッセージ４０２のための同じトランザクションコンテキスト上で呼出され得る。メッセージ４０２のためのトランザクションコンテキストは、Ｓ／ＲＭ４０５がトランザクションに対応するメッセージ４０２の配信についての通知を受信しないことを保証するために使用可能である。要求ファンクション４２５は、サービス４７０に送信すべきメッセージ４０２の処理を行なうようにＥＳＢ４８０を起動するために呼出され得る。要求４１１は、インバウンド受入れインターフェイス４２０のインスタンスを含み得る。ＥＳＢ４８０がメッセージ４０２の配信ステータスについて通知された場合、インバウンド受入れインターフェイス４２０は後で呼出され得る。

要求４１１の受信に応答して、プロセス４００は、ＥＳＢ４８０が、さらなる処理のためのＣ／ＲＭ４５５への通信のためにメッセージ４０２を待ち行列に入れるようにという要求４１２を、ＥＳＢ４８０の処理パイプライン４３５に送信することを含み得る。メッセージ４０２がさらなる処理のためにパイプライン４３５から取出され得ると判断すると、プロセス４００は、ＥＳＢ４８０が、ディスパッチ要求ファンクション４４５を介して要求４１６をＣ／ＲＭ４５５に通信することを含み得る。ディスパッチャ要求ファンクション４４５は、メッセージ（たとえば、メッセージ４０２）を、Ｃ／ＲＭ４５５のアウトバウンド処理チェーンの初めに置く。

いくつかの実施形態では、ディスパッチ要求ファンクションを呼出す前に、プロセス４００は、ＥＳＢ４８０が、配信ステータスインターフェイスモジュール２３２の呼出し可能インターフェイス（たとえば、呼出し可能インターフェイス２３４）のインスタンスを作成するようにという要求４１４を通信することを含み得る。そのような実施形態では、呼出し可能インターフェイス２３４は、アウトバウンド配信（outbound delivered）インターフェイス４４０を含み得る。アウトバウンド配信インターフェイス４４０は、サービス４７０へのメッセージ４０２の「アウトバウンド」配信が受理確認されたか否かを示すステータスを特定するためのパラメータを含み得る。アウトバウンド配信インターフェイス４４０のインスタンスは、呼出されると、アウトバウンド配信インターフェイス４４０のパラメータによって示されたメッセージ４０２のステータスについての情報を格納できるアウトバウンド配信ルーチンを行なうために、配信ステータスインターフェイスモジュール２３２の実行を起動できる。具体的には、ステータスは、メッセージ４０２が配信されたか否かを示すことができる。ステータスは、メッセージ４０２の配信を示すサービス４７０からの受理確認応答の受信に基づき得る。

ある実施形態では、アウトバウンド配信インターフェイス４４０のインスタンスは、ディスパッチャ要求ファンクション４４５への要求４１６に含まれ得る。ディスパッチャ要求ファンクション４４５は、アウトバウンド配信インターフェイス４４０のインスタンスをＣ／ＲＭ４５５に提供できる。Ｃ／ＲＭ４５５は、通信マネージャ１３０のためにメッセージ４０２のアウトバウンド配信のステータスを格納するために、アウトバウンド配信インターフェイス４４０を呼出すことができる。いくつかの実施形態では、メッセージ４０２の複製であるメッセージのためにアウトバウンド配信インターフェイス４４０が以前に呼出された場合、アウトバウンド配信インターフェイス４４０のインスタンスは作成されないかもしれない。

プロセス４００は、Ｃ／ＲＭ４５５が、ディスパッチャ要求ファンクション４４５の要求４１６に応答して、要求４１８を受信することを含み得る。Ｃ／ＲＭ４５５は、メッセージ４０２のためのさらなる処理を行なってから、サービス４７０へのメッセージ４０２の配信の試みに進むことができる。Ｃ／ＲＭ４５５は、ローカルＩＤ取得ルーチン４８５を呼出す（４１９）ことによって、メッセージ４０２のためのユニークメッセージ識別子を判断してもよい。メッセージ識別子は、サービス４７０に複製を送信しないようにするために、Ｃ／ＲＭ４５５によって使用されてもよい。ソース４９０がウェブサービス・リアイアブルメッセージングサポートを有するいくつかの実施形態では、ローカルＩＤ取得ルーチン４８５は、シーケンス番号をメッセージ識別子として使用してもよい。いくつかの実施形態では、ローカルＩＤ取得ルーチン４８５は、ＥＳＢ４８０によって実現されてもよい。ローカルＩＤ取得ルーチン４８５は、メッセージ４０２のデジタル署名に基づいてメッセージ識別子を判断してもよい。メッセージ識別子はまた、メッセージ識別子に関連付けられたメッセージの配信ステータスを追跡するために、通信マネージャ１３０によって使用され得る。通信マネージャ１３０は、ローカルＩＤ取得ルーチンから判断されたメッセージ識別子に基づいて、メッセージ４０２のサービス４７０への配信のために試みられた複製メッセージを識別できる。

Ｃ／ＲＭ４５５は、メッセージ４０２のための配信ステータスを追跡するために、メッセージ４０２に関連付けられるべき別のメッセージ識別子を判断してもよい。プロセス４００は、Ｃ／ＲＭ４５５が、サービス４７０のＲＭＤに、Ｃ／ＲＭ４５５とＲＭＤ４７０との間に新しいシーケンスを作成する（たとえば“CREATE_SEQUENCE）ようにという要求４２２を送信することを含み得る。Ｃ／ＲＭ４５５は、シーケンス番号に基づいて識別子を判断してもよい。サービス４７０は、メッセージのためのシーケンス番号を割当て、そのシーケンス番号をＣ／ＲＭ４５５に返してもよい。メッセージ４０２は、シーケンス番号を使用してサービス４７０に送信されてもよい。Ｃ／ＲＭ４５５は、サービス４７０への配信のための再試行を管理するために、メッセージ４０２のための識別子を維持してもよい。Ｃ／ＲＭ４４５からＲＭＤ４７０へのシーケンスが失敗した場合には、ソース４９０とＳ／ＲＭ４０５との間の信頼性シーケンスも同様に失敗するように、ソース４９０とＳ／ＲＭ４０５との間の通信に関連付けられたシーケンスは、Ｃ／ＲＭ４５５とＲＭＤ４７０との間の通信に関連付けられたシーケンスにリンクされてもよい。

プロセス４００は、Ｃ／ＲＭ４５５が、メッセージ４０２についての情報がデータストア４６０で管理されることを要求する（４２１）ために、通信マネージャ１３０と通信することを含み得る。通信マネージャ１３０は、メッセージ４０２に関連付けられたメッセージ識別子を追跡するために使用されるそのメッセージ識別子を格納できる。サービス４７０がそのプロトコルのためのシーケンス番号およびメッセージ識別子を使用する場合、通信マネージャ１３０によって生成されたメッセージ識別子は、メッセージ４０２のためのシーケンス番号および／またはメッセージ識別子に関連付けられてもよい。生成されたメッセージ識別子をメッセージ４０２のシーケンス番号および／またはメッセージ識別子に関連付けて格納することは、メッセージのための配信ステータスが、複製メッセージが以前に送信されたか否かを判断するために追跡されることを可能にし得る。メッセージ識別子の存在は、メッセージ４０２が、以前に送信されたメッセージの複製であることを示すことができる。いくつかの実施形態では、通信マネージャ１３０は、メッセージ識別子（たとえば、メッセージ識別子１６２）に関連付けて格納された情報を識別するために、データストア４６０をサーチするように要求され得る（４２１）。データストア４６０は、メッセージ４０２のためのメッセージ識別子が格納されているか否かを判断するために、メッセージ４０２のユニークデジタル署名またはメッセージを識別する他の情報を使用してサーチされ得る。メッセージ識別子が見つからない場合、通信マネージャ１３０は、メッセージ識別子をデータストア４６０に格納するよう要求され、その他の場合、メッセージ４０２に関連付けられたデータストア４６０で見つかったメッセージ識別子を使用するよう要求され得る（４２４）。

プロセス４００は、Ｃ／ＲＭ４５５が、トランスポートルーチン４６５を介してサービス４７０に要求４２６を送信することを含み得る。トランスポートルーチン４６５は、ＥＳＢ４８０のインターフェイス（たとえば、出力インターフェイス２２４）として提供され得る。いくつかの実施形態では、トランスポートルーチン４６５は、出力インターフェイス２２４において含まれ、または実現され得る。次に、プロセス４００は、トランスポートルーチン４６５が、要求４２６の受信に応答して、要求４２８をサービス４７０に送信することを含み得る。トランスポートルーチン４６５は、サービス４７０にメッセージ４０２を配信できる。プロセス４００は、Ｃ／ＲＭ４５５が、メッセージ４０２を再配信しようとして、次の要求４２６をサービス４７０に送信することを含み得る。Ｃ／ＲＭ４５５は、メッセージ４０２に関連付けられた以前のメッセージ識別子を、メッセージ４０２のための配信ステータスに関連付けるために使用してもよい。

Ｃ／ＲＭ４５５は、応答４３１がトランスポートルーチン４６５から受信されるまで待つことができる。応答４３１は、メッセージ４０２を配信する試みの結果を示すことができる。応答４３１は、メッセージ４０２がターゲットサービスに配信されたという受理確認（たとえば、「ＡＣＫ」メッセージ」）を示す、または受理確認が受信されなかったことを示す、応答データおよびメタデータを含み得る。プロセス４００は、Ｃ／ＲＭ４５５が、結果などの応答４３１における情報がデータストア４６０に格納されることを要求する（４３３）ために、通信マネージャ１３０と通信することを含み得る。

要求４２８の配信が失敗したと判断すると、プロセス４００は、サービス４７０が、メッセージ４０２を配信するようにという要求４２８が失敗したことを示す応答４３１をＣ／ＲＭ４５５に送信することを含み得る。いくつかの実施形態では、サービス４７０は、配信が失敗したことを示す結果を送信しなくてもよい。Ｃ／ＲＭ４５５は、ある期間の後でトランスポートルーチン４６５を介して別の要求４２６をサービス４７０に送信しようとしてもよい。ある実施形態では、Ｃ／ＲＭ４５５は、配信を再試行するための１つ以上の基準に基づいて、メッセージ４０２の配信を再試行できる。配信のための１つ以上の基準は、サービス４７０によってサポートされる通信プロトコルのためのＱｏＳパラメータに基づき得る。１つ以上の基準は、配信を再試行する試みの数、および配信を再試行するタイムアウト期間を示すことができる。いくつかの実施形態では、トランスポートルーチン４６５は、要求４２６が再試行されるべきか否かを示すパラメータを含み得る。アウトバウンド配信インターフェイス４４０は、サービス４７０へのメッセージ４０２のアウトバウンド配信が行なわれなかった（たとえば、配信されなかった）というステータスを示すパラメータを用いて呼出され得る。

要求４２６は再試行されず、したがって配信されるであろうと判断すると、プロセス４００は、Ｃ／ＲＭ４５５が、アウトバウンド配信インターフェイス４４０のインスタンスが呼出されることを要求する（４３２）ことを含み得る。応答４３１がメッセージ４０２についての配信の受理確認を示すと判断すると、プロセス４００は、Ｃ／ＲＭ４５５が、メッセージ４０２のアウトバウンド配信が行なわれた（たとえば、配信された）というステータスを示すパラメータを用いてアウトバウンド配信インターフェイス４４０のインスタンスが呼出されることを要求する（４３２）ことを含み得る。

プロセス４００は、ＥＳＢ４８０がメッセージ４０２の配信ステータスについて通知されるとインバウンド受入れインターフェイス４２０を呼出すようにという要求４３４を含み得る。たとえば、アウトバウンド配信インターフェイス４４０が呼出されたことに応答して、ＥＳＢ４８０に提供されたインバウンド受入れインターフェイス４２０は、メッセージ４０２に関連付けられた同じトランザクションコンテキストのために、ＥＳＢ４８０によって呼出され得る。インバウンド配信インターフェイス４２０のインスタンスは、配信ステータスがメッセージ４０２に関連付けられ、他のメッセージには関連付けられていないことを保証するためにディスパッチ要求４４５を呼出すために、メッセージ４０２のための同じトランザクションコンテキスト上で呼出され得る。インバウンド受入れインターフェイス４２０は、メッセージ４０２の配信ステータスを示すパラメータを用いて呼出され得る。インバウンド受入れインターフェイス４２０へのパラメータとして特定されたメッセージ４０２の配信ステータスは、アウトバウンド配信インターフェイス４４０によって示された配信ステータスに基づき得る。たとえば、インバウンドインターフェイスファンクション４２０に提供されたステータスは、アウトバウンド配信インターフェイス４４０によって示された配信ステータスに基づいて、メッセージ４０２が配信されたこと、またはメッセージ４０２が配信されなかったことを示すことができる。

インバウンド受入れインターフェイス４２０が呼出されたことに応答して、プロセス４００は、通信マネージャ１３０の配信応答インターフェイスモジュール２３２が、インバウンド受入れインターフェイス４２０のパラメータによって示されたステータスに基づいて配信ステータスを判断するために呼出されることを含み得る。プロセス４００は、配信ステータスインターフェイスマネージャ２３２が、データストア４１５（たとえば、データストア１６０）における配信ステータス１６４を更新するために、メッセージ４０２のための配信ステータスをメッセージマネージャ２３６に提供することを含み得る。いくつかの実施形態では、プロセス４００は、通信マネージャ１３０がデータストア４６０（たとえばデータストア１６０）に配信ステータスを格納することを含み得る。それは、Ｃ／ＲＭ４５５のために維持され得る。

ある実施形態では、メッセージが配信されたことを示す（たとえば“InboundAccepted＝真”）インバウンド配信インターフェイス４２０を呼出すことによって、メッセージ４０２に関連付けられたトランザクションをコミットすることができる。メッセージが配信されなかったことを示す（たとえば“InboundAccepted＝偽”）インバウンド配信インターフェイス４２０を呼出すことによって、メッセージ４０２に関連付けられたトランザクションをロールバックすることができる。

受理確認の受信に基づいてメッセージ４０２が配信されたことを配信ステータスが示すと判断すると、プロセス４００は、通信マネージャ１３０が、データストア４１５に、メッセージ４０２が配信されたことを示すように更新されるよう要求する（４３８）ことを含み得る。プロセス４００は、メッセージ４０２の配信について受理確認が受信された場合、通信マネージャ１３０が、メッセージ４０２に関連付けられたトランザクションがコミットされることを要求する（４３６）ことを含み得る。トランザクションをコミットすることにより、メッセージ４０２は配信された。いくつかの実施形態では、コミットが成功した場合、プロセス４００は、通信マネージャ１３０が、トランザクションが完了した（たとえば、コミットされた）こと、および／またはメッセージ４０２が配信された（たとえば、受理確認された）ことを示すように、情報をデータストア４１５に格納することを含み得る。コミットが成功しなかった場合、プロセス４００は、通信マネージャ１３０が、メッセージ４０２をコミットできないことを示すようにデータストア４１５を更新することを含み得る。いくつかの実施形態では、メッセージ４０２に関連付けられたトランザクションコンテキストがアクティブであり、かつ、トランザクションのために他の動作が行なわれている場合、トランザクションはコミットされないかもしれない。

メッセージ４０２を配信できないこと、したがってメッセージ４０２について配信の受理確認が受信されなかったことを配信ステータスが示すと判断すると、プロセス４００は、通信マネージャ１３０が、データストア４１５に、メッセージ４０２が配信されていないことを示すように更新されるよう要求する（４３８）ことを含み得る。プロセス４００は、通信マネージャ１３０が、メッセージ４０２のためのトランザクションがロールバックされることを要求する（４３６）ことを含み得る。トランザクションをロールバックすることにより、メッセージ４０２の配信のステータスは、未配信と同様であり得る。いくつかの実施形態では、プロセス４００は、インバウンド受入れインターフェイス４２０が、データストア４１５における情報に、トランザクションは行なわなかった（たとえば、ロールバックされた）こと、およびメッセージ４０２を配信できないことを示すよう要求することを含み得る。

インバウンド受入れインターフェイス４２０が要求４３４に応答して処理を行なった後で、プロセス４００は、インバウンド受入れインターフェイス４２０が、アウトバウンド配信インターフェイス４４０に、ＥＳＢ応答ルーチン４３０への要求４３４の結果４４２を通信することを含み得る。いくつかの実施形態では、インバウンドの受入れられるインターフェイス４２０は、結果４４２がアウトバウンド配信インターフェイス４４０に提供されることを要求できる。

プロセス４００は、通信マネージャ１３０が、結果４４２に基づいて、メッセージ４０２のための通信を終了すべきか否かを判断することを含み得る。メッセージ４０２が配信されたこと、およびメッセージ４０２のためのトランザクションがコミットされたことを結果４４２が示すと判断すると、プロセス４００は、アウトバウンド配信インターフェイス４４０が、ディスパッチ要求ファンクション４４５に、メッセージ４０２のためのＳ／ＲＭ４０５とＣ／ＲＭ４５５との間の通信を終了する（たとえば、通信シーケンスを終了する）よう要求する（４４４）ことを含み得る。通信を終了することにより、通信マネージャ１３０は、メッセージ４０２に関連付けて格納されたメッセージ識別子を含む、メッセージ４０２についての情報を削除できる。その結果、メッセージ４０２の配信ステータスはもはや、メッセージ４０２に関連付けて維持されないかもしれない。

しかしながら、メッセージ４０２が配信されなかったこと、および／またはメッセージ４０２のためのトランザクションがコミットされなかったことを結果４４２が示すと判断すると、プロセス４００は、アウトバウンド配信インターフェイス４４０が、Ｓ／ＲＭ４０５とＣ／ＲＭ４５５との間の通信の終了を防止することを含み得る。Ｓ／ＲＭ４０５とＣ／ＲＭ４５５との間の通信が終了されない場合、メッセージ識別子４０２を含む、メッセージについての情報は、メッセージ４０２の配信ステータスが引き続きメッセージ識別子に関連付けられるように、データストア４６０に格納されたままであってもよい。データストア４６０にメッセージ識別子を維持することにより、Ｃ／ＲＭ４５５は、通信マネージャ１３０に、メッセージ４０２のための配信ステータスを判断するよう要求できる。Ｓ／ＲＭ４０５とＣ／ＲＭ４５５との間の通信シーケンスが終了すると、メッセージ４０２の配信ステータスを管理するために通信マネージャ１３０によって生成されたメッセージ識別子は、データストア４６０、４１５から除去され得る。ある実施形態では、ある期間の間通信シーケンスが存在した場合、メッセージ識別子は、メッセージ４０２に関連付けてストレージから除去され得る。いくつかの実施形態では、メッセージ識別子は、Ｓ／ＲＭ４０５とＣ／ＲＭ４５５との間の通信シーケンスの終了のために、ある期間に関連付けて格納され得る。通信シーケンスが終了するようにＱｏＳ基準を上回った場合、メッセージ識別子は除去され得る。

プロセス４００は、Ｃ／ＲＭ４５５が、結果４３１からの応答データを通信するようにという要求４４６を、ＥＳＢ４８０の処理パイプライン４３５に送信することを含み得る。ＥＳＢ４８０の処理パイプライン４３５は、ＥＳＢ応答ルーチン４３０に、ソース４９０への配信のために応答データをＳ／ＲＭ４０５に配信するように要求してもよい（４４８）。メッセージの配信ステータスは、要求４４８に含まれていてもよい。Ｓ／ＲＭ４０５は、結果４３１からの応答データの要求４５２をソース４９０に通信してもよい。

図４に示すプロセス４００の例では、メッセージ識別子（たとえば、メッセージのシーケンス番号および識別子）に関連付けて管理される配信ステータスは、メッセージの配信を管理するために使用可能である。仲介通信ハンドラにおける通信マネージャの実現は、配信ステータスが変化する際に、通信システムのさまざまなコンポーネント（たとえば、Ｃ／ＲＭ、Ｓ／ＲＭ、ターゲットサービスＲＭＤ、およびＥＳＢ）が、呼出し可能インターフェイスを介して配信ステータスを共有することを可能にし得る。さまざまなコンポーネントは、送信元（たとえば、ソース）が配信について引き続き通知され得るように、かつ、配信のための再試行の試みが適正に管理され得るように、仲介通信ハンドラによって引き続き通知され得る。いくつかの実施形態では、メッセージの同じシーケンス番号および識別子を使用して配信のための複製メッセージを送信することにより、ターゲットサービスをサポートしているサーバコンピュータは、メッセージ４０２のためにサポートされるプロトコルに従ってサービス品質パラメータを維持することができる。

図５は、実施形態のうちの１つを実現するための分散型システム５００の簡略図を示す。分散型システム５００は、図１の通信システム１００および／または図２の通信システム２００を実現できる。分散型システム５００は、図３のプロセス３００および／または図４のプロセス４００を実現できる。図示された実施形態では、分散型システム５００は１つ以上のクライアントコンピューティング装置５０２、５０４、５０６、および５０８を含み、それらは、１つ以上のネットワーク５１０を通して、ウェブブラウザ、専用クライアント（たとえば、オラクル・フォームズ（Oracle Forms））などのクライアントアプリケーションを実行し、動作させるように構成される。ある実施形態では、１つ以上のクライアントコンピューティング装置５０２〜５０８は、図１のソース１０２および／または図１のターゲットサービス１０４、１０６を含み得る。サーバ５１２は、ネットワーク５１０を介して、リモートクライアントコンピューティング装置５０２、５０４、５０６、および５０８と通信可能に結合されてもよい。サーバ５１２は、図１のソースサーバコンピュータ１４０および／または図１の宛先サーバコンピュータ１５０を含み得る。

さまざまな実施形態では、サーバ５１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを動かすように適合されてもよい。サービスまたはソフトウェアアプリケーションは、非仮想環境および仮想環境を含み得る。仮想環境は、仮想のイベント、トレードショー、シミュレータ、教室、ショッピング交換、および企業に使用されるものを、２次元または３次元（３Ｄ）表現、ページベースの論理環境などであろうとなかろうと含み得る。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスまたはクラウドサービスとして、もしくはソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）モデルの下で、クライアントコンピューティング装置５０２、５０４、５０６、および／または５０８のユーザに提供されてもよい。クライアントコンピューティング装置５０２、５０４、５０６、および／または５０８を動作させるユーザは次に、これらのコンポーネントによって提供されるサービスを利用するためにサーバ５１２とやりとりするために、１つ以上のクライアントアプリケーションを利用してもよい。

図５に示す構成では、システム５００のソフトウェアコンポーネント５１８、５２０および５２２は、サーバ５１２上で実現されるとして図示されている。他の実施形態では、システム５００のコンポーネントのうちの１つ以上、および／またはこれらのコンポーネントによって提供されるサービスも、クライアントコンピューティング装置５０２、５０４、５０６、および／または５０８のうちの１つ以上によって実現されてもよい。クライアントコンピューティング装置を動作させるユーザは次に、これらのコンポーネントによって提供されるサービスを使用するために、１つ以上のクライアントアプリケーションを利用してもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。分散型システム５００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるべきである。図５に示す実施形態はこのため、実施形態システムを実現するための分散型システムの一例であり、限定的であるよう意図されてはいない。

クライアントコンピューティング装置５０２、５０４、５０６、および／または５０８は、携帯型ハンドヘルド装置（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブル装置（たとえば、グーグル・グラス（Google Glass）（登録商標）頭部装着型ディスプレイ）、マイクロソフト・ウィンドウズ・モバイル（Microsoft Windows Mobile）（登録商標）などの実行ソフトウェア、および／または、インターネット、電子メール、ショートメッセージサービス（short message service：ＳＭＳ）、ブラックベリー（登録商標）、または他の通信プロトコル対応のｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）、ブラックベリー（登録商標）１０、パームＯＳなどのさまざまなモバイルオペレーティングシステムであってもよい。クライアントコンピューティング装置は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを例として含む、汎用パーソナルコンピュータであり得る。クライアントコンピューティング装置は、たとえばグーグル・クロームＯＳなどのさまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを限定なしで含む、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ（登録商標）様オペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであり得る。それに代えて、またはそれに加えて、クライアントコンピューティング装置５０２、５０４、５０６、および５０８は、ネットワーク５１０を通して通信可能である、シン・クライアント・コンピュータ、インターネット対応ゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャー入力装置を有する、または有さない、マイクロソフトＸｂｏｘゲーミングコンソール）、および／またはパーソナルメッセージング装置といった、任意の他の電子装置であってもよい。

例示的な分散型システム５００は４つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、サーバ５１２とやりとりしてもよい。

分散型システム５００におけるネットワーク５１０は、ＴＣＰ／ＩＰ（transmission control protocol/Internet protocol：伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（systems network architecture：システム・ネットワーク・アーキテクチャ）、ＩＰＸ（Internet packet exchange：インターネットパケット交換）、アップル・トーク（Apple Talk）などを限定なしで含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。単なる例として、ネットワーク５１０は、イーサネット（登録商標）、トークンリングなどに基づくものといったローカルエリアネットワーク（ＬＡＮ）であり得る。ネットワーク５１０は、ワイドエリアネットワークおよびインターネットであり得る。それは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を何ら限定されることなく含む仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、電気電子技術者協会（the Institute of Electrical and Electronics：ＩＥＥＥ）８０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、および／または、これらのおよび／または他のネットワークの任意の組合せを含み得る。

サーバ５１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを例として含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せで構成されてもよい。サーバ５１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化に関わる他のコンピューティングアーキテクチャを含み得る。論理記憶装置の１つ以上のフレキシブルプールは、サーバのための仮想記憶装置を維持するために仮想化され得る。仮想ネットワークは、ソフトウェア定義ネットワーキングを使用して、サーバ５１２によって制御され得る。さまざまな実施形態では、サーバ５１２は、前述の開示で説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ５１２は、この開示の一実施形態に従った上述の処理を行なうためのサーバに対応していてもよい。

サーバ５１２は、上述のもののうちのいずれかを含むオペレーティングシステム、および商業的に入手可能な任意のサーバオペレーティングシステムを実行してもよい。サーバ５１２はまた、さまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行してもよく、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩ（common gateway interface：コモンゲートウエイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース（Sybase）、ＩＢＭ（International Business Machines：インターナショナル・ビジネス・マシーンズ）などから商業的に入手可能なものを限定なしで含む。

いくつかの実現化例では、サーバ５１２は、クライアントコンピューティング装置５０２、５０４、５０６、および５０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析して統合するための１つ以上のアプリケーションを含んでいてもよい。一例として、データフィードおよび／またはイベント更新は、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る、１つ以上の第三者情報源および連続データストリームから受信されたツイッター（登録商標）フィード、ヴェースブック（登録商標）更新またはリアルタイム更新を含んでいてもよいが、それらに限定されない。サーバ５１２はまた、クライアントコンピューティング装置５０２、５０４、５０６、および５０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含んでいてもよい。

分散型システム５００はまた、１つ以上のデータベース５１４および５１６を含んでいてもよい。データベース５１４および５１６は、さまざまな場所に存在していてもよい。例として、データベース５１４および５１６のうちの１つ以上は、サーバ５１２に対してローカルな（および／または、サーバ５１２内にある）非一時的記憶媒体上に存在していてもよい。それに代えて、データベース５１４および５１６は、サーバ５１２からリモートであってもよく、ネットワークベースの接続または専用接続を介してサーバ５１２と通信してもよい。一組の実施形態では、データベース５１４および５１６は、ストレージエリアネットワーク（storage-area network：ＳＡＮ）に存在していてもよい。同様に、サーバ５１２に帰するファンクションを行なうための任意の必要なファイルは適宜、サーバ５１２上にローカルに格納されてもよく、および／またはリモートに格納されてもよい。一組の実施形態では、データベース５１４および５１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、検索するように適合された、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでいてもよい。図１のデータストア１６０は、１つ以上のデータベース５１４および５１６に含まれ得る。

図６は、この開示の一実施形態に従った、実施形態システムの１つ以上のコンポーネントによって提供されるサービスをクラウドサービスとして提供し得るシステム環境６００の１つ以上のコンポーネントの簡略ブロック図である。システム環境６００は、図１の通信システム１００および／または図２の通信システム２００を含むかまたは実現することができる。システム環境６００は、図３のプロセス３００および／または図４のプロセス４００を実現することができる。図示された実施形態では、システム環境６００は、クラウドサービスを提供するクラウドインフラストラクチャシステム６０２とやりとりするためにユーザによって使用され得る１つ以上のクライアントコンピューティング装置６０４、６０６、および６０８を含む。クライアントコンピューティング装置は、クラウドインフラストラクチャシステム６０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム６０２とやりとりするためにクライアントコンピューティング装置のユーザによって使用され得る、ウェブブラウザ、専用クライアントアプリケーション（たとえば、オラクル・フォームズ）、または何らかの他のアプリケーションといったクライアントアプリケーションを動作させるように構成されてもよい。

図６に示すクラウドインフラストラクチャシステム６０２は、図示されたもの以外のコンポーネントを有していてもよい、ということが理解されるべきである。また、図６に示す実施形態は、この発明の一実施形態を取入れ得るクラウドインフラストラクチャシステムの単なる一例である。たとえば、クラウドインフラストラクチャシステム６０２は、通信システム１００および／または通信システム２００の１つ以上の要素を含むかまたは実現することができる。別の例では、ターゲットサービス１０４、１０６は、クラウドインフラストラクチャシステム６０２によって含まれるかまたは実現されてもよい。いくつかの他の実施形態では、クラウドインフラストラクチャシステム６０２は、図６に示すものよりも多い、または少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、もしくは、異なる構成または配置のコンポーネントを有していてもよい。

クライアントコンピューティング装置６０４、６０６、および６０８は、５０２、５０４、５０６、および５０８について上述したものと同様の装置であってもよい。

例示的なシステム環境６００は３つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、クラウドインフラストラクチャシステム６０２とやりとりしてもよい。

ネットワーク６１０は、クライアント６０４、６０６、および６０８とクラウドインフラストラクチャシステム６０２との間のデータの通信および交換を容易にしてもよい。各ネットワークは、ネットワーク５１０について上述したものを含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム６０２は、サーバ５１２について上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスといった、クラウドインフラストラクチャシステムのユーザにとってオンデマンドで利用可能にされる多数のサービスを含んでいてもよい。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザの必要性を満たすために動的にスケール変更され得る。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンス化は、ここに「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムから、インターネットなどの通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを作り上げるサーバおよびシステムは、顧客自身の業務用サーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどのネットワーク通信を介してオンデマンドでアプリケーションをオーダーし、使用してもよい。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってユーザに提供されるかまたは当該技術分野において他の態様で公知であるようなストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、もしくは他のサービスへの、保護されたコンピュータネットワークアクセスを含んでいてもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへの、パスワードで保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク化された開発者による私的使用のための、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。

ある実施形態では、クラウドインフラストラクチャシステム６０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼でき、高可用性で、かつ安全な態様で顧客に配信される、アプリケーション、ミドルウェアおよびデータベースサービス提供物一式を含んでいてもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクル・パブリック・クラウド（Oracle Public Cloud）である。

ビッグデータと呼ばれることもある大量のデータは、多くのレベルで、および異なるスケールで、インフラストラクチャシステムによってホストされ、および／または操作され得る。そのようなデータは、非常に大きくて複雑であるために典型的なデータベース管理ツールまたは従来のデータ処理アプリケーションを使用して処理することが困難であり得るデータセットを含み得る。たとえば、何テラバイトものデータは、パーソナルコンピュータまたはそれらのラックベースの相当物を使用して格納し、検索し、処理することが困難であり得る。そのようなサイズのデータは、大抵の現在のリレーショナルデータベース管理システムおよびデスクトップ統計および視覚化パッケージを使用して作業することが困難であり得る。それらは、許容できる経過時間内にデータを取込み、監督し、管理し、処理するために、よく使用されるソフトウェアツールの構造を超えた、何千ものサーバコンピュータを動かす超並列処理ソフトウェアを必要とし得る。

大きいデータ量を視覚化し、傾向を検出し、および／または他の態様でデータとやりとりするために、極めて大きいデータセットがアナリストおよび研究者によって格納され、操作され得る。そのようなデータを提示し、もしくは、データまたはデータが表わすものに対する外力をシミュレートするために、並列にリンクされた何十、何百、または何千ものプロセッサがデータに対して作用できる。これらのデータセットは、データベースで編成されたもの、あるいは構造化モデルに従ったものといった構造化データ、および／または、非構造化データ（たとえば、電子メール、画像、データｂｌｏｂ（binary large object：バイナリ・ラージ・オブジェクト）、ウェブページ、複雑なイベント処理）を伴い得る。より多い（またはより少ない）コンピューティングリソースを比較的迅速に目標に集中させるように一実施形態の能力を活用することにより、クラウドインフラストラクチャシステムは、ビジネス、政府機関、研究組織、私人、同志の個人または組織のグループ、もしくは他のエンティティからの要望に基づいて、大きいデータセットに対してタスクを実行するためにより良好に利用可能であってもよい。

さまざまな実施形態では、クラウドインフラストラクチャシステム６０２は、クラウドインフラストラクチャシステム６０２によって提供されるサービスに顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。クラウドインフラストラクチャシステム６０２は、異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム６０２がクラウドサービスを販売する組織によって所有され（たとえば、オラクルによって所有され）、サービスが一般大衆または異なる産業企業にとって利用可能とされる、パブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム６０２が単一の組織のためにのみ動作され、その組織内の１つ以上のエンティティのためのサービスを提供し得る、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム６０２、およびクラウドインフラストラクチャシステム６０２によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム６０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリー、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリー、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリー、または、ハイブリッドサービスを含むサービスの他のカテゴリーの下で提供される、１つ以上のサービスを含んでいてもよい。顧客は、クラウドインフラストラクチャシステム６０２によって提供される１つ以上のサービスを、サブスクリプションオーダーを介してオーダーしてもよい。クラウドインフラストラクチャシステム６０２は次に、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を行なう。

いくつかの実施形態では、クラウドインフラストラクチャシステム６０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを限定なしで含んでいてもよい。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上にオンデマンドアプリケーション一式を構築し、配信するための能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得できる。さまざまな異なるＳａａＳサービスが提供されてもよい。例は、大型組織のための販売実績管理、企業統合、およびビジネス柔軟性についてのソリューションを提供するサービスを限定なしで含む。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例は、（オラクルなどの）組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合できるようにするサービスと、プラットフォームによって提供される共有のサービスを活用する新しいアプリケーションを構築するための能力とを限定なしで含んでいてもよい。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得できる。プラットフォームサービスの例は、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクル・データベース・クラウド・サービス（Database Cloud Service：ＤＢＣＳ）などを限定なしで含む。

ＰａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用するとともに、デプロイメントされたサービスを制御することができる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、オラクル・フュージョン・ミドルウェア（Oracle Fusion Middleware）サービス）、およびＪａｖａ（登録商標）クラウドサービスを含んでいてもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形をしたデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発してデプロイメントするためのプラットフォームを提供してもよく、Ｊａｖａ（登録商標）クラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａ（登録商標）アプリケーションをデプロイメントするためのプラットフォームを提供してもよい。

クラウドインフラストラクチャシステムにおいて、さまざまな異なるインフラストラクチャサービスが、ＩａａＳプラットフォームによって提供されてもよい。これらのインフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、ならびに他の基礎的コンピューティングリソースなどの基本コンピューティングリソースの管理および制御を容易にする。

ある実施形態では、クラウドインフラストラクチャシステム６０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース６３０を含んでいてもよい。一実施形態では、インフラストラクチャリソース６３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージ、およびネットワーキングリソースなどのハードウェアの予め統合され最適化された組合せを含んでいてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム６０２におけるリソースは、複数のユーザによって共有され、要望ごとに動的に再割当てされてもよい。加えて、リソースは、異なる時間帯におけるユーザに割当てられてもよい。たとえば、クラウドインフラストラクチャシステム６３０は、第１の時間帯における第１の一組のユーザが、特定数の時間、クラウドインフラストラクチャシステムのリソースを利用することを可能にし、次に、異なる時間帯に位置する別の一組のユーザへの同じリソースの再割当てを可能にして、それによりリソースの利用を最大化してもよい。

ある実施形態では、クラウドインフラストラクチャシステム６０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム６０２によって提供されるサービスによって共有される、多くの内部共有サービス６３２が提供されてもよい。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを限定なしで含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステム６０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供してもよい。一実施形態では、クラウド管理機能性は、クラウドインフラストラクチャシステム６０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでいてもよい。

一実施形態では、図６に示すように、クラウド管理機能性は、オーダー管理モジュール６２０、オーダーオーケストレーションモジュール６２２、オーダープロビジョニングモジュール６２４、オーダー管理および監視モジュール６２６、およびアイデンティティ管理モジュール６２８などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであり得る、１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、もしくはそれらを使用して提供されてもよい。

例示的な動作６３４では、クライアント装置６０４、６０６または６０８などのクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム６０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム６０２によって提供される１つ以上のサービスについてサブスクリプションオーダーを出すことにより、クラウドインフラストラクチャシステム６０２とやりとりしてもよい。ある実施形態では、顧客は、クラウドユーザインターフェイス（User Interface：ＵＩ）であるクラウドＵＩ６１２、クラウドＵＩ６１４および／またはクラウドＵＩ６１６にアクセスし、これらのＵＩを介してサブスクリプションオーダーを出してもよい。顧客がオーダーを出したことに応答してクラウドインフラストラクチャシステム６０２が受信したオーダー情報は、顧客と、顧客が申し込むつもりである、クラウドインフラストラクチャシステム６０２によって提供される１つ以上のサービスとを識別する情報を含んでいてもよい。

顧客によってオーダーが出された後で、オーダー情報がクラウドＵＩ６１２、６１４および／または６１６を介して受信される。

動作６３６で、オーダーがオーダーデータベース６１８に格納される。オーダーデータベース６１８は、クラウドインフラストラクチャシステム６０２によって動作され、他のシステム要素とともに動作される、いくつかのデータベースのうちの１つであり得る。

動作６３８で、オーダー情報はオーダー管理モジュール６２０に転送される。場合によっては、オーダー管理モジュール６２０は、オーダーを検証し、検証後にオーダーを予約するといった、オーダーに関連する請求および課金機能を行なうように構成されてもよい。

動作６４０で、オーダーに関する情報がオーダーオーケストレーションモジュール６２２に通信される。オーダーオーケストレーションモジュール６２２は、顧客によって出されたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするために、オーダー情報を利用してもよい。場合によっては、オーダーオーケストレーションモジュール６２２は、オーダープロビジョニングモジュール６２４のサービスを使用して、申し込まれたサービスをサポートするようにリソースのプロビジョニングをオーケストレーションしてもよい。

ある実施形態では、オーダーオーケストレーションモジュール６２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、オーダーがプロビジョニングに進むべきか否かを判断するためにビジネス論理を適用する。動作６４２で、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール６２２は、リソースを割当ててサブスクリプションオーダーを遂行するために必要とされるリソースを構成するようにという要求を、オーダープロビジョニングモジュール６２４に送信する。オーダープロビジョニングモジュール６２４は、顧客によってオーダーされたサービスのためのリソースの割当てを可能にする。オーダープロビジョニングモジュール６２４は、クラウドインフラストラクチャシステム６０２によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。オーダーオーケストレーションモジュール６２２はこのため、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または予めプロビジョニングされて要求時にのみ割当てられるか否かといった実現詳細から切り離されてもよい。

動作６４４で、サービスおよびリソースが一旦プロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム６０２のオーダープロビジョニングモジュール６２４によって、クライアント装置６０４、６０６および／または６０８上の顧客に送信されてもよい。

動作６４６で、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール６２６によって管理され、追跡されてもよい。場合によっては、オーダー管理および監視モジュール６２６は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップタイムおよびシステムダウンタイムの量といった、サブスクリプションオーダーにおけるサービスについての使用統計を収集するように構成されてもよい。

ある実施形態では、クラウドインフラストラクチャシステム６０２は、アイデンティティ管理モジュール６２８を含んでいてもよい。アイデンティティ管理モジュール６２８は、クラウドインフラストラクチャシステム６０２においてアクセス管理および認証サービスなどのアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール６２８は、クラウドインフラストラクチャシステム６０２によって提供されるサービスを利用したい顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを行なうことが認可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール６２８はまた、各顧客についての記述的情報と、その記述的情報が誰によってどのようにアクセスされ、修正され得るかについての記述的情報との管理を含んでいてもよい。

図７は、この発明のさまざまな実施形態が実現され得る例示的なコンピュータシステム７００を示す。システム７００は、上述のコンピュータシステムのうちのいずれかを実現するために使用されてもよい。たとえば、システム７００では、図１の通信システム１００および図２の通信システム２００の要素のすべてまたはいくつかが含まれ、または実現され得る。システム７００は、図３のプロセス３００または図４のプロセス４００のうちの一方または双方を実現できる。図７に示すように、コンピュータシステム７００は、バスサブシステム７０２を介して多くの周辺サブシステムと通信する処理部７０４を含む。これらの周辺サブシステムは、処理加速部７０６と、Ｉ／Ｏサブシステム７０８と、記憶サブシステム７１８と、通信サブシステム７２４とを含んでいてもよい。記憶サブシステム７１８は、有形のコンピュータ読取可能記憶媒体７２２と、システムメモリ７１０とを含む。

バスサブシステム７０２は、コンピュータシステム７００のさまざまなコンポーネントおよびサブシステムを意図されるように互いに通信させるためのメカニズムを提供する。バスサブシステム７０２は単一のバスとして概略的に図示されているが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。バスサブシステム７０２は、さまざまなバスアーキテクチャのうちのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、ＩＥＥＥ Ｐ１３８６．１規格で製造されるメザニンバスとして実現可能な、産業標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、強化ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準組織（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、および周辺コンポーネント相互接続（Peripheral Component Interconnect：ＰＣＩ）バスを含んでいてもよい。

１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実現され得る処理部７０４は、コンピュータシステム７００の動作を制御する。処理部７０４には、１つ以上のプロセッサが含まれていてもよい。これらのプロセッサは、シングルコアまたはマルチコアプロセッサを含んでいてもよい。ある実施形態では、処理部７０４は、各処理部にシングルまたはマルチコアプロセッサが含まれた、１つ以上の独立した処理部７３２および／または７３４として実現されてもよい。他の実施形態では、処理部７０４はまた、２つのデュアルコアプロセッサをシングルチップへと集積することによって形成されるクアッドコア処理部として実現されてもよい。

さまざまな実施形態では、処理部７０４は、プログラムコードに応答してさまざまなプログラムを実行でき、同時に実行される複数のプログラムまたはプロセスを維持できる。任意の所与の時間において、実行されるべきプログラムコードのうちのいくつかまたはすべては、プロセッサ７０４に、および／または記憶サブシステム７１８にあり得る。好適なプログラミングを通して、プロセッサ７０４は、上述のさまざまな機能性を提供できる。コンピュータシステム７００は加えて処理加速部７０６を含んでいてもよく、それは、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、専用プロセッサなどを含み得る。

Ｉ／Ｏサブシステム７０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含んでいてもよい。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付き音声入力装置、マイクロホン、および他のタイプの入力装置を含んでいてもよい。ユーザインターフェイス入力装置は、たとえば、ジェスチャーおよび口頭コマンドを使用したナチュラルユーザインターフェイスを通して、マイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラなどの入力装置をユーザが制御し、それとやりとりすることを可能にする、マイクロソフトＫｉｎｅｃｔ（登録商標）運動センサなどの運動感知および／またはジェスチャー認識装置を含んでいてもよい。ユーザインターフェイス入力装置はまた、ユーザから目の活動（たとえば、写真撮影中および／またはメニュー選択中の「まばたき」）を検出し、アイジェスチャーを入力装置（たとえば、グーグル・グラス（登録商標））への入力として変換する、グーグル・グラス（登録商標）まばたき検出器などのアイジェスチャー認識装置を含んでいてもよい。加えて、ユーザインターフェイス入力装置は、ユーザが音声コマンドを通して音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）とやりとりできるようにする音声認識検出装置を含んでいてもよい。

ユーザインターフェイス入力装置はまた、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルビデオカメラ、携帯型メディアプレイヤー、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線検出装置などの音声／視覚装置を限定なしで含んでいてもよい。加えて、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン放出断層撮影装置、医療用超音波検査装置などの医療用撮像入力装置を含んでいてもよい。ユーザインターフェイス入力装置はまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力装置を含んでいてもよい。

ユーザインターフェイス出力装置は、表示サブシステム、表示灯、または、音声出力装置などの非視覚的ディスプレイを含んでいてもよい。表示サブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネル装置、投影装置、タッチスクリーンなどであってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム７００からユーザまたは他のコンピュータに情報を出力するためのあらゆる可能なタイプの装置およびメカニズムを含むよう意図されている。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、カーナビ、プロッタ、音声出力装置、およびモデムといった、テキスト、グラフィックスおよび音声／映像情報を視覚的に搬送するさまざまな表示装置を限定なしで含んでいてもよい。

コンピュータシステム７００は、現在システムメモリ７１０内にあるとして図示されたソフトウェア要素を含む記憶サブシステム７１８を含んでいてもよい。システムメモリ７１０は、処理部７０４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されたデータとを格納してもよい。

コンピュータシステム７００の構成およびタイプに依存して、システムメモリ７１０は揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／または不揮発性（読出専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは典型的には、処理部７０４に直ちにアクセス可能であり、および／または処理部７０４によって現在動作および実行中のデータおよび／またはプログラムモジュールを含む。いくつかの実現化例では、システムメモリ７１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでいてもよい。いくつかの実現化例では、起動中などにコンピュータシステム７００内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、典型的にはＲＯＭに格納されていてもよい。限定のためではなく例として、システムメモリ７１０はまた、クライアントアプリケーション、ウェブブラウザ、中央層アプリケーション、リレーショナルデータベース管理システムなど（relational database management system：ＲＤＢＭＳ）を含み得るアプリケーションプログラム７１２と、プログラムデータ７１４と、オペレーティングシステム７１６とを示す。例として、オペレーティングシステム７１６は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョン、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ（登録商標）様オペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステム、グーグル・クローム（登録商標）ＯＳなどを限定なしで含む）、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１０ＯＳ、パーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含んでいてもよい。

記憶サブシステム７１８はまた、いくつかの実施形態の機能性を提供する基本プログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能記憶媒体を提供してもよい。プロセッサによって実行されると上述の機能性を提供するソフトウェア（プログラム、コードモジュール、命令）が、記憶サブシステム７１８に格納されてもよい。これらのソフトウェアモジュールまたは命令は、処理部７０４によって実行されてもよい。記憶サブシステム７１８はまた、この発明に従って使用されるデータを格納するためのリポジトリを提供してもよい。

記憶サブシステム７００はまた、コンピュータ読取可能記憶媒体７２２にさらに接続され得るコンピュータ読取可能記憶媒体リーダ７２０を含んでいてもよい。システムメモリ７１０とともに、およびオプションでシステムメモリ７１０と組合わされて、コンピュータ読取可能記憶媒体７２２は、リモート、ローカル、固定および／またはリムーバブルの記憶装置に加えて、コンピュータ読取可能情報を一時的におよび／またはより永続的に含み、格納し、送信し、検索するための記憶媒体を包括的に表わしてもよい。

コードまたはコードの一部を含むコンピュータ読取可能記憶媒体７２２はまた、情報の格納および／または送信のためのあらゆる方法または技術で実現される揮発性および不揮発性でリムーバブルおよび非リムーバブルの媒体を含むがそれらに限定されない記憶媒体および通信媒体を含む、当該技術分野において公知であるかまたは使用されるあらゆる適切な媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的消去可能プログラマブルＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、もしくは他の有形のコンピュータ読取可能媒体といった、有形の非一時的コンピュータ読取可能記憶媒体を含み得る。特定される場合、これは、所望情報を送信するために使用可能であり、コンピューティングシステム７００によってアクセスされ得るデータ信号、データ送信、または任意の他の媒体といった、非有形の一時的コンピュータ読取可能媒体も含み得る。

例として、コンピュータ読取可能記憶媒体７２２は、非リムーバブルで不揮発性の磁気媒体から読出し、またはそれに書込むハードディスクドライブ、リムーバブルで不揮発性の磁気ディスクから読出し、またはそれに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、およびＢｌｕ−Ｒａｙ（登録商標）ディスク、または他の光学媒体といった、リムーバブルで不揮発性の光ディスクから読出し、またはそれに書込む光ディスクドライブを含んでいてもよい。コンピュータ読取可能記憶媒体７２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digitalＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでいてもよいが、それらに限定されない。コンピュータ読取可能記憶媒体７２２はまた、フラッシュメモリベースのソリッドステートドライブ（solid-state drive：ＳＳＤ）、企業フラッシュドライブ、固体ＲＯＭといった、不揮発性メモリに基づいたＳＳＤ、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤといった、揮発性メモリに基づいたＳＳＤ、および、ＤＲＡＭベースのＳＳＤとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含んでいてもよい。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージをコンピュータシステム７００に提供してもよい。

通信サブシステム７２４は、他のコンピュータシステムおよびネットワークへのインターフェイスを提供する。通信サブシステム７２４は、コンピュータシステム７００とは別のシステムからデータを受信し、別のシステムにデータを送信するためのインターフェイスとして機能する。たとえば、通信サブシステム７２４は、コンピュータシステム７００がインターネットを介して１つ以上の装置に接続できるようにしてもよい。いくつかの実施形態では、通信サブシステム７２４は、（たとえば、３Ｇ、４Ｇ、またはＥＤＧＥ（enhanced data rates for global evolution：エンハンスト・データレート・フォー・グローバル・エボリューション）、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格）、または他の移動通信技術、またはそれらの任意の組合せといった携帯電話技術、高度なデータネットワーク技術を使用した）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコンポーネント、全地球測位システム（global positioning system：ＧＰＳ）受信機コンポーネント、および／または他のコンポーネントを含み得る。いくつかの実施形態では、通信サブシステム７２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット（登録商標））を提供できる。

いくつかの実施形態では、通信サブシステム７２４はまた、コンピュータシステム７００を使用し得る１人以上のユーザのために、構造化および／または非構造化データフィード７２６、イベントストリーム７２８、イベント更新７３０などの形をした入力通信を受信してもよい。

例として、通信サブシステム７２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリー（Rich Site Summary：ＲＳＳ）フィードなどのウェブフィード、および／または１つ以上の第三者情報源からのリアルタイム更新といった、ソーシャルメディアネットワークおよび／または他の通信サービスのユーザからのデータフィード７２６をリアルタイムで受信するように構成されてもよい。

加えて、通信サブシステム７２４はまた、リアルタイムイベントのイベントストリーム７２８および／またはイベント更新７３０を含み得る、明確な終わりがなく本質的に連続的または無限であり得る連続データストリームの形をしたデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含んでいてもよい。

通信サブシステム７２４はまた、構造化および／または非構造化データフィード７２６、イベントストリーム７２８、イベント更新７３０などを、コンピュータシステム７００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム７００は、ハンドヘルド携帯装置（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブル装置（たとえば、グーグル・グラス（登録商標）頭部装着型ディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含む、さまざまなタイプのうちの１つであり得る。

コンピュータおよびネットワークの絶えず変化する性質により、図７に示すコンピュータシステム７００の説明は、単に特定の一例として意図される。図７に示すシステムよりも多い、または少ないコンポーネントを有する他の多くの構成が可能である。たとえば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組合せで実現されてもよい。また、ネットワーク入力／出力装置などの他のコンピューティング装置への接続が採用されてもよい。ここに提供される開示および教示に基づいて、当業者であれば、さまざまな実施形態を実現するための他のやり方および／または方法を理解するであろう。

前述の明細書では、この発明の局面がその特定の実施形態に関して説明されているが、当業者であれば、この発明がそれらに限定されないことを認識するであろう。上述の発明のさまざまな特徴および局面は、個々にまたはともに使用されてもよい。また、実施形態は、明細書のより広範な精神および範囲から逸脱することなく、ここに説明されたものを超えるあらゆる数の環境および用途において利用され得る。したがって、明細書および図面は、限定的ではなく例示的であるとみなされるべきである。

Claims (21)

1. コンピューティングシステムによって、ソースから、ターゲットサービスに送信すべきメッセージを受信するステップと、
   前記コンピューティングシステムによって、前記メッセージに関連付けられたメッセージ識別子を判断するステップと、
   前記コンピューティングシステムによって、前記メッセージ識別子に基づいて、前記メッセージが以前に前記ターゲットサービスに送信されたと判断するステップと、
   前記コンピューティングシステムによって、前記メッセージが前記ターゲットサービスに配信されたか否かを判断するステップと、
   前記メッセージが前記ターゲットサービスに配信されたと判断すると、前記コンピューティングシステムによって、前記ターゲットサービスへの前記メッセージの配信を防止するステップと、
   前記メッセージが前記ターゲットサービスに配信されていないと判断すると、前記ターゲットサービスへの前記メッセージの配信に関連する１つ以上のアクションを行なうステップとを含む、方法。
2. 前記メッセージは、ウェブサービス・リライアブルメッセージング（ＷＳ−ＲＭ）プロトコルに対応するフォーマットを有する、請求項１に記載の方法。
3. 前記メッセージ識別子がデータストアに格納された識別子に関連付けられているか否かを判断するステップをさらに含み、前記メッセージ識別子が前記データストアに格納された識別子に関連付けられていると判断することは、前記メッセージが以前に前記ターゲットサービスに送信されたことを示す、請求項１に記載の方法。
4. 前記メッセージ識別子が識別子に関連付けられていないと判断すると、
   前記メッセージ識別子に関連付けられるべき識別子を生成するステップをさらに含み、前記識別子は前記メッセージからの情報に基づいて生成され、さらに、
   前記識別子を前記データストアに格納するステップを含む、請求項３に記載の方法。
5. 前記メッセージのフォーマットを使用して、前記メッセージのシーケンス番号および識別子を判断するステップをさらに含み、前記フォーマットは通信プロトコルに基づいており、前記メッセージに関連付けられた前記識別子は、前記メッセージの前記シーケンス番号および前記識別子に基づいて生成される、請求項４に記載の方法。
6. 前記メッセージの配信に関連するアクションを行なうステップは、前記メッセージを前記ターゲットサービスに送信するステップを含み、前記メッセージは、前記メッセージのシーケンス番号および識別子を示す情報を用いて前記ターゲットサービスに再配信される、請求項４に記載の方法。
7. 配信ステータスインターフェイスを介して、仲介サービスシステムから、前記メッセージが前記ターゲットサービスに配信されたことを示す情報を受信するステップと、
   前記メッセージが前記ターゲットサービスに配信されたことを示す前記情報を使用して、前記メッセージの配信ステータスを更新するステップと、
   前記メッセージが前記ターゲットサービスに配信されたことを示す前記情報を前記ソースに送信するステップとをさらに含む、請求項１に記載の方法。
8. 前記メッセージが以前に前記ターゲットサービスに送信されていないと判断すると、前記メッセージを前記ターゲットサービスに送信するステップをさらに含む、請求項１に記載の方法。
9. メモリと、
   前記メモリに結合された１つ以上のプロセッサとを含む、システムであって、前記１つ以上のプロセッサは、
   ソースから、ターゲットサービスに送信すべきメッセージを受信し、
   前記メッセージに関連付けられたメッセージ識別子を判断し、
   前記メッセージ識別子に基づいて、前記メッセージが以前に前記ターゲットサービスに送信されたか否かを判断し、
   前記メッセージが前記ターゲットサービスに配信されたか否かを判断し、
   前記メッセージが前記ターゲットサービスに配信されたと判断すると、前記ターゲットサービスへの前記メッセージの配信を防止し、
   前記メッセージが前記ターゲットサービスに配信されていないと判断すると、前記ターゲットサービスへの前記メッセージの配信に関連する１つ以上のアクションを行なうように構成可能である、システム。
10. 前記１つ以上のプロセッサは、前記メッセージ識別子がデータストアに格納された識別子に関連付けられているか否かを判断するように構成可能であり、前記メッセージが前記データストアに格納された識別子に関連付けられていると判断することは、前記メッセージが以前に前記ターゲットサービスに送信されたことを示す、請求項９に記載のシステム。
11. 前記１つ以上のプロセッサはさらに、
    前記メッセージのフォーマットを使用して、前記メッセージのシーケンス番号および識別子を判断するように構成可能であり、前記フォーマットは通信プロトコルに基づいており、さらに、
    前記メッセージ識別子が識別子に関連付けられていないと判断すると、
    前記メッセージ識別子に関連付けられるべき識別子を生成するように構成可能であり、前記識別子は前記メッセージの前記シーケンス番号および前記識別子に基づいて生成され、さらに、
    前記識別子をデータストアに格納するように構成可能である、請求項９に記載のシステム。
12. 前記メッセージの配信に関連するアクションを行なうことは、前記メッセージを前記ターゲットサービスに送信することを含み、前記メッセージは、前記メッセージのシーケンス番号および識別子を示す情報を用いて前記ターゲットサービスに送信される、請求項９に記載のシステム。
13. 前記１つ以上のプロセッサはさらに、
    配信ステータスインターフェイスを介して、仲介サービスシステムから、前記メッセージが前記ターゲットサービスに配信されたことを示す情報を受信し、
    前記メッセージが前記ターゲットサービスに配信されたことを示す前記情報を使用して、前記メッセージの配信ステータスを更新し、
    前記メッセージが前記ターゲットサービスに配信されたことを示す情報を前記ソースに送信するように構成可能である、請求項９に記載のシステム。
14. 前記１つ以上のプロセッサはさらに、前記メッセージが以前に前記ターゲットサービスに送信されていないと判断すると、前記メッセージを前記ターゲットサービスに送信するように構成可能である、請求項９に記載のシステム。
15. １つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに以下のステップを行なわせる命令の組を格納した、コンピュータ読取可能メモリであって、前記以下のステップは、
    ソースから、ターゲットサービスに送信すべきメッセージを受信するステップと、
    前記メッセージに関連付けられたメッセージ識別子を判断するステップと、
    前記メッセージ識別子に基づいて、前記メッセージが以前に前記ターゲットサービスに送信されたと判断するステップと、
    前記メッセージが前記ターゲットサービスに配信されたか否かを判断するステップと、
    前記メッセージが前記ターゲットサービスに配信されたと判断すると、前記ターゲットサービスへの前記メッセージの配信を防止するステップと、
    前記メッセージが前記ターゲットサービスに配信されていないと判断すると、前記ターゲットサービスへの前記メッセージの配信に関連する１つ以上のアクションを行なうステップとを含む、コンピュータ読取可能メモリ。
16. 前記命令の組はさらに、前記１つ以上のプロセッサによって実行されると、前記メッセージが以前に前記ターゲットサービスに送信されていないと判断すると、前記メッセージを前記ターゲットサービスに送信するステップを、前記１つ以上のプロセッサに行なわせる、請求項１５に記載のコンピュータ読取可能メモリ。
17. 前記命令の組はさらに、前記１つ以上のプロセッサによって実行されると、前記メッセージ識別子がデータストアに格納された識別子に関連付けられているか否かを判断するステップを、前記１つ以上のプロセッサに行なわせ、識別されたメッセージが前記データストアに格納されていると判断することは、前記メッセージが以前に前記ターゲットサービスに送信されたことを示す、請求項１５に記載のコンピュータ読取可能メモリ。
18. 前記命令の組はさらに、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに以下のステップを行なわせ、前記以下のステップは、
    配信ステータスインターフェイスを介して、仲介サービスシステムから、前記メッセージが前記ターゲットサービスに配信されたことを示す情報を受信するステップと、
    前記メッセージが前記ターゲットサービスに配信されたことを示す前記情報を使用して、前記メッセージの配信ステータスを更新するステップと、
    前記メッセージが前記ターゲットサービスに配信されたことを示す前記情報を前記ソースに送信するステップとを含む、請求項１５に記載のコンピュータ読取可能メモリ。
19. 前記メッセージの配信に関連するアクションを行なうステップは、前記メッセージを前記ターゲットサービスに送信するステップを含み、前記メッセージは、前記メッセージのシーケンス番号および識別子を示す情報を用いて前記ターゲットサービスに再配信される、請求項１５に記載のコンピュータ読取可能メモリ。
20. 前記命令の組はさらに、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに以下のステップを行なわせ、前記以下のステップは、
    前記メッセージのフォーマットを使用して、前記メッセージのシーケンス番号および識別子を判断するステップを含み、前記フォーマットは通信プロトコルに基づいており、前記以下のステップはさらに、
    前記メッセージ識別子が識別子に関連付けられていないと判断すると、
    前記メッセージ識別子に関連付けられるべき識別子を生成するステップを含み、前記識別子は前記メッセージの前記シーケンス番号および前記識別子に基づいて生成され、さらに、
    前記識別子をデータストアに格納するステップを含む、請求項１５に記載のコンピュータ読取可能メモリ。
21. コンピューティングシステムによって、ソースから、ターゲットサービスに送信すべきメッセージを受信するための手段と、
    前記コンピューティングシステムによって、前記メッセージに関連付けられたメッセージ識別子を判断するための手段と、
    前記コンピューティングシステムによって、前記メッセージ識別子に基づいて、前記メッセージが以前に前記ターゲットサービスに送信されたと判断するための手段と、
    前記コンピューティングシステムによって、前記メッセージが前記ターゲットサービスに配信されたか否かを判断するための手段と、
    前記メッセージが前記ターゲットサービスに配信されたと判断すると、前記コンピューティングシステムによって、前記ターゲットサービスへの前記メッセージの配信を防止するための手段と、
    前記メッセージが前記ターゲットサービスに配信されていないと判断すると、前記ターゲットサービスへの前記メッセージの配信に関連する１つ以上のアクションを行なうための手段とを含む、システム。