JP2008226127A

JP2008226127A - 分散処理におけるメッセージングの高信頼化装置及び高信頼化方法

Info

Publication number: JP2008226127A
Application number: JP2007066786A
Authority: JP
Inventors: Hitoshi Sumiyoshi; 仁住吉; Kazuhiro Kawagome; 和宏河込
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2007-03-15
Filing date: 2007-03-15
Publication date: 2008-09-25

Abstract

【課題】メッセージの送受信における高信頼化が図られていないクライアントとサーバ間においても簡易に高信頼化を実現できる高信頼化装置及び高信頼化方法を提供する。
【解決手段】クライアントとサーバの間に送受信制御部とＩＯＲテーブルを有する高信頼化装置を接続する。送受信制御部はクライアントからあて先情報とオブジェクトのリクエストを受け取るとＩＯＲテーブルを参照して対応するサーバＩＯＲを読み込む。さらに、高信頼化装置はＰｉｎｇとＫｅｅｐ＿Ａｌｉｖｅを使用してサーバと高信頼化装置の通信の接続を確認する。接続が確認されたとき、送受信制御部はサーバにメッセージを送信する。サーバからの応答は高信頼化装置に送信され、高信頼化装置がクライアントに送信するように構成しても、サーバから直接クライアントに送信するように構成してもよい。
【選択図】図１

Description

本発明は分散処理を行うオブジェクト・リクエスト・ブローカが実装されているサーバ及びクライアント間のメッセージングの信頼性を高める高信頼化装置及び高信頼化方法に関する。

複数のコンピュータを接続して異なるコンピュータに存在するオブジェクトを呼び出す分散オブジェクト技術においては、オブジェクトの呼び出しに際して接続が切断された場合の対処が問題となる。例えば、接続が切断されているにもかかわらずクライアントからサーバに対してオブジェクトを要求するリクエストが送信されると、そのリクエストは喪失され、クライアントにおいてリクエストを送信したプログラムは応答を待ち続ける。

この問題に関しては従来より多くの技術が開発されてきた。例えば、サーバ側においてオブジェクトを送信するプログラムと、クライアント側においてオブジェクトを要求するプログラムとの間に接続の確認とオブジェクトの授受に関するプロトコルを設定し、このプロトコルに従って、サーバ側とクライアント側のプログラムを開発するという方法が考えられる。しかし、この方法は開発工数が非常にかかるという問題点がある。

また、ＯＳレベルの方法としてＴＣＰ／ＩＰのＰｉｎｇやＫｅｅｐ＿Ａｌｉｖｅを用いて接続を確認することが考えられる。これらを実行する頻度は通常１時間から１０分に１回程度である。しかし、上記問題の解決のためにはから０．１秒に１回程度まで頻度を高める必要がある。このように高頻度にＰｉｎｇやＫｅｅｐ＿Ａｌｉｖｅを行うと、クライアントにおいて動作している他のプログラムの実行速度に悪影響がある。

より少ない開発工数によってこの問題を解決するための製品が従来より販売されている。例えば、特許文献１にはマイクロソフト社のＣＯＭ＋に関する仕様が詳細に記載されている。
特表２００２−５２２８４３号公報

しかし、特許文献１に記載の技術を活用するためにはＣＯＭ＋を実装しているマイクロソフト社のＯＳをサーバとクライアントにインストールし、ＣＯＭ＋をサポートする開発言語によって既にあるソフトウエア資産を作り直し、ＣＯＭ＋が利用できるようにオブジェクトを登録する必要がある。このため、作業工数とコストがかかるという問題点があった。

本発明は上記のような問題点に鑑みてなされたものであり、メッセージの送受信における高信頼化が図られていないクライアントとサーバ間においても簡易に高信頼化を実現できる高信頼化装置及び高信頼化方法を提供することを目的とする。

この目的を達成するために、請求項１に記載の発明は分散処理を行うオブジェクト・リクエスト・ブローカが実装されているサーバ及びクライアントとの間に接続され、サーバ及びクライアントとメッセージの送受信を行う高信頼化装置であって、サーバへのあて先情報を含むサーバＩＯＲとサーバへのあて先情報を高信頼化装置に変更したあて先情報を含む代理ＩＯＲとを格納するＩＯＲテーブルと；メッセージの送受信を制御する送受信制御部と；を備え、送受信制御部が、クライアントから代理ＩＯＲとオブジェクトを要求するリクエストを受信したとき、送受信制御部が代理ＩＯＲを基にＩＯＲテーブルを検索して対応するサーバＩＯＲを読み込み；送受信制御部がサーバとの接続が確立されていることを、接続を確認する接続確認プログラムによって判定し；接続が確認されない場合には、接続が確認されるまで所定の時間間隔にて接続確認プログラムを実行して接続の確認を継続し；接続が確認された場合は、読み込んだサーバＩＯＲと受信したリクエストをサーバに送信する、ことを特徴とする高信頼化装置を提供する。

また、請求項７に記載の発明は分散処理を行うオブジェクト・リクエスト・ブローカが実装されているサーバ及びクライアントとの間に接続され、サーバ及びクライアントとメッセージの送受信を行う高信頼化装置の高信頼化方法であって、高信頼化装置が、サーバへのあて先情報を含むサーバＩＯＲとサーバへのあて先情報を高信頼化装置に変更したあて先情報を含む代理ＩＯＲとを格納するＩＯＲテーブルと；メッセージの送受信を制御する送受信制御部と；を備え、送受信制御部が、クライアントから代理ＩＯＲとオブジェクトを要求するリクエストを受信したとき、送受信制御部が代理ＩＯＲを基にＩＯＲテーブルを検索して対応するサーバＩＯＲを読み込むステップと；送受信制御部がサーバとの接続が確立されていることを、接続を確認する接続確認プログラムによって判定し、接続が確認されない場合には、接続が確認されるまで所定の時間間隔にて前記接続確認プログラムを実行して接続の確認を継続するステップと；接続が確認された場合は、読み込んだ前記サーバＩＯＲと受信したリクエストをサーバに送信するステップと；を有することを特徴とする高信頼化方法を提供する。

本発明によれば、高信頼化装置がサーバとクライアントの間に接続され、高信頼化装置の送受信制御部がクライアントからリクエストを受信すると、クライアントに代わってサーバとの接続の確認とリクエストの送信と応答の受信を行うため、既存のソフトウエア資産に変更を加えることなく簡易に高信頼化を実現できる。

以下、本発明の第１の実施形態について図面を用いて説明する。図１は本実施形態の高信頼化装置の接続関係を示した図である。本実施形態の高信頼化装置１１はサーバ１０と通信回線１３を介して接続され、また、クライアント１２と通信回線１３を介して接続される。

このように、高信頼化装置１１はサーバ１０とクライアント１２の間に通信回線１３を介して接続される。サーバ１０及びクライアント１２は複数接続されていても良い。通信回線１３は種類を問わず、ＬＡＮであってもインターネットのような公衆通信回線網を介するものであっても良い。

サーバ１０とクライアント１２には分散処理アーキテクチャに基づくオブジェクト・リクエスト・ブローカ（ＯＲＢ）が実装されている。ＯＲＢの例としては共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ：ＣｏｍｍｏｎＯｂｊｅｃｔＲｅｑｕｅｓｔＢｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅ）、ＪａｖａＲＭＩ（ＪａｖａＲｅｍｏｔｅＭｅｔｈｏｄＩｎｖｏｃａｔｉｏｎ）、ＨＯＲＢ（ＨｉｒａｎｏＯｂｊｅｃｔＲｅｑｕｅｓｔＢｒｏｋｅｒ）などが挙げられるが、本実施形態は特にＣＯＲＢＡが実装されているサーバ１０とクライアント１２において効果的である。

図２は本実施形態の高信頼化装置１１の構成を表した概要図である。高信頼化装置１１は送受信制御部２１と記憶装置３０とを備える。送受信制御部２１はＣＰＵ２２と、メモリ２３と、サーバ１０とクライアント１２と通信可能な通信手段２４と、ソフトウエア２５を備える。ソフトウエア２５はＴＣＰ／ＩＰをサポートするＯＳ（オペレーションシステム）２６と、通信を媒介するゲートウエイアプリケーション２７を含む。

記憶装置３０は例えば磁気ハードディスクやフラッシュメモリなどを用いることができる。記憶装置３０はサーバ１０へのあて先情報であるサーバＩＯＲとサーバへのあて先情報を高信頼化装置１１に変更した代理ＩＯＲとを対応付けて格納するＩＯＲテーブル２８と、クライアント１２から受信した代理ＩＯＲとサーバ１０に存在するオブジェクトを要求するリクエストを格納するリクエストテーブル２９を備える。

ここで、あて先情報とはネットワーク上においてオブジェクトが存在する場所を特定する情報を含むデータである。あて先情報の例としてはＩＯＲ（ＩｎｔｅｒｏｐｅｒａｂｌｅＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅ）が挙げられる。ＩＯＲはオブジェクトの存在する場所を特定する情報のほかに、サーバの場所を示す情報、送信元を識別する情報、プロトコルの種類、利用できるＯＲＢサービスに関する情報などを含んでいてもよい。また、メッセージとはコンピュータ間において送受信されるデータをいい、ＩＯＲとリクエストが含まれる。

