JP3776706B2 - データ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents
データ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP3776706B2 JP3776706B2 JP2000305303A JP2000305303A JP3776706B2 JP 3776706 B2 JP3776706 B2 JP 3776706B2 JP 2000305303 A JP2000305303 A JP 2000305303A JP 2000305303 A JP2000305303 A JP 2000305303A JP 3776706 B2 JP3776706 B2 JP 3776706B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- reply
- connection
- communication device
- data communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Retry When Errors Occur (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、通信の異常発生時の通信負荷を低減させることができるデータ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
近時、クライアント／サーバ構成のデータ通信装置が主流になっている。このようなデータ通信装置においては、クライアントの数が増えるに従って、通信負荷が増えるため、通信負荷をできるだけ増やさない手段、方法が切望されている。
【０００３】
【従来の技術】
図９は、従来のＣＯＲＢＡ（Common Object Request Broker Architecture）通信システムの構成を示すブロック図である。ＣＯＲＢＡは、標準化団体ＯＭＧ(Object Management Group）が定める異機種間接続のための標準化仕様であり、異機種間の連携プロトコルと分散アプリケーション構築のための各種ＡＰＩ（Application Program Interface)を規定するものである。
【０００４】
簡単に言えば、ＣＯＲＢＡは、分散システム環境でクライアントが、サーバ内のオブジェクト（例えば、アプリケーションプログラム）にアクセスするためのメカニズムを提供する標準技術である。ここで、ＣＯＲＢＡにおけるオブジェクトとは、クライアントから要求することができる一つまたは複数のサービスを提供する、識別可能にカプセル化されたエンティティをいう。
【０００５】
図９には、ｎ台のクライアント１０1〜１０nと、これらのクライアント１０1〜１０nとネットワーク（図示略）を介して接続されたサーバ２０とからなるＣＯＲＢＡ通信システムが図示されている。クライアント１０1〜１０nのそれぞれは、所定のプロトコルに従って、サーバ２０との間で通信を行う。このプロトコルにおいては、リクエスト、リプライ、コミット、ロールバックという処理が発生する。
【０００６】
リクエストは、クライアント１０1〜１０nのそれぞれからサーバ２０のトランザクション処理を依頼するためのものである。トランザクションの発生のデータベース２５の更新依頼を行うためのものである。リプライは、上記リクエストに対する返信であり、サーバ２０からクライアント１０1〜１０nへ通知されるものである。コミットは、クライアント１０1〜１０nのそれぞれの処理結果をデータベース２５に反映させるためのものである。リプライは、クライアント１０1〜１０nとサーバ２０との間のコネクションが異常切断された場合に、データベース２５を、トランザクションが実行される前の状態に戻し、一貫性を保つためのものである。
【０００７】
クライアント１０1において、ＯＲＢ（Object Request Broker：分散オブジェクト間通信機構）１１1は、クライアント１０1とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ１１1は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【０００８】
ここで、ＣＯＲＢＡにおけるネーミングサービスについて説明する。ＣＯＲＢＡにおけるネーミングサービスによれば、クライアントは、オブジェクトにアクセスする場合、オブジェクトの位置ではなく、名前でアクセスできるようになるため、オブジェクトの物理的な位置を意識する必要がない。
【０００９】
具体的には、クライアントからアクセスがあった場合、サーバ２０内でオブジェクトリファレンスが生成され、これがクライアントに返されることにより、ネーミングサービスが提供される。このオブジェクトリファレンスは、オブジェクトを名前で一意に識別するための情報である。
【００１０】
リクエスト送信部１２1は、上述したリクエストをサーバ２０へ送信する機能を備えている。リプライ受信部１３1は、サーバ２０からのリプライを受信する機能を備えている。このリプライは、上記リクエストに対する返信である。コミット／ロールバック送信部１４1は、上述したコミットまたはロールバックをサーバ２０へ送信する機能を備えている。
【００１１】
クライアント１０2において、ＯＲＢ１１2は、ＯＲＢ１１1と同様にして、クライアント１０2とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ１１2は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００１２】
リクエスト送信部１２2は、上述したリクエストをサーバ２０へ送信する機能を備えている。リプライ受信部１３2は、サーバ２０からのリプライを受信する機能を備えている。このリプライは、上記リクエストに対する返信である。コミット／ロールバック送信部１４2は、上述したコミットまたはロールバックをサーバ２０へ送信する機能を備えている。
【００１３】
クライアント１０nにおいて、ＯＲＢ１１nは、ＯＲＢ１１1と同様にして、クライアント１０nとサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ１１nは、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００１４】
リクエスト送信部１２nは、上述したリクエストをサーバ２０へ送信する機能を備えている。リプライ受信部１３nは、サーバ２０からのリプライを受信する機能を備えている。このリプライは、上記リクエストに対する返信である。コミット／ロールバック送信部１４nは、上述したコミットまたはロールバックをサーバ２０へ送信する機能を備えている。
【００１５】
サーバ２０は、クライアント１０1〜１０nからのリクエストを受信する機能と、上記リクエストに対する返信としてのリプライをクライアント１０1〜１０nへ送信する機能と、クライアント１０1〜１０nからのコミットを受信する機能と、上記コミットに基づいてデータベース２５を更新する機能と、クライアント１０1〜１０nからのロールバックを受信する機能と、上記ロールバックに基づいてデータベース２５を、トランザクションが実行される前の状態に戻す機能とを備えている。
【００１６】
具体的には、サーバ２０は、ＯＲＢ２１、リクエスト受信部２２、リプライ送信部２３、コミット／ロールバック受信部２４およびデータベース２５から構成されている。ＯＲＢ２１は、サーバ２０とクライアント１０1〜１０nとを仲介するソフトウェア・バスである。リクエスト受信部２２は、クライアント１０1〜１０nからのリクエストを受信する機能を備えている。
【００１７】
リプライ送信部２３は、上記リクエストに対する返信としてのリプライをクライアント１０1〜１０nへ送信する機能を備えている。コミット／ロールバック受信部２４は、クライアント１０1〜１０nからのコミットを受信する機能と、上記コミットに基づいてデータベース２５を更新する機能と、クライアント１０1〜１０nからのロールバックを受信する機能と、上記ロールバックに基づいてデータベース２５を、トランザクションが実行される前の状態に戻す機能とを備えている。
【００１８】
つぎに、上述した従来のＣＯＲＢＡ通信システムの動作について図１０を参照しつつ説明する。図１０は、従来のＣＯＲＢＡ通信システムの動作を説明するシーケンス図である。はじめに、クライアント１０nとサーバ２０との間における正常時の動作について説明する。なお、クライアント１０1〜クライアント１０n-1（図示略）とサーバ２０との間における動作は、以下に説明するクライアント１０nとサーバ２０との間における動作と同様である。
【００１９】
（正常時）
図１０に示したステップＳＡ１では、クライアント１０nのリクエスト送信部１２nからリクエストが送信されると、サーバ２０のリクエスト受信部２２によりリクエストが受信される。
【００２０】
これにより、ステップＳＡ２では、サーバ２０のリプライ送信部２３からリプライが送信されると、リプライ受信部１３nによりリプライが受信される。ステップＳＡ３では、コミット／ロールバック送信部１４nによりコミットが送信されると、コミット／ロールバック受信部２４によりコミットが受信される。これにより、サーバ２０では、データベース２５が更新される。
【００２１】
（異常時）
つぎに、図９に示したクライアント１０nとサーバ２０との間に設定されているコネクションが異常切断した場合について説明する。図１０に示したステップＳＢ１では、クライアント１０nのリクエスト送信部１２nからリクエストが送信されると、サーバ２０のリクエスト受信部２２によりリクエストが受信される。これにより、ステップＳＢ２では、サーバ２０のリプライ送信部２３からリプライが送信される。
【００２２】
ここで、コネクションが異常切断するとトランザクション不整合が発生し、上記リプライは、リプライ受信部１３nに受信されない。この場合、ステップＳＢ３では、コミット／ロールバック送信部１４nによりロールバックが送信されると、コミット／ロールバック受信部２４によりロールバックが受信される。これにより、サーバ２０では、データベース２５が、トランザクションが実行される前の状態に戻される。すなわち、異常時には、データベース２５が更新されない。
【００２３】
【発明が解決しようとする課題】
ところで、前述したように、従来のＣＯＲＢＡ通信システムでは、通信の異常発生時に、クライアント１０1〜１０nとサーバ２０との間で、コミット／ロールバックのための通信が必要であるため、クライアント数が増えるに従って、通信負荷（トランザクション）が増大するという問題があった。特に、ネットワークの回線容量が少ない場合にボトルネックとなる。
【００２４】
本発明は、上記に鑑みてなされたもので、通信の異常発生時の通信負荷を低減させることができるデータ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２５】
【課題を解決するための手段】
上記目的を達成するために、本発明は、外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信装置において、前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新手段と、前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ手段と、前記外部通信装置との間のコネクションを監視するコネクション監視手段と、前記コネクション監視手段の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信手段とを備えたことを特徴とする。
【００２６】
また、本発明は、外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信方法において、前記外部通信装置からトランザクション処理の実行を依 頼するリクエストがあった場合に前記データベースを更新するデータベース更新工程と、前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ工程と、前記外部通信装置との間のコネクションを監視するコネクション監視工程と、前記コネクション監視工程の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信工程とを含むことを特徴とする。
【００２７】
また、本発明は、外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信装置に適用されるデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新工程と、前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ工程と、前記外部通信装置との間のコネクションを監視するコネクション監視工程と、前記コネクション監視工程の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信工程と、をコンピュータに実行させるためのデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００２８】
かかる発明によれば、外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合にデータベースを更新し、リクエストに対応するリプライ情報を外部通信装置へ送信するとともにメモリに格納しておき、コネクションの異常切断時に当該リプライ情報を外部通信装置へ送信するようにしたので、従来の外部装置からのロールバックの場合に比べて、通信回線のトラフィック量を低減でき、通信の異常発生時の通信負荷を低減させることができる。
【００２９】
【発明の実施の形態】
以下、図面を参照して本発明にかかるデータ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体の一実施の形態について詳細に説明する。
【００３０】
図１は、本発明にかかる一実施の形態の構成を示すブロック図である。同図には、ｎ台のクライアント３０1〜３０nと、これらのクライアント３０1〜３０nとネットワーク（図示略）を介して接続されたサーバ２０とからなるＣＯＲＢＡを利用したデータ通信が図示されている。クライアント３０1〜３０nのそれぞれは、所定のプロトコルに従って、サーバ２０との間で通信を行う。ここで、注意すべき点は、前述した従来のＣＯＲＢＡ通信システム（図９参照）に比較して、コミット／ロールバックという通信負荷を増加させる要因が無いことである。
【００３１】
クライアント３０1において、ＯＲＢ３１1は、クライアント３０1とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ３１1は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００３２】
リクエスト送信部３２1は、上述したリクエストをサーバ２０へ送信する機能を備えている。ここで、ＯＲＢ３１1は、リクエストの送信時に当該リクエストを識別するためのリクエストＩＤを取得し、これをリクエストに付加する。リプライ受信部３３1は、図５（ａ）に示したリプライ情報５０1を受信する。
【００３３】
このリプライ情報５０1は、ＩＰアドレス（１）、ポート番号（１）、リクエストＩＤ（１）、クライアントアプリケーション名（１）およびリプライデータ（１）から構成されている。このリプライ情報５０1は、リクエストに対する返信として、後述するリプライ送信部４３から送信される情報である。
【００３４】
ここで、上記リクエストＩＤは、ＯＲＢ３１1により取得されたリクエストＩＤである。クライアントアプリケーション（１）は、クライアント３０1のリクエスト送信部３２1およびリプライ受信部３３1の名称である。リプライデータ（１）は、サーバ４０のリプライ送信部４３から送信されるデータである。
【００３５】
トランザクション通知エージェント３４1は、図５（ｂ）に示したフォーマットの通知リプライ情報６０に基づいて、コネクション異常切断によるクライアント３０1側のトランザクションの整合をとる機能を備えている。通知リプライ情報６０は、リクエストＩＤ、クライアントアプリケーション名およびリプライデータから構成されている。
【００３６】
図７（ｂ）に通知リプライ情報６０の具体例を示す。通知リプライ情報９０1は、クライアント３０1とサーバ４０との間でコネクション異常切断が発生した場合に、後述するトランザクション保証部４４から送信される情報であり、リクエストＩＤ（１）、クライアントアプリケーション名（１）およびリプライデータ（１）から構成されている。この通知リプライ情報９０1は、図５（ａ）に示したリプライ情報５０1に対応している。トランザクション通知エージェント３４1は、通知リプライ情報９０1からコネクション異常切断時のリクエストを特定し、この特定結果に基づいて、トランザクションの整合をとる。
【００３７】
クライアント３０2において、ＯＲＢ３１2は、クライアント３０2とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ３１2は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００３８】
リクエスト送信部３２2は、上述したリクエストをサーバ２０へ送信する機能を備えている。ここで、ＯＲＢ３１2は、リクエストの送信時に当該リクエストを識別するためのリクエストＩＤを取得し、これをリクエストに付加する。リプライ受信部３３2は、図５（ａ）に示したリプライ情報５０2を受信する。
【００３９】
このリプライ情報５０2は、ＩＰアドレス（２）、ポート番号（２）、リクエストＩＤ（２）、クライアントアプリケーション名（２）およびリプライデータ（２）から構成されている。このリプライ情報５０2は、リクエストに対する返信として、後述するリプライ送信部４３から送信される情報である。
【００４０】
ここで、上記リクエストＩＤは、ＯＲＢ３１2により取得されたリクエストＩＤである。クライアントアプリケーション（２）は、クライアント３０2のリクエスト送信部３２2およびリプライ受信部３３2の名称である。リプライデータ（２）は、サーバ４０のリプライ送信部４３から送信されるデータである。
【００４１】
トランザクション通知エージェント３４2は、図７（ｂ）に示した通知リプライ情報９０2に基づいて、コネクション異常切断によるクライアント３０2側のトランザクションの整合をとる機能を備えている。通知リプライ情報９０2は、クライアント３０2とサーバ４０との間でコネクション異常切断が発生した場合に、後述するトランザクション保証部４４から送信される情報であり、リクエストＩＤ（２）、クライアントアプリケーション名（２）およびリプライデータ（２）から構成されている。
【００４２】
また、通知リプライ情報９０2は、図５（ａ）に示したリプライ情報５０2に対応している。トランザクション通知エージェント３４2は、通知リプライ情報９０2からコネクション異常切断時のリクエストを特定し、この特定結果に基づいて、トランザクションの整合をとる。
【００４３】
クライアント３０nにおいて、ＯＲＢ３１nは、クライアント３０nとサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ３１nは、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００４４】
リクエスト送信部３２nは、上述したリクエストをサーバ２０へ送信する機能を備えている。ここで、ＯＲＢ３１nは、リクエストの送信時に当該リクエストを識別するためのリクエストＩＤを取得し、これをリクエストに付加する。リプライ受信部３３nは、図５（ａ）に示したリプライ情報５０nを受信する。
【００４５】
このリプライ情報５０nは、ＩＰアドレス（ｎ）、ポート番号（ｎ）、リクエストＩＤ（ｎ）、クライアントアプリケーション名（ｎ）およびリプライデータ（ｎ）から構成されている。このリプライ情報５０nは、リクエストに対する返信として、後述するリプライ送信部４３から送信される情報である。
【００４６】
ここで、上記リクエストＩＤは、ＯＲＢ３１nにより取得されたリクエストＩＤである。クライアントアプリケーション（ｎ）は、クライアント３０nのリクエスト送信部３２nおよびリプライ受信部３３nの名称である。リプライデータ（ｎ）は、サーバ４０のリプライ送信部４３から送信されるデータである。なお、一実施の形態では、図５（ａ）に示したリプライ情報５０1〜５０nに代えて、図７（ｂ）に示したリプライ情報８０1〜８０nを用いてもよい。
【００４７】
トランザクション通知エージェント３４nは、図５（ｂ）に示した通知リプライ情報９０nに基づいて、コネクション異常切断によるクライアント３０n側のトランザクションの整合をとる機能を備えている。通知リプライ情報９０nは、クライアント３０nとサーバ４０との間でコネクション異常切断が発生した場合に、後述するトランザクション保証部４４から送信される情報であり、リクエストＩＤ（ｎ）、クライアントアプリケーション名（ｎ）およびリプライデータ（ｎ）から構成されている。
【００４８】
また、通知リプライ情報９０nは、図５（ａ）に示したリプライ情報５０nに対応している。トランザクション通知エージェント３４nは、通知リプライ情報９０nからコネクション異常切断時のリクエストを特定し、この特定結果に基づいて、トランザクションの整合をとる。
【００４９】
サーバ４０は、クライアント３０1〜３０nからのリクエストを受信する機能と、上記リクエストに対する返信としてのリプライ情報５０1〜５０nをクライアント３０1〜３０nへ送信する機能と、サーバ４０とクライアント３０1〜３０nとの間のコネクションを監視する機能と、データベース４５を更新する機能等を備えている。
【００５０】
具体的には、サーバ４０は、ＯＲＢ４１、リクエスト受信部４２、リプライ送信部４３、トランザクション保証部４４およびデータベース４５から構成されている。ＯＲＢ４１は、サーバ４０とクライアント３０1〜３０nとを仲介するソフトウェア・バスである。このＯＲＢ４１は、リプライ情報５０1〜５０n（図５（ａ）参照）を送信する機能と、サーバ４０とクライアント３０1〜３０nとの間のコネクションを監視する機能とを備えている。
【００５１】
まや、ＯＲＢ４１は、コネクションの監視結果として図５（ｃ）に示したフォーマットのコネクション監視結果情報７０をトランザクション保証部４４へ通知する。コネクション監視結果情報７０は、通知情報種別コード（Ｘ’０３’）および通知コード（Ｘ’００’またはＸ’０１’）から構成されている。通知種別コードは、コネクションが解放されたことを通知するためのコードである。通知コードは、コネクションの解放時に正常解放されたかまたは異常切断されたかを通知するためのコードである。
【００５２】
リクエスト受信部４２は、クライアント３０1〜３０nからのリクエストを受信する機能を備えている。リプライ送信部４３は、上記リクエストに対する返信としてのリプライデータ（図５（ｂ）参照）をＯＲＢ４１へ送信する機能を備えている。トランザクション保証部４４は、コネクションの異常切断時に伴うクライアント側のトランザクション不整合を回避し、トランザクションを保証する機能を備えている。また、トランザクション保証部４４は、ＯＲＢ４１からのコネクション監視結果情報７０（異常解放の場合）に基づいて、通知リプライ情報９０1〜９０nをクライアント３０1〜３０nへ送信する機能を備えている。
【００５３】
つぎに、上述した一実施の形態の動作について図２〜図７を参照して説明する。図２は、本発明にかかる一実施の形態の動作を説明するシーケンス図である。はじめに、クライアント３０nとサーバ４０との間における正常時の動作をメインにして説明する。なお、クライアント３０1〜クライアント３０n-1（図示略）とサーバ４０との間における動作は、以下に説明するクライアント３０nとサーバ４０との間における動作と同様である。
【００５４】
（正常時）
図３に示したステップＳＥ１では、トランザクション保証部４４は、サーバ４０のＯＲＢ４１からのリプライ情報（図７（ａ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００５５】
一方、図４に示したステップＳＦ１では、クライアント３０1〜３０nのトランザクション通知エージェント３４1〜３４nのそれぞれは、トランザクション保証部４４からの通知リプライ情報（図７（ｂ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００５６】
ここで、図２に示したステップＳＣ１で、クライアント３０nのリクエスト送信部３２nからリクエストが送信される。このとき、ＯＲＢ３１nは、図５（ａ）に示したリクエストＩＤ（ｎ）を取得し、これをリクエストに付加する。そして、リクエスト（リクエストＩＤ）は、サーバ４０のリクエスト受信部４２により受信される。
【００５７】
ステップＳＣ２では、リプライ送信部４３は、図５（ａ）に示したリプライデータ（ｎ）をＯＲＢ４１へ送信する。これにより、ステップＳＣ３では、ＯＲＢ４１は、図５（ａ）に示したリプライ情報５０nをトランザクション保証部４４へ送信する。このリプライ情報５０nは、トランザクション保証部４４に受信される。
【００５８】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ１の判断結果を「Ｙｅｓ」として、リプライ情報５０1をメモリ（図示略）に格納する。ステップＳＥ２では、トランザクション保証部４４は、ＯＲＢ４１からのコネクション監視結果情報７０（図５（ｂ）参照）を受信したか否かを判断し、この判断結果が判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００５９】
つぎに、図２に示したステップＳＣ４では、ＯＲＢ４１は、上記リプライ情報５０nをクライアント３０nのリプライ受信部３３nへ送信する。このリプライ情報５０nは、リプライ受信部３３nに受信された後、メモリ（図示略）に格納される。
【００６０】
そして、クライアント３０nとサーバ４０との間のコネクションが正常解放されると、ステップＳＣ６では、ＯＲＢ４１は、コネクション正常解放通知として、コネクション監視結果情報７０（図５（ｃ）参照）をトランザクション保証部４４へ送信する。このコネクション監視結果情報７０（正常解放）は、トランザクション保証部４４により受信される。
【００６１】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ２の判断結果を「Ｙｅｓ」とする。ステップＳＥ３では、トランザクション保証部４４は、受信したコネクション監視結果情報７０の通知コードを参照し、コネクションが正常に解放されたか否かを判断し、この場合、判断結果を「Ｙｅｓ」とする。ステップＳＥ４では、トランザクション保証部４４は、メモリに格納されているリプライ情報５０n（図５（ａ）参照）を破棄する。
【００６２】
（異常時）
つぎに、図１に示したクライアント３０nとサーバ４０との間に設定されているコネクションが異常切断した場合について説明する。図３に示したステップＳＥ１では、トランザクション保証部４４は、サーバ４０のＯＲＢ４１からのリプライ情報（図７（ａ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００６３】
一方、図４に示したステップＳＦ１では、クライアント３０1〜３０nのトランザクション通知エージェント３４1〜３４nのそれぞれは、トランザクション保証部４４からの通知リプライ情報（図７（ｂ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００６４】
ここで、図２に示したステップＳＤ１で、クライアント３０nのリクエスト送信部３２nからリクエストが送信される。このとき、ＯＲＢ３１nは、図５（ａ）に示したリクエストＩＤ（ｎ）を取得し、これをリクエストに付加する。そして、リクエスト（リクエストＩＤ）は、サーバ４０のリクエスト受信部４２により受信される。
【００６５】
ステップＳＤ２では、リプライ送信部４３は、図５（ａ）に示したリプライデータ（ｎ）をＯＲＢ４１へ送信する。これにより、ステップＳＤ３では、ＯＲＢ４１は、図５（ａ）に示したリプライ情報５０nをトランザクション保証部４４へ送信する。このリプライ情報５０nは、トランザクション保証部４４に受信される。
【００６６】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ１の判断結果を「Ｙｅｓ」として、リプライ情報５０1をメモリ（図示略）に格納する。ステップＳＥ２では、トランザクション保証部４４は、ＯＲＢ４１からのコネクション監視結果情報７０（図５（ｂ）参照）を受信したか否かを判断し、この判断結果が判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００６７】
つぎに、図２に示したステップＳＤ４では、ＯＲＢ４１は、上記リプライ情報５０nをクライアント３０nのリプライ受信部３３nへ送信する。このリプライ情報５０nは、リプライ受信部３３nに受信された後、メモリ（図示略）に格納される。
【００６８】
ここで、クライアント３０nとサーバ４０との間のコネクションが異常切断されると、ステップＳＤ６では、ＯＲＢ４１は、コネクション異常切断通知として、コネクション監視結果情報７０（図５（ｃ）参照）をトランザクション保証部４４へ送信する。このとき、トランザクションの不整合が発生する。上記コネクション監視結果情報７０（異常切断）は、トランザクション保証部４４により受信される。
【００６９】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ２の判断結果を「Ｙｅｓ」とする。ステップＳＥ３では、トランザクション保証部４４は、受信したコネクション監視結果情報７０の通知コードを参照し、コネクションが正常に解放されたか否かを判断し、この場合、判断結果を「Ｎｏ」とする。ステップＳＥ５では、トランザクション保証部４４は、コネクション異常切断に対応するＩＰアドレスおよびポート番号をキーにして、メモリに格納されている（複数の）リプライ情報から、コネクション異常切断に対応するリプライ情報５０n（図５（ａ）参照）を検索する。
【００７０】
ステップＳＥ６（図２：ステップＳＤ７）では、トランザクション保証部４４は、リプライ情報５０nに対応する通知リプライ情報９０n（図７（ｂ）参照）をクライアント３０nのトランザクション通知エージェント３４nへ送信する。この通知リプライ情報９０nは、トランザクション通知エージェント３４nにより受信される。
【００７１】
これにより、トランザクション通知エージェント３４nは、図４に示したステップＳＦ１の判断結果を「Ｙｅｓ」とする。ステップＳＦ２では、トランザクション通知エージェント３４1は、受信した通知リプライ情報９０nのクライアントアプリケーション名（リクエストＩＤでも良い）をキーとして、メモリに格納されている複数のリプライ情報の中から、コネクション異常切断に対応する通知リプライ情報９０nを検索する。ステップＳＦ４では、トランザクション通知エージェント３４1は、上記通知リプライ情報９０nのリプライデータに基づいて、トランザクションの整合をとる。
【００７２】
なお、一実施の形態においては、図３に示したステップＳＥ５でリプライ情報を検索し、検索されたリプライ情報に対応する通知リプライ情報をトランザクション通知エージェントへ送信する例について説明したが、図６に示したステップＳＧ５のように検索することなく、メモリに格納されている全リプライ情報をトランザクション通知エージェントへ送信するようにしてもよい。図６に示したステップＳＧ１〜ステップＳＧ４は、図３に示したステップＳＥ１〜ステップＳＥ４に対応している。
【００７３】
以上説明したように、一実施の形態によれば、クライアント３０ 1 〜３０ n からトランザクション処理の実行を依頼するリクエストがあった場合にデータベース４５を更新し、リクエストに対応する通知リプライ情報をクライアント３０1〜３０nへ送信するとともに、メモリに格納しておき、コネクションの異常切断時に当該通知リプライ情報をクライアント３０1〜３０nへ送信するようにしたので、従来のクライアント３０1〜３０nからのロールバックの場合に比べて、ネットワークのトラフィック量を低減でき、通信の異常発生時の通信負荷を低減させることができる。
【００７４】
また、一実施の形態によれば、コネクションが正常解放された場合に、メモリに格納されたリプライ情報を破棄するようにしたので、メモリの利用効率を向上させることができる。
【００７５】
また、一実施の形態によれば、通知リプライ情報にリクエストを識別するためのリクエストＩＤを含ませるようにしたので、このリクエストＩＤに基づいて、コネクションの異常切断に対応するリクエストを容易に特定することができ、異常切断に伴うトランザクションの整合をとることができる。
【００７６】
以上本発明にかかる一実施の形態について図面を参照して詳述してきたが、具体的な構成例はこの一実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。
【００７７】
例えば、前述した一実施の形態においては、サーバ４０の機能を実現するためのデータ通信プログラムを図８に示したコンピュータ読み取り可能な記録媒体２００に記録して、この記録媒体２００に記録されたデータ通信プログラムを同図に示したコンピュータ１００に読み込ませ、実行することによりサーバ４０の機能を実現するようにしてもよい。
【００７８】
図８に示したコンピュータ１００は、上記データ通信プログラムを実行するＣＰＵ（Central Processing Unit）１０１と、キーボード、マウス等の入力装置１０２と、各種データを記憶するＲＯＭ（Read Only Memory）１０３と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）１０４と、記録媒体２００からデータ通信プログラムを読み取る読取装置１０５と、ディスプレイ、プリンタ等の出力装置１０６と、装置各部を接続するバスＢＵとから構成されている。
【００７９】
ＣＰＵ１０１は、読取装置１０５を経由して記録媒体２００に記録されているデータ通信プログラムを読み込んだ後、データ通信プログラムを実行することにより、前述したサーバ４０の機能を実現する。なお、記録媒体２００には、光ディスク、フロッピー（登録商標）ディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【００８０】
【発明の効果】
以上説明したように、本発明によれば、外部装置からトランザクション処理の実行を依頼するリクエストがあった場合にデータベースを更新し、リクエストに対応するリプライ情報を外部装置へ送信するとともに、メモリに格納しておき、コネクションの異常切断時に当該リプライ情報を外部装置へ送信するようにしたので、従来の外部装置からのロールバックの場合に比べて、通信回線のトラフィック量を低減でき、通信の異常発生時の通信負荷を低減させることができるという効果を奏する。
【００８１】
また、本発明によれば、コネクションが正常解放された場合に、メモリに格納されたリプライ情報を破棄するようにしたので、メモリの利用効率を向上させることができるという効果を奏する。
【００８２】
また、本発明によれば、リプライ情報にリクエストを識別するための識別情報を含ませるようにしたので、この識別情報に基づいて、コネクションの異常切断に対応するリクエストを容易に特定することができ、異常切断に伴うトランザクションの整合をとることができるという効果を奏する。
【図面の簡単な説明】
【図１】 本発明にかかる一実施の形態の構成を示すブロック図である。
【図２】 同一実施の形態の動作を説明するシーケンス図である。
【図３】 図１に示したトランザクション保証部４４の動作を説明するフローチャートである。
【図４】 図１に示したトランザクション通知エージェント３４1〜３４nの動作を説明するフローチャートである。
【図５】 同一実施の形態で用いられるリプライ情報およびコネクション通知情報のフォーマットを示す図である。
【図６】 図１に示したトランザクション保証部４４の動作を説明するフローチャートである。
【図７】 同一実施の形態で用いられるリプライ情報のフォーマットを示す図である。
【図８】 同一実施の形態の変形例を示すブロック図である。
【図９】 従来のＣＯＲＢＡ通信システムの構成を示すブロック図である。
【図１０】 従来のＣＯＲＢＡ通信システムの動作を説明するシーケンス図である。
【符号の説明】
３０1 〜３０n クライアント
３１1 〜３１n ＯＲＢ
３２1 〜３２n リクエスト送信部
３３1 〜３３n リプライ受信部
３４1 〜３４n トランザクション通知エージェント
４０ サーバ
４１ ＯＲＢ
４２ リクエスト受信部
４３ リプライ送信部
４４ トランザクション保証部
１００ コンピュータ
１０１ ＣＰＵ
２００ 記録媒体
【発明の属する技術分野】
本発明は、通信の異常発生時の通信負荷を低減させることができるデータ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
近時、クライアント／サーバ構成のデータ通信装置が主流になっている。このようなデータ通信装置においては、クライアントの数が増えるに従って、通信負荷が増えるため、通信負荷をできるだけ増やさない手段、方法が切望されている。
【０００３】
【従来の技術】
図９は、従来のＣＯＲＢＡ（Common Object Request Broker Architecture）通信システムの構成を示すブロック図である。ＣＯＲＢＡは、標準化団体ＯＭＧ(Object Management Group）が定める異機種間接続のための標準化仕様であり、異機種間の連携プロトコルと分散アプリケーション構築のための各種ＡＰＩ（Application Program Interface)を規定するものである。
【０００４】
簡単に言えば、ＣＯＲＢＡは、分散システム環境でクライアントが、サーバ内のオブジェクト（例えば、アプリケーションプログラム）にアクセスするためのメカニズムを提供する標準技術である。ここで、ＣＯＲＢＡにおけるオブジェクトとは、クライアントから要求することができる一つまたは複数のサービスを提供する、識別可能にカプセル化されたエンティティをいう。
【０００５】
図９には、ｎ台のクライアント１０1〜１０nと、これらのクライアント１０1〜１０nとネットワーク（図示略）を介して接続されたサーバ２０とからなるＣＯＲＢＡ通信システムが図示されている。クライアント１０1〜１０nのそれぞれは、所定のプロトコルに従って、サーバ２０との間で通信を行う。このプロトコルにおいては、リクエスト、リプライ、コミット、ロールバックという処理が発生する。
【０００６】
リクエストは、クライアント１０1〜１０nのそれぞれからサーバ２０のトランザクション処理を依頼するためのものである。トランザクションの発生のデータベース２５の更新依頼を行うためのものである。リプライは、上記リクエストに対する返信であり、サーバ２０からクライアント１０1〜１０nへ通知されるものである。コミットは、クライアント１０1〜１０nのそれぞれの処理結果をデータベース２５に反映させるためのものである。リプライは、クライアント１０1〜１０nとサーバ２０との間のコネクションが異常切断された場合に、データベース２５を、トランザクションが実行される前の状態に戻し、一貫性を保つためのものである。
【０００７】
クライアント１０1において、ＯＲＢ（Object Request Broker：分散オブジェクト間通信機構）１１1は、クライアント１０1とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ１１1は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【０００８】
ここで、ＣＯＲＢＡにおけるネーミングサービスについて説明する。ＣＯＲＢＡにおけるネーミングサービスによれば、クライアントは、オブジェクトにアクセスする場合、オブジェクトの位置ではなく、名前でアクセスできるようになるため、オブジェクトの物理的な位置を意識する必要がない。
【０００９】
具体的には、クライアントからアクセスがあった場合、サーバ２０内でオブジェクトリファレンスが生成され、これがクライアントに返されることにより、ネーミングサービスが提供される。このオブジェクトリファレンスは、オブジェクトを名前で一意に識別するための情報である。
【００１０】
リクエスト送信部１２1は、上述したリクエストをサーバ２０へ送信する機能を備えている。リプライ受信部１３1は、サーバ２０からのリプライを受信する機能を備えている。このリプライは、上記リクエストに対する返信である。コミット／ロールバック送信部１４1は、上述したコミットまたはロールバックをサーバ２０へ送信する機能を備えている。
【００１１】
クライアント１０2において、ＯＲＢ１１2は、ＯＲＢ１１1と同様にして、クライアント１０2とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ１１2は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００１２】
リクエスト送信部１２2は、上述したリクエストをサーバ２０へ送信する機能を備えている。リプライ受信部１３2は、サーバ２０からのリプライを受信する機能を備えている。このリプライは、上記リクエストに対する返信である。コミット／ロールバック送信部１４2は、上述したコミットまたはロールバックをサーバ２０へ送信する機能を備えている。
【００１３】
クライアント１０nにおいて、ＯＲＢ１１nは、ＯＲＢ１１1と同様にして、クライアント１０nとサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ１１nは、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００１４】
リクエスト送信部１２nは、上述したリクエストをサーバ２０へ送信する機能を備えている。リプライ受信部１３nは、サーバ２０からのリプライを受信する機能を備えている。このリプライは、上記リクエストに対する返信である。コミット／ロールバック送信部１４nは、上述したコミットまたはロールバックをサーバ２０へ送信する機能を備えている。
【００１５】
サーバ２０は、クライアント１０1〜１０nからのリクエストを受信する機能と、上記リクエストに対する返信としてのリプライをクライアント１０1〜１０nへ送信する機能と、クライアント１０1〜１０nからのコミットを受信する機能と、上記コミットに基づいてデータベース２５を更新する機能と、クライアント１０1〜１０nからのロールバックを受信する機能と、上記ロールバックに基づいてデータベース２５を、トランザクションが実行される前の状態に戻す機能とを備えている。
【００１６】
具体的には、サーバ２０は、ＯＲＢ２１、リクエスト受信部２２、リプライ送信部２３、コミット／ロールバック受信部２４およびデータベース２５から構成されている。ＯＲＢ２１は、サーバ２０とクライアント１０1〜１０nとを仲介するソフトウェア・バスである。リクエスト受信部２２は、クライアント１０1〜１０nからのリクエストを受信する機能を備えている。
【００１７】
リプライ送信部２３は、上記リクエストに対する返信としてのリプライをクライアント１０1〜１０nへ送信する機能を備えている。コミット／ロールバック受信部２４は、クライアント１０1〜１０nからのコミットを受信する機能と、上記コミットに基づいてデータベース２５を更新する機能と、クライアント１０1〜１０nからのロールバックを受信する機能と、上記ロールバックに基づいてデータベース２５を、トランザクションが実行される前の状態に戻す機能とを備えている。
【００１８】
つぎに、上述した従来のＣＯＲＢＡ通信システムの動作について図１０を参照しつつ説明する。図１０は、従来のＣＯＲＢＡ通信システムの動作を説明するシーケンス図である。はじめに、クライアント１０nとサーバ２０との間における正常時の動作について説明する。なお、クライアント１０1〜クライアント１０n-1（図示略）とサーバ２０との間における動作は、以下に説明するクライアント１０nとサーバ２０との間における動作と同様である。
【００１９】
（正常時）
図１０に示したステップＳＡ１では、クライアント１０nのリクエスト送信部１２nからリクエストが送信されると、サーバ２０のリクエスト受信部２２によりリクエストが受信される。
【００２０】
これにより、ステップＳＡ２では、サーバ２０のリプライ送信部２３からリプライが送信されると、リプライ受信部１３nによりリプライが受信される。ステップＳＡ３では、コミット／ロールバック送信部１４nによりコミットが送信されると、コミット／ロールバック受信部２４によりコミットが受信される。これにより、サーバ２０では、データベース２５が更新される。
【００２１】
（異常時）
つぎに、図９に示したクライアント１０nとサーバ２０との間に設定されているコネクションが異常切断した場合について説明する。図１０に示したステップＳＢ１では、クライアント１０nのリクエスト送信部１２nからリクエストが送信されると、サーバ２０のリクエスト受信部２２によりリクエストが受信される。これにより、ステップＳＢ２では、サーバ２０のリプライ送信部２３からリプライが送信される。
【００２２】
ここで、コネクションが異常切断するとトランザクション不整合が発生し、上記リプライは、リプライ受信部１３nに受信されない。この場合、ステップＳＢ３では、コミット／ロールバック送信部１４nによりロールバックが送信されると、コミット／ロールバック受信部２４によりロールバックが受信される。これにより、サーバ２０では、データベース２５が、トランザクションが実行される前の状態に戻される。すなわち、異常時には、データベース２５が更新されない。
【００２３】
【発明が解決しようとする課題】
ところで、前述したように、従来のＣＯＲＢＡ通信システムでは、通信の異常発生時に、クライアント１０1〜１０nとサーバ２０との間で、コミット／ロールバックのための通信が必要であるため、クライアント数が増えるに従って、通信負荷（トランザクション）が増大するという問題があった。特に、ネットワークの回線容量が少ない場合にボトルネックとなる。
【００２４】
本発明は、上記に鑑みてなされたもので、通信の異常発生時の通信負荷を低減させることができるデータ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２５】
【課題を解決するための手段】
上記目的を達成するために、本発明は、外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信装置において、前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新手段と、前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ手段と、前記外部通信装置との間のコネクションを監視するコネクション監視手段と、前記コネクション監視手段の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信手段とを備えたことを特徴とする。
【００２６】
また、本発明は、外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信方法において、前記外部通信装置からトランザクション処理の実行を依 頼するリクエストがあった場合に前記データベースを更新するデータベース更新工程と、前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ工程と、前記外部通信装置との間のコネクションを監視するコネクション監視工程と、前記コネクション監視工程の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信工程とを含むことを特徴とする。
【００２７】
また、本発明は、外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信装置に適用されるデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新工程と、前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ工程と、前記外部通信装置との間のコネクションを監視するコネクション監視工程と、前記コネクション監視工程の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信工程と、をコンピュータに実行させるためのデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００２８】
かかる発明によれば、外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合にデータベースを更新し、リクエストに対応するリプライ情報を外部通信装置へ送信するとともにメモリに格納しておき、コネクションの異常切断時に当該リプライ情報を外部通信装置へ送信するようにしたので、従来の外部装置からのロールバックの場合に比べて、通信回線のトラフィック量を低減でき、通信の異常発生時の通信負荷を低減させることができる。
【００２９】
【発明の実施の形態】
以下、図面を参照して本発明にかかるデータ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体の一実施の形態について詳細に説明する。
【００３０】
図１は、本発明にかかる一実施の形態の構成を示すブロック図である。同図には、ｎ台のクライアント３０1〜３０nと、これらのクライアント３０1〜３０nとネットワーク（図示略）を介して接続されたサーバ２０とからなるＣＯＲＢＡを利用したデータ通信が図示されている。クライアント３０1〜３０nのそれぞれは、所定のプロトコルに従って、サーバ２０との間で通信を行う。ここで、注意すべき点は、前述した従来のＣＯＲＢＡ通信システム（図９参照）に比較して、コミット／ロールバックという通信負荷を増加させる要因が無いことである。
【００３１】
クライアント３０1において、ＯＲＢ３１1は、クライアント３０1とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ３１1は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００３２】
リクエスト送信部３２1は、上述したリクエストをサーバ２０へ送信する機能を備えている。ここで、ＯＲＢ３１1は、リクエストの送信時に当該リクエストを識別するためのリクエストＩＤを取得し、これをリクエストに付加する。リプライ受信部３３1は、図５（ａ）に示したリプライ情報５０1を受信する。
【００３３】
このリプライ情報５０1は、ＩＰアドレス（１）、ポート番号（１）、リクエストＩＤ（１）、クライアントアプリケーション名（１）およびリプライデータ（１）から構成されている。このリプライ情報５０1は、リクエストに対する返信として、後述するリプライ送信部４３から送信される情報である。
【００３４】
ここで、上記リクエストＩＤは、ＯＲＢ３１1により取得されたリクエストＩＤである。クライアントアプリケーション（１）は、クライアント３０1のリクエスト送信部３２1およびリプライ受信部３３1の名称である。リプライデータ（１）は、サーバ４０のリプライ送信部４３から送信されるデータである。
【００３５】
トランザクション通知エージェント３４1は、図５（ｂ）に示したフォーマットの通知リプライ情報６０に基づいて、コネクション異常切断によるクライアント３０1側のトランザクションの整合をとる機能を備えている。通知リプライ情報６０は、リクエストＩＤ、クライアントアプリケーション名およびリプライデータから構成されている。
【００３６】
図７（ｂ）に通知リプライ情報６０の具体例を示す。通知リプライ情報９０1は、クライアント３０1とサーバ４０との間でコネクション異常切断が発生した場合に、後述するトランザクション保証部４４から送信される情報であり、リクエストＩＤ（１）、クライアントアプリケーション名（１）およびリプライデータ（１）から構成されている。この通知リプライ情報９０1は、図５（ａ）に示したリプライ情報５０1に対応している。トランザクション通知エージェント３４1は、通知リプライ情報９０1からコネクション異常切断時のリクエストを特定し、この特定結果に基づいて、トランザクションの整合をとる。
【００３７】
クライアント３０2において、ＯＲＢ３１2は、クライアント３０2とサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ３１2は、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００３８】
リクエスト送信部３２2は、上述したリクエストをサーバ２０へ送信する機能を備えている。ここで、ＯＲＢ３１2は、リクエストの送信時に当該リクエストを識別するためのリクエストＩＤを取得し、これをリクエストに付加する。リプライ受信部３３2は、図５（ａ）に示したリプライ情報５０2を受信する。
【００３９】
このリプライ情報５０2は、ＩＰアドレス（２）、ポート番号（２）、リクエストＩＤ（２）、クライアントアプリケーション名（２）およびリプライデータ（２）から構成されている。このリプライ情報５０2は、リクエストに対する返信として、後述するリプライ送信部４３から送信される情報である。
【００４０】
ここで、上記リクエストＩＤは、ＯＲＢ３１2により取得されたリクエストＩＤである。クライアントアプリケーション（２）は、クライアント３０2のリクエスト送信部３２2およびリプライ受信部３３2の名称である。リプライデータ（２）は、サーバ４０のリプライ送信部４３から送信されるデータである。
【００４１】
トランザクション通知エージェント３４2は、図７（ｂ）に示した通知リプライ情報９０2に基づいて、コネクション異常切断によるクライアント３０2側のトランザクションの整合をとる機能を備えている。通知リプライ情報９０2は、クライアント３０2とサーバ４０との間でコネクション異常切断が発生した場合に、後述するトランザクション保証部４４から送信される情報であり、リクエストＩＤ（２）、クライアントアプリケーション名（２）およびリプライデータ（２）から構成されている。
【００４２】
また、通知リプライ情報９０2は、図５（ａ）に示したリプライ情報５０2に対応している。トランザクション通知エージェント３４2は、通知リプライ情報９０2からコネクション異常切断時のリクエストを特定し、この特定結果に基づいて、トランザクションの整合をとる。
【００４３】
クライアント３０nにおいて、ＯＲＢ３１nは、クライアント３０nとサーバ２０とを仲介するソフトウェア・バスである。このＯＲＢ３１nは、自身のＩＰアドレスおよびＰＯＲＴ番号を含む初期オブジェクトリファレンスを有している。
【００４４】
リクエスト送信部３２nは、上述したリクエストをサーバ２０へ送信する機能を備えている。ここで、ＯＲＢ３１nは、リクエストの送信時に当該リクエストを識別するためのリクエストＩＤを取得し、これをリクエストに付加する。リプライ受信部３３nは、図５（ａ）に示したリプライ情報５０nを受信する。
【００４５】
このリプライ情報５０nは、ＩＰアドレス（ｎ）、ポート番号（ｎ）、リクエストＩＤ（ｎ）、クライアントアプリケーション名（ｎ）およびリプライデータ（ｎ）から構成されている。このリプライ情報５０nは、リクエストに対する返信として、後述するリプライ送信部４３から送信される情報である。
【００４６】
ここで、上記リクエストＩＤは、ＯＲＢ３１nにより取得されたリクエストＩＤである。クライアントアプリケーション（ｎ）は、クライアント３０nのリクエスト送信部３２nおよびリプライ受信部３３nの名称である。リプライデータ（ｎ）は、サーバ４０のリプライ送信部４３から送信されるデータである。なお、一実施の形態では、図５（ａ）に示したリプライ情報５０1〜５０nに代えて、図７（ｂ）に示したリプライ情報８０1〜８０nを用いてもよい。
【００４７】
トランザクション通知エージェント３４nは、図５（ｂ）に示した通知リプライ情報９０nに基づいて、コネクション異常切断によるクライアント３０n側のトランザクションの整合をとる機能を備えている。通知リプライ情報９０nは、クライアント３０nとサーバ４０との間でコネクション異常切断が発生した場合に、後述するトランザクション保証部４４から送信される情報であり、リクエストＩＤ（ｎ）、クライアントアプリケーション名（ｎ）およびリプライデータ（ｎ）から構成されている。
【００４８】
また、通知リプライ情報９０nは、図５（ａ）に示したリプライ情報５０nに対応している。トランザクション通知エージェント３４nは、通知リプライ情報９０nからコネクション異常切断時のリクエストを特定し、この特定結果に基づいて、トランザクションの整合をとる。
【００４９】
サーバ４０は、クライアント３０1〜３０nからのリクエストを受信する機能と、上記リクエストに対する返信としてのリプライ情報５０1〜５０nをクライアント３０1〜３０nへ送信する機能と、サーバ４０とクライアント３０1〜３０nとの間のコネクションを監視する機能と、データベース４５を更新する機能等を備えている。
【００５０】
具体的には、サーバ４０は、ＯＲＢ４１、リクエスト受信部４２、リプライ送信部４３、トランザクション保証部４４およびデータベース４５から構成されている。ＯＲＢ４１は、サーバ４０とクライアント３０1〜３０nとを仲介するソフトウェア・バスである。このＯＲＢ４１は、リプライ情報５０1〜５０n（図５（ａ）参照）を送信する機能と、サーバ４０とクライアント３０1〜３０nとの間のコネクションを監視する機能とを備えている。
【００５１】
まや、ＯＲＢ４１は、コネクションの監視結果として図５（ｃ）に示したフォーマットのコネクション監視結果情報７０をトランザクション保証部４４へ通知する。コネクション監視結果情報７０は、通知情報種別コード（Ｘ’０３’）および通知コード（Ｘ’００’またはＸ’０１’）から構成されている。通知種別コードは、コネクションが解放されたことを通知するためのコードである。通知コードは、コネクションの解放時に正常解放されたかまたは異常切断されたかを通知するためのコードである。
【００５２】
リクエスト受信部４２は、クライアント３０1〜３０nからのリクエストを受信する機能を備えている。リプライ送信部４３は、上記リクエストに対する返信としてのリプライデータ（図５（ｂ）参照）をＯＲＢ４１へ送信する機能を備えている。トランザクション保証部４４は、コネクションの異常切断時に伴うクライアント側のトランザクション不整合を回避し、トランザクションを保証する機能を備えている。また、トランザクション保証部４４は、ＯＲＢ４１からのコネクション監視結果情報７０（異常解放の場合）に基づいて、通知リプライ情報９０1〜９０nをクライアント３０1〜３０nへ送信する機能を備えている。
【００５３】
つぎに、上述した一実施の形態の動作について図２〜図７を参照して説明する。図２は、本発明にかかる一実施の形態の動作を説明するシーケンス図である。はじめに、クライアント３０nとサーバ４０との間における正常時の動作をメインにして説明する。なお、クライアント３０1〜クライアント３０n-1（図示略）とサーバ４０との間における動作は、以下に説明するクライアント３０nとサーバ４０との間における動作と同様である。
【００５４】
（正常時）
図３に示したステップＳＥ１では、トランザクション保証部４４は、サーバ４０のＯＲＢ４１からのリプライ情報（図７（ａ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００５５】
一方、図４に示したステップＳＦ１では、クライアント３０1〜３０nのトランザクション通知エージェント３４1〜３４nのそれぞれは、トランザクション保証部４４からの通知リプライ情報（図７（ｂ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００５６】
ここで、図２に示したステップＳＣ１で、クライアント３０nのリクエスト送信部３２nからリクエストが送信される。このとき、ＯＲＢ３１nは、図５（ａ）に示したリクエストＩＤ（ｎ）を取得し、これをリクエストに付加する。そして、リクエスト（リクエストＩＤ）は、サーバ４０のリクエスト受信部４２により受信される。
【００５７】
ステップＳＣ２では、リプライ送信部４３は、図５（ａ）に示したリプライデータ（ｎ）をＯＲＢ４１へ送信する。これにより、ステップＳＣ３では、ＯＲＢ４１は、図５（ａ）に示したリプライ情報５０nをトランザクション保証部４４へ送信する。このリプライ情報５０nは、トランザクション保証部４４に受信される。
【００５８】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ１の判断結果を「Ｙｅｓ」として、リプライ情報５０1をメモリ（図示略）に格納する。ステップＳＥ２では、トランザクション保証部４４は、ＯＲＢ４１からのコネクション監視結果情報７０（図５（ｂ）参照）を受信したか否かを判断し、この判断結果が判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００５９】
つぎに、図２に示したステップＳＣ４では、ＯＲＢ４１は、上記リプライ情報５０nをクライアント３０nのリプライ受信部３３nへ送信する。このリプライ情報５０nは、リプライ受信部３３nに受信された後、メモリ（図示略）に格納される。
【００６０】
そして、クライアント３０nとサーバ４０との間のコネクションが正常解放されると、ステップＳＣ６では、ＯＲＢ４１は、コネクション正常解放通知として、コネクション監視結果情報７０（図５（ｃ）参照）をトランザクション保証部４４へ送信する。このコネクション監視結果情報７０（正常解放）は、トランザクション保証部４４により受信される。
【００６１】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ２の判断結果を「Ｙｅｓ」とする。ステップＳＥ３では、トランザクション保証部４４は、受信したコネクション監視結果情報７０の通知コードを参照し、コネクションが正常に解放されたか否かを判断し、この場合、判断結果を「Ｙｅｓ」とする。ステップＳＥ４では、トランザクション保証部４４は、メモリに格納されているリプライ情報５０n（図５（ａ）参照）を破棄する。
【００６２】
（異常時）
つぎに、図１に示したクライアント３０nとサーバ４０との間に設定されているコネクションが異常切断した場合について説明する。図３に示したステップＳＥ１では、トランザクション保証部４４は、サーバ４０のＯＲＢ４１からのリプライ情報（図７（ａ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００６３】
一方、図４に示したステップＳＦ１では、クライアント３０1〜３０nのトランザクション通知エージェント３４1〜３４nのそれぞれは、トランザクション保証部４４からの通知リプライ情報（図７（ｂ）参照）を受信したか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００６４】
ここで、図２に示したステップＳＤ１で、クライアント３０nのリクエスト送信部３２nからリクエストが送信される。このとき、ＯＲＢ３１nは、図５（ａ）に示したリクエストＩＤ（ｎ）を取得し、これをリクエストに付加する。そして、リクエスト（リクエストＩＤ）は、サーバ４０のリクエスト受信部４２により受信される。
【００６５】
ステップＳＤ２では、リプライ送信部４３は、図５（ａ）に示したリプライデータ（ｎ）をＯＲＢ４１へ送信する。これにより、ステップＳＤ３では、ＯＲＢ４１は、図５（ａ）に示したリプライ情報５０nをトランザクション保証部４４へ送信する。このリプライ情報５０nは、トランザクション保証部４４に受信される。
【００６６】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ１の判断結果を「Ｙｅｓ」として、リプライ情報５０1をメモリ（図示略）に格納する。ステップＳＥ２では、トランザクション保証部４４は、ＯＲＢ４１からのコネクション監視結果情報７０（図５（ｂ）参照）を受信したか否かを判断し、この判断結果が判断結果が「Ｎｏ」である場合、同判断を繰り返す。
【００６７】
つぎに、図２に示したステップＳＤ４では、ＯＲＢ４１は、上記リプライ情報５０nをクライアント３０nのリプライ受信部３３nへ送信する。このリプライ情報５０nは、リプライ受信部３３nに受信された後、メモリ（図示略）に格納される。
【００６８】
ここで、クライアント３０nとサーバ４０との間のコネクションが異常切断されると、ステップＳＤ６では、ＯＲＢ４１は、コネクション異常切断通知として、コネクション監視結果情報７０（図５（ｃ）参照）をトランザクション保証部４４へ送信する。このとき、トランザクションの不整合が発生する。上記コネクション監視結果情報７０（異常切断）は、トランザクション保証部４４により受信される。
【００６９】
これにより、トランザクション保証部４４は、図３に示したステップＳＥ２の判断結果を「Ｙｅｓ」とする。ステップＳＥ３では、トランザクション保証部４４は、受信したコネクション監視結果情報７０の通知コードを参照し、コネクションが正常に解放されたか否かを判断し、この場合、判断結果を「Ｎｏ」とする。ステップＳＥ５では、トランザクション保証部４４は、コネクション異常切断に対応するＩＰアドレスおよびポート番号をキーにして、メモリに格納されている（複数の）リプライ情報から、コネクション異常切断に対応するリプライ情報５０n（図５（ａ）参照）を検索する。
【００７０】
ステップＳＥ６（図２：ステップＳＤ７）では、トランザクション保証部４４は、リプライ情報５０nに対応する通知リプライ情報９０n（図７（ｂ）参照）をクライアント３０nのトランザクション通知エージェント３４nへ送信する。この通知リプライ情報９０nは、トランザクション通知エージェント３４nにより受信される。
【００７１】
これにより、トランザクション通知エージェント３４nは、図４に示したステップＳＦ１の判断結果を「Ｙｅｓ」とする。ステップＳＦ２では、トランザクション通知エージェント３４1は、受信した通知リプライ情報９０nのクライアントアプリケーション名（リクエストＩＤでも良い）をキーとして、メモリに格納されている複数のリプライ情報の中から、コネクション異常切断に対応する通知リプライ情報９０nを検索する。ステップＳＦ４では、トランザクション通知エージェント３４1は、上記通知リプライ情報９０nのリプライデータに基づいて、トランザクションの整合をとる。
【００７２】
なお、一実施の形態においては、図３に示したステップＳＥ５でリプライ情報を検索し、検索されたリプライ情報に対応する通知リプライ情報をトランザクション通知エージェントへ送信する例について説明したが、図６に示したステップＳＧ５のように検索することなく、メモリに格納されている全リプライ情報をトランザクション通知エージェントへ送信するようにしてもよい。図６に示したステップＳＧ１〜ステップＳＧ４は、図３に示したステップＳＥ１〜ステップＳＥ４に対応している。
【００７３】
以上説明したように、一実施の形態によれば、クライアント３０ 1 〜３０ n からトランザクション処理の実行を依頼するリクエストがあった場合にデータベース４５を更新し、リクエストに対応する通知リプライ情報をクライアント３０1〜３０nへ送信するとともに、メモリに格納しておき、コネクションの異常切断時に当該通知リプライ情報をクライアント３０1〜３０nへ送信するようにしたので、従来のクライアント３０1〜３０nからのロールバックの場合に比べて、ネットワークのトラフィック量を低減でき、通信の異常発生時の通信負荷を低減させることができる。
【００７４】
また、一実施の形態によれば、コネクションが正常解放された場合に、メモリに格納されたリプライ情報を破棄するようにしたので、メモリの利用効率を向上させることができる。
【００７５】
また、一実施の形態によれば、通知リプライ情報にリクエストを識別するためのリクエストＩＤを含ませるようにしたので、このリクエストＩＤに基づいて、コネクションの異常切断に対応するリクエストを容易に特定することができ、異常切断に伴うトランザクションの整合をとることができる。
【００７６】
以上本発明にかかる一実施の形態について図面を参照して詳述してきたが、具体的な構成例はこの一実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。
【００７７】
例えば、前述した一実施の形態においては、サーバ４０の機能を実現するためのデータ通信プログラムを図８に示したコンピュータ読み取り可能な記録媒体２００に記録して、この記録媒体２００に記録されたデータ通信プログラムを同図に示したコンピュータ１００に読み込ませ、実行することによりサーバ４０の機能を実現するようにしてもよい。
【００７８】
図８に示したコンピュータ１００は、上記データ通信プログラムを実行するＣＰＵ（Central Processing Unit）１０１と、キーボード、マウス等の入力装置１０２と、各種データを記憶するＲＯＭ（Read Only Memory）１０３と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）１０４と、記録媒体２００からデータ通信プログラムを読み取る読取装置１０５と、ディスプレイ、プリンタ等の出力装置１０６と、装置各部を接続するバスＢＵとから構成されている。
【００７９】
ＣＰＵ１０１は、読取装置１０５を経由して記録媒体２００に記録されているデータ通信プログラムを読み込んだ後、データ通信プログラムを実行することにより、前述したサーバ４０の機能を実現する。なお、記録媒体２００には、光ディスク、フロッピー（登録商標）ディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【００８０】
【発明の効果】
以上説明したように、本発明によれば、外部装置からトランザクション処理の実行を依頼するリクエストがあった場合にデータベースを更新し、リクエストに対応するリプライ情報を外部装置へ送信するとともに、メモリに格納しておき、コネクションの異常切断時に当該リプライ情報を外部装置へ送信するようにしたので、従来の外部装置からのロールバックの場合に比べて、通信回線のトラフィック量を低減でき、通信の異常発生時の通信負荷を低減させることができるという効果を奏する。
【００８１】
また、本発明によれば、コネクションが正常解放された場合に、メモリに格納されたリプライ情報を破棄するようにしたので、メモリの利用効率を向上させることができるという効果を奏する。
【００８２】
また、本発明によれば、リプライ情報にリクエストを識別するための識別情報を含ませるようにしたので、この識別情報に基づいて、コネクションの異常切断に対応するリクエストを容易に特定することができ、異常切断に伴うトランザクションの整合をとることができるという効果を奏する。
【図面の簡単な説明】
【図１】 本発明にかかる一実施の形態の構成を示すブロック図である。
【図２】 同一実施の形態の動作を説明するシーケンス図である。
【図３】 図１に示したトランザクション保証部４４の動作を説明するフローチャートである。
【図４】 図１に示したトランザクション通知エージェント３４1〜３４nの動作を説明するフローチャートである。
【図５】 同一実施の形態で用いられるリプライ情報およびコネクション通知情報のフォーマットを示す図である。
【図６】 図１に示したトランザクション保証部４４の動作を説明するフローチャートである。
【図７】 同一実施の形態で用いられるリプライ情報のフォーマットを示す図である。
【図８】 同一実施の形態の変形例を示すブロック図である。
【図９】 従来のＣＯＲＢＡ通信システムの構成を示すブロック図である。
【図１０】 従来のＣＯＲＢＡ通信システムの動作を説明するシーケンス図である。
【符号の説明】
３０1 〜３０n クライアント
３１1 〜３１n ＯＲＢ
３２1 〜３２n リクエスト送信部
３３1 〜３３n リプライ受信部
３４1 〜３４n トランザクション通知エージェント
４０ サーバ
４１ ＯＲＢ
４２ リクエスト受信部
４３ リプライ送信部
４４ トランザクション保証部
１００ コンピュータ
１０１ ＣＰＵ
２００ 記録媒体
Claims (5)
- 外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信装置において、
前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新手段と、
前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ手段と、
前記外部通信装置との間のコネクションを監視するコネクション監視手段と、
前記コネクション監視手段の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信手段と、
を備えたことを特徴とするデータ通信装置。 - 前記コネクション監視手段の監視結果に基づいて、前記コネクションが正常解放された場合、前記メモリに格納されたリプライ情報を破棄するリプライ情報破棄手段を備えたことを特徴とする請求項１に記載のデータ通信装置。
- 前記リプライ情報には、前記リクエストを識別するための識別情報が含まれていることを特徴とする請求項１または２に記載のデータ通信装置。
- 外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信方法において、
前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新工程と、
前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ工程と、
前記外部通信装置との間のコネクションを監視するコネクション監視工程と、
前記コネクション監視工程の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信工程と、
を含むことを特徴とするデータ通信方法。 - 外部通信装置との間でデータ通信を行うことによりデータベースを更新するデータ通信装置に適用されるデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記外部通信装置からトランザクション処理の実行を依頼するリクエストがあった場合に前記データベースを更新するデータベース更新工程と、
前記リクエストに対応するリプライ情報を前記外部通信装置へ送信するとともにメモリに格納するリプライ工程と、
前記外部通信装置との間のコネクションを監視するコネクション監視工程と、
前記コネクション監視工程の監視結果に基づいて、前記コネクションが異常切断された場合、前記メモリに格納された、当該コネクションに対応するリプライ情報を前記外部通信装置へ送信する送信工程と、
をコンピュータに実行させるためのデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000305303A JP3776706B2 (ja) | 2000-10-04 | 2000-10-04 | データ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体 |
| US09/804,907 US20020040385A1 (en) | 2000-10-04 | 2001-03-13 | Method and device for data communication, and a computer product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000305303A JP3776706B2 (ja) | 2000-10-04 | 2000-10-04 | データ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002118620A JP2002118620A (ja) | 2002-04-19 |
| JP3776706B2 true JP3776706B2 (ja) | 2006-05-17 |
Family
ID=18786191
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000305303A Expired - Fee Related JP3776706B2 (ja) | 2000-10-04 | 2000-10-04 | データ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20020040385A1 (ja) |
| JP (1) | JP3776706B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9258391B2 (en) | 2009-05-29 | 2016-02-09 | Canon Kabushiki Kaisha | Processing method and apparatus |
| JP5432595B2 (ja) * | 2009-05-29 | 2014-03-05 | キヤノン株式会社 | 通信装置及びその処理方法 |
| US11157517B2 (en) * | 2016-04-18 | 2021-10-26 | Amazon Technologies, Inc. | Versioned hierarchical data structures in a distributed data store |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5101402A (en) * | 1988-05-24 | 1992-03-31 | Digital Equipment Corporation | Apparatus and method for realtime monitoring of network sessions in a local area network |
| JP2865675B2 (ja) * | 1988-09-12 | 1999-03-08 | 株式会社日立製作所 | 通信ネットワーク制御方法 |
| US5680549A (en) * | 1994-12-30 | 1997-10-21 | Compuserve Incorporated | System for transferring network connections from first to second program where the first enters an inactive state and resumes control of connections when second terminates |
| US5835721A (en) * | 1995-08-21 | 1998-11-10 | Apple Computer, Inc. | Method and system for data transmission over a network link between computers with the ability to withstand temporary interruptions |
| US5802258A (en) * | 1996-05-03 | 1998-09-01 | International Business Machines Corporation | Loosely coupled system environment designed to handle a non-disruptive host connection switch after detection of an error condition or during a host outage or failure |
| US5835724A (en) * | 1996-07-03 | 1998-11-10 | Electronic Data Systems Corporation | System and method for communication information using the internet that receives and maintains information concerning the client and generates and conveys the session data to the client |
| US6167025A (en) * | 1996-09-11 | 2000-12-26 | Telcordia Technologies, Inc. | Methods and apparatus for restoring connections in an ATM network |
| US5796952A (en) * | 1997-03-21 | 1998-08-18 | Dot Com Development, Inc. | Method and apparatus for tracking client interaction with a network resource and creating client profiles and resource database |
| JPH114244A (ja) * | 1997-04-15 | 1999-01-06 | Yazaki Corp | ネットワークの異常監視方法、及び異常監視システム |
| US6223289B1 (en) * | 1998-04-20 | 2001-04-24 | Sun Microsystems, Inc. | Method and apparatus for session management and user authentication |
| US6141414A (en) * | 1998-05-08 | 2000-10-31 | Conexant Systems, Inc. | Data access arrangement having combined remote hang-up/ring detection circuitry |
| US6625657B1 (en) * | 1999-03-25 | 2003-09-23 | Nortel Networks Limited | System for requesting missing network accounting records if there is a break in sequence numbers while the records are transmitting from a source device |
| US6614756B1 (en) * | 1999-08-20 | 2003-09-02 | 3Com Corporation | Method of detecting and recovering from signaling congestion in an asynchronous transfer mode network |
| US6671729B1 (en) * | 2000-04-13 | 2003-12-30 | Lockheed Martin Corporation | Autonomously established secure and persistent internet connection and autonomously reestablished without user intervention that connection if it lost |
-
2000
- 2000-10-04 JP JP2000305303A patent/JP3776706B2/ja not_active Expired - Fee Related
-
2001
- 2001-03-13 US US09/804,907 patent/US20020040385A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20020040385A1 (en) | 2002-04-04 |
| JP2002118620A (ja) | 2002-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5805798A (en) | Fail-safe event driven transaction processing system and method | |
| US7676616B2 (en) | Method, apparatus and program storage device for providing asynchronous status messaging in a data storage system | |
| JP3213766B2 (ja) | レプリケートファイル更新システム | |
| US5784617A (en) | Resource-capability-based method and system for handling service processor requests | |
| JP4144897B2 (ja) | 共通作業キュー環境における最適格サーバ | |
| US6999997B2 (en) | Method and apparatus for communication of message data using shared queues | |
| US7899897B2 (en) | System and program for dual agent processes and dual active server processes | |
| US7814176B2 (en) | System and method for processing transactions in a multisystem database environment | |
| JPH10149296A (ja) | サーバ・コンピュータ集約トポロジーを識別するための方法及び装置 | |
| TW201240413A (en) | Lightweight input/output protocol | |
| US6732360B1 (en) | System and method for providing connection between client and heterogeneous database management systems | |
| US7500251B2 (en) | Method and system for managing programs for web service system | |
| US20060056433A1 (en) | Message processing and content based searching for message locations in an asynchronous network | |
| US8141103B2 (en) | Solution for modifying a queue manager to support smart aliasing which permits extensible software to execute against queued data without application modifications | |
| CN104580428A (zh) | 一种数据路由方法、数据管理装置和分布式存储系统 | |
| JP3776706B2 (ja) | データ通信装置、データ通信方法およびデータ通信プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| US6578115B2 (en) | Method and apparatus for handling invalidation requests to processors not present in a computer system | |
| US7249163B2 (en) | Method, apparatus, system and computer program for reducing I/O in a messaging environment | |
| KR102598619B1 (ko) | 데이터베이스 관리 서비스 제공 시스템 | |
| JP4222065B2 (ja) | 情報システムにおけるデータアクセス方法および情報システム | |
| JP4536292B2 (ja) | ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 | |
| JP2002032236A (ja) | データ通信装置及びそのデータ通信方法 | |
| KR100316841B1 (ko) | 관리 대행자의 재실행방법 및 장치 | |
| JP3939930B2 (ja) | オブジェクトリファレンス生成装置、オブジェクトリファレンス生成方法およびオブジェクトリファレンス生成プログラムを記録したコンピュータ読み取り可能な記録媒体、並びにオブジェクトリファレンス生成プログラム | |
| JPH11110365A (ja) | ネットワーク計算機システム、該システムで用いる計算機、および該システムに係る方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050307 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050315 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050513 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050614 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050823 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060221 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060223 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100303 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100303 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110303 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110303 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120303 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130303 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130303 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140303 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |