(57)【要約】クライアントとデータ源との間の再試行通信を管理するためのシステムが提供される。このシステムは、シーケンシャルに組合せられてクライアント通信の通信経路を形成する複数の論理コンポーネントを含む。上記通信経路におけるコンポーネントのうち少なくとも１つが再試行コンポーネントとして指定される。この再試行コンポーネントは、上記通信経路におけるコンポーネントすべてについて、障害のおきたクライアント通信を再試行する。
2005527899.tif 000002
【特許請求の範囲】
【請求項１】
送信側と、意図された受信側との間の通信を管理するためのシステムであって、
前記送信側から前記意図された受信側への送信側通信をシーケンシャルに転送するように結合された複数の論理コンポーネントと、
前記送信側通信が前記意図された受信側に到達することに失敗した場合に前記意図された受信側への前記送信側通信の送信を再試行するように指定された、前記複数のコンポーネントのうちの再試行コンポーネントと、
前記複数の論理コンポーネントのうちの多数のコンポーネントとを含み、前記多数のコンポーネントは、前記送信側通信に障害が起きたのに応じて、前記送信側通信に障害が起きたという標示を前記再試行コンポーネントへ転送し、自らは前記意図された受信側への前記送信側通信の送信を再試行しない、システム。
【請求項２】
前記送信側はクライアントであり、前記意図された受信側はデータ源であり、前記送信側通信は前記データ源により管理されるデータへの要求である、請求項１に記載の方法。
【請求項３】
前記再試行コンポーネントは、前記送信側から前記意図された受信側への通信経路において前記多数のコンポーネントの前にある、請求項１に記載のシステム。
【請求項４】
前記再試行コンポーネントはサーバマシンのインターフェイスに設けられ、前記インターフェイスは、他の装置から前記サーバマシンへの要求を処理するように構成されたものである、請求項１に記載のシステム。
【請求項５】
前記再試行コンポーネントは、要求に応対して前記要求を前記意図された受信側へ発送するサーバマシン内のサーバ内論理コンポーネントである、請求項１に記載のシステム。
【請求項６】
前記再試行コンポーネントは、前記送信側から前記送信側通信を受取る負荷平衡装置に常駐し、前記複数の論理コンポーネントにおける他のコンポーネントを含むサーバマシンに前記送信側通信を合図する、請求項１に記載のシステム。
【請求項７】
前記複数のコンポーネントのうち少なくとも前記多数のコンポーネントは第１のサーバマシンに常駐し、前記再試行コンポーネントは、第２のサーバマシンにおけるコンポーネントを使用して前記意図された受信側への前記第１の通信の送信を再試行するように構成される、請求項１に記載のシステム。
【請求項８】
前記再試行コンポーネントはトポロジマップにアクセスして前記多数のコンポーネントのうちどれが適正に機能しているかを判断する、請求項１に記載のシステム。
【請求項９】
さらに、前記複数の論理コンポーネントの外部にあるモニタを含み、前記外部モニタは、前記送信側通信が前記意図された受信側に到達するのに失敗したかどうかを検出し、かつ前記送信側通信が前記意図された受信側に到達するのに失敗したときに前記再試行コンポーネントに通信するように構成される、請求項１に記載のシステム。
【請求項１０】
前記再試行コンポーネントは、前記第１の通信を再送信する前に前記第１の通信が再試行可能であるかどうかを判断する、請求項１に記載のシステム。
【請求項１１】
前記再試行コンポーネントは、前記第１の通信が前記意図された受信側にアクセスするのに失敗したことが前記多数の論理コンポーネントのうち１つ以上により標示された場合に前記意図された受信側への前記第１の通信の送信を再試行するように構成された唯一のコンポーネントである、請求項１に記載のシステム。
【請求項１２】
前記再試行コンポーネントは、前記送信側通信の特性に少なくとも部分的に基づいて前記送信側通信が再試行可能であるかどうかを判断する、請求項１０に記載のシステム。
【請求項１３】
前記単一の再試行コンポーネントおよび前記多数のコンポーネントはサーバマシンに常駐し、前記再試行コンポーネントは、前記第１の通信が前記意図された受信側にアクセスするのに失敗したことが前記多数のコンポーネントのうちいずれかにより標示された場合に他のサーバマシンと交信して前記第１の通信を再送信するように構成される、請求項１０に記載のシステム。
【請求項１４】
前記再試行コンポーネントは前記送信側に常駐しており、広域ネットワークにわたり前記多数のコンポーネントと通信する、請求項１に記載のシステム。
【請求項１５】
前記単一の再試行コンポーネントは、前記送信側通信が再試行可能であるかどうかを判断するのに際し、前記第１の通信が安全にされているかどうかを判断する、請求項１０に記載のシステム。
【請求項１６】
前記単一の再試行コンポーネントは、前記送信側通信が再試行可能であるかどうかを判断するのに際して前記送信側の識別情報を識別する、請求項１０に記載のシステム。
【請求項１７】
前記単一の再試行コンポーネントは、前記送信側通信が再試行可能であるかどうかを判断するのに際して前記受信側の識別情報を識別する、請求項１０に記載のシステム。
【請求項１８】
前記単一の再試行コンポーネントはサーバマシンに常駐し、前記単一の再試行コンポーネントは前記サーバマシンにおける少なくとも１つの他の代替コンポーネントを識別し、かつ前記第１の通信を前記少なくとも１つの他の代替コンポーネントへ転送することにより前記意図された受信側への前記送信側通信の送信を再試行する、請求項１に記載のシステム。
【請求項１９】
前記再試行コンポーネントは、前記送信側通信の送信を再試行する前に、当該の送信側通信につき再試行が以前に試みられた回数を判断し、そして、前記回数が再試行についての最大閾値未満である場合にのみ前記送信側通信の送信を再試行する、請求項１に記載のシステム。
【請求項２０】
ネットワーク通信を管理する、コンピュータにより実現される方法であって、
送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するステップを含み、前記第１の通信経路は、前記送信側から前記意図された受信側への通信をシーケンシャルに受取り転送する複数の論理コンポーネントを含み、前記再試行ポイントは前記通信経路の一部を形成し、前記方法はさらに、
前記通信経路のうち前記再試行ポイントを超えた部分において前記送信側通信が前記意図された受信側にアクセスするのに失敗した場合に、前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するステップと、
前記意図された受信側にアクセスする前記送信側通信を前記再試行ポイントからのみ再送信するステップとを含む、方法。
【請求項２１】
前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するステップは、前記送信側通信が前記意図された受信側にアクセスするのに失敗したことが検出されるのに応じて実行される、請求項２０に記載の方法。
【請求項２２】
再試行ポイントを指定するステップは、サーバ内論理コンポーネントを再試行ロジックの実行に指定するステップを含む、請求項２０に記載の方法。
【請求項２３】
送信側要求が３データを検索するのに失敗したことを検出するステップは、前記意図された受信側が利用不可能であることを検出するステップを含む、請求項２０に記載の方法。
【請求項２４】
送信側要求がデータを検索するのに失敗したことを検出するステップは、前記通信経路にある論理コンポーネントに障害が起きたことを検出するステップを含む、請求項２０に記載の方法。
【請求項２５】
さらに、前記送信側要求に障害が起きたことを検出した後に前記送信側要求のための新たな通信経路を選択するステップを含む、請求項２０に記載の方法。
【請求項２６】
新たな通信経路を選択するステップは、前記再試行ポイントにおけるロジックを使用して、前記意図された受信側にアクセスするために利用可能な通信経路を識別するステップを含む、請求項２０に記載の方法。
【請求項２７】
再試行ポイントを指定するステップは、前記通信経路を形成する前記論理コンポーネントの一部を前記再試行ポイントとして選択するステップを含み、前記論理コンポーネントの前記一部は少なくとも２つの論理コンポーネントを含む、請求項２０に記載の方法。
【請求項２８】
論理コンポーネントの一部を選択するステップは、作業負荷を複数のサーバマシン間に分散させる負荷平衡装置から前記論理コンポーネントの前記一部を選択するステップを含み、前記論理コンポーネントの前記一部は前記複数のサーバマシンのうちの１つに常駐する、請求項２７に記載の方法。
【請求項２９】
さらに、前記送信側通信を再送信する前に前記送信側通信が再試行可能であるかどうかを判断するステップを含む、請求項２０に記載の方法。
【請求項３０】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側の識別情報を判別するステップと、前記送信側の前記識別情報が前記送信側通信の再送信を許すように指定されている場合に前記送信側通信を再送信するステップとを含む、請求項２９に記載の方法。
【請求項３１】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記意図された受信側の識別情報を判別するステップと、前記意図された受信側の前記識別情報が前記送信側通信の再送信を許すように指定されている場合に前記送信側通信を再送信するステップとを含む、請求項２９に記載の方法。
【請求項３２】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信が安全にされていた場合に前記送信側通信が再試行不可能であると判断するステップを含む、請求項２９に記載の方法。
【請求項３３】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信につき以前に再試行が試みられた回数を判断するステップと、前記回数が再試行についての最大閾値未満である場合にのみ前記送信側通信を再試行するステップとを含む、請求項２９に記載の方法。
【請求項３４】
ネットワーク通信を処理する、コンピュータにより実現される方法であって、
送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するステップを含み、前記第１の通信経路は、前記送信側から前記意図された受信側への通信をシーケンシャルに受取って転送する複数の論理コンポーネントを含み、前記再試行ポイントは前記通信経路の一部を形成し、前記方法はさらに、
前記通信経路のうち前記再試行ポイントと前記意図された受信側との間の部分において前記送信側通信が前記意図された受信側にアクセスするのに失敗した場合、前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するステップと、
前記送信側通信が再試行可能であるかどうかを判断するステップと、
前記送信側要求が再試行可能であれば、前記再試行ポイントから前記意図された受信側にアクセスするように前記送信側通信を再送信するステップとを含む、方法。
【請求項３５】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信の特性を、前記送信側通信が再試行可能であるかどうかについての対応する標示と照合させるステップを含む、請求項３４に記載の方法。
【請求項３６】
送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するステップは、前記送信側についてのサーバ内論理コンポーネントを前記再試行ポイントして選択するステップを含む、請求項３４に記載の方法。
【請求項３７】
前記意図された受信側にアクセスするように前記送信側要求を再送信するステップは、異なる通信経路を使用して前記意図された受信側へ前記送信側要求を再送信するステップを含む、請求項３４に記載の方法。
【請求項３８】
異なる通信経路を使用するステップは、前記意図された受信側のために前記送信側通信を転送するように前記通信経路の外部にある通信装置にアクセスするステップを含む、請求項３７に記載の方法。
【請求項３９】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信が安全にされているかどうかを判断するステップを含む、請求項３４に記載の方法。
【請求項４０】
前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するステップは、前記再試行ポイントと前記意図された受信側との間にある前記複数のコンポーネントのうちの１つにおいて前記送信側通信が前記意図された受信側にアクセスするのに失敗したかどうかを検出するステップを含む、請求項３４に記載の方法。
【請求項４１】
前記意図された受信側にアクセスするように前記送信側通信を前記再試行ポイントからのみ再送信するステップは、前記再試行ポイントにおける対応する装置の外部にある装置に少なくとも部分的に常駐する新たな通信経路を選択するステップを含む、請求項３４に記載の方法。
【請求項４２】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記新たな通信経路が使用されることになるかどうかを判断するステップを含む、請求項４１に記載の方法。
【請求項４３】
さらに、前記送信側通信が安全であるかどうかを判断するステップと、前記新たな通信経路が前記送信側通信の再送信に使用されることになる場合に前記送信側通信が再試行不可能であると判断するステップとを含む、請求項４２に記載の方法。
【請求項４４】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信が安全にされているかどうかを判断するステップと、前記意図された受信側にアクセスするように前記送信側通信を再送信するステップが前記通信経路の外部にある通信装置を使用するステップを含むかどうかを判断するステップとを含む、請求項３４に記載の方法。
【請求項４５】
前記送信側通信が再試行可能であるかどうかを判断するステップは前記送信側の識別情報を判別するステップを含み、前記意図された受信側にアクセスするように前記送信側通信を再送信するステップは、前記送信側の前記識別情報が前記送信側通信の再送信を許す場合に前記送信側通信を再送信するステップを含む、請求項３４に記載の方法。
【請求項４６】
前記送信側通信が再試行可能であるかどうかを判断するステップは前記意図された受信側の識別情報を判別するステップを含み、前記意図された受信側にアクセスするように前記送信側通信を再送信するステップは、前記意図された受信側の前記識別情報が前記送信側通信の再送信を許す場合に前記送信側通信を再送信するステップを含む、請求項３４に記載の方法。
【請求項４７】
送信側と意図された受信側との間の通信を管理するためのシステムであって、前記システムは、シーケンシャルに組合せられて送信側通信を前記意図された受信側に転送する複数の論理コンポーネントを含む装置において実現され、前記システムは、
データを蓄積するメモリを含み、前記データは、１つ以上の特性を識別し、かつ前記１つ以上の特性を有する通信が再試行可能であるかどうかを標示し、前記システムはさらに、
前記複数の論理コンポーネントのうちの再試行コンポーネントを含み、前記再試行コンポーネントは、前記送信側通信において前記特性を識別し、前記送信側通信が前記意図された受信側にアクセスするのに失敗した場合に前記メモリにアクセスして前記送信側通信の送信を再試行すべきかどうかを判断する、システム。
【請求項４８】
メモリ内に蓄積された前記データは、前記送信側通信が安全にされているかどうかを標示する特性を、前記送信側通信が再試行可能であるかどうかについての対応する標示と照合させることにより、前記送信側通信が再試行可能であるかどうかを標示する、請求項４７に記載のシステム。
【請求項４９】
メモリ内に蓄積された前記データは、前記送信側通信の動作を、前記送信側通信が再試行可能であるかどうかについての対応する標示に照合させることにより、前記送信側通信が再試行可能であるかどうかを標示する、請求項４７に記載のシステム。
【請求項５０】
前記再試行コンポーネントは、前記サーバマシンについて前記意図された受信側にアクセスするのに失敗した選択送信側通信のみを再試行するように構成される、請求項４７に記載のシステム。
【請求項５１】
前記再試行コンポーネントは、前記装置において前記複数の論理コンポーネントを含む１群のコンポーネントからコンポーネントの組合せを選択するように構成され、前記１群のコンポーネントにおける前記コンポーネントのうち少なくともいくつかは前記装置の外部にある、請求項５０に記載のシステム。
【請求項５２】
ネットワーク通信を管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するステップを実行させ、前記第１の通信経路は、前記送信側から前記意図された受信側への通信をシーケンシャルに受取り転送する複数の論理コンポ
ーネントを含み、前記再試行ポイントは前記通信経路の一部を形成し、前記１つ以上のプロセッサにさらに、
前記通信経路のうち前記再試行ポイントを超えた部分において前記送信側通信が前記意図された受信側にアクセスするのに失敗した場合、前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するステップと、
前記再試行ポイントから前記意図された受信側にアクセスするように前記送信側通信を再送信するステップとを実行させる、コンピュータ読取可能媒体。
【請求項５３】
前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するための命令は、前記送信側通信が前記意図された受信側にアクセスするのに失敗したことを検出するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項５４】
再試行ポイントを指定するための命令は、サーバ内論理コンポーネントを使用して前記再試行ロジックを実行するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項５５】
送信側要求がデータを検索するのに失敗したことを検出するための命令は、前記意図された受信側が利用不可能であることを検出するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項５６】
送信側要求がデータを検索するのに失敗したことを検出するための命令は、前記通信経路における論理コンポーネントに障害が起きたことを検出するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項５７】
さらに、前記送信側要求に障害が起きたことを検出した後に前記送信側要求のための新たな通信経路を選択するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項５８】
新たな通信経路を選択するための命令は、前記再試行ポイントにある論理を使用して、前記意図された受信側にアクセスするために利用可能な通信経路を識別するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項５９】
再試行ポイントを指定するための命令は、前記通信経路を形成する前記論理コンポーネントのうち一部を前記再試行ポイントとして選択するための命令を含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項６０】
前記論理コンポーネントの一部を選択するための命令は、複数のサーバマシンのための負荷平衡装置を選択するための命令を含み、前記複数のサーバマシンは、少なくとも、前記再試行ポイントが常駐する第１のサーバマシンと、前記送信側通信を前記意図された受信側に送信するために前記再試行ポイントにアクセスできる別のサーバマシンとを含む、請求項５２に記載のコンピュータ読取可能媒体。
【請求項６１】
さらに、前記送信側通信を再送信する前に、前記送信側通信が再試行可能であるかどうかを判断するための命令を含む、請求項６０に記載のコンピュータ読取可能媒体。
【請求項６２】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記送信側の識別情報を判別するための命令と、前記送信側の前記識別情報が前記送信側通信の再送信を許すように指定されている場合に前記送信側通信を再送信するための命令とを含む、請求項６１に記載のコンピュータ読取可能媒体。
【請求項６３】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記意図された受信側の識別情報を判別するための命令と、前記意図された受信側の前記識別情報が前記送信側通信の再送信を許すように指定されている場合に前記送信側通信を再送信するための命令とを含む、請求項６１に記載のコンピュータ読取可能媒体。
【請求項６４】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記送信側通信が安全にされている場合に前記送信側通信が再試行不可能であると判断するための命令を含む、請求項６１に記載のコンピュータ読取可能媒体。
【請求項６５】
ネットワーク通信を管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能媒体であって、１つ以上のコンピュータによる前記１つ以上の命令シーケンスの実行は、１つ以上のプロセッサに、
送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するステップを実行させ、前記第１の通信経路は、前記送信側から前記意図された受信側への通信をシーケンシャルに受取り転送する複数の論理コンポーネントを含み、前記再試行ポイントは前記通信経路の一部を形成し、前記１つ以上のプロセッサにさらに、
前記通信経路のうち前記再試行ポイントと前記意図された受信側との間の部分において前記送信側通信が前記意図された受信側にアクセスするのに失敗した場合に、前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するステップと、
前記送信側通信が再試行可能であるかどうかを判断するステップと、
前記再試行ポイントからのみ、かつ前記送信側要求が再試行可能である場合にのみ、前記意図された受信側にアクセスするように前記送信側通信を再送信するステップとを実行させる、コンピュータ読取可能媒体。
【請求項６６】
送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するための命令は、前記送信側のためのサーバ内論理コンポーネントを前記再試行ポイントとして選択するための命令を含む、請求項６５に記載のコンピュータ読取可能媒体。
【請求項６７】
前記意図された受信側にアクセスするように前記送信側要求を再送信するための命令は、異なる通信経路を使用して、前記意図された受信側へ前記送信側要求を再送信するための命令を含む、請求項６５に記載のコンピュータ読取可能媒体。
【請求項６８】
異なる通信経路を使用するための命令は、前記意図された受信側のために前記送信側通信を転送するために前記通信経路の外部にある通信装置にアクセスするための命令を含む、請求項６７に記載のコンピュータ読取可能媒体。
【請求項６９】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記送信側通信が安全にされているかどうかを判断するための命令を含む、請求項６５に記載のコンピュータ読取可能媒体。
【請求項７０】
前記送信側通信が前記意図された受信側にアクセスするのに失敗したという標示を前記再試行ポイントに合図するための命令は、前記再試行ポイントと前記意図された受信側との間にある前記複数のコンポーネントのうち１つにおいて前記送信側通信が前記意図された受信側にアクセスするのに失敗したかどうかを検出するための命令を含む、請求項６５に記載のコンピュータ読取可能媒体。
【請求項７１】
前記再試行ポイントからのみ前記意図された受信側にアクセスするように前記送信側通信を再送信するための命令は、前記再試行ポイントが位置する装置の外側にある装置に少
なくとも部分的に常駐する新たな通信経路を選択するための命令を含む、請求項６５に記載のコンピュータ読取可能媒体。
【請求項７２】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記新たな通信経路が使用されることになるかどうかを判断するための命令を含む、請求項７１に記載のコンピュータ読取可能媒体。
【請求項７３】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記送信側通信が安全であるかどうかを判断するための命令と、前記新たな通信経路が前記送信側通信を再送信するのに使用されることになる場合に前記送信側通信が再試行不可能であると判断するための命令とを含む、請求項７２に記載のコンピュータ読取可能媒体。
【請求項７４】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記送信側通信が安全にされているかどうかを判断するための命令を含み、前記意図された受信側にアクセスするように前記送信側通信を再送信するステップは、前記通信経路の外部にある通信装置を使用するステップを含む、請求項７３に記載のコンピュータ読取可能媒体。
【請求項７５】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記送信側の識別情報を判別するための命令を含み、前記意図された受信側にアクセスするように前記送信側通信を再送信するための命令は、前記送信側の前記識別情報が前記送信側通信の再送信を許す場合に前記送信側通信を再送信するための命令を含む、請求項７３に記載のコンピュータ読取可能媒体。
【請求項７６】
前記送信側通信が再試行可能であるかどうかを判断するための命令は、前記意図された受信側の識別情報を判別するための命令を含み、前記意図された受信側にアクセスするように前記送信側通信を再送信するための命令は、前記意図された受信側の識別情報が前記送信側通信の再送信を許す場合に前記送信側通信を再送信するための命令を含む、請求項７３に記載のコンピュータ読取可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
この発明は、ネットワーク経由の通信の管理に関する。特定的に、この発明の各実施例は多層ネットワーク通信システムにおける再試行技術に関する。
【背景技術】
【０００２】
発明の背景
クライアント／サーバ型の通信に対処するネットワークの応用はますます高度なものとなっている。典型的なクライアント／サーバ通信においては、クライアントがサーバに要求を送信し、サーバがクライアントに応答を返す。典型的に、サーバはクライアントの要求に対処する複数の論理コンポーネントからなる。しばしば、クライアントの要求に応じて応答が生成される前に、サーバ内の複数の論理コンポーネントによりクライアントの要求に或る処理がなされる場合がある。
【０００３】
典型的な応用例では、サーバはクライアントの要求に応じてデータ源にアクセスしてクライアントのための情報を検索する。サーバ内の各論理コンポーネントはクライアントの要求に対して或る関数を実行し、それからクライアントの要求を意図されたデータ源または別のコンポーネントへ転送（forward）する。たとえば、サーバ内コンポーネントの１つは、ＪＡＶＡ（登録商標）プログラムであって、或る計算を実行し、選択データを得るためにデータ源に問合せ、さらに或る計算を実行して結果をクライアントに返すものであり得る。サーバ内のその他のコンポーネントは当該の通信にシーケンシャルに対処して、追加の計算を実行したりまたはさらなるデータベース問合せを行なったりできる。
【０００４】
また、サーバ内コンポーネントのうちいくつかはクライアントの要求への応答に対処する場合もある。たとえば、データ源へクライアント要求を転送するのに加え、サーバ内コンポーネントはまたデータ源からクライアントへ応答を転送して返すことがある。上記コンポーネントはまた、クライアントの要求への応答を受取るのに応じて計算を実行しかつ／または追加の問合せを行なうことがある。
【０００５】
いくつかの構成例においては、クライアント通信に対処する装置は負荷平衡装置およびサーバマシンを含む。サーバマシンは負荷平衡装置により一群のサーバマシンから選択される。選択されたサーバマシンおよび負荷平衡装置を用いて、データベースなどのデータ源とクライアントとの間の通信のやり取りがなされる。サーバマシンはクライアント通信を負荷平衡装置から意図されたデータベースへ転送する。データベースは、ウェブサーバや、またはその他クライアント通信のための情報へのアクセスを可能にするマシンに対応し得る。
【０００６】
クライアント通信に対処する複数の装置は一緒になって多数の論理コンポーネントをもたらし、これらがクライアント通信を処理してからデータベースへの転送がなされる。たとえば、論理コンポーネントをサーバマシン内で層状にして、クライアント通信に対処するのに用いられるプロセスを分散させる場合がある。これら層状になったコンポーネントはクライアント通信にシーケンシャルに対処する。その結果、クライアント通信は、異なるマシンに常駐する多数のコンポーネントによりシーケンシャルに処理されてから意図されたデータベースにより受取られる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、クライアント通信がその宛先に到達するのに失敗することがしばしばある。このようなクライアント通信の障害の理由としては、クライアント通信が宛先へ合図されたときにこの宛先がアクセス不可能であるというものがある。クライアント通信の障害の理由としてはさらに、クライアント通信に対処するコンポーネントの１つに障害が生じるというものがある。
【０００８】
多くのクライアント／サーバシステムにおいて、コンポーネントは、障害が検出された時点で障害の起きたクライアント通信を再試行するように構成されている。多層構成においては、障害検出は、クライアント通信に個々に対処する論理コンポーネントすべてへ伝搬される。その結果、１つのサーバマシン内の多数のコンポーネントは障害の起きたクライアント通信の再試行を個々に試みることになる。さらに、多層構成においては、いくつかのコンポーネントは、障害がクライアントへ報告される前に、障害の起きたクライアント通信の送信を多数回再試行することになる。このように障害の起きたクライアント通信の再試行を余分に試みることは、その大部分が無駄なことでしかない。
【０００９】
たとえば、図８に示すように、サーバマシン８００において、第１のアプリケーション８３０、第２のアプリケーション８４０およびサーバアプリケーション８２０を含む通信経路が与えられると仮定する。この通信経路はクライアント８１０を或る宛先へ結合するのに用いられる。この例においてはこの宛先とはデータ源８５０である。再試行コンポーネントが指定されていない従来のシステムにおいては、第２のアプリケーション８４０、第１のアプリケーション８３０およびサーバアプリケーション８２０を用いて、障害の起きたクライアント通信を繰返し再試行する。たとえば障害が生じたのが第２のアプリケーション８４０によるデータ源８５０との交信の試行時である場合、従来のシステムであれば第２のアプリケーション８４０がクライアント通信を再試行し、それからこの障害を第１のアプリケーション８３０に対して標示することになる。そして、第１のアプリケーションは障害の起きたクライアント通信を再試行する。データ源８５０が第２のアプリケーション８４０にとってなお利用可能でなければ、第１のアプリケーション８３０による再試行の後に第２のアプリケーション８４０はもう一度再試行を行なう。第２のアプリケーション８４０が二度再試行を行ない第１のアプリケーション８３０が一度再試行を行なった後にサーバ内コンポーネント８２０に対して当該の障害が通知される。サーバ内コンポーネント８２０が再試行すれば、場合により、第２のアプリケーション８４０はさらに二度再試行し、第１のアプリケーション８３０も再び再試行する。その結果、クライアント８１０はクライアント通信に障害が発生したことを通知されるまでにかなり長い間待たされることになる。
【００１０】
いくつかの既存のシステムにおいては、冗長コンポーネントを伴う環境で障害が発生したとき、この環境は自らを再構成して、以後の要求が別のなお活きているインスタンスへ送信されるようにする。こうすれば要求の再試行は通常首尾よく行なわれるが、別のマシンおよび追加のリソースが必要となる。たとえば、或るデータベースサーバがクラッシュした場合、環境は自らを再構成して以後の要求が別のサーバマシンへ行くようにする。別のサーバマシンの選択は、しばしば元のサーバマシン内の内部コンポーネントに障害が発生した後、負荷平衡装置により行なうことができる。
【００１１】
上記の事情に鑑み、通信経路で生じた障害に応じて通信経路内での多数のコンポーネントが再試行動作を実行する結果として生じる無駄なしに、通信の障害に対処するための技術を提供することが明らかに望ましい。
【課題を解決するための手段】
【００１２】
発明の概要
クライアントとデータ源との間で障害の起きた通信を再試行するための技術が提供され
る。一実施例において、クライアントとデータ源との間の通信経路の一部を形成するサーバマシンは、単一の内部論理コンポーネントにおいて再試行ロジックを含むように構成される。上記サーバマシン内のその他の論理コンポーネントは、再試行を試みるよう指定されたコンポーネントに対し、障害が起きたクライアント通信を報告する。
【００１３】
一実施例に従うと、再試行通信は再試行ロジックが常駐するコンポーネントから管理され得る。再試行ロジックは、いくつかの通信を再試行可能、および他の通信を再試行不可能として選択的に識別するように構成され得る。再試行ロジックはまた、障害の起きたクライアント通信のために新たな通信経路を選択するためのロジックと組合せられる場合もある。
【００１４】
他の実施例では、クライアント通信の経路における別の装置からの再試行技術および再試行通信の管理を組込む。たとえばこの試行技術は負荷平衡装置で実現されたり、またはクライアントで実現されたりする。
【発明を実施するための最良の形態】
【００１５】
添付の図面の各図を参照して、この発明について制限としてでなく例として説明を行なう。図中においては、同様の参照番号は同様の要素を指す。
【００１６】
発明の詳細な説明
データ源にアクセスするための方法および装置が記載される。以下の記載においては、この発明の完全な理解がもたらされるよう説明上多くの具体的な詳細について述べる。しかし、この発明がこれら具体的な詳細なしに実施可能であることは明らかであろう。一方で、周知の構造および装置については、これをブロック図の形で示すことによりこの発明を不必要に不明瞭にすることを避けている。
【００１７】
Ａ．概観
一実施例に従うと、クライアントとデータ源との間の通信経路を形成するシーケンシャルなコンポーネントについて再試行ポイントが指定される。指定された再試行コンポーネントは上記通信経路内のコンポーネントのうち１つにおいて設けられる。クライアントからデータ源への通信がその宛先に到達するのに失敗した場合、上記指定された再試行コンポーネントが、上記宛先への上記クライアント通信の送信を再試行する唯一のコンポーネントである。その他のコンポーネントは宛先への通信の送信を再試行するのではなく、当該の通信が宛先に到達するのに失敗したことを再試行コンポーネントに報知する。
【００１８】
再試行コンポーネントが必要とされる場合としては、クライアント通信に対してその通信経路内のコンポーネントの１つで障害が起きた場合がある。加えて、再試行コンポーネントが必要とされる場合としてはさらに、通信経路内のコンポーネントのうち１つが欠落した場合や、またはその他でクライアント通信の処理に失敗した場合がある。
【００１９】
上記宛先はデータ源であり得る。データ源の例としてはデータベースおよびディレクトリがある。一実施例では、データベースサーバとデータベースとを含むデータベースシステムがこのデータ源を構成し得る。
【００２０】
データ源は、ネットワークサーバ、データデポジトリたとえばディレクトリやデータベース装置、およびその他の記憶装置を含み得る。インターネット用途では、典型的にデータ源５０はウェブサーバまたはウェブ対応型データデポジトリである。
【００２１】
論理コンポーネントは、プログラム、アプリケーション、ソフトウェア、符号化したファームウェアまたはハードウェアを含み、これらはクライアント通信を処理して特定の作
業を実行するように構成されたものである。再試行コンポーネントは、データ源へのクライアント通信の送信を再試行するように構成された論理コンポーネントである。場合により再試行コンポーネントは、データ源へ通信を送信する際、データ源への通信経路の一部を形成する中間コンポーネントへ上記通信を送る。再試行コンポーネントは、元の通信経路またはその等価物を用いてクライアント通信の送信を再試行することができる。これに代えて、再試行コンポーネントは、再試行コンポーネントの外部にある装置において、異なる中間コンポーネントにより形成される別の通信経路を選択するように構成される場合もある。再試行コンポーネントはまた、通信経路で障害が起きたのが元のデータ源であれば、別のデータ源へアクセスを試みてもよい。
【００２２】
再試行コンポーネントの特定の例として、サーバマシンについて入来する要求に応対してこれを発送するサーバマシンにあるサーバ内論理コンポーネントがある。その他の、サーバマシンのためのインターフェイスとして働くコンポーネントもまた、再試行ロジックを実現するのに適している。
【００２３】
一実施例において、複数の論理コンポーネントがシーケンシャルに結合されてクライアントからデータ源への通信を転送する。これらコンポーネントのうち１つが通信経路内のコンポーネントについての再試行コンポーネントとして指定される。再試行コンポーネントは、当該クライアント通信がデータ源へのアクセスに失敗したことが検出された場合にデータ源への第１の通信の送信を再試行する。通信経路内の他のコンポーネントは、当該の通信に障害があったという標示を再試行コンポーネントへ転送するように指定される。通信経路内の１つのコンポーネントに障害が生じると、その前のコンポーネント（すなわち障害の生じたコンポーネントへ要求を転送したコンポーネント）が標示を再試行コンポーネントへ転送する。再試行コンポーネントではないが通信経路内にあるコンポーネントはいずれも上記標示を受取り、同様にこの標示を再試行コンポーネントへ転送することになる。このように、他のコンポーネントの各々が上記標示を再試行コンポーネントへ合図する際にデータ源へ第１の通信を再送信することはない。
【００２４】
通信経路は、シーケンシャルに組合せられてクライアント通信をデータ源へ転送する論理コンポーネントを含む。通信経路内の論理コンポーネントは異なる装置に常駐し得る。再試行ポイントとは、障害の起きたクライアント通信の送信を再試行するためのロジックが常駐する通信経路上の場所である。
【００２５】
再試行ロジックは、障害の起きたクライアント通信をデータ源へ再送信しようと試みる前に、このクライアント通信が再試行可能であるかどうかを判断する場合がある。いくつかの種類の通信または特定の要求は再試行不可能であると指定され得る。これら指定は再試行ロジックに組込まれ得る。
【００２６】
再試行ロジックはまた、障害の起きたクライアント通信を再送信する前に代替的な通信経路を判断する場合がある。この代替的な通信経路は、以前の通信経路内のコンポーネントが常駐する装置の外側に常駐し得る。再試行コンポーネントは、障害の起きた通信を迂回するような任意の経路に沿って上記要求を送信することができる。たとえば、再試行ロジックは、障害が発生した装置の外側に通信を送信する必要があるかどうかを検討する場合がある。この判断を行なう際、再試行コンポーネントはまた、或る特定の要求が再試行可能であるかどうかを判断する場合がある。
【００２７】
別の実施例において、クライアントとデータ源との間の第１の通信経路上に再試行ポイントが指定される。この第１の通信経路は、シーケンシャルにクライアント通信を受取りデータ源へ転送する複数の論理コンポーネントを含む。再試行ポイントは通信経路の一部をなす。クライアント通信の経路内のコンポーネントのうち１つに障害が起きるか、また
はこれが他でその宛先に到達できない場合、この障害が再試行コンポーネントに通知される。
【００２８】
たとえば、一実施例において、クライアント通信が通信経路のうち再試行ポイントとデータ源との間の部分においてデータ源にアクセスすることに失敗した場合、クライアント通信がデータ源へのアクセスに失敗したという標示が、通信経路内の他のコンポーネントのうち１つ以上により再試行ポイントに対して合図される。
【００２９】
一実施例に従うと、再試行ロジックは、クライアント通信が再試行可能であるかどうかについての判断を行なう。再試行ロジックは、クライアントの要求が再試行可能であると判断された場合にのみクライアント通信を再送信することができる。
【００３０】
ここに記載の技術を用いると、システムは単一の指定された再試行コンポーネントを用いて最適な数の再試行を実行することができる。多くの場合、データ源がアクセス可能であるかを判断するには単一回の再試行で十分であろう。これとは対照的に、従来のシステムに対しては、再試行を最適な回数だけ、とりわけただ１回だけ実行するように設定をすることができないが、それは典型的に各々のコンポーネントがクライアント通信をその障害検出時に自動的に再試行するからである。したがって、各々のコンポーネントが再試行を単一回だけ実行するように構成されている場合でも、実際に実行される再試行の回数は、少なくとも再試行を実行するコンポーネントの数と同数であろう。
【００３１】
さらに、この発明についてのいくつかの実施例においては、再試行ロジックはその他の判断および決定を行なうように構成可能である。具体的には、再試行コンポーネントは、或る特定のクライアント通信が再試行可能であるかを判断し、かつ必要に応じ新たな通信経路を識別するように構成され得る。従来のシステムでは、障害の起きたクライアント通信を再試行するコンポーネントが多すぎるため、再試行ロジックの構成は困難でより非効率的になっている。
【００３２】
別の実現例において、再試行コンポーネントはクライアント通信の送信の再試行前に或る判断を行なう。この判断は、当該のクライアント通信について再試行が以前に試みられた回数に対応し得る。再試行コンポーネントは、以前の試行数が再試行についての最大閾値よりも小さい場合にクライアント通信の送信を再試行することができる。
【００３３】
Ｂ．再試行技術を伴うシステムの説明
図１は、クライアントとデータ源との間で合図される通信についての指定された再試行コンポーネントを有するシステム１００を例示する。システム１００内の選択コンポーネントはシーケンシャルに組合せられてクライアント１０とデータ源５０との間に１つ以上の通信経路を形成する。障害の起きたクライアント通信がデータ源５０にアクセスするために再送信されることが可能な、選択された通信経路において指定された場所が、再試行コンポーネントで示される。
【００３４】
説明上、クライアント１０が情報をデータ源５０から要求するという文脈においてシステム１００の説明を行なう。しかしながら、送信元コンピュータから宛先コンピュータへの通信を処理し転送する、および宛先コンピュータから送信元コンピュータへ応答を処理し転送するもっと広い文脈においてシステム１００を採用することもまた可能である。したがって、データ源５０をクライアント通信の宛先として参照しているのは、宛先がたとえばデータベースシステムであるという一応用例を示すためである。
【００３５】
システム１００はクライアント１０とデータ源５０との間に多数の通信経路を有し得る。各々の通信経路はただ１つのコンポーネントを含むことも、または代替的に、任意の１
つのマシンにあって通信経路の一部をなす選択コンポーネントのみを含むこともあり、これは障害の起きたクライアント通信のデータ源への送信を再試行するように構成される。各々の通信経路におけるその他のコンポーネントは、障害の起きたクライアント通信を再試行コンポーネントに送るように構成される。
【００３６】
この発明の実施例には、とりわけ障害の起きたクライアント通信の無駄な再試行が増大することを回避するという利点がある。再試行の実行に１つのコンポーネントを選択することにより、システム１００が実行する再試行の回数は減少する。その結果、クライアント１０へ障害を報告する際の遅延は、再試行ロジックを特に使用しない他システムと比較して大幅に減少させることができ、これは特に、他のシステムであって、最終的に再試行要求を行なうことになるコンポーネントがいくつもあるシステムにおいて見られる最悪の事態と比較した場合に顕著である。
【００３７】
一実施例により得られる別の利点として、再試行ロジックを比較的容易にかつ支援をほとんど受けずにシステム内で実現できることが挙げられる。たとえば、再試行ロジックはサーバマシン内の単一の論理コンポーネントにおいて実現され得る。再試行ロジックが既にある状態で、時間の経過に伴い追加のコンポーネントを環境に対する実質的な構成なしに環境に追加することができる。
【００３８】
加えて、再試行ロジックを１コンポーネントに集中化させることにより再試行通信の管理が容易となる。再試行ロジックは、再試行不可能であると予め指定されたクライアント通信についての再試行を除外するように構成され得る。たとえば、安全（secure）な通信は再試行不可能であると予め指定され得る。要求が再試行可能であるかどうかの判断は要求の種類に基づいて行なうことができる。たとえば、いつなされたかを問わず同じ答を返す要求は再試行可能なものである。
【００３９】
これとは対照的に、その他の従来のシステムにおいては、通信経路内の各々のコンポーネントが障害の起きたクライアント通信を再送信することができてしまう。この結果としてしばしば長期間の遅延が生じるが、それは１つのコンポーネントに障害が生じると、通信経路内の上流にある複数のコンポーネントがクライアント通信の送信を再試行してからやっと以前の通信に障害が生じたことがクライアントに通知される場合があるからである。
【００４０】
図１に示す構成において、システム１００は、負荷平衡装置２５、第１のサーバマシン２０、第２のサーバマシン３０および第３のサーバマシン４０を含む。このように組合わせたサーバマシンは、クライアント通信を宛先へ転送する前にクライアント通信を処理するためのサーバファーム（server farm）に対応し得る。負荷平衡装置２５はこれらサーバマシンのうち１つを選択してクライアント１０とデータ源５０との間の通信経路を形成する。
【００４１】
ネットワーク１５はインターネットなどの広域ネットワークに対応し得る。クライアント１０はネットワーク１５経由で通信を行なうように構成された端末であり得る。クライアント１０およびネットワーク１５の典型的な例には、インターネットにアクセスするウェブブラウザを入れたデスクトップコンピュータが挙げられる。
【００４２】
負荷平衡装置２５は、クライアント１０からデータ源５０へ合図されたクライアント通信を途中で受ける。このクライアント通信はデータの要求に対応し得る。これに代えて、クライアント通信は、データ源５０内におけるデータの書込、既存のデータの変更または既存のデータの消去を要求するものであってもよい。クライアント通信を受取るのに応答して負荷平衡装置２５は、各々のサーバマシンにおける利用可能なリソースに依存してサ
ーバマシンのうち１つを選択してデータ源５０にアクセスさせる。サーバマシン２０，３０，４０の各々は、クライアント通信をシーケンシャルに処理する複数の論理コンポーネントを含む。図１に示す例では、負荷平衡装置２５は第１のサーバマシン２０を選択し、こうしてクライアント１０、負荷平衡装置２５、第１のサーバマシン２０およびデータ源５０によって通信経路１２が形成される。第１のサーバマシン２０内の複数の論理コンポーネント（図２を参照）はシーケンシャルに組合せられて通信経路１２の一部を形成する。
【００４３】
一実施例に従うと、サーバマシン２０，３０，４０の各々は、障害の起きたクライアント通信を当該サーバマシン内の指定された論理コンポーネントから再送信するための再試行ロジックを伴って構成される。図１は再試行コンポーネント２２を含むように構成された第１のサーバマシン２０を例示する。一実現例において、再試行コンポーネント２２は負荷平衡装置２５と直接通信する。たとえば、再試行コンポーネント２２は、負荷平衡装置２５から直接クライアント通信を発送するサーバ内論理コンポーネントにおいて実現され得る。第１のサーバマシン２０内にある複数の他のコンポーネント２４は通信経路１２においては再試行コンポーネント２２の後に位置付けられる。
【００４４】
この構成において、シーケンシャルに組合せられて通信経路１２を形成する第１のサーバマシン２０内の各コンポーネントを振り分けて、このシーケンスにおける第１のコンポーネントが、障害の起きたクライアント通信を再試行する唯一のコンポーネントとなるようにする。障害の起きたクライアント通信について、第１のサーバマシン２０内の他のコンポーネント２４はクライアント通信に障害が生じたという標示を再試行コンポーネント２２に返す。コンポーネント２４は障害の起きたクライアント通信の再送信を試みることはない。
【００４５】
他の実施例においては、再試行ロジックは他のところでクライアント１０とデータ源５０との間の一通信経路に設けられ得る。一実現例においては、再試行コンポーネント２２として働くロジックを含むのは負荷平衡装置２５である。別の実現例では、再試行コンポーネント２２として働くロジックを含むのはクライアント１０である。再試行コンポーネント２２をデータ源５０から遠くへ動かせば、通信経路１２において、障害の起きたクライアント通信をデータ源５０へ送り返すことを再試行し得るコンポーネントの数が減少する。
【００４６】
図２は、再試行ロジックを含むように構成されたサーバマシンの動作を説明するブロック図である。サーバマシンは、サーバマシンへの通信をシーケンシャルに処理する複数の論理コンポーネントを含む。
【００４７】
一実施例において、第１のサーバマシン１２０は、多数の層状にされたコンポーネントを用いてクライアント通信１１２を処理する。これらコンポーネントは、シーケンス１１４に従いクライアント通信１１２を処理するように調整される。シーケンス１１４内のコンポーネントのうち少なくとも１つは再試行ポイント１２２として指定される。
【００４８】
一実施例において、再試行コンポーネント１２２は、シーケンス１１４内で最初にクライアント通信１１２を受取るコンポーネントに対応する。シーケンス１１４内で用いられる他のコンポーネントは第１のアプリケーション１２４および第２のアプリケーション１２６を含む。第１のアプリケーション１２４は再試行ポイント１２２からクライアント通信１１２を受取る。第２のアプリケーションは第１のコンポーネント１２４からクライアント通信１１２を受取る。第２のアプリケーション１２６はクライアント通信１１２をデータ源１５０へ転送する。クライアント通信１１２に障害が起きると、この通信をサーバマシン１２０がデータ源１５０へ再送信しようと試みるのは再試行ポイント１２２におい
てのみである。
【００４９】
一実施例において、再試行ポイント１２２は、再試行ロジックを含むように構成された第１のサーバマシン１２０のサーバ内コンポーネントに対応する。第１のアプリケーション１２４は、データ源１５０からの情報をクライアント１１０に呈示するためのプレゼンテーション層に対応し得る。第２のアプリケーション１２６は事務用ロジックまたはその他特定の種類のネットワーク通信用のアプリケーションに対応し得る。たとえば、ＪＡＶＡ（登録商標）環境においては、第１のアプリケーション１２４は、データ源１５０からのＪＡＶＡ（登録商標）対応データを呈示するためのＪＡＶＡ（登録商標）Servlet Engine（ＪＳＥＲＶＥ）アプリケーションである。第２のアプリケーション１２６は、事務用アプリケーションを完全なものにするためのロジックを担うＥＪＢサーバアプリケーションに対応し得る。各々のアプリケーションはクライアント通信１１２を独立して処理してこれに変更を加え得る。
【００５０】
データ源１５０は逆シーケンス１１６を用いてクライアントに応答１３２を合図して返すことができる。逆シーケンス１１６において、応答１３２はデータ源１５０により第２のアプリケーション１２６へ合図され、これは次にこの応答を第１のアプリケーション１２４へ、そして再試行ポイント１２２へ転送する。それから応答１３２はクライアント１１０へと転送されて戻る。
【００５１】
しばしば、クライアント通信１１２に対処するコンポーネントの１つに障害が生じる。この障害はシーケンス１１４内のいずれかのコンポーネントによって引起こされることも、またはこれに代えてデータ源１５０により引起こされることもある。たとえば、データ源１５０が利用できなくなったり、またはクライアント通信１１２を処理できないほどの渋滞が起きたりする場合がある。このときに第２のアプリケーション１２６がクライアント通信１１２をデータ源１５０に合図しようと試みると障害が生じる。クライアント通信に障害が起きたポイントにあるコンポーネントは、逆シーケンス１１６を用いて、クライアント通信１１２に障害が生じたという標示を合図できる。再試行ポイント１２２は、クライアント通信１１２に障害が生じたという標示を受取るのに応答して、データ源１５０へのクライアント通信１１２の送信を再試行できる。
【００５２】
再試行ポイント１２２は、障害の起きたクライアント通信１１２を再送信する際に再試行シーケンスを実現する。一実施例において、第１の再試行シーケンス１１８はシーケンス１１４と同じコンポーネントおよび機構を含む。別の実施例では、第２の再試行シーケンス１１９が別のサーバマシン１３０のコンポーネントを含む。たとえば、第２の再試行シーケンス１１９においては、再試行ポイント１２２がクライアント通信１１２を第２のサーバマシン１３０の第１のアプリケーション１３４に合図する場合がある。第１のアプリケーション１３４はそのサーバマシンにある第２のアプリケーション１３６へクライアント通信１１２を転送できる。第２のサーバマシン１３０の第１のコンポーネント１３４および第２のコンポーネント１３６は、第１のサーバマシン１２０の第１のアプリケーション１２４および第２のアプリケーション１２６と類似または同一の機能を実行することができる。
【００５３】
さらにまた、サーバマシン１２０がクライアント通信を処理し転送するための多重プロセスを有する場合、他の実施例で再試行ポイント１２２は同じサーバマシン１２０におけるもう１つのプロセスを選択することができる。
【００５４】
一実施例において、各々のコンポーネントはその後続の層にあるコンポーネントのトポロジマップを維持する。そして、各々のコンポーネントは活きている（alive）コンポーネントを選択することができる。再試行ポイント１２２はトポロジマップを用いて、他の
サーバマシンまたは同じマシンにあるコンポーネントの状態を判断できる。再試行ポイント１２２には、トポロジマップからの情報を用いて再試行の送信に好適な経路の選択を行なうための知能が与えられ得る。
【００５５】
さらに別の実施例では他の再試行シーケンスが設けられ得る。たとえば、シーケンス１１４内のコンポーネントのうち１つに障害が起きたことが検出されると、再試行ポイント１２２にあるコンポーネントは、障害の起きたクライアント通信１１２の送信を再試行するときにそのコンポーネントを迂回するような選択を行なうことができる。
【００５６】
サーバ内コンポーネント１２２は再試行シーケンスを選択するロジックを含み得る。たとえば、クライアント通信１１２が安全なものであれば、サーバ内コンポーネント１２２は第１のサーバマシン１２０の内部にある再試行シーケンスのみを用いることができる。これに代えて、サーバ内コンポーネント１２２が再試行コンポーネントを性能に基づいて選択することもある。たとえばサーバ内コンポーネント１２２は、特定のクライアント要求に有用なデータセットを有するキャッシュを用いるために再試行を同じサーバマシンに維持するのがよいと判断する場合がある。
【００５７】
図３は、クライアント３１０とデータ源３５０との間の通信経路内の再試行ロジックを実現するシーケンス図を示す。ここでの通信経路は、負荷平衡装置３１５、サーバ内コンポーネント３２０、第１のアプリケーション３３０、第２のアプリケーション３４０およびデータ源３５０を含む。図３は、サーバ内コンポーネント３２０が再試行ロジックを含むと仮定したものである。加えて、図３においては、再試行ロジックは障害の起きたクライアント通信を再送信するのに新たな通信経路を選択しないと仮定してある。
【００５８】
上述のように、図３のシステムが従来の再試行技術を用いた場合、その結果として無駄な再試行が増大するというおそれがある。ここで図３を用いて、障害の起きたクライアント通信を指定されたコンポーネントから再試行するように構成されたため従来のシステムで生じていた遅延が減少するシステムの動作を説明する。指定された再試行コンポーネント３２０のみを用いることにより、この発明の実施例において再試行の数を単一の試みへと減少させることができる。
【００５９】
ここに記載の技術を用いて、クライアントはクライアント通信３１２を合図し、これはネットワーク経由で負荷平衡装置３１５に引渡される。負荷平衡装置３１５はクライアント通信３１２をサーバ内コンポーネント３２０へ転送する。サーバ内コンポーネント３２０は、負荷平衡装置３１５により選択されたサーバマシンに常駐し得る。クライアント通信３１２は、サーバ内コンポーネント３２０、第１のアプリケーション３３０そして第２のアプリケーション３４０により転送されてデータ源３５０に至る。
【００６０】
たとえば第２のアプリケーション３４０がデータ源３５０へのアクセスに失敗すると、第２のアプリケーション３４０はこの障害についての通知３２２を第１のアプリケーション３３０に対して合図する。第１のアプリケーション３３０はこの通知３２２をサーバ内コンポーネント３２０へ転送する。
【００６１】
第１のアプリケーション３３０から通知３２２を受取るのに応答して、サーバ内コンポーネント３２０は再試行３３２を第１のアプリケーション３３０へ合図することができる。再試行３３２はクライアント通信３１２の内容を含む。再試行３３２は、第１のアプリケーション３３０、第２のアプリケーション３４０それからデータ源３５０へ転送される。
【００６２】
再試行３３２が首尾よく行なわれれば、データ源３５０からの応答３４２がクライアン
ト３１０へ返される。応答３４２は、第２のアプリケーション３４０、第１のアプリケーション３３０、サーバ内コンポーネント３２０、負荷平衡装置３１５およびクライアント３１０からなるシーケンスを用いてクライアント３１０へ転送され得る。
【００６３】
Ｃ．再試行技術の実現の方法
図４は、クライアントをデータ源に結合するのに用いるサーバマシンのための再試行ロジックを実現する方法を説明する。図４に記載するような方法は図２に記載するようなコンポーネントおよびシステムで実現され得る。
【００６４】
ステップ４１０にて、障害の起きたクライアント通信を検出する。この障害の起きたクライアント通信は障害のポイントで検出され得る。たとえば、第２のアプリケーション１２６（図２）がデータ源１５０へのアクセスに失敗した場合、その検出のポイントは第２のアプリケーション１２６においてである。
【００６５】
ステップ４２０にて、障害の起きたクライアント通信を再試行ポイントに報告する。障害を検出したコンポーネントは、通信経路のシーケンスに従って上記障害を隣接するコンポーネントへ報告することができる。１つ以上の中間のコンポーネントが組合せられて、クライアント通信をこの障害を検出したコンポーネントから再試行ポイントへシーケンシャルに転送する。これに代えて、障害の起きたクライアント通信を検出したコンポーネントがこの障害を再試行ポイントに直接報告するように構成されることもあり、こうすれば通信経路における中間コンポーネントを迂回することができる。
【００６６】
ステップ４３０にて、障害の起きたクライアント通信を再試行ポイントからデータ源へ再送信する。このステップは自動的に実行可能であり、クライアント通信に障害が起きたという報告を再試行ポイントが受取るのに応答して行なわれる。
【００６７】
ステップ４４０にて、上記再試行が首尾よく行なわれたかどうかについての判断を行なう。一実施例に従うと、再試行が失敗した場合、この障害がステップ４５０にてクライアントに報告される。したがって、再試行ポイントはただ一度再試行を試みるように構成され得る。
【００６８】
再試行が首尾よく行なわれれば、ステップ４６０にて、データ源からの応答をクライアントに報告する。たとえば、クライアント通信が読出動作に対応する場合、クライアントへの応答には、クライアントのブラウザがクライアントの要求に対応する情報を出力できるようにするデータおよびその他の情報が入っている。
【００６９】
他の再試行技術とは対照的に、図４に記載したような実施例で得られる利点の１つとして、障害の起きたクライアント通信が検出されこれに対する処置がなされるポイントがクライアント通信の経路内の或る選択コンポーネントに局所化されるということがある。再試行アクションが行なわれるポイントは、クライアント通信の通信経路内における多数のコンポーネントにより無差別的に共有されるわけではない。多数の論理コンポーネントが組合せられてクライアント通信の通信経路を形成しながら、一実施例においては障害への処置をとるコンポーネントはただ１つだけとする。このような方法により、何百または何千ものクライアント通信に同時的に対処するシステムにおいてリソースが節約される。
【００７０】
加えて、再試行コンポーネントが、クライアント通信経路において障害が検出されるただ１つの場所である場合がある。これに代えて、障害のポイントがクライアント通信経路内のもう１つのコンポーネントで検出されることもある。さらにまた、障害の起きたクライアント通信が外部のモニタにより検出されてこれを再試行コンポーネントが再試行することもある。
【００７１】
さらに、図４に記載のものなどの方法を実現するよう構成されたシステムはまた、上記再試行ロジックによりその他の機能も実現するよう構成可能な場合もある。他の種類の技術の一例を図５に記載する。
【００７２】
図５は、クライアントをデータ源に結合するためのシステムにおいて再試行ロジックを実現する方法を説明する。ここでは図２での番号を参照しているが、これは一実施例で用いられるコンポーネントの例を示すことを意図したものである。図５に記載の方法は、クライアント１１０とデータ源１５０との間の通信経路を形成する１つ以上の論理コンポーネントにおいて実現され得る。
【００７３】
ステップ５１０にて、クライアント通信に障害の起きたことが、データ源へ当該クライアント通信を伝える論理コンポーネントの１つにより検出される。この論理コンポーネントは、シーケンス１１４において再試行ポイント１２２の後に続くコンポーネントに対応するものであり得る。クライアント通信に障害が起きていると検出される場合として、論理コンポーネントのうち１つがシーケンス１１４におけるすぐ次のコンポーネントへのアクセスに失敗した場合がある。クライアント通信に障害が起きたと検出される場合としてはまた、シーケンス１１４における最後の論理コンポーネントがデータ源１５０へのアクセスに失敗した場合もあり得る。
【００７４】
ステップ５２０にて、クライアント通信に障害が起きたという標示が再試行ポイントに対して合図される。この標示は逆シーケンスに従って再試行コンポーネント１２２へ伝えられる場合がある。これに代えて、障害の起きたクライアント通信を検出しているコンポーネントがその標示を直接再試行ポイント１２２に対して合図する場合もあり、その場合には、クライアント通信が最初に再試行ポイント１２２から転送されたときにこれに対処した中間コンポーネントは迂回される。
【００７５】
ステップ５３０にて、上記障害の起きたクライアント通信が再試行可能であるかどうかについて判断を行なう。一実施例では、この判断は再試行ポイント１２２で行なわれる。たとえば再試行ポイント１２２は、サーバマシン１２０内の１サーバ内コンポーネントであって、障害の起きたクライアント通信が再試行可能であるかを判断するための知能を含む再試行ロジックを伴って構成されたサーバ内コンポーネントに対応し得る。
【００７６】
クライアント通信が再試行可能であるかを識別するために、再試行ポイント１２２は当該クライアント通信についての情報を識別することがある。この情報をテーブルまたはその他のデータ構造内で参照することで、障害の起きたクライアント通信を再試行すべきかどうかを標示できるようにする場合がある。再試行ポイント１２２は、或る種類の通信は再試行不可能であると判断できる。たとえば安全な通信は再試行不可能であると判断されることになる。これに代えて、当該の要求が再試行可能であるかどうかを通信の種類によって標示する場合もある。たとえば、静的なデータに対する要求は再試行可能であると予め判断される場合がある。さらにまた、再試行ポイント１２２は、クライアント通信についてのいくつかの送信元および／または宛先を再試行不可能であると識別するように構成され得る。
【００７７】
ステップ５３０にて、障害の起きたクライアント通信が再試行不可能であると判断された場合、ステップ５４０ではクライアント通信に障害が起きたことをクライアントに通知する。たとえば、クライアント通信に障害が起きたという標示を再試行ポイント１２２がクライアント１１０へ転送する。
【００７８】
一方、一実施例において、ステップ５３０にて障害の起きたクライアント通信が再試行
可能であると判断された場合、ステップ５５０にて、再試行ポイント１２２は通信経路を選択して障害の起きたクライアント通信の送信を再試行する。たとえば、再試行ポイント１２２は別のサーバマシンにアクセスして、上記別のサーバマシン内のコンポーネントを組込む新たな通信経路を用いる場合がある。これに代えて、たとえば障害がデータ源１５０に生じたと判断された場合には再試行ポイント１２２は以前の通信経路の使用を決定してもよい。
【００７９】
通信経路が一旦選択されれば、再試行コンポーネント１２２は障害の起きたクライアント通信をデータ源１５０へ再送信する。再試行ポイント１２２はクライアント通信の転送の際、選択された通信経路のシーケンスにおいて次に続くコンポーネントにクライアント通信を合図する。
【００８０】
ウェブベースの通信などの用途においては、要求が再試行可能であるかどうかが要求の内容によって標示される場合がある。たとえばＵＲＬには、要求が再試行可能であるかどうかを標示する変数またはその他の文字列が入っている場合がある。
【００８１】
図６は、或る障害の起きたクライアント通信が再試行可能であるかどうかを判断する再試行ロジックで実現され得るデータ構造６００を説明する。データ構造５００は、クライアント通信の中から識別された１つ以上のパラメータを対応する値とつき合わせて、当該クライアント通信が再試行可能であるかどうかを判断する。上記クライアント通信の中から識別された１つ以上のパラメータは１組のパラメータ特性６１０に属する。各々のパラメータについてのそれぞれ対応する値は１組のパラメータ値６２０に属する。
【００８２】
想定された一例において、パラメータ特性６１０は、クライアント通信が安全なものであるかどうかを識別するためのセキュリティパラメータ６１２、どの動作（読出、書込、消去など）が当該クライアント通信により指定されているかを識別するための動作パラメータ６１４、１つ以上のユーザ定義パラメータ６１６、および／または１つ以上のベンダ指定パラメータ６１８を含む。ユーザ定義パラメータはクライアントのユーザにより定義または構成可能である。ベンダ定義パラメータはサーバマシンのベンダにより定義または構成可能である。たとえばサーバファームにおいては、サーバマシンに１つ以上の論理アプリケーションがベンダにより設けられるかまたは構成される。
【００８３】
パラメータ値６２０は以下のものを含む。セキュリティパラメータの値６２２は、障害の起きたクライアント通信が、安全でない通信の場合には必ず再試行されるが、安全な通信の場合には決して再試行されないように定めることがあり得る。動作パラメータ６１４の値６２４は、再試行が、読出動作を指定するクライアント通信については実行され得るが書込または消去の動作については実行され得ないように指定することがあり得る。値６２６は、ユーザ定義パラメータ６１６と整合するように構成可能である。たとえば値６２６は、クライアント通信の宛先が或る特定のネットワークアドレスＩＰ（ａ）である場合には、障害の起きたクライアント通信の再試行を除外する場合がある。値６２８はベンダ定義パラメータ６１８と整合するように構成可能である。たとえば、ベンダ定義パラメータとして、ＩＤ（ａ）を有するクライアントユーザについては、障害の起きたクライアント通信の再試行を除外するパラメータを設けることができる。
【００８４】
さらに、再試行可能なクライアント通信を識別するためのもっと高度なデータ構造および技術が考えられ得る。一実施例においては、データ構造６００に変更を加えて、再試行ポイントの外側にある新たな通信経路で再試行可能なクライアント通信を識別できるようにする場合がある。たとえば、安全なクライアント通信を、同じサーバマシン内のコンポーネントを用いて合図された場合のみ再試行可能とすることができる。
【００８５】
特定の一応用例において、テーブル６００は、ＵＲＬ（uniform resource locator）のパターンに対応し得る。たとえば、ウェブブラウザから送られたＨＴＴＰ（Hypertext Transfer Protocol）要求におけるＵＲＬパターンに特定のパターンが含まれていた場合、このパターンを特定の再試行関数または命令とつき合わせる。たとえば、"http://website/documents/reads/*"などのパターンを指定するかまたはこれを含む要求は再試行可能であると指定され得る。一方、"http://website/documents/updates/*"などのパターンを指定する要求は再試行不可能であると指定され得る。後者の場合、当該要求は再試行不可能であり得るが、それはデータを更新する要求は本来的に、アクセスされているデータが静的でなく動的であることを意味しているからである。
【００８６】
Ｄ．代替形態
ここに記載した各実施例はクライアント１０とデータ源５０との間の通信経路での単一の再試行コンポーネントのみを記載しているが、実施例によっては多数の再試行コンポーネントがある場合もある。具体的に、多数の再試行コンポーネントをクライアント１０とデータ源５０との間の通信経路で適当に位置付けることができる。たとえば、一実現例においては、サーバマシン２０および負荷平衡装置２５の各々が再試行コンポーネントを含んでもよい。サーバマシン２０内にあるコンポーネントは、サーバマシンとデータ源との間でクライアント通信に障害が起きた場合に当該サーバマシンの再試行コンポーネントから障害の起きたクライアント通信の送信を再試行するように構成される。同様に、負荷平衡装置２５内のコンポーネントもまた、負荷平衡装置の論理コンポーネントのうち１つでクライアント通信に障害が起きた場合に当該負荷平衡装置の再試行コンポーネントからクライアント通信の送信を再試行するように構成される。
【００８７】
ここに記載の各実施例ではクライアントからデータ源への通信に焦点をあてて説明している。しかし、ここに記載の技術はこの文脈に限定されるものではなく、送信側がメッセージを意図された受信側に送信し、このメッセージが多数の中間コンポーネントを通過することになるあらゆる事例で採用可能である。たとえば上記メッセージは、クライアントからの要求に応じてデータ源からクライアントへ送信される応答である場合がある。この要求はまた、クライアントから、サービスを提供するがクライアントにより検索可能なデータの供給源ではないサーバへの要求であり得る。
【００８８】
Ｅ．ハードウェアの説明
図７は、この発明の一実施例が実現され得るコンピュータシステム７００を示すブロック図である。コンピュータシステム７００は、バス７０２またはその他情報を通信するための通信機構と、バス７０２に結合され情報を処理するプロセッサ７０４とを備える。コンピュータシステム７００はさらにランダムアクセスメモリ（ＲＡＭ）またはその他の動的記憶装置などの主メモリ７０６を備え、これはバス７０２に結合されて、プロセッサ７０４が実行する命令および情報を記憶する。主メモリ７０６はまた、プロセッサ７０４が命令を実行している間に一時的な変数またはその他の中間情報を蓄積するためにも用いられ得る。コンピュータシステム７００はさらに、バス７０２に結合されてプロセッサ７０４のための静的情報および命令を記憶する読出専用メモリ（ＲＯＭ）７０８またはその他の静的記憶装置を備える。さらに、バス７０２に結合されて情報および命令を記憶するための磁気ディスクまたは光ディスクなどの記憶装置７１０が設けられる。
【００８９】
コンピュータシステム７００はバス７０２を介して、情報をコンピュータユーザに対して表示するための陰極線管（ＣＲＴ）などの表示装置７１２に結合され得る。英数字式キーおよびその他のキーを含む入力装置７１４がバス７０２に結合されて情報およびコマンド選択をプロセッサ７０４に通信する。別の種類のユーザ入力装置として、マウス、トラックボールまたはカーソルキーなどのカーソル操作装置７１６があり、これにより方向情報およびコマンド選択をプロセッサ７０４に通信し、ディスプレイ７１２におけるカーソ
ルの動きを制御する。一般的にこの入力装置は、第１の軸（たとえばｘ軸）および第２の軸（たとえばｙ軸）の２本の軸上における２自由度を有し、これにより入力装置は或る平面上の位置を指定することができる。
【００９０】
この発明は、コンピュータシステム７００を使用してここに記載の技術を実現することに関する。この発明の一実施例に従うと、主メモリ７０６に入っている１つ以上の命令からなる１つ以上のシーケンスをプロセッサ７０４が実行するのに応じてここに記載の技術がコンピュータシステム７００により実行される。上記命令は別のコンピュータ読取可能媒体、たとえば記憶装置７１０から主メモリ７０６に読込まれ得る。主メモリ７０６に入っている命令シーケンスが実行されるのに伴い、プロセッサ７０４においてここに記載されたプロセスステップが実行される。これに代わる実施例では、ソフトウェアによる命令に代えて、またはこれと組合せて、ハードウェア回路を用いてこの発明を実現する場合もある。したがってこの発明の各実施例は、ハードウェア回路およびソフトウェアのいかなる特定の組合せにも限定されない。
【００９１】
ここで用いる「コンピュータ読取可能媒体」という用語は、命令をプロセッサ７０４が実行できるようここに供給することに関与するあらゆる媒体を指す。このような媒体は多くの形態をとることができ、これには不揮発性媒体、揮発性媒体および伝送媒体が含まれるがこれに限定されない。不揮発性媒体にはたとえば、記憶装置７１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には主メモリ７０６などのダイナミックメモリが含まれる。伝送媒体には同軸ケーブル、銅線および光ファイバが含まれ、これにはバス７０２を構成するワイヤが含まれる。伝送媒体はまた音波または光波の形態をとることもでき、これにはたとえば電波通信および赤外線データ通信の際に生成されるものなどがある。
【００９２】
コンピュータ読取可能媒体の一般的な形態にはたとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、またはその他任意の磁気媒体、ＣＤ−ＲＯＭ、その他任意の光媒体、パンチカード、紙テープ、その他任意の孔パターンによる物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他任意のメモリチップまたはカートリッジ、後に記載するような搬送波、またはその他コンピュータが読出可能な任意の媒体が含まれる。
【００９３】
１つ以上の命令からなる１つ以上のシーケンスをプロセッサ７０４が実行できるようここへ伝達することにはさまざまな形態のコンピュータ読取可能媒体が関与し得る。たとえば、命令はまず遠隔コンピュータの磁気ディスクに収められ得る。この遠隔コンピュータは命令を自分のダイナミックメモリにロードし、モデムを用いて電話回線経由でこれら命令を送信し得る。コンピュータシステム７００に対してローカルなモデムが電話回線上のデータを受信し、赤外線送信機を用いてこのデータを赤外線信号に変換し得る。赤外線信号で搬送されたデータは赤外線検出器で受信され、適当な回路がこのデータをバス７０２に出力することになる。バス７０２はデータを主メモリ７０６へと伝達し、ここからプロセッサ７０４は命令を検索して実行する。任意には、主メモリ７０６が受取った命令をプロセッサ７０４による実行前または実行後に記憶装置７１０に記憶させてもよい。
【００９４】
コンピュータシステム７００はさらに、バス７０２に結合された通信インターフェイス７１８を含む。通信インターフェイス７１８は、ローカルネットワーク７２２に接続されたネットワークリンク７２０に対する２方向データ通信結合を行なうものである。たとえば通信インターフェイス７１８として統合デジタル通信サービス網（ＩＳＤＮ）カードまたはモデムを用いることができ、これにより対応する種類の電話回線に対するデータ通信接続を行なう。別の例として、通信インターフェイス７１８にローカルエリアネットワーク（ＬＡＮ）カードを用いてもよく、これにより対応するＬＡＮに対するデータ通信接続
を行なう。無線リンクもまた実現可能である。このような実現例のいずれにおいても、通信インターフェイス７１８は、さまざまな種類の情報を表わすデジタルデータの流れを搬送する電気信号、電磁信号または光信号を送受信する。
【００９５】
一般的にネットワークリンク７２０は、１つ以上のネットワーク経由で他のデータ装置に対するデータ通信を可能にする。たとえばネットワークリンク７２０はローカルネットワーク７２２経由で、ホストコンピュータ７２４や、またはインターネットサービスプロバイダ（ＩＳＰ）７２６の稼動させるデータ装置に対する接続を行なうことができる。そしてＩＳＰ７２６は、現在一般に「インターネット」と称される全世界規模パケットデータ通信網７２８を通じてデータ通信サービスを提供する。ローカルネットワーク７２２およびインターネット７２８ではともに、デジタルデータの流れを搬送する電気信号、電磁信号または光信号を使用する。このようにさまざまなネットワークを経由する信号や、デジタルデータをコンピュータシステム７００に入出力するように搬送するネットワークリンク７２０上および通信インターフェイス７１８経由の信号は、情報を運ぶ搬送波の形態の例である。
【００９６】
コンピュータシステム７００は、ネットワーク、ネットワークリンク７２０および通信インターフェイス７１８を通じてメッセージを送信し、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ７３０は或るアプリケーションプログラムについての要求されたコードを、インターネット７２８、ＩＳＰ７２６、ローカルネットワーク７２２そして通信インターフェイス７１８経由で送信することがあり得る。
【００９７】
こうして受信されたコードは、受信されるとプロセッサ７０４により実行され、かつ／または記憶装置７１０もしくはその他の不揮発性記憶装置内で、後で実行されるように蓄積され得る。このようにコンピュータシステム７００は搬送波の形でアプリケーションコードを取得し得る。
【００９８】
以上の明細書においては、この発明をその特定の実施例を参照して記載した。しかし、この発明のより広い意味および範囲から逸脱することなく、さまざまな変形および変更がこの発明で可能であることが明らかであろう。したがってこの明細書および図面は、限定的でなく例示的な意味で考えられるべきである。
【図面の簡単な説明】
【００９９】
【図１】クライアントとデータ源との間で合図される通信のための指定された再試行コンポーネントを有するシステムを説明する図である。
【図２】再試行ロジックを含むように構成されたサーバマシンの動作を説明するブロック図である。
【図３】クライアントとデータ源との間の通信経路において再試行ロジックを実現するためのシーケンス図である。
【図４】クライアントをデータ源に結合するのに用いるサーバマシンのための再試行ロジックを実現する一方法を説明する図である。
【図５】クライアントをデータ源に結合するためのシステムにおける再試行ロジックを実現する一方法を説明する図である。
【図６】障害の起きた或るいくつかの通信が再試行可能であるかどうかを判断する再試行ロジックで実現され得るデータ構造を説明する図である。
【図７】この発明の一実施例が実現され得るコンピュータシステムを説明するブロック図である。
【図８】クライアントとサーバとの間で障害の起きた通信を再試行する先行技術のシステムを説明する図である。
【図１】
2005527899.tif 000003
【図２】
2005527899.tif 000004
【図３】
2005527899.tif 000005
【図４】
2005527899.tif 000006
【図５】
2005527899.tif 000007
【図６】
2005527899.tif 000008
【図７】
2005527899.tif 000009
【図８】
2005527899.tif 000010
【手続補正書】
【提出日】平成16年6月25日(2004.6.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信側と、意図された受信側との間の通信を管理するためのシステムであって、
前記送信側から前記意図された受信側への送信側通信をシーケンシャルに転送するように結合された複数の論理コンポーネントと、
前記送信側通信が前記意図された受信側に到達することに失敗した場合に前記意図された受信側への前記送信側通信の送信を再試行するように指定された、前記複数の論理コンポーネントのうちの再試行コンポーネントと、
前記複数の論理コンポーネントのうちの多数のコンポーネントとを含み、前記多数のコンポーネントは、前記送信側通信に障害が起きたのに応じて、前記送信側通信に障害が起きたという標示を前記再試行コンポーネントへ転送し、自らは前記意図された受信側への前記送信側通信の送信を再試行しない、システム。
【請求項２】
前記送信側はクライアントであり、前記意図された受信側はデータ源であり、前記送信側通信は前記データ源により管理されるデータへの要求である、請求項１に記載のシステム。
【請求項３】
前記再試行コンポーネントは、前記送信側から前記意図された受信側への通信経路において前記多数のコンポーネントの前にある、請求項１に記載のシステム。
【請求項４】
前記再試行コンポーネントはサーバマシンのインターフェイスの一部として設けられ、前記インターフェイスは、他の装置からの要求を処理するように構成されたものである、請求項１に記載のシステム。
【請求項５】
前記再試行コンポーネントは、要求を前記意図された受信側へ送信するサーバマシン内のサーバ内論理コンポーネントである、請求項１に記載のシステム。
【請求項６】
前記再試行コンポーネントは、前記送信側から前記送信側通信を受取る負荷平衡装置に常駐し、前記複数の論理コンポーネントにおける他のコンポーネントを含むサーバマシンに前記送信側通信を送信する、請求項１に記載のシステム。
【請求項７】
前記複数の論理コンポーネントのうち少なくとも前記多数のコンポーネントは第１のサーバマシンに常駐し、前記再試行コンポーネントは、第２のサーバマシンにおけるコンポーネントを使用して前記意図された受信側への前記送信側通信の送信を再試行するように構成される、請求項１に記載のシステム。
【請求項８】
前記再試行コンポーネントはトポロジマップにアクセスして前記多数のコンポーネントのうちどれが適正に機能しているかを判断する、請求項１に記載のシステム。
【請求項９】
さらに、前記複数の論理コンポーネントの外部にある外部モニタを含み、前記外部モニタは、前記送信側通信が前記意図された受信側に到達するのに失敗したかどうかを検出し、かつ前記送信側通信が前記意図された受信側に到達するのに失敗したときに前記再試行コンポーネントに通信するように構成される、請求項１に記載のシステム。
【請求項１０】
前記再試行コンポーネントは、前記送信側通信を再送信する前に前記送信側通信が再試行可能であるかどうかを判断する、請求項１に記載のシステム。
【請求項１１】
前記再試行コンポーネントは、前記送信側通信が前記意図された受信側に到達するのに失敗したことが前記多数のコンポーネントのうち１つ以上により標示された場合に前記意図された受信側への前記送信側通信の送信を再試行するように構成された唯一のコンポーネントである、請求項１に記載のシステム。
【請求項１２】
前記再試行コンポーネントは、前記送信側通信の特性に少なくとも部分的に基づいて前記送信側通信が再試行可能であるかどうかを判断する、請求項１０に記載のシステム。
【請求項１３】
前記再試行コンポーネントおよび前記多数のコンポーネントはサーバマシンに常駐し、前記再試行コンポーネントは、前記送信側通信が前記意図された受信側に到達するのに失敗したことが前記多数のコンポーネントのうちいずれかにより標示された場合に他のサーバマシンと交信して前記送信側通信を再送信するように構成される、請求項１０に記載のシステム。
【請求項１４】
前記再試行コンポーネントは前記送信側に常駐しており、広域ネットワークにわたり前記多数のコンポーネントと通信する、請求項１に記載のシステム。
【請求項１５】
前記再試行コンポーネントは、前記送信側通信が再試行可能であるかどうかを判断するのに際し、前記送信側通信が安全にされているかどうかを判断する、請求項１０に記載のシステム。
【請求項１６】
前記再試行コンポーネントは、前記送信側通信が再試行可能であるかどうかを判断するのに際して前記送信側の識別情報を識別する、請求項１０に記載のシステム。
【請求項１７】
前記再試行コンポーネントは、前記意図された受信側の識別情報に基づいて前記送信側通信が再試行可能であるかどうかを判断する、請求項１０に記載のシステム。
【請求項１８】
前記再試行コンポーネントはサーバマシンに常駐し、単一の前記再試行コンポーネントは前記サーバマシンにおける少なくとも１つの他の代替コンポーネントを識別し、かつ前記送信側通信を前記少なくとも１つの他の代替コンポーネントへ転送することにより前記意図された受信側への前記送信側通信の送信を再試行する、請求項１に記載のシステム。
【請求項１９】
前記再試行コンポーネントは、前記送信側通信の送信を再試行する前に、当該の送信側通信につき再試行が以前に試みられた回数を判断し、そして、前記回数が再試行について
の最大閾値未満である場合にのみ前記送信側通信の送信を再試行する、請求項１に記載のシステム。
【請求項２０】
ネットワーク通信を管理する、コンピュータにより実現される方法であって、
送信側と意図された受信側との間の第１の通信経路において再試行ポイントを指定するステップを含み、前記第１の通信経路は、前記送信側から前記意図された受信側への送信側通信をシーケンシャルに受取り転送する複数の論理コンポーネントを含み、前記再試行ポイントは前記第１の通信経路の一部を形成し、前記方法はさらに、
前記第１の通信経路のうち前記再試行ポイントを超えた部分において前記送信側通信が前記意図された受信側に到達するのに失敗した場合に、前記送信側通信が前記意図された受信側に到達するのに失敗したという標示を前記再試行ポイントに送信するステップと、
前記送信側通信を前記意図された受信側へ前記再試行ポイントからのみ再送信するステップとを含む、方法。
【請求項２１】
前記送信側通信が前記意図された受信側に到達するのに失敗したという標示を前記再試行ポイントに送信するステップは、前記送信側通信が前記意図された受信側に到達するのに失敗したことが検出されるのに応じて実行される、請求項２０に記載の方法。
【請求項２２】
前記再試行ポイントを指定するステップは、サーバ内論理コンポーネントを再試行ロジックの実行に指定するステップを含む、請求項２０に記載の方法。
【請求項２３】
前記送信側通信が意図された受信側に到達するのに失敗したことを検出するステップは、前記意図された受信側が利用不可能であることを検出するステップを含む、請求項２０に記載の方法。
【請求項２４】
前記送信側通信が前記意図された受信側に到達するのに失敗したことを検出するステップは、前記通信経路にある論理コンポーネントに障害が起きたことを検出するステップを含む、請求項２０に記載の方法。
【請求項２５】
さらに、前記送信側通信に障害が起きたことを検出した後に前記送信側通信のための新たな通信経路を選択するステップを含む、請求項２０に記載の方法。
【請求項２６】
新たな通信経路を選択するステップは、前記再試行ポイントにおけるロジックを使用して、前記意図された受信側に到達するために利用可能な通信経路を識別するステップを含む、請求項２０に記載の方法。
【請求項２７】
前記再試行ポイントを指定するステップは、前記第１の通信経路を形成する前記論理コンポーネントの一部を前記再試行ポイントとして選択するステップを含み、前記論理コンポーネントの前記一部は少なくとも２つの論理コンポーネントを含む、請求項２０に記載の方法。
【請求項２８】
論理コンポーネントの一部を選択するステップは、作業負荷を複数のサーバマシン間に分散させる負荷平衡装置から前記論理コンポーネントの前記一部を選択するステップを含み、前記論理コンポーネントの前記一部は前記複数のサーバマシンのうちの１つに常駐する、請求項２７に記載の方法。
【請求項２９】
さらに、前記送信側通信が再試行可能であるかどうかを判断するステップと、
前記送信側通信が再試行可能である場合にのみ前記送信側通信を再送信するステップとを含む、請求項２０に記載の方法。
【請求項３０】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側の識別情報を判別するステップと、前記送信側の前記識別情報が前記送信側通信の再送信を許すように指定されている場合に前記送信側通信を再送信するステップとを含む、請求項２９に記載の方法。
【請求項３１】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記意図された受信側の識別情報を判別するステップと、前記意図された受信側の前記識別情報が前記送信側通信の再送信を許すように指定されている場合に前記送信側通信を再送信するステップとを含む、請求項２９に記載の方法。
【請求項３２】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信が安全にされていた場合に前記送信側通信が再試行不可能であると判断するステップを含む、請求項２９に記載の方法。
【請求項３３】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信につき以前に再試行が試みられた回数を判断するステップと、前記回数が再試行についての最大閾値未満である場合にのみ前記送信側通信を再試行するステップとを含む、請求項２９に記載の方法。
【請求項３４】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信の特性を、前記送信側通信が再試行可能であるかどうかについての対応する標示と照合させるステップを含む、請求項２９に記載の方法。
【請求項３５】
前記送信側と前記意図された受信側との間の前記第１の通信経路において前記再試行ポイントを指定するステップは、前記送信側に対応するサーバ内論理コンポーネントを前記再試行ポイントして選択するステップを含む、請求項２９に記載の方法。
【請求項３６】
前記意図された受信側に前記送信側通信を再送信するステップは、異なる通信経路を使用して前記意図された受信側へ前記送信側通信を再送信するステップを含む、請求項２９に記載の方法。
【請求項３７】
前記異なる通信経路を使用するステップは、前記意図された受信側のために前記送信側通信を転送するように前記第１の通信経路の外部にある通信装置にアクセスするステップを含む、請求項３６に記載の方法。
【請求項３８】
前記送信側通信が前記意図された受信側に到達するのに失敗したという標示を前記再試行ポイントに送信するステップは、前記再試行ポイントと前記意図された受信側との間にある前記複数の論理コンポーネントのうちの１つにおいて前記送信側通信が前記意図された受信側に到達するのに失敗したかどうかを検出するステップを含む、請求項２９に記載の方法。
【請求項３９】
前記送信側通信を前記意図された受信側へ前記再試行ポイントからのみ再送信するステップは、前記再試行ポイントにおける対応する装置の外部にある装置に少なくとも部分的に常駐する新たな通信経路を選択するステップを含む、請求項２９に記載の方法。
【請求項４０】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記新たな通信経路が使用されることになるかどうかを判断するステップを含む、請求項３９に記載の方法。
【請求項４１】
さらに、前記送信側通信が安全であるかどうかを判断するステップと、前記新たな通信
経路が前記送信側通信の再送信に使用されることになる場合に前記送信側通信が再試行不可能であると判断するステップとを含む、請求項４０に記載の方法。
【請求項４２】
前記送信側通信が再試行可能であるかどうかを判断するステップは、前記送信側通信が安全にされているかどうかを判断するステップと、前記意図された受信側に前記送信側通信を再送信するステップが前記第１の通信経路の外部にある通信装置を使用するステップを含むかどうかを判断するステップとを含む、請求項２９に記載の方法。
【請求項４３】
送信側と意図された受信側との間の通信を管理するためのシステムであって、前記システムは、シーケンシャルに組合せられて送信側通信を前記意図された受信側に転送する複数の論理コンポーネントを含む装置において実現され、前記システムは、
データを蓄積するメモリを含み、前記データは、通信についての１つ以上の特性を識別し、かつ前記１つ以上の特性を有する通信が再試行可能であるかどうかを標示し、前記システムはさらに、
前記複数の論理コンポーネントのうちの再試行コンポーネントを含み、前記再試行コンポーネントは、前記送信側通信において前記特性を識別し、前記送信側通信が前記意図された受信側に到達するのに失敗した場合に前記メモリにアクセスして前記送信側通信の送信を再試行すべきかどうかを判断する、システム。
【請求項４４】
メモリ内に蓄積された前記データは、前記送信側通信が安全にされているかどうかに基づいて前記送信側通信が再試行可能であるかどうかを標示する、請求項４３に記載のシステム。
【請求項４５】
メモリ内に蓄積された前記データは、前記送信側通信の動作に基づいて前記送信側通信が再試行可能であるかどうかを標示する、請求項４３に記載のシステム。
【請求項４６】
前記再試行コンポーネントは、前記複数の論理コンポーネントのうち、前記意図された受信側に到達するのに失敗した送信側通信を再試行する唯一のコンポーネントとして構成される、請求項４３に記載のシステム。
【請求項４７】
前記再試行コンポーネントは、前記通信の送信を再試行するための送信経路として働くように前記装置において前記複数の論理コンポーネントを含む１群のコンポーネントからコンポーネントの組合せを選択するように構成され、前記１群のコンポーネントにおける前記コンポーネントのうち少なくともいくつかは前記装置の外部にある、請求項４６に記載のシステム。
【請求項４８】
ネットワーク通信を管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、請求項２０から請求項４２のいずれかに記載の方法を実行させる、コンピュータ読取可能媒体。
【手続補正書】
【提出日】平成17年1月13日(2005.1.13)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】図７
【補正方法】変更
【補正の内容】
【図７】
2005527899.tif 000011
【国際調査報告】
2005527899.tif 000012
2005527899.tif 000013
2005527899.tif 000014
2005527899.tif 000015
2005527899.tif 000016
2005527899.tif 000017