次に、本実施形態の高信頼化装置１１の動作について説明する。高信頼化装置１１の動作は準備段階であるＩＯＲ設定処理と高信頼化を実現するリクエスト送受信処理を含む。

図３はＩＯＲ設定処理のシーケンスチャートである。ＩＯＲ設定処理の目的は、第１に高信頼化装置１１のＩＯＲテーブル２８にサーバＩＯＲと代理ＩＯＲを対応付けて格納することであり、第２にクライアント１２に代理ＩＯＲを格納することである。

ＩＯＲ設定処理に先立ち、クライアント１２には高信頼化装置１１のＩＯＲテーブル２８にサーバＩＯＲと代理ＩＯＲの設定を行うソフトウエアであるＩＯＲ設定エージェントをインストールしておく。ＩＯＲ設定エージェントは高信頼化装置１１のＩＯＲテーブル２８をリモートにて更新するようにプログラムする。

ステップＳ３０１において、クライアント１２はサーバＩＯＲをサーバ１０に要求する。ステップＳ３０２においてクライアント１２はサーバ１０からサーバＩＯＲを受信する。なお、サーバＩＯＲの取得方法は限定されない。例えば、クライアント１２がサーバ１０において稼動しているネームサービスを利用して取得しても良い。また、サーバ１０の管理者からメールにてサーバＩＯＲを入手してもよい。入手したサーバＩＯＲはＩＯＲ設定エージェントが読み込める状態にてクライアント１２の記憶装置に格納しておく。

ステップＳ３０３において、クライアント１２はＩＯＲ設定エージェントにより高信頼化装置１１の送受信制御部２１にサーバＩＯＲと、ＩＯＲテーブル２８にサーバＩＯＲを格納する設定指示とを送信する。

ステップＳ３０４において、送受信制御部２１は受信したサーバＩＯＲをＩＯＲテーブル２８に格納する。ステップＳ３０５において、高信頼化装置１１の送受信制御部２１はサーバＩＯＲに対応し、高信頼化装置１１をあて先とする代理ＩＯＲを生成し、この代理ＩＯＲをサーバＩＯＲと対応付けてＩＯＲテーブル２８に格納する。

ステップＳ３０６において、高信頼化装置１１の送受信制御部２１は生成した代理ＩＯＲをクライアント１２に送信する。ステップＳ３０７において、クライアント１２は受信した代理ＩＯＲをクライアント１２のＯＲＢが利用できる状態に格納する。

図４は本実施形態におけるＩＯＲテーブル２８の内容を示した図である。ＩＯＲテーブル２８の項目はサーバＩＯＲと代理ＩＯＲである。格納されるＩＯＲの例は、第１レコード４０１において、サーバＩＯＲは送信先がサーバ１、オブジェクトの場所がサーバ１、送信元が高信頼化装置であり、代理ＩＯＲは送信先が高信頼化装置、オブジェクトの場所がサーバ１、送信元がクライアント１である。

ここで、従来のＩＯＲは送信先がサーバ１、オブジェクトの場所がサーバ１、送信元がクライアント１となっている。これに代えて、クライアントは第１レコード４０１の代理ＩＯＲを使用してリクエストを送信する。このため、代理ＩＯＲとリクエストはサーバ１ではなく、高信頼化装置１１に送信される。

第２レコード４０２においては、サーバＩＯＲは送信先とオブジェクトの場所がサーバ２、代理ＩＯＲは送信元がクライアント１になっている。また、第３レコード４０３においては、サーバＩＯＲは送信先とオブジェクトの場所がサーバ２、代理ＩＯＲは送信元がクライアント２になっている。このように、サーバやクライアントが複数あるときはＩＯＲの内容が変わり、ＩＯＲテーブル２８に格納される。

後述するように、高信頼化装置１１の送受信制御部２１はクライアントから受信した代理ＩＯＲを対応するサーバＩＯＲに変更して送信する。このため、サーバＩＯＲとリクエストはサーバに送信され、リクエストに対する応答は高信頼化装置１１に送信される。

図５は本実施形態におけるリクエストテーブル２９の内容を示した図である。リクエストテーブル２９の項目は代理ＩＯＲとリクエストである。代理ＩＯＲは例えば送信先が高信頼化装置、オブジェクトの場所がサーバ１、送信元がクライアント１であり、リクエストは例えばｏｂｊｅｃｔＡである。

図６は本実施形態の高信頼化装置１１におけるリクエスト送受信処理のフローチャートである。リクエスト送受信処理を行うプログラムは、ゲートウエイアプリケーションをカスタマイズして作成しても、新たにアプリケーションを作成しても良い。なお、一般にゲートウェイはリクエストごとにマルチスレッドで動作する。ここでは一本のスレッドの処理フローについて述べる。

