(57)【要約】      （修正有）【課題】上位のアプリケーションの使用環境の制限が緩やかな通信方式を提供する。【解決手段】端末とサーバの通信において、ファイアウォールによって許可されるプロトコルを使用し、受信用と送信用の処理を個別に用意し、受信用と送信用の処理ではデータをそれぞれステートレスなプロトコルによりカプセル化し、双方向の非同期な通信を可能とする。【選択図】  図１０
2004192358.tif 000002
【特許請求の範囲】
【請求項１】
センタ側の装置と端末との間でファイアウォールを介して通信を行う通信方式であって、
端末からの送信に基づき、センタ側の装置は識別情報を作成し、上記作成された識別情報をセンタ側の装置は送信し、上記端末がこれを受け取り、
上記識別情報を付加したデータを有するリクエストを上記端末からセンタ側の装置に送信し、センタ側の装置は上記データを有するリクエストを受け取り、データの受取に基づき端末にレスポンスを送ると共に、センタ側の装置は受け取ったデータに基づく処理を行い、
上記端末は、処理結果を返信するためのリクエストをセンタ側の装置に行い、センタ側の装置は上記端末からのリクエストに対し、処理結果の有無を調べ、処理結果の有無あるいは処理結果を伝送するためのレスポンスを上記端末に行い、
上記端末は、上記レスポンスが処理結果が無い状態を示す場合、処理結果を返信するためのリクエストをセンタ側の装置に行い、
上記処理結果を返信するための端末からのリクエストの送信と、センタ側の装置が行う、該リクエストに対する処理結果の有無の調査および端末へのレスポンスの送信と、を繰り返すことを特徴とする、端末とセンタ側の装置との間で送受信を行うための双方向通信方式。
【請求項２】
センタ側の装置と端末との間でファイアウォールを介して通信を行う通信方式であって、
端末からの送信を受けて、センタ側の装置は識別情報を作成し、上記作成された識別情報をセンタ側の装置は上記端末へ送信し、
上記識別情報が付加したデータを有するリクエストを上記端末から受け、センタ側の装置は受け取ったデータに基づく処理を行い、
処理結果を返信するためのリクエストを端末から受け、センタ側の装置は、端末からのリクエストに関する処理結果の有無を調べ、処理結果の有無あるいは処理結果を伝送のためのレスポンスを上記端末に行い、
上記センタ側の装置は、端末からの処理結果を返信するためのリクエストを受信する度に、該リクエストに対する処理結果の有無の調査および端末へのレスポンスの送信を繰り返すことを特徴とする、端末とセンタ側の装置との間で送受信を行うための双方向通信方式。
【請求項３】
請求項２に記載の通信方式において、送受信をＨＴＴＰまたはＨＴＴＰＳに基づいて行うことを特徴とする、端末とセンタ側の装置との間で送受信を行うための双方向通信方式。
【請求項４】
センタ側の装置と端末との間でファイアウォールを介して通信を行う通信方式であって、
端末は、センタ側の装置に識別情報を依頼して、該識別情報をセンタ側の装置から受け取り、
上記端末は、上記識別情報を付加したデータを有する処理依頼をセンタ側の装置に送信し、
上記端末は、上記処理依頼の処理結果を返信するためのリクエストをセンタ側の装置に送信し、
上記端末は、上記リクエストに対する、処理結果の有無あるいは処理結果を示すレスポンスを上記センタ側の装置から受け取り、
上記端末は、上記レスポンスが処理結果が無い状態を示す場合、処理結果を返信するためのリクエストをセンタ側の装置に送信して、このレスポンスを受け取り、
上記端末は、上記レスポンスが処理結果が無い状態を示す場合に、上記処理結果を返信するためのリクエストの送信を繰り返すことを特徴とする、端末とセンタ側の装置との間で送受信を行うための双方向通信方式。
【請求項５】
請求項４に記載の通信方式において、送受信をＨＴＴＰまたはＨＴＴＰＳに基づいて行うことを特徴とする、端末とセンタ側の装置との間で送受信を行うための双方向通信方式。
【請求項６】
センタ側の装置と端末との間で通信を行うためのプログラムであって、コンピュータを有するシステムは本プログラムを実行することで以下の機能を有することを特徴とする双方向通信のためのプログラム。
端末からの送信に基づき、センタ側の装置は識別情報を作成し、上記識別情報をセンタ側の装置は上記端末に送信し、
上記識別情報を有する第1のカプセル化したデータを備えた送信を上記端末からセンタ側の装置に行い、
センタ側の装置は、データの受取に基づき第２のカプセル化したデータをレスポンスとして端末に送信し、
上記端末は、第1のカプセル化したデータを備えた送信の処理結果を返信するための第３のカプセル化したデータを備えた送信をセンタ側に行い、
センタ側の装置は上記端末からの第３のカプセル化したデータを備えた送信に対し、処理結果の有無あるいは処理結果を伝送するための第４のカプセル化したデータを上記端末に送信し、
上記端末は、第４のカプセル化したデータが処理結果が無い状態を示す場合、処理結果を返信するための第３のカプセル化したデータを備えた送信をセンタ側に行い、
第４のカプセル化したデータが処理結果が無い状態を示す場合の、上記処理結果を返信するための端末からの送信と、これに基づいてセンタ側の装置が行う、を繰り返す。
【請求項７】
センタ側の装置と端末との間で通信を行うためのプログラムであって、コンピュータを有するシステムは本プログラムを実行することで以下の機能を有することを特徴とする双方向通信のためのプログラム、
端末の識別情報を有する第１のカプセル化したデータを端末から受け、センタ側の装置はデータの受取に基づき第２のカプセル化したデータをレスポンスとして端末に送信し、
処理結果を返信するためのリクエストとして第３のカプセル化したデータを端末から受け、センタ側の装置は、処理結果の有無あるいは処理結果を伝送のために第４のカプセル化したデータを端末に送信し、
センタ側の装置は、端末からの処理結果を返信するための第３のカプセル化したデータを受信する度に、第４のカプセル化したデータの送信を繰り返す。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、端末とセンタ側の装置との間の双方向の通信技術に関する。
【０００２】
【従来の技術】
一般的にクライアント側の端末とセンタ側の装置であるサーバの間の双方向通信には、ソケット方式が広く使われている。ソケットとは、ネットワークにおける接続とデータの送信と受信を受け持つ機能である。ネットワーク上で通信を行う場合、通信を行うコンピュータ間で接続を確立する必要があり、ソケットはその接続の機能と、接続された状態でのデータの送信と受信の機能、接続の切断の機能を有している。
【０００３】
ソケットを使用してクライアント側の端末とセンタ側の装置であるサーバの間の双方向通信を行う場合の例を以下に示す。まず初めに、センタ側の装置であるサーバは、ネットワークを介してクライアント側の端末に対して何らかのサービスを提供する。またセンタ側の装置であるサーバでは、そのサービスに対応したポート番号を用意し、常にクライアント側の端末からの接続を待ち受けているようにする。例えばＷｅｂサーバであれば、クライアント側の端末のブラウザからの要求に対して、ＨＴＭＬページを送信するサービスを提供しており、ポート番号８０番を使用していることが多い。
【０００４】
次にクライアント側の端末は、ネットワークを介してセンタ側の装置であるサーバに対して何らかのサービスを要求し、またその応答に対して処理を行う。またその際クライアント側の端末では、そのサービスに対応したポート番号を使用して、ネットワークを介してサーバに対して接続を行う。例えばＷｅｂクライアント側の端末のブラウザであれば、ポート番号として８０番を使用してサーバに接続する。それからサーバに対してＨＴＭＬページの送信を要求し、その結果としてサーバからＨＴＭＬページが送信された場合、ブラウザ側でそのＨＴＭＬページの内容を表示する。
【０００５】
図１において、センタ側の装置であるサーバ１５０では、サーバのソケット１６０を使用し、サービスに対応した固定のポート番号を使用し、クライアント側の端末１１０からの接続を待ち受ける。クライアント側の端末１１０のソケット１２０からその固定ポートに対して接続した場合、サーバ１５０のソケット１６０は、新たにそのクライアント側の端末のソケット１２０と通信するためのセンタ側の装置であるサーバのソケット１７０を作成し、そのサーバのソケット１７０がクライアント側の端末のソケット１２０との通信を行う。この一連の処理の間、サーバ１５０で接続を待ち受けていたサーバのソケット１６０は、この新しいサーバのソケット１７０を作成した後、再度クライアント側端末からの接続を待ち受けている。
【０００６】
サーバのソケット１６０は、クライアント側端末からの接続毎にその端末に対応したサーバのソケット１７０を順次作成する。クライアント側端末との通信を行うサーバのソケット１７０では、対応するクライアント側端末のソケット１２０に対して、ソケット１２０から送信されたデータ１０１を受信データ１０１として受信したり、端末のソケット１２０に対して送信するデータ１０３を送信することができる。またサーバのソケット１７０と端末のソケット１２０間のデータの送信と受信は非同期に行うことができる。この送信と受信の処理が終了した場合には、端末１１０のソケット１２０との接続１８０を切断する。
【０００７】
上述したとおり、端末１１０のソケット１２０では、サービスに対応したポート番号を使用し、サーバ１５０に対して接続する。サーバ１５０での処理により、サーバ１５０のソケット１７０と接続した端末のソケット１２０では、サーバのソケット１７０に対して、ソケット１７０から送信されたデータ１０３を受信データ１０３として受信したり、サーバのソケット１７０に対して送信するデータ１０１を送信することができる。またクライアント側の端末のソケット１２０からサーバのソケット１７０に対してデータの送信と受信は非同期に行うことができる。処理が終了した場合にはサーバのソケット１７０との接続１８０を切断する。
【０００８】
このように上記サーバとクライアント側の端末へのソケットの適用により、クライアント側の端末とセンタ側の装置であるサーバの間で双方向の通信を行うことができる。
【０００９】
このようなクライアント側の端末とセンタ側の装置であるサーバとの間で双方向の通信ができる構成においては、通信は単なるデータの送信と受信だけではなく、新規にデータの構成と内容をクライアント側端末とサーバの間で、プロトコルとして決めることにより、その構成の上で動作するアプリケーションを作成することが可能である。
【００１０】
その実装例の一つとしてＲＰＣ（Remote Procedure Call）がある。ＲＰＣとは、遠隔手続き呼出しであり、プログラムの一部の手続きの実行を、ネットワークに接続した別のマシンに委託するメカニズムである。そのメカニズムは、クライアント側の端末とセンタ側の装置であるサーバとでプロトコルを定め、クライアント側の端末側からデータを送信してセンタ側の装置であるサーバ側の関数を呼び出し、その関数の結果を、上記端末側がサーバ側から受信するというものである。
【００１１】
図２において、クライアント側の端末２１０とセンタ側の装置であるサーバ２５０との間でプロトコルを定める。次に端末２１０ではＲＰＣのプロトコルに従い、サーバ２５０において呼び出す関数とその関数に渡す引数を指定するデータ２０１を作成する。データ２０１はソケットにより作成されたソケット通信路２９０を使用して、サーバ２５０に対して送信される。サーバ２５０では、端末２１０から送信されたデータ２０１を受信し、ＲＰＣのプロトコルに従いデータの内容を解析する。データ内容の解析により、サーバ２５０で呼び出す関数と関数に渡す引数が取得される。なお、以下に示す英数字「Ｓ」はシステム動作手順であるステップを意味している。その後、サーバ２５０では取得した関数に対して取得した引数を渡してステップＳ２６０で、その指定された関数を引数付きで呼び出す。その結果をＲＰＣのプロトコルに従いクライアント側の端末への送信用データ２０３として作成する。次にそのデータをソケット通信路２９０を使用して、クライアント端末２１０に対して送信する。クライアント端末２１０では、サーバ２５０によって送信された関数呼び出しの結果のデータ２０３を取得する。
【００１２】
上記ＲＰＣにおいて、クライアント側端末からセンタ側のサーバへの手続きの要求を行う処理が１つの場合は、端末からサーバへの手続きの呼び出しの送信と、その結果を端末がサーバから受信するタイミングは同期を取っていても非同期であっても性能は変らない。しかし複数の独立したＲＰＣの処理を行う場合に、ネットワークの資源を有効に使用するため等の理由から、クライアント側端末とセンタ側サーバの接続を複数行わずに、１つの接続の上で、クライアント側端末からサーバへの手続きの要求を行う処理を複数行う必要がある。その場合に、クライアント側端末からセンタ側サーバへの手続きの呼び出しの送信処理と、その送信に対する結果を端末がセンタ側サーバから受信するタイミングで同期を取ったとすると、次の問題が生じる。例えばあるセンタ側サーバ上の手続きの呼び出しがサーバ上で時間がかかった場合、独立した別のＲＰＣによる処理の次の呼び出しが、その分遅れてしまうなど、性能に影響する問題が生じる。
【００１３】
また、機能としても独立したＲＰＣの処理に関しては、他の処理に影響されないようにすることが必要である。上述した理由により、クライアント側端末からセンタ側サーバへの手続きの要求を行う処理が複数の場合には、非同期での通信が求められる。非同期の通信が可能であれば、独立したＲＰＣの処理で、ある手続きの呼び出しに時間がかかった場合でも、別のＲＰＣの、手続きの呼び出しには影響を及ぼさない。またＲＰＣに限らず、クライアント側の端末とセンタ側のサーバの間での双方向の通信は、性能や機能の面から非同期での通信が望ましい。
【００１４】
このような状況下で、現状のソケットが使用されているクライアント側端末とセンタ側サーバでの通信では、ソケットがデータの送信と受信を非同期で行うことができる。そのため、クライアント側の端末とセンタ側のサーバで、送信と受信を行う処理を、例えばスレッドを使用して個別に作成することにより、上記で求められるような双方向の非同期での通信が可能である。
【００１５】
次にソケットが使用されているクライアント側の端末とセンタ側のサーバの通信において、クライアント端末とサーバとで、送信と受信を行う処理を、例えばスレッドとして個別に作成することにより、双方向の非同期での通信を行う例を図３に示す。
【００１６】
図３は、クライアント側の端末３１０とセンタ側のサーバ３５０の間の通信を、ソケット通信路３９０を使用して行う場合の例である。この例では、端末３１０とサーバ３５０において送信と受信の処理を個別にスレッドで処理することにより、双方向で非同期の通信を行うことに関して述べる。
【００１７】
まず実装について説明する。端末３１０において、ソケット通信路３９０を用いて送信と受信を行う。その処理を、それぞれ端末の送信スレッド３２０、端末の受信スレッド３３０で実装している。またセンタ側のサーバ３５０において、ソケット通信路３９０を用いて送信を行う処理と受信を行う処理を、それぞれサーバの送信スレッド３７０、サーバの受信スレッド３６０で実装している。
【００１８】
次に通信方式に関して述べる。まずクライアント側の端末３１０で、センタ側のサーバ３５０へ送信するデータ３０１が発生し送信が必要になったとする。その場合には、端末３１０の送信スレッド３２０において、ソケット通信路３９０を使用してデータ３０１を送信する。またクライアント側の端末３１０でセンタ側のサーバ３５０からのデータの受信が必要になった場合には、端末３１０の受信スレッド３３０において、ソケット通信路３９０を使用してデータを受信する。この場合、センタ側のサーバ３５０からクライアント側の端末３１０に対してデータ３０３が送信されている場合には端末３１０はデータ３０３をクライアントの受信スレッド３３０で受信することになる。
【００１９】
また、センタ側のサーバ３５０で、クライアント側の端末３１０へ送信するデータ３０３が発生し送信が必要になったとする。その場合には、サーバ３５０の送信スレッド３７０においてソケット通信路３９０を使用してデータ３０３を送信する。またセンタ側のサーバ３５０で端末３１０からのデータの受信が必要になった場合には、サーバ３５０の受信スレッド３６０においてソケット通信路３９０を使用してデータを受信する。この場合、端末３１０からサーバ３５０に対してデータ３０１が送信されている場合にはサーバ３５０はサーバの受信スレッド３６０でデータ３０１を受信することになる。
【００２０】
現在、一般にインターネットに接続している企業や組織の多くは、セキュリティ上の理由からファイアウォールを使用し、ファイアウォール経由でインターネットに接続している。ファイアウォールとは、インターネットを経由した不特定多数のセンタ側の装置であるサーバへのアクセスに対して、通過点を設定し、そこで全ての入出力をチェックするハードウェアとソフトウェアのことである。このファイアウォールにより、許可されていない通信を遮断し、許可している通信を通過させたりすることが可能である。ところが、このファイアウォールではステートレスなプロトコルであるＨＴＴＰやＨＴＴＰＳのみ使用できるように制限していることが多い。
【００２１】
その理由としては、ブラウザを利用して外部から企業の紹介等のホームページへのアクセスを可能としても、それ以外のＦＴＰ（ファイル転送プロトコル）等のプロトコルは許可せず、そのことにより内部のファイルの流出や外部から内部へのファイルの侵入を防ぐことができるからである。このような事情から、外部からはブラウザで上述の企業や組織のＷｅｂセンタ側の装置であるサーバにアクセスしてホームページを閲覧することはできても、ファイル転送はできないようにすることができる。
【００２２】
なお、ＨＴＴＰ（HyperText Transfer Protocol）やＨＴＴＰＳ（Hypertext Transfer Protocol Security）は、ＷｅｂサーバとＷｅｂクライアント（ブラウザ）との間でデータをやりとりするためのプロトコルである。またホームページ等Ｗｅｂブラウザで表示されるデータは、センタ側のサーバ上にＨＴＭＬ（HyperText Markup Language）形式で作成され保存されている。ＨＴＭＬ形式で作成されるＨｙｐｅｒｔｅｘｔとは、文章や画像などに加え、例えばＷｅｂブラウザで表示したときに下線のついた文字があり、その文字を選択すると、他の文章が表示可能となるような、他の情報を関連付けした文書のことである。
【００２３】
上述のＨＴＴＰやＨＴＴＰＳはＨＴＭＬページの表示用のプロトコルであり、ステートレスなプロトコルの１つである。ステートレスなプロトコルとは、クライアント側の端末とセンタ側のサーバとの通信において、通信の開始は必ずクライアント側の端末から行い、端末からの要求の度に新しく接続を確立し、またクライアント側の端末が次回接続したときにはセンタ側のサーバは前回の接続や処理結果を記憶していないプロトコルのことである。そのため処理の流れは、例えば「クライアント側の端末からデータを送信し、センタ側のサーバではそのデータを受信し、その後でそのデータをセンタ側のサーバが処理し、その結果をセンタ側のサーバがクライアント側の端末に送信し、クライアント側の端末がそのデータを受信する」となる。この流れは１リクエスト１レスポンスの形になっている。
【００２４】
一般のＷｅｂブラウザとＷｅｂサーバにおいて、上述で述べた処理の流れは例えば次のようになる。まず、最初にＷｅｂブラウザに対して企業または組織のトップページとして公開されているＵＲＬ（Uniform Resource Locator：インターネットにおける情報の「住所」）を指定する。クライアントの端末であるブラウザは、ＵＲＬの内容を解析し、目的のＷｅｂサーバに対して接続を行う。Ｗｅｂサーバとの接続が完了すると、クライアント側の端末はＨＴＴＰプロトコルを使用してセンタ側のサーバに対してＨＴＭＬ形式のデータの送信を要求する。センタ側のサーバはこの要求に対して、指定されたＨＴＭＬ形式のデータを取得してクライアント側の端末に対してデータを送信する。クライアント側の端末ではセンタ側のサーバから送られたデータを受信し、その後、そのデータの内容に従ってフォントサイズの設定や色の設定を行い、トップページの表示を行う。その後ブラウザを使用して他のページを表示する場合には、上記の接続とデータの送受信を再度繰り返し行うことにより、ページの表示を行うことになる。なお、ＨＴＴＰＳは、ＨＴＴＰに関してセキュリティを付加したプロトコルであり、クライアント側の端末とセンタ側のサーバの間でデータの暗号化と復号化等を行う。
【００２５】
また以前はファイアウォールでのプロトコルの制限がなくクライアント側の端末とセンタ側のサーバの間でソケットを使用することができた。しかしながら、現状においてはセキュリティを考慮してファイアウォールを設定することが必要となってきている。従って、ファイアフォールを設定することにより、使用できるプロトコルが、ＨＴＴＰまたはＨＴＴＰＳに制限されることになる。この状況において、例えば、以前に動作していた、ソケットを使用することによって実装されたクライアント側の端末とセンタ側のサーバの間、の双方向で非同期な通信を行う構成の上で実装されたＲＰＣ等のアプリケーションを動かす要求がある。このように、センタ側のサーバがファイアウォールを経由してネットワークに接続されている状態で、ファイアウォールの制限によりステートレスなプロトコルであるＨＴＴＰまたはＨＴＴＰＳしか使用できない構成の上でも、双方向の非同期通信が動作するように、ソケットを使用していた以前の機能を利用できればたいへん便利である。
【００２６】
ファイアウォールを介して接続する端末とセンタ装置間の通信技術を開示する文献としては次のものがある（例えば、特許文献１参照）。
【００２７】
特許文献１には、二方向的なプロセス対プロセスのバイトストリームのプロトコルに関する技術が記載されており、詳細には次の内容が開示されている。
「ファイアウォールが使用されているネットワーク環境において分散型プログラミングを利用するための、ファイアウォールを通過する両方向プロセス・トゥ・プロセス・バイト・ストリーム・プロトコル」
【００２８】
【特許文献１】
特表２００２−５１７８５７号公報（段落〔０００８〕−〔０００９〕）
【００２９】
【発明が解決しようとする課題】
上記従来技術では上位のアプリケーションの機能と密接に連携して通信を実現しており、ファイアウォールを使用する環境で使用できるプロトコルによる通信では同期通信しか実現できていない。すなわち上位アプリケーションの使用環境が厳しく制限される。できるだけ使用環境が緩やかなことが望ましい。
【００３０】
本発明の目的は、上位のアプリケーションの、使用環境の制限が緩やかな通信方式を提供することである。すなわち、上位のアプリケーションが例えばサブルーチンのように自由度を持って扱える通信技術を提供することである。
【００３１】
【課題を解決するための手段】
本発明による解決手段の１つは、端末とセンタ側の装置であるサーバとの通信において、端末からの処理結果の返信依頼に基づきセンタ側装置が送信を行うことである。
【００３２】
本発明による解決手段の他の１つは、端末からの処理結果の返信依頼を、処理結果が得られない場合に、繰り返し送信することである。
【００３３】
本発明によるさらに他の解決手段は、端末からの処理結果の返信依頼を、上位のプログラムの条件を満たすまで、繰り返し送信することである。本発明の他の解決手段は、クライアント側の端末とセンタ側装置とで、受信用と送信用の処理が相互に干渉することなく独立に任意のタイミングで処理するようにしたことである。その他の解決手段は、以下の、実施の形態の説明、の中で記述する。本発明によれば、上位アプリケーションの使用環境に係る自由度を確保できる。
【００３４】
また以下に説明の実施の形態では次のような具体的な実施例の効果がある。
以前からソケットを通信の基盤として使用していたＲＰＣ（Remote ProcedureCall）のような上位アプリケーションを、本発明の通信方式、例えばＨＴＴＰまたはＨＴＴＰＳ等を使用した通信を基盤とするシステムに、容易に移行することができ、たいへん利用し易くなる。
【００３５】
【発明の実施の形態】
上記従来の技術の欄で説明したごとく、セキュリティを考慮すると、ファイアウォールを端末とセンタ側装置との間に設けることが必要である。ファイアフォールを設けると、使用できるプロトコルがＨＴＴＰまたはＨＴＴＰＳなど、特定のものに制限されることになる。
【００３６】
以前からソケット方式が使用されている場合、ソケット方式を使用していたことによって端末とセンタ側のサーバとの間ですでに利用されていた、双方向で非同期な通信を行う構成を前提として既に実装されているＲＰＣ等のアプリケーションを、セキュリティを強化したファイアウォールを有するシステムで動作させてほしいとの要求が考えられる。このように、センタ側の装置がファイアウォールを経由してネットワークに接続されている状態で、ファイアウォールの制限によりステートレスなプロトコルであるＨＴＴＰまたはＨＴＴＰＳしか使用できない構成の上でも、双方向の非同期通信が動作するようにでき、さらにソケットを使用していた以前のアプリケーション機能を利用できればたいへん便利である。
【００３７】
また以下に説明する実施の形態では次のような考え方を考慮している。クライアント側の端末とセンタ側の装置、例えばサーバあるいはホストコンピュータ、の間で、ＨＴＴＰやＨＴＴＰＳしか使用できない環境において、ＨＴＴＰやＨＴＴＰＳはステートレスなプロトコルであるために、クライアント側の端末からの要求の度に新しく接続を確立し、クライアント側の端末が次回接続したときにはセンタ側の装置(以下代表してサーバと記す)は前回の接続や処理結果を記憶していないという問題がある。この問題を解決することが必要であり、この解決には、セッション管理という方法が考えられる。
【００３８】
セッション管理では、センタ側のサーバ側でクライアント側の端末を管理し、クライアント側の端末の、以前の接続時の状況を管理する。そのため、例えば最初の接続でセンタ側のサーバに対して検索用の条件を送信しておき、次回の接続でその検索処理の結果をセンタ側のサーバから受信する、その結果を使用して次の接続では再度検索条件を絞り込んでセンタ側のサーバに送信する、といったような、以前の接続時の状況から今回の接続に対応したデータを送信および受信することが可能となる。しかしセッション管理においても、ＨＴＴＰやＨＴＴＰＳの１リクエスト１レスポンス方式は変わらない。そのため、この一連の処理に関しては、センタ側のサーバとクライアント側の端末では同期を取る必要があり、新たな課題が生じる。以下の実施の形態で説明する技術ではこのような課題に対して、図１１から図１２の説明で後述するように上位のアプリケーションにより簡単に対応できる。
【００３９】
以下に説明する本発明の実施の形態では、例えばセンタ側のサーバがファイアウォールを経由してネットワークに接続されている状態で、ファイアウォールの制限によりステートレスなプロトコルであるＨＴＴＰやＨＴＴＰＳしか使用できない場合において、クライアント側の端末とセンタ側のサーバとの間で双方向の非同期な通信を提供し、その上でＲＰＣ等のアプリケーションが双方向で非同期な通信を行って動作することを可能とする技術を提案している。
【００４０】
また以下の実施の形態は、例えばネットワークを介して接続されたクライアント側の端末とセンタ側のサーバとの間でファイアウォールの制限のためにステートレスなプロトコルであるＨＴＴＰやＨＴＴＰＳしか使用できない環境に対して、双方向の非同期な通信を行うアプリケーションを作成するための基盤の技術を提案している。
【００４１】
次に本発明の一実施例について図４〜図１０の図面を用いて説明する。
まず初めに、図４に示すシステムは、ネットワーク４３０を介してセンタ側の装置であるホストコンピュータ、例えばサーバ４１０とクライアント側の端末４４０が接続されている。センタ側の装置であるサーバ４１０はファイアウォール４２０を介してネットワーク４３０に接続している。一般に１つのセンタ側装置に接続するクライアント側の端末は１個以上であり、センタ側の装置はネットワークを介して接続する複数のクライアント側の端末４４０に対して並列的にサービスを提供する。インターネットに接続するセンタ側の装置であるサーバ４１０は、インターネットの特性上、不特定多数からのアクセスが想定される。そのためこの実施例では、セキュリティの強化の面からファイアウォール４２０を介してネットワーク４３０と接続している。このファイアウォール４２０はセキュリティを強化するために、クライアント側の端末４４０と接続可能なプロトコルをＨＴＴＰやＨＴＴＰＳといったステートレスなプロトコルに限定している。
【００４２】
図５に、クライアント側の端末とセンタ側の装置であるサーバとの間で、双方向で非同期な通信を行うための準備を行う処理のフローを示す。まず初めにクライアント側の端末４４０はステップ５２０でステートレスなプロトコルでサーバ４１０に接続する。ステップＳ５２２で端末４４０はリクエスト５２４をサーバ４１０に送信する。リクエスト５２４には、ストリーム通信の開始を要求する内容が入っている。次にそのリクエスト５２４を受信したサーバ４１０では、ステップＳ５６０で、接続を行ったクライアント側の端末を一意に識別できる識別情報を作成する。ステップＳ５６２で、サーバ４１０はこの識別情報をレスポンス５６１によって端末４４０に送信する。
【００４３】
端末４４０では、上記識別情報を受信し、次の通信からこの識別情報を使用する。すなわちサーバ４１０へのデータの送信またはサーバ４１０からのデータの受信といった、サーバとのストリームの処理を行う場合にこの識別情報を使用する。またセンタ側のサーバ４１０では、複数のクライアント側の端末からの接続がある場合でも、上記識別情報によりクライアント側の端末を識別することが可能になる。
【００４４】
双方向で非同期な通信を行うための準備が終了した後は、クライアント側の端末４４０からセンタ側のサーバ４１０へのデータの送信、またはクライアント側のサーバからのデータの受信が行われる。
その送受信は、クライアント側の端末４４０とセンタ側のサーバ４１０でそれぞれ相互に干渉することなく独立に任意のタイミングで行われる。
これは例えば、スレッドを使用することにより、双方向で非同期な通信が実現される。
【００４５】
以下に、クライアント側の端末４４０からセンタ側の装置であるサーバ４１０へのデータの送信と、クライアント側の端末４４０でのサーバ４１０からのデータの受信の処理を説明する。
【００４６】
図６は、クライアント側の端末４４０からセンタ側の装置であるサーバ４１０へのデータの送信方法のフローを示す。
最初にクライアント側の端末４４０からステートレスなプロトコルで、サーバ４１０に接続する。次にステップＳ６２０でクライアント側の端末を一意に識別できる識別情報とデータを伝送情報に設定して、クライアント側の端末からセンタ側のサーバへ、リクエスト６２１として送信する。センタ側のサーバ４１０ではその情報を受信し、ステップＳ６６０でクライアント側の端末を識別する識別情報を使用し、クライアント側の端末４４０からのデータを受信する準備をする。その後、センタ側の装置であるサーバ４１０ではステップＳ６７０でクライアント側の端末４４０から送信されたデータを受信する。
【００４７】
センタ側の装置であるサーバ４１０ではそのデータを受信した後で、ステップＳ６８０で、正しくデータを受信したことを表すデータを作成しレスポンス６８１としてクライアント側の端末４４０に送信する。クライアント側の端末はセンタ側の装置であるサーバに対して送信するデータが発生する度に上記のデータ送信方式に従いデータの送信を行う。
【００４８】
図７に、クライアント側の端末４４０からセンタ側の装置であるサーバ４１０に対してデータを送信する処理で使用される、ＨＴＴＰのリクエスト７１０（第１のカプセル化したデータ）とそのレスポンス７２０（第２のカプセル化したデータ）の内容を示す。ＨＴＴＰリクエスト７１０には、データのＨＴＴＰプロトコルによる通信情報のカプセル化により次の情報が設定されている。すなわちそれは、ＨＴＴＰヘッダ、センタ側の装置であるサーバ４１０がクライアント側の端末４４０を一意に識別する情報、このＨＴＴＰリクエストがクライアント側の端末４４０からセンタ側のサーバ４１０へのデータの送信であることを表す情報、および送信するデータ７１１の各情報である。
またＨＴＴＰレスポンス７２０には、ＨＴＴＰヘッダとセンタ側の装置であるサーバで設定した送信処理の成否が設定されている。
【００４９】
図８に、センタ側のサーバ４１０からのデータを受信するクライアント側の端末４４０の受信方法を示す。
まず、クライアント側の端末４４０からステートレスなプロトコルでセンタ側の装置であるサーバ４１０に接続し、ステップＳ８２０でクライアント側の端末４４０を一意に識別できる情報をリクエスト８２１としてセンタ側の装置であるサーバ４１０に送信する。
次にセンタ側の装置であるサーバ４１０ではその情報を受信した後で、ステップＳ８６０でクライアント側の端末４４０へのデータ送信の準備としてクライアント側の端末へ送信するデータを検索する。
【００５０】
検索した結果、データが有る場合には、センタ側の装置であるサーバ４１０はステップＳ８７０でクライアント側の端末４４０に対してそのデータをレスポンス８７１として送信する。
【００５１】
データが無い場合には、センタ側のサーバ４１０はリクエスト８２１が届いてから一定時間内かどうかの判定を行うステップＳ８８０を行う。ステップＳ８８０では現在の時間が、リクエストがサーバ４１０に届いてから一定時間内かどうかを確認し、一定時間内であればデータの検索を行うステップＳ８６０を続けて行う。一定時間を過ぎた場合には、ステップＳ８９０の処理に移りデータが無かったことを、クライアントにレスポンス８９１で送信する。上述したとおり、センタ側の装置であるサーバ４１０は、一定時間内にデータが有る場合には、ステップＳ８７０でクライアント側の端末４４０に対してそのデータをレスポンスＳ８７１として送信する。
【００５２】
検索処理Ｓ８６０で一定時間を過ぎた場合には、センタ側の装置であるサーバ４１０はステップＳ８９０でクライアント側の端末４４０に対してデータが無かったことを表すデータをレスポンス８９１として送信する。次にステップＳ８９１では本実施の処理を呼び出す上位のアプリケーションの要求処理を満たすか否かを判断する。その要求処理とは要求データの受信を完了した場合などである。要求処理を満足した場合は本処理を終了し、満足しない場合はステップＳ８２０に戻る。なおステップＳ８９１は上位のアプリケーションの使用方法によっては無くてもかまわない。一方クライアント側の端末４４０は、クライアント側の端末とセンタ側のサーバが通信を開始した直後、または一旦上記データ受信方式に従いデータ受信のリクエストを発行しレスポンスが返ってきた後で、常に上記のデータ受信方式に従いデータの受信を行う。
【００５３】
クライアント側の端末４４０からセンタ側のサーバ４１０へのリクエストは、クライアント側端末の上位のアプリケーションで終了を指示するまで続けられる。
【００５４】
図９は、クライアント側の端末４４０がセンタ側の装置であるサーバ４１０からデータを受信する処理で使用されるＨＴＴＰのリクエストとレスポンスのデータの内容を示している。
ＨＴＴＰリクエスト９１０（第３のカプセル化したデータ）では、データのＨＴＴＰプロトコルによる通信情報のカプセル化により次の情報が設定されている。すなわちそれは、ＨＴＴＰヘッダ、センタ側の装置であるサーバがクライアント側の端末を一意に識別する情報、このＨＴＴＰリクエストでクライアント側の端末４４０がセンタ側の装置であるサーバ４１０からデータを受信することを表す情報である。
【００５５】
ＨＴＴＰレスポンス９２０（第４のカプセル化したデータ）では、図８の８７０でセンタ側のサーバ４１０からクライアント側の端末４４０に送信されるＨＴＴＰレスポンス８７１のデータの内容を示している。そこでは、受信データがあることを表す情報と、センタ側のサーバ４１０からクライアント側の端末４４０に送信するデータ９２１を設定している。一方、ＨＴＴＰレスポンス９３０（第４のカプセル化したデータ）では、図８の８９０でセンタ側の装置４１０からクライアント側の端末４４０に送信されるＨＴＴＰレスポンス８９１のデータの内容を示している。
ここでは、受信データがないことを表す情報を設定している。
【００５６】
図１０は、本発明によるクライアント側の端末４４０とセンタ側の装置であるサーバ４１０との間の通信を独立した２本のＨＴＴＰ通信である送信用ＨＴＴＰ通信１１１０と受信用ＨＴＴＰ通信１１２０を使用して行う構成を示す。この構成では、クライアント側の端末４４０とセンタ側のサーバ４１０において送信と受信の処理を個別に独立して行う方法を示している。
【００５７】
その方法は、スレッドで送信および受信に関する処理を行うことにより、双方向で非同期の通信を行うことである。以下、その処理を説明する。まずその処理の実装に関して述べる。クライアント側の端末４４０においては、送信用ＨＴＴＰ通信１１１０を使用して送信を行う処理をクライアント側の端末４４０の送信スレッド１０２０で、受信用ＨＴＴＰ通信１１２０を使用して受信を行う処理をクライアント側の端末４４０の受信スレッド１０３０で実装している。またセンタ側の装置であるサーバ４１０においては、送信用ＨＴＴＰ通信１１１０を使用して受信を行う処理をサーバ４１０の受信スレッド１０６０、受信用ＨＴＴＰ通信１１２０を使用して送信を行う処理をサーバ４１０の送信スレッド１０７０で実装している。
【００５８】
次に処理の流れについて説明する。まずクライアント側の端末４４０で、センタ側の装置であるサーバ４１０へ送信するデータ１００１が上位のアプリケーションで発生し、送信が必要になった場合に次の処理を行う。
このデータ１００１は例えばある目的の演算処理をセンタ側装置に行わせるものである。
【００５９】
上記データの送信では、クライアント側の端末４４０の送信スレッド１０２０を使用して送信を開始し、送信用ＨＴＴＰ通信１１１０を使用して図６に示す方式でデータ１００１をセンタ側の装置であるサーバ４１０に対して送信する。データ１００１は図７のＨＴＴＰリクエストの送信するデータ７１１に相当する。サーバ４１０に送信するデータはリクエスト６２１であり、その結果をサーバからレスポンス６８１として受信する。
【００６０】
またクライアント側の端末４４０では、クライアント側の端末の受信スレッド１０３０によりセンタ側のサーバ４１０からのデータ１００３の受信処理を行う。
この受信処理は図８に示す方式で、まず受信要求を表すリクエストをセンタ側のサーバ４１０に送信する。
【００６１】
この受信要求を表すリクエストは、クライアント側の端末４４０の通信開始直後、または一旦クライアント側の端末の受信スレッド１０３０でセンタ側のサーバ４１０からのレスポンスを受け取った後で、常にセンタ側のサーバ４１０に対して送信しておく。次にセンタ側のサーバ４１０からライアント側の端末４４０に対して、送信するべきデータ１００３が送られた場合には、クライアント側の端末４４０はデータ１００３をセンタ側の装置であるサーバ４１０から受信する。サーバのデータ１００３は例えば上記データ１００１に基づく演算処理の結果として発生したデータであり、上記演算処理が終了すると上記端末４４０の識別情報が付加されて保持される。サーバ４１０は、図８のステップＳ８６０でこのデータの有無、すなわちリクエストされた演算処理の終了の有無および処理結果としてのデータの有無を検索する。上記処理結果であるデータ１００３を上記識別情報に基づく検索により見つけると、上述のとおり、そのデータ１００３を受信スレッド１０３０へ送信する。データ１００３は図９のＨＴＴＰレスポンスの受信するデータ９２１に相当する。クライアント端末４４０に送信するデータはレスポンス８７１であり、その要求はクライアント端末４４０からリクエスト８２１として受信する。
【００６２】
すなわち、センタ側の装置であるサーバ４１０ではリクエストに基づく処理を行った結果、クライアント側の端末４４０へ送信するべきデータ１００３が発生した場合には、このデータを送信するため、サーバ４１０の送信スレッド１０７０を使用して送信を開始し、受信用ＨＴＴＰ通信１１２０を使用してデータを送信する。
【００６３】
データの送信は、以下のステップの処理により実行される。
そのステップは、センタ側の装置であるサーバ４１０で、クライアント側の端末４４０に対する識別可能な情報等のデータを設定し、その情報をもとに図８のデータの検索でデータの取得が行われる。
またセンタ側のサーバ４１０は、クライアント側の端末４４０からのデータの受信が必要になった場合に、サーバ４１０の受信スレッド１０６０を使用して受信を開始し、送信用ＨＴＴＰ通信１１１０を使用してデータ１００１を受信する。
【００６４】
上述のように本実施例では、送信用ＨＴＴＰ通信路１１１０と受信用通信路１１２０を確保し続けることができる。この処理の終了処理は、例えば端末４４０の上位のアプリケーションプログラムが終了を判断し、指示した場合その中断命令によって実施される。
【００６５】
以上、述べたように上記実施の形態によれば、ファイアウォールを通過するステートレスなプロトコルを用いて双方向で非同期な通信を実行できる。さらに、本方法は機能が独立しており、関数化できるので、上位アプリケーションとの密着度が少なく、上位アプリケーションからサブルーチン的に用いることができる。そのために、他の通信方法を使用していたシステムを本実施例の方式を用いたシステムに移行することが容易である。
【００６６】
また、本実施例の方式で部分的に同期処理を実行するように上位のアプリケーションで調整することも、本実施例の機能独立性の高さから用意に実現できる。上位のアプリケーションから本発明の実施例の方法を用いて、部分的に同期処理を行う方法を図１１と図１２を用いて説明する。まず、図１１は非同期で動作する本実施例で説明した関数を非同期処理で用いる上位アプリケーションの使用例である。Ｓｕｂ１、Ｓｕｂ２、Ｓｕｂ３は本実施例の方法で動作する関数、ａｒｇ１、ａｒｇ２、ａｒｇ３はその関数の引数、Ｐｒｉｄ１、Ｐｒｉｄ２、Ｐｒｉｄ３は各関数が取得したプロセスｉｄである。まずステップＳ１１０１で関数Ｓｕｂ１をコールする。続いてステップＳ１１０２で関数Ｓｕｂ２をコールし、さらに続いてステップＳ１１０３で関数Ｓｕｂ３をコールする。 この処理によりステップＳ１１０１からステップＳ１１０３は、それぞれ非同期で動作する。
【００６７】
図１２は非同期で動作する本実施例で説明した関数を同期処理で用いる上位アプリケーションの使用例である。Ｓｕｂ１、Ｓｕｂ２、Ｓｕｂ３は本実施例の方法で動作する関数、ａｒｇ１、ａｒｇ２、ａｒｇ３はその関数の引数、Ｐｒｉｄ１、Ｐｒｉｄ２、Ｐｒｉｄ３は各関数が取得したプロセスｉｄである。まずステップＳ１１０１で関数Ｓｕｂ１をコールする。ついでステップＳ１２０２でプロセスＰｒｉｄ１が終了するまで待機する。プロセスＰｒｉｄ１の終了を確認したのちステップＳ１２０３で関数Ｓｕｂ２をコールする。同様にステップＳ１２０４でプロセスＰｒｉｄ２が終了するまで処理を止めて待機する。プロセスＰｒｉｄ２が終了するのを確認したのち、ステップＳ１２０５で関数Ｓｕｂ３をコールする。 この一連の処理によりステップＳ１２０１、ステップＳ１２０３ 、ステップＳ１２０５は、それぞれ同期をとって順番に動作する。
【００６８】
また本実施例に関して、例えばクライアント側の端末をＪａｖａ（Ｒ）のアプレット、センタ側の装置であるサーバをＪａｖａ（Ｒ）のサーブレットで実装することも可能である。
その場合には、以下のような方法でクライアント側の端末とセンタ側の装置であるサーバの間の、データの送信と受信に関して保守・点検や異常が発生した場合の原因を確認する方法が実装できる。
【００６９】
まずクライアント側の端末側では、Ｊａｖａ（Ｒ）コンソールに対して、送信用のＨＴＴＰ通信のリクエストとレスポンスの内容と、受信用のＨＴＴＰ通信のリクエストとレスポンスの内容を出力する。次にセンタ側の装置であるサーバ側では、送信用のＨＴＴＰ通信と受信用のＨＴＴＰ通信によりクライアント側の端末から送信されたリクエストと、クライアント側の端末に返却するレスポンスの内容を、サーブレットの使用するログファイルに出力する。
このようにクライアント側の端末とセンタ側の装置であるサーバの上記出力を合わせて確認することにより、データが正確に送信または受信されているかを確認することができる。
【００７０】
さらに、これまでにクライアント側の端末とセンタ側のサーバにおいてソケット等のファイアウォールなどのセキュリティ機能を通過できない通信機能を使用してアプリケーションを開発していた場合においても前述の方法を用いることで、ファイアウォールを通過する双方向の非同期な通信を行うアプリケーションへの移行がたいへん簡単になる。
【００７１】
【発明の効果】
本発明では、自由度の大きい通信方式あるいは通信方式に係る技術を提供できる。
また上記実施の形態に記載の技術によれば、ファイアウォールによる制限を意識せずに、双方向の非同期な通信を行うアプリケーションを作成することがたいへん簡単になる。
【図面の簡単な説明】
【図１】クライアント側の端末とセンタ側の装置であるサーバの間をソケットで接続した場合の処理の例を示す図である。
【図２】クライアント側の端末とセンタ側の装置であるサーバの間の、通信の基盤をソケットで作成した場合で、上位のアプリケーションとしてＲＰＣを実装した場合の処理の例を示す図である。
【図３】クライアント側の端末とセンタ側の装置であるサーバの間の、通信の基盤をソケットで作成した場合で、スレッドを使用することにより双方向で非同期の通信を行う例を示す図である。
【図４】クライアント側の端末とセンタ側の装置であるサーバがネットワークにより接続されていることを示す図である。
【図５】クライアント側の端末とセンタ側の装置であるサーバが通信の準備を行う処理を示す図である。
【図６】クライアント側の端末からセンタ側の装置であるサーバに対してデータを送信する処理を示す図である。
【図７】クライアント側の端末からセンタ側の装置であるサーバに対してデータを送信する処理で使用されるＨＴＴＰのリクエストとレスポンスのデータの内容を示す図である。
【図８】クライアント側の端末がセンタ側の装置であるサーバからデータを受信する処理を示す図である。
【図９】クライアント側の端末がセンタ側の装置であるサーバからデータを受信する処理で使用されるＨＴＴＰのリクエストとレスポンスのデータの内容を示す図である。
【図１０】クライアント側の端末とセンタ側の装置であるサーバの間の、通信の基盤をＨＴＴＰ通信で作成した場合で、スレッドを使用することにより双方向で非同期の通信を行う例を示す図である。
【図１１】上位アプリケーションの非同期処理での使用例である。
【図１２】上位アプリケーションの同期処理での使用例である。
【符号の説明】
１０１・・・クライアント側の端末からセンタ側のサーバに送信するデータおよびセンタ側のサーバが受信するデータ、１０３・・・センタ側のサーバからクライアント側の端末に送信するデータおよびクライアント側の端末が受信するデータ、１１０・・・クライアント側の端末、１２０・・・クライアント側の端末のソケット、１５０・・・センタ側の装置であるサーバ、１６０・・・センタ側のサーバのソケット、１７０・・・作成されたサーバのソケット、１８０・・・クライアントとサーバのソケットによる接続、２０１・・・ＲＰＣに従い作成された端末からサーバに送信するデータおよびサーバが受信するデータ、２０３・・・ＲＰＣに従い作成された端末に送信するデータおよびクライアント側の端末が受信するデータ、２１０・・・クライアント側の端末、２５０・・・センタ側のサーバ、２９０・・・ソケット通信路、３０１・・・クライアント側の端末からサーバに送信するデータおよびサーバが受信するデータ、３０３・・・サーバからクライアント側の端末に送信するデータおよびクライアント側の端末が受信するデータ、３１０・・・クライアント側の端末、３２０・・・クライアント側の端末の送信スレッド、３３０・・・クライアント側の端末の受信スレッド、３５０・・・センタ側のサーバ、３６０・・・センタ側の装置であるサーバの受信スレッド、３７０・・・サーバの送信スレッド、３９０・・・ソケット通信路、４１０・・・センタ側のサーバ、４２０・・・ファイアウォール、４３０・・・ネットワーク、４４０・・・クライアント側の端末、５２４・・・クライアント側の端末からのリクエスト、５６１・・・サーバからのレスポンス、６２１・・・クライアント側の端末からのリクエスト、６８１・・・サーバからのレスポンス、７１０・・・クライアント側の端末からデータを送信する場合のＨＴＴＰリクエスト、７１１・・・クライアントがサーバに送信するデータ、７２０・・・クライアント側の端末からデータを送信する場合のＨＴＴＰレスポンス、８２１・・・クライアント側の端末からのリクエスト、８７１・・・センタ側の装置であるサーバからのレスポンス、８９１・・・センタ側の装置であるサーバからのレスポンス、９１０・・・クライアント側の端末がデータを受信する場合のＨＴＴＰリクエスト、９２０・・・センタ側の装置であるサーバがクライアント側の端末に送信するデータがある場合のＨＴＴＰレスポンス、９２１・・・サーバがクライアントに送信するデータ、９３０・・・センタ側の装置であるサーバがクライアント側の端末に送信するデータがない場合のＨＴＴＰレスポンス、１００１・・・クライアント側の端末からセンタ側の装置であるサーバに送信するデータ、１００３・・・センタ側の装置であるサーバからクライアント側の端末に送信するデータ、１０２０・・・クライアント側の端末の送信スレッド、１０３０・・・クライアント側の端末の受信スレッド、１０６０・・・センタ側の装置であるサーバの受信スレッド、１０７０・・・センタ側の装置であるサーバの送信スレッド、１１１０・・・送信用ＨＴＴＰ通信、１１２０・・・受信用ＨＴＴＰ通信
【図１】
2004192358.tif 000003
【図２】
2004192358.tif 000004
【図３】
2004192358.tif 000005
【図４】
2004192358.tif 000006
【図５】
2004192358.tif 000007
【図６】
2004192358.tif 000008
【図７】
2004192358.tif 000009
【図８】
2004192358.tif 000010
【図９】
2004192358.tif 000011
【図１０】
2004192358.tif 000012
【図１１】
2004192358.tif 000013
【図１２】
2004192358.tif 000014