ステップＳ６０１において、送受信制御部２１はクライアント１２から代理ＩＯＲとオブジェクトを要求するリクエストを受信する。ステップＳ６０２において、送受信制御部２１は受信した代理ＩＯＲとリクエストをリクエストテーブル２９に格納する。

ステップＳ６０３において、送受信制御部２１はＩＯＲテーブル２８を参照し、受信した代理ＩＯＲに対応するサーバＩＯＲを読み出す。前述したＩＯＲ設定処理において、受信した代理ＩＯＲと同一のものがＩＯＲテーブル２８の代理ＩＯＲに格納されているため、送受信制御部２１は受信した代理ＩＯＲ自身をキーにＩＯＲテーブル２８の代理ＩＯＲの欄を検索することにより、対応するサーバＩＯＲを読み出すことができる。

ステップＳ６０４において、送受信制御部２１はサーバＩＯＲに記載されているサーバ１０にＰｉｎｇを送信する。ここで、ＰｉｎｇはＴＣＰ／ＩＰのプログラムであり、ＩＰパケットをノードに対して送信するものである。ノードはＰｉｎｇのＩＰパケットを受信するとＩＰパケットを送信元に送信する。従って、サーバ１０から応答のＰｉｎｇが送信されてくれば、サーバ１０が起動していることが確認できる。

ステップＳ６０５において、送受信制御部２１はサーバ１０から応答のＰｉｎｇを受信したか判定する。所定時間内に送受信制御部２1が応答のＰｉｎｇを受信しない場合にはステップＳ６０４に戻る。応答のＰｉｎｇを受信した場合にはステップＳ６０６に進む。

ここで、ステップＳ６０５を実行する時間間隔、すなわちサーバ１０へのＰｉｎｇ送信の時間間隔は５０ｍｓ（ミリ秒）以上２００ｍｓ以下であることが望ましく、１００ｍｓであることがより望ましい。通常Ｐｉｎｇは１０分から１時間に１回程度の割合にて送信される。本実施形態においては、クライアントにおいてオブジェクトを要求するプログラムが動いており、このプログラムにサーバ１０から受信したオブジェクトをできるだけ早く返す必要があるため、時間間隔を短くする必要があるが、短くしすぎるとサーバ１０に負荷がかかるため上記の時間間隔が望ましい。

ステップＳ６０６において、送受信制御部２１はサーバ１０にＫｅｅｐ＿Ａｌｉｖｅを送信する。ここで、Ｋｅｅｐ＿Ａｌｉｖｅとは例えばＴＣＰ／ＩＰなどのプロトコルにおいて、通信の接続を確認するために送信されるテキストデータを送信するプログラムをいうが、このテキストデータをＫｅｅｐ＿Ａｌｉｖｅともいう。接続が確立している場合には、Ｋｅｅｐ＿Ａｌｉｖｅを受信した機器はＫｅｅｐ＿Ａｌｉｖｅに対応する応答を、Ｋｅｅｐ＿Ａｌｉｖｅを送信してきた装置に送信する。従って、Ｋｅｅｐ＿Ａｌｉｖｅに対する応答が送信されてくれば、サーバ１０とクライアント１２において接続が確立されているか確認することができる。

ステップＳ６０７において、送受信制御部２１はサーバ１０からＫｅｅｐ＿Ａｌｉｖｅへ応答を受信したか判定する。所定時間内に送受信制御部２1がＫｅｅｐ＿Ａｌｉｖｅへ応答を受信しない場合には再接続処理（ステップＳ６０７０）を行ない、ステップＳ６０６に戻る。Ｋｅｅｐ＿Ａｌｉｖｅへ応答を受信した場合にはステップＳ６０８に進む。

ここで、ステップＳ６０６を実行する時間間隔、すなわちサーバ１０へのＫｅｅｐ＿Ａｌｉｖｅ送信の時間間隔は５０ｍｓ（ミリ秒）以上２００ｍｓ以下であることが望ましく、１００ｍｓであることがより望ましい。通常Ｋｅｅｐ＿Ａｌｉｖｅは数分から数十分に１回程度の割合にて送信される。本実施形態においては、クライアントにおいてオブジェクトを要求するプログラムが動いており、このプログラムにサーバ１０から受信したオブジェクトをできるだけ早く返す必要があるため、時間間隔を短くする必要があるが、短くしすぎるとサーバ１０に負荷がかかるため上記の時間間隔が望ましい。

ステップＳ６０８において、送受信制御部２１はサーバ１０にサーバＩＯＲとリクエストを送信する。ステップＳ６０９において、送受信制御部２１はサーバ１０にＫｅｅｐ＿Ａｌｉｖｅを送信する。このＫｅｅｐ＿Ａｌｉｖｅの送信はサーバＩＯＲとリクエストを送信した直後においても接続が確立されていることを確認することにより、サーバＩＯＲとリクエストがサーバ１０に到達していることを推定するために行われる。

ステップＳ６１０において、送受信制御部２１はサーバ１０からＫｅｅｐ＿Ａｌｉｖｅへ応答を受信したか判定する。所定時間内に送受信制御部２1がＫｅｅｐ＿Ａｌｉｖｅへ応答を受信しない場合にはステップＳ６０６に戻る。Ｋｅｅｐ＿Ａｌｉｖｅへ応答を受信した場合にはステップＳ６１１に進む。

ステップＳ６１１において、送受信制御部２１はサーバ１０からリクエストへの応答を受信する。ステップＳ６０８において送受信制御部２１がサーバ１０に送信したサーバＩＯＲにはリクエストの送信元を高信頼化装置１１として記載されている。従って、サーバ１０のＯＲＢはリクエストへの応答を高信頼化装置１１に送信する。

ステップＳ６１２において、送受信制御部２１はクライアント１２にリクエストへの応答を送信する。リクエストの応答を送信するクライアントの識別は、例えば次のように行う。サーバ１０のＯＲＢから送受信制御部２１が受信したデータの中には要求したオブジェクトを識別する識別情報が含まれている。送受信制御部２１はこの識別情報をキーにリクエストテーブルのリクエストを検索し、該当する識別情報を有するリクエストに対応する代理ＩＯＲを読み出す。代理ＩＯＲにはリクエストを送信したクライアントを識別する情報が記載されている。この情報に基づいて送信先のクライアントを特定し、リクエストを送信する。

なお、クライアントに送信する際に、Ｐｉｎｇ及びＫｅｅｐ＿Ａｌｉｖｅを用いて上述したサーバ１０との接続確認と同様な接続確認をクライアントに対して行うように構成してもよい。

ステップＳ６１３において、送受信制御部２１は代理ＩＯＲとリクエストをリクエストテーブル２９から削除する。

以上のように、本実施形態の高信頼化装置１１は、クライアント１２から代理ＩＯＲとリクエストを受信したとき、クライアント１２に代わってサーバ１０との接続の確認とメッセージの送受信を行うため、クライアント１２に負荷をかけずにサーバ１０へのリクエストの送信をより確実に行うことができる。

また、サーバ１０とクライアント１２の間に高信頼化装置１１を接続し、ＩＯＲ設定処理を行うことのみによりメッセージのやり取り、すなわちメッセージングにおける高信頼化を実現でき、既存のソフトウエア資産の変更を必要としない。

次に、第２の実施形態について説明する。本実施形態における高信頼化装置１１の接続関係は実施形態１と同様である。すなわち、図１に示すように、高信頼化装置１１はサーバ１０と通信回線１３を介して接続され、また、クライアント１２と通信回線１３を介して接続される。

高信頼化装置１１はサーバ１０とクライアント１２の間に通信回線１３を介して接続される。サーバ１０及びクライアント１２は複数接続されていても良い。通信回線１３は種類を問わず、ＬＡＮであってもインターネットのような公衆通信回線網を介するものであっても良い。サーバ１０とクライアント１２には分散処理アーキテクチャに基づくオブジェクト・リクエスト・ブローカ（ＯＲＢ）が実装されている。

本実施形態における高信頼化装置１１の構成は実施形態１と同様である。すなわち、図２に示すように、高信頼化装置１１は送受信制御部２１と記憶装置３０とを備える。送受信制御部２１はＣＰＵ２２と、メモリ２３と、サーバ１０とクライアント１２と通信可能な通信手段２４と、ソフトウエア２５を備える。ソフトウエア２５はＴＣＰ／ＩＰをサポートするＯＳ（オペレーションシステム）２６と、通信を媒介するゲートウエイアプリケーション２７を含む。

次に、本実施形態の高信頼化装置１１の動作について説明する。高信頼化装置１１の動作は準備段階であるＩＯＲ設定処理と高信頼化を実現するリクエスト送受信処理を含む。本実施形態のＩＯＲ設定処理は実施形態１と同様のステップを有するが、生成するサーバＩＯＲの内容が実施形態１とは異なる。先ず、ＩＯＲ設定処理を説明する。

本実施形態のＩＯＲ設定処理は図３に示す如くである。ステップＳ３０１において、クライアント１２はサーバＩＯＲをサーバ１０に要求する。ステップＳ３０２においてクライアント１２はサーバ１０からサーバＩＯＲを受信する。なお、サーバＩＯＲの取得方法は限定されない。例えば、クライアント１２がサーバ１０において稼動しているネームサービスを利用して取得しても良い。また、サーバ１０の管理者からメールにてサーバＩＯＲを入手してもよい。入手したサーバＩＯＲはＩＯＲ設定エージェントが読み込める状態にてクライアント１２の記憶装置に格納しておく。

ステップＳ３０３において、クライアント１２はＩＯＲ設定エージェントにより高信頼化装置１１の送受信制御部２１にサーバＩＯＲとＩＯＲテーブル２８にサーバＩＯＲを格納する設定指示を送信する。

図７は本実施形態におけるＩＯＲテーブル２８の内容を示した図である。ＩＯＲテーブル２８の項目はサーバＩＯＲと代理ＩＯＲである。格納されるＩＯＲの例は、第１レコード７０１において、サーバＩＯＲは送信先がサーバ１、オブジェクトの場所がサーバ１、送信元がクライアント１であり、代理ＩＯＲは送信先が高信頼化装置、オブジェクトの場所がサーバ１、送信元がクライアント１である。

ここで、従来のＩＯＲは送信先がサーバ１、オブジェクトの場所がサーバ１、送信元がクライアント１となっている。これに代えて、クライアントは第１レコード７０１の代理ＩＯＲを使用してリクエストを送信する。このため、代理ＩＯＲとリクエストはサーバ１ではなく、高信頼化装置１１に送信される。

第２レコード７０２においては、サーバＩＯＲは送信先とオブジェクトの場所がサーバ２、代理ＩＯＲは送信元がクライアント１になっている。また、第３レコード７０３においては、サーバＩＯＲは送信先とオブジェクトの場所がサーバ２、代理ＩＯＲは送信元がクライアント２になっている。このように、サーバやクライアントが複数あるときはＩＯＲの内容が変わり、ＩＯＲテーブル２８に格納される。

後述するように、高信頼化装置１１の送受信制御部２１はクライアントから受信した代理ＩＯＲを対応するサーバＩＯＲに変更して送信する。このため、サーバＩＯＲとリクエストはサーバに送信され、リクエストに対する応答は高信頼化装置１１を経由せずに直接送信元であるクライアントに送信される。

本実施形態におけるリクエストテーブル２９の内容は第１の実施形態と同様である。すなわち、図５に示すように、リクエストテーブル２９の項目は代理ＩＯＲとリクエストである。代理ＩＯＲは例えば送信先が高信頼化装置、オブジェクトの場所がサーバ１、送信元がクライアント１であり、リクエストは例えばｏｂｊｅｃｔＡである。

図８は本実施形態の高信頼化装置１１におけるリクエスト送受信処理のフローチャートである。リクエスト送受信処理を行うプログラムは、ゲートウエイアプリケーションをカスタマイズして作成しても、新たにアプリケーションを作成しても良い。

ステップＳ８０１において、送受信制御部２１はクライアント１２から代理ＩＯＲとオブジェクトを要求するリクエストを受信する。ステップＳ８０２において、送受信制御部２１は受信した代理ＩＯＲとリクエストをリクエストテーブル２９に格納する。

ステップＳ８０３において、送受信制御部２１はＩＯＲテーブル２８を参照し、受信した代理ＩＯＲに対応するサーバＩＯＲを読み出す。前述したＩＯＲ設定処理において、受信した代理ＩＯＲと同一のものがＩＯＲテーブル２８の代理ＩＯＲに格納されているため、送受信制御部２１は受信した代理ＩＯＲ自身をキーにＩＯＲテーブル２８の代理ＩＯＲの欄を検索することにより、対応するサーバＩＯＲを読み出すことができる。

ステップＳ８０４において、送受信制御部２１はサーバＩＯＲに記載されているサーバ１０にＰｉｎｇを送信する。ステップＳ８０５において、送受信制御部２１はサーバ１０から応答のＰｉｎｇを受信したか判定する。所定時間内に送受信制御部２1が応答のＰｉｎｇを受信しない場合にはステップＳ８０４に戻る。応答のＰｉｎｇを受信した場合にはステップＳ８０６に進む。

ここで、ステップＳ８０５を実行する時間間隔、すなわちサーバ１０へのＰｉｎｇ送信の時間間隔は５０ｍｓ（ミリ秒）以上２００ｍｓ以下であることが望ましく、１００ｍｓであることがより望ましい。通常Ｐｉｎｇは１０分から１時間に１回程度の割合にて送信される。本実施形態においては、クライアントにおいてオブジェクトを要求するプログラムが動いており、このプログラムにサーバ１０から受信したオブジェクトをできるだけ早く返す必要があるため、時間間隔を短くする必要があるが、短くしすぎるとサーバ１０に負荷がかかるため上記の時間間隔が望ましい。

ステップ８０６において、送受信制御部２１はサーバ１０にＫｅｅｐ＿Ａｌｉｖｅを送信する。ステップＳ８０７において、送受信制御部２１はサーバ１０からＫｅｅｐ＿Ａｌｉｖｅへ応答を受信したか判定する。所定時間内に送受信制御部２1がＫｅｅｐ＿Ａｌｉｖｅへ応答を受信しない場合には再接続処理（ステップＳ８０７０）を行ない、ステップＳ８０６に戻る。Ｋｅｅｐ＿Ａｌｉｖｅへ応答を受信した場合にはステップＳ８０８に進む。

ここで、ステップＳ８０６を実行する時間間隔、すなわちサーバ１０へのＫｅｅｐ＿Ａｌｉｖｅ送信の時間間隔は５０ｍｓ（ミリ秒）以上２００ｍｓ以下であることが望ましく、１００ｍｓであることがより望ましい。通常Ｋｅｅｐ＿Ａｌｉｖｅは数分から数十分に１回程度の割合にて送信される。本実施形態においては、クライアントにおいてオブジェクトを要求するプログラムが動いており、このプログラムにサーバ１０から受信したオブジェクトをできるだけ早く返す必要があるため、時間間隔を短くする必要があるが、短くしすぎるとサーバ１０に負荷がかかるため上記の時間間隔が望ましい。

ステップＳ８０８において、送受信制御部２１はサーバ１０にサーバＩＯＲとリクエストを送信する。ステップＳ８０９において、送受信制御部２１はサーバ１０にＫｅｅｐ＿Ａｌｉｖｅを送信する。このＫｅｅｐ＿Ａｌｉｖｅの送信はサーバＩＯＲとリクエストを送信した直後においても接続が確立されていることを確認することにより、サーバＩＯＲとリクエストがサーバ１０に到達していることを推定するために行われる。

ステップＳ８１０において、送受信制御部２１はサーバ１０からＫｅｅｐ＿Ａｌｉｖｅへ応答を受信したか判定する。所定時間内に送受信制御部２1がＫｅｅｐ＿Ａｌｉｖｅへ応答を受信しない場合にはステップＳ８０６に戻る。Ｋｅｅｐ＿Ａｌｉｖｅへ応答を受信した場合にはステップＳ８１１に進む。ステップＳ８１１において、送受信制御部２１は代理ＩＯＲとリクエストをリクエストテーブル２９から削除する。

以上のように、本実施形態の高信頼化装置１１は、サーバ１０からのリクエストへの応答が高信頼化装置１１を経由せずサーバ１０から直接クライアント１２に送信される。このため、クライアント１２はより迅速にリクエストへの応答を受信することができる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

高信頼化装置の接続関係を示した図である。高信頼化装置の構成を表した概要図である。ＩＯＲ設定処理のシーケンスチャートである。第１の実施形態におけるＩＯＲテーブルの内容を示した図である。リクエストテーブルの内容を示した図である。第１の実施形態のクエスト送受信処理のフローチャートである。第２の実施形態におけるＩＯＲテーブルの内容を示した図である。第２の実施形態のリクエスト送受信処理のフローチャートである。

符号の説明

１０：サーバ、
１１：高信頼化装置、
１２：クライアント、
１３：通信回線、
２１：送受信制御部、
２２：ＣＰＵ、
２３：メモリ、
２４：通信手段、
２５：ソフトウエア、
２６：ＯＳ、
２７：ゲートウエイアプリケーション、
２８：ＩＯＲテーブル、
２９：リクエストテーブル、
３０：記憶装置。

Claims

分散処理を行うオブジェクト・リクエスト・ブローカが実装されているサーバ及びクライアントとの間に接続され、前記サーバ及び前記クライアントとメッセージの送受信を行う高信頼化装置であって、
前記サーバへのあて先情報を含むサーバＩＯＲと前記サーバへのあて先情報を前記高信頼化装置に変更したあて先情報を含む代理ＩＯＲとを格納するＩＯＲテーブルと、
前記メッセージの送受信を制御する送受信制御部と、
を備え、
前記送受信制御部が、前記クライアントから前記代理ＩＯＲとオブジェクトを要求するリクエストを受信したとき、
前記送受信制御部が前記代理ＩＯＲを基に前記ＩＯＲテーブルを検索して対応する前記サーバＩＯＲを読み込み、
前記送受信制御部が前記サーバとの接続が確立されていることを、接続を確認する接続確認プログラムによって判定し、
接続が確認されない場合には、接続が確認されるまで所定の時間間隔にて前記接続確認プログラムを実行して接続の確認を継続し、
接続が確認された場合は、読み込んだ前記サーバＩＯＲと前記受信した前記リクエストを前記サーバに送信する、
ことを特徴とする高信頼化装置。
前記送受信制御部が、前記サーバから前記リクエストへの応答を受信したとき、
前記送受信制御部が前記リクエストを送信したクライアントに前記リクエストへの応答を送信することを特徴とする請求項１に記載の高信頼化装置。
前記クライアントから受信した前記代理ＩＯＲと前記リクエストを格納するリクエストテーブルを更に備え、
前記送受信制御部が前記クライアントから前記代理ＩＯＲと前記リクエストを受信したとき、
前記送受信制御部が受信した前記代理ＩＯＲと前記リクエストを前記リクエストテーブルに格納し、
前記送受信制御部が前記サーバに前記サーバＩＯＲと前記受信したリクエストを送信した後に、
前記サーバとの接続を前記接続確認プログラムによって判定し、
接続が確認された場合は、前記リクエストテーブルに格納された送信済みの前記代理ＩＯＲと前記リクエストを削除する
ことを特徴とする請求項１又は２に記載の高信頼化装置。
前記分散処理を行うオブジェクト・リクエスト・ブローカが共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ）であることを特徴とする請求項１乃至３のいずれか１項に記載の高信頼化装置。
前記接続確認プログラムがＴＣＰ／ＩＰのＰｉｎｇ及びＫｅｅｐ＿Ａｌｉｖｅであることを特徴とする請求項１乃至４のいずれか１項に記載の高信頼化装置。
前記Ｐｉｎｇ及び前記Ｋｅｅｐ＿Ａｌｉｖｅを送信する時間間隔が５０ｍｓ以上２００ｍｓ以下であることを特徴とする請求項５に記載の高信頼化装置。
分散処理を行うオブジェクト・リクエスト・ブローカが実装されているサーバ及びクライアントとの間に接続され、前記サーバ及び前記クライアントとメッセージの送受信を行う高信頼化装置の高信頼化方法であって、
前記高信頼化装置が、
前記サーバへのあて先情報を含むサーバＩＯＲと前記サーバへのあて先情報を前記高信頼化装置に変更したあて先情報を含む代理ＩＯＲとを格納するＩＯＲテーブルと、
前記メッセージの送受信を制御する送受信制御部と、
を備え、
前記送受信制御部が、前記クライアントから前記代理ＩＯＲとオブジェクトを要求するリクエストを受信したとき、
前記送受信制御部が前記代理ＩＯＲを基に前記ＩＯＲテーブルを検索して対応する前記サーバＩＯＲを読み込むステップと、
前記送受信制御部が前記サーバとの接続が確立されていることを、接続を確認する接続確認プログラムによって判定し、
接続が確認されない場合には、接続が確認されるまで所定の時間間隔にて前記接続確認プログラムを実行して接続の確認を継続するステップと、
接続が確認された場合は、読み込んだ前記サーバＩＯＲと前記受信した前記リクエストを前記サーバに送信するステップと、
を有することを特徴とする高信頼化方法。
前記送受信制御部が、前記サーバから前記リクエストへの応答を受信したとき、
前記送受信制御部が前記リクエストを送信したクライアントに前記リクエストへの応答を送信するステップを更に有することを特徴とする請求項７に記載の高信頼化方法。
前記クライアントから受信した前記代理ＩＯＲと前記リクエストを格納するリクエストテーブルを更に備える前記高信頼化装置の高信頼化方法であって、
前記送受信制御部が前記クライアントから前記代理ＩＯＲと前記リクエストを受信したとき、
前記送受信制御部が受信した前記代理ＩＯＲと前記リクエストを前記リクエストテーブルに格納するステップと、
前記送受信制御部が前記サーバに前記サーバＩＯＲと前記受信したリクエストを送信するステップの後に、
前記サーバとの接続を前記接続確認プログラムによって判定し、
接続が確認された場合は、前記リクエストテーブルに格納された送信済みの前記代理ＩＯＲと前記リクエストを削除するステップを
更に有することを特徴とする請求項７又は８に記載の高信頼化方法。
前記分散処理アーキテクチャに基づくオブジェクト・リクエスト・ブローカが共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ）であることを特徴とする請求項７乃至９のいずれか１項に記載の高信頼化方法。
前記接続確認プログラムがＴＣＰ／ＩＰのＰｉｎｇ及びＫｅｅｐ＿Ａｌｉｖｅであることを特徴とする請求項７乃至１０のいずれか１項に記載の高信頼化方法。
前記Ｐｉｎｇ及び前記Ｋｅｅｐ＿Ａｌｉｖｅを送信する時間間隔が５０ｍｓ以上２００ｍｓ以下であることを特徴とする請求項１１に記載の高信頼化方法。