(57)【要約】【課題】  ＷｅｂＳｏｃｋｅｔに非対応のＷｅｂサービスを利用する場合においても、クライアントアプリケーションからのリクエストによるＷｅｂＳｏｃｋｅｔ通信を可能とする。【解決手段】      ＷｅｂＳｏｃｋｅｔ通信とＷｅｂＳｏｃｋｅｔ以外のプロトコルを用いた通信とを仲介するゲートウェイ装置であって、ＷｅｂＳｏｃｋｅｔを用いる第１の通信手段と、ＷｅｂＳｏｃｋｅｔとは異なる第２のプロトコルを用いる第２の通信手段と、第１の通信手段と第２の通信手段の間に、ＷｅｂＳｏｃｋｅｔ形式の第１のデータと第２のプロトコル形式の第２のデータとを相互に変換し、第１のデータと第２のデータとを紐付けるデータ変換手段を設ける。クライアントはＷｅｂＳｏｃｋｅｔを用いながら、ＷｅｂＳｏｃｋｅｔに非対応のＷｅｂサービスを利用することが出来る。【選択図】      図２
2015045897.tif 000002
【特許請求の範囲】
【請求項１】
ＷｅｂＳｏｃｋｅｔにより通信を行う第１の通信手段と、ＷｅｂＳｏｃｋｅｔとは異なるプロトコルにより通信を行う第２の通信手段と、前記第１の通信手段からから受信したＷｅｂＳｏｃｋｅｔ形式の第１のデータをＷｅｂＳｏｃｋｅｔとは異なる第２のプロトコル形式の第２のデータに変換し前記第２の通信手段から受信した前記第２のデータを前記第１のデータに変換するとともに前記第１のデータと前記第２のデータとを紐付けするデータ変換部と、を有することを特徴とするゲートウェイ装置。
【請求項２】
ルータ機能部を有していることを特徴とする請求項１に記載のゲートウェイ装置。
【請求項３】
前記紐付け手段が、前記第１のデータまたは前記第２のデータに識別子とコールバックＵＲＬを紐付け情報として付与する紐付け情報付与手段を有することを特徴とする請求項１または請求項２に記載のゲートウェイ装置。
【請求項４】
前記紐付け手段が、前記ルータに接続するクライアントのプライベートＩＰアドレスと前記ＷｅｂＳｏｃｋｅｔデータとを紐付けるアドレス紐付け手段を有していることを特徴とする請求項２または請求項３に記載のゲートウェイ装置。
【請求項５】
ＷｅｂＳｏｃｋｅｔにより通信を行う第１の通信手段と、ＷｅｂＳｏｃｋｅｔとは異なるプロトコルにより通信を行う第２の通信手段と、前記第１の通信手段からから受信したＷｅｂＳｏｃｋｅｔ形式の第１のデータをＷｅｂＳｏｃｋｅｔとは異なる第２のプロトコル形式の第２のデータに変換し前記第２の通信手段から受信した前記第２のデータを前記第１のデータに変換し前記第１のデータと前記第２のデータとを紐付けするデータ変換部と、を有するゲートウェイ装置を用いた通信方法であって、前記第１の通信手段から第１のデータを受信する工程と、前記第１のデータを前記第２のデータに変換する工程と、前前記第２の通信手段から前記第２のデータを受信する工程と、前記第２のデータを前記第１のデータに変換する工程と、記第１のデータと前記第２のデータとを紐付けする工程と、を有することを特徴とするゲートウェイ装置を用いた通信方法。
【請求項６】
前記紐付けする工程が、前記第１データまたは第２のデータに識別子とコールバックＵＲＬを付与する工程を有することを特徴とする請求項５に記載のゲートウェイ装置を用いた通信方法。
【請求項７】
前記ゲートウェイ装置が複数のクライアントとＷｅｂＳｏｃｋｅｔコネクションを確立する工程と、前記クライアントからのリクエストと前記クライアントのプライベートＩＰアドレスを紐付けする工程を有することを特徴とする請求項５または請求項６に記載のゲートウェイ装置を用いた通信方法。
【請求項８】
ＷｅｂＳｏｃｋｅｔにより通信を行う第１の通信手段と、ＷｅｂＳｏｃｋｅｔとは異なるプロトコルにより通信を行う第２の通信手段と、前記第１の通信手段からから受信したＷｅｂＳｏｃｋｅｔ形式の第１のデータをＷｅｂＳｏｃｋｅｔとは異なる第２のプロトコル形式の第２のデータに変換し前記第２の通信手段から受信した前記第２のデータを前記第１のデータに変換し前記第１のデータと前記第２のデータとを紐付けするデータ変換部と、を有するゲートウェイ装置に用いる通信プログラムあって、前記第１の通信手段から第１のデータを受信するステップと、前記第１のデータを前記第２のデータに変換するステップと、前前記第２の通信手段から前記第２のデータを受信するステップと、前記第２のデータを前記第１のデータに変換するステップと、前記第１のデータと前記第２のデータとを紐付けするステップと、を有することを特徴とするゲートウェイ装置に用いる通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲートウェイ装置に関し、特にＷｅｂＳｏｃｋｅｔを用いるゲートウェイ装置に関する。
【背景技術】
【０００２】
サービス指向アーキテクチャ（Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ：ＳＯＡ）は、標準的なインターフェースを持った再利用可能なソフトウェア部品の組合せによってシステムを構成するというコンピュータシステムの作り方である。このようなソフトウェア部品の代表例はＷｅｂサービスである。
【０００３】
これまでの一般的なＷｅｂアプリケーションでは、Ｗｅｂサービスの組合せは、ネットワーク上に配備されたアプリケーションサーバが担当し、クライアント（主にＷｅｂブラウザ）はアプリケーションサーバが行った処理の結果を表示する機能を担っていた。
【０００４】
しかしながら、ＡｊａｘやＣｏｍｅｔのような近年のＨＴＭＬ技術の発展により、ＷｅｂブラウザはＨＴＭＬ表示にとどまらず、クライアントサイドで様々な処理を実施するクライアントアプリケーションとしての利用が可能になってきている。これにより、アプリケーションサーバが存在していなくとも、クライアントアプリケーション上におけるＷｅｂサービスの組合せによって、アクセスしたのと同等の機能を実現することも可能である。
【０００５】
さらに多様な機能を実現するためには、通常の同期通信だけでなく、サーバからクライアントへのデータのプッシュと、非同期通信ができることが望ましい。ところが、Ａｊａｘアプリケーションでは、サーバとクライアント間のデータのやり取りが頻繁に発生するが、あくまでブラウザ側からサーバにデータの送信リクエストを出す手段であり、サーバ側からクライアントにデータをプッシュ配信することが難しい。またＣｏｍｅｔでは、サーバ側からのプッシュ配信が可能なものの、ＨＴＴＰコネクションを長時間占有するため、同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性がある。この問題はクライアントの数が増えるとさらに深刻になる。
【０００６】
これらの課題を解決する技術としてＷｅｂＳｏｃｋｅｔが考案された。ＨＴＴＰでは、接続の確立→リクエスト送信→レスポンス受信→切断といったプロセスを繰り返し行う必要があるのに対し、ＷｅｂＳｏｃｋｅｔでは接続の確立は１回だけでよい。また、接続、切断等のＨＴＴＰヘッダが不要になるため、トラフィックを抑えられる。そして、コネクションを確立した後は、非同期で双方向の通信を行うことが出来る。すなわちサーバからクライアントへのデータのプッシュも可能である。
【０００７】
このようなＷｅｂＳｏｃｋｅｔの特性を利用することで、通信の負荷を軽減しリアルタイムで情報をプッシュする技術が種々検討されている。
【０００８】
例えば、特許文献１には、クライアントとサーバの間にＷｅｂＳｏｃｋｅｔコネクションを張ることで、多数のクライアントが同時に参加するオークションシステムを構築する方法が提案されている。このオークションシステムでは、クライアントがサーバとＷｅｂＳｏｃｋｅｔコネクションを確立し、クライアントから一度情報の送信リクエストを出しておけば、以降は入札価格の更新等があるたびに、サーバからクライアントに情報がプッシュ送信される。このシステムでは通信の負荷が非常に軽いため、能力の低いサーバでも用いることができ、クライアントの数が増えても、タイムラグのないリアルタイム通信を実現することができる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１３−２０４０７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかし、特許文献１の技術は、サーバがＷｅｂＳｏｃｋｅｔに対応していることが前提となっており、既にサービスが提供されている多くのＷｅｂＳｏｃｋｅｔ非対応サーバには適用することが出来ないという問題点がある。
【００１１】
すなわち、ＷｅｂＳｏｃｋｅｔ非対応のサーバとクライアント間の通信において、ＨＴＴＰ等による同期型Ｗｅｂサービスは利用可能であるが、非同期型Ｗｅｂサービスは利用することが出来ない。
【００１２】
またＨＴＴＰを用いた非同期型Ｗｅｂサービスを利用するためには、クライアントにＨＴＴＰサーバ機能が必要であるが、一般的には、ＨＴＴＰサーバ機能は、クライアントアプリケーションに組み込むことが出来ないという問題がある。
【００１３】
本発明の目的は、上記の課題に鑑みて成されたものであり、ＷｅｂＳｏｃｋｅｔ非対応のサーバとクライアント間においても、クライアントアプリケーションからのリクエストによる非同期型通信の利用を可能とすることである。
【課題を解決するための手段】
【００１４】
上記の課題を解決するために、本発明のゲートウェイ装置は、ＷｅｂＳｏｃｋｅｔにより通信を行う第１の通信手段と、ＷｅｂＳｏｃｋｅｔとは異なるプロトコルにより通信を行う第２の通信手段と、前記第１の通信手段からから受信したＷｅｂＳｏｃｋｅｔ形式の第１のデータをＷｅｂＳｏｃｋｅｔとは異なる第２のプロトコル形式の第２のデータに変換し前記第２の通信手段から受信した前記第２のデータを前記第１のデータに変換するとともに前記第１のデータと前記第２のデータとを紐付けするデータ変換部と、を有する。
【発明の効果】
【００１５】
本発明によるゲートウェイ装置では、ＷｅｂＳｏｃｋｅｔを用いて、ＷｅｂＳｏｃｋｅｔとは異なるプロトコルによるＷｅｂサービスを利用することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明第１の実施の形態のゲートウェイ装置のブロック図である。
【図２】本発明第１の実施の形態の動作を示すシーケンス図である。
【図３】本発明第１の実施の形態のゲートウェイ装置のリクエスト送信動作を示すフローチャートである。
【図４】本発明第１の実施の形態のＷｅｂＳｏｃｋｅｔデータフォーマットの一例である。
【図５】本発明第１の実施の形態の紐付け情報の一例である。
【図６】本発明第１の実施の形態のレスポンスデータ形式の一例である。
【図７】本発明第１の実施の形態のデータ変換の一例である。
【図８】本発明第１のレスポンス受信動作を示すフローチャートである。
【図９】本発明第２の実施の形態を示すブロック図である。
【発明を実施するための形態】
【００１７】
本実施の形態のゲートウェイ装置は、ＷｅｂＳｏｃｋｅｔによる非同期型双方向通信と、ＷｅｂＳｏｃｋｅｔとは異なる他の通信プロトコルを用いた通信とを仲介するものである。以下、図面を参照しながら本発明について詳細に説明する。
（第１の実施の形態）
図１は、本発明第１の実施の形態のゲートウェイ装置を示す構成図である。
【００１８】
ゲートウェイ装置１００は、ＷｅｂＳｏｃｋｅｔ通信部１、ＷｅｂＳｏｃｋｅｔデータ解析部２、変換シナリオ部３、Ｗｅｂサービスデータ生成部４、Ｗｅｂサービス通信部５、Ｗｅｂサービスデータ解析部６、紐付け情報保持部７、シナリオ保持部８、ＷｅｂＳｏｃｋｅｔデータ生成部９を有する。
【００１９】
ＷｅｂＳｏｃｋｅｔ通信部１は、クライアントとの間でＷｅｂＳｏｃｋｅｔのコネクションを確立し、クライアントから受信したデータをＷｅｂＳｏｃｋｅｔデータ解析部２へ出力する。また、ＷｅｂＳｏｃｋｅｔデータ生成部９から入力されたデータをクライアントに対し送信する。
【００２０】
ＷｅｂＳｏｃｋｅｔデータ解析部２は、入力されたデータを解析し、各種パラメータを変換シナリオ部３へ出力する。
【００２１】
変換シナリオ部３は、ＷｅｂＳｏｃｋｅｔデータ解析部２とシナリオ保持部８の情報を元にデータフォーマットの変換を実施し、Ｗｅｂサービスデータ生成部４へ出力する。その際にクライアント側の通信とＷｅｂサービス側の通信の紐付け、および非同期Ｗｅｂサービスにおけるリクエストとレスポンスの紐付けのために用いる識別子（パラメータ名）を紐付け情報保持部７へ保存する。また、Ｗｅｂサービスデータ解析部６から入力されたデータとシナリオ保持部８の情報を元にデータフォーマットの変換を実施し、ＷｅｂＳｏｃｋｅｔデータ生成部９に出力する。その際に紐付け情報保持部７に保持された紐付け情報を参照し、Ｗｅｂサービス側通信とクライアント側通信の紐付けを行う。
【００２２】
紐付け情報保持部７は、クライアント側の通信とＷｅｂサービス側の通信の紐付け、および非同期Ｗｅｂサービスにおけるリクエストとレスポンスの紐付けのために用いる識別子の保持に利用される。また、コールバックＵＲＬと適用される変換シナリオ情報の保持に利用される。
【００２３】
Ｗｅｂサービスデータ生成部４は変換シナリオ部３から入力された情報から、Ｗｅｂサービスのリクエスト情報を生成し、Ｗｅｂサービス通信部５へ出力する。
【００２４】
Ｗｅｂサービス通信部５は、Ｗｅｂサービスサーバとコネクションを確立し、要求リクエストの送信を行う。また、レスポンスを受信し、Ｗｅｂサービスデータ解析部６へ出力する。
【００２５】
Ｗｅｂサービスデータ解析部６は、入力されたデータを解析し、各種パラメータを変換シナリオ部３へ出力する。
【００２６】
ＷｅｂＳｏｃｋｅｔデータ生成部９は変換シナリオ部３から入力された情報から、ＷｅｂＳｏｃｋｅｔデータに変換されたＷｅｂサービスのレスポンス情報を生成し、ＷｅｂＳｏｃｋｅｔ通信部１へ出力する。
【００２７】
シナリオ保持部８は、ＷｅｂＳｏｃｋｅｔ通信およびＷｅｂサービス通信の制御に必要なサービスシーケンス情報、データフォーマットおよびそのマッピング、Ｗｅｂサービスにおけるリクエストとレスポンスの紐付けのために用いる識別子情報（パラメータ名）を保持する。
【００２８】
次にゲートウェイ装置１００の動作について説明する。
【００２９】
図２はゲートウェイ装置１００を用いて、クライアント２００がＷｅｂサービスサーバ３００を利用するときのフローを示すシーケンス図である。図２を参照して、まず動作の概要を説明する。
【００３０】
まずクライアント２００がゲートウェイ装置１００との間にＷｅｂＳｏｃｋｅｔコネクションを確立する（Ｓ１−１）。以降クライアント２００とゲートウェイ装置１００の間では、コネクションの切断・再接続を行うことなく、非同期、双方向の通信が可能になる。次にクライアント２００がゲートウェイ装置１００にＷｅｂサービス・リクエストを送信する（Ｓ１−２）。ゲートウェイ装置１００は受信したデータを解析し（Ｓ１−３）、Ｗｅｂサービスに適合するようにデータ変換シナリオを決定し（Ｓ１−４）、識別子とコールバックＵＲＬを決定する。結果は紐付け情報保持部７に保存される（Ｓ１−５）。次いでデータ変換を実行し（Ｓ１−６）、Ｗｅｂサービスサーバ３００にＷｅｂサービス・リクエストを送信する。Ｗｅｂサービスサーバ３００は、受信した要求に応じた処理を行い（Ｓ１−８）、レスポンスをゲートウェイ装置１００に送信する（Ｓ１−９）。レスポンスは、コールバックＵＲＬへのリクエストの形で送信される。ゲートウェイ装置１００は、レスポンスを受信すると、データ解析を行い（Ｓ１−１０）、クライアント２００から受信したリクエストとの紐付けを行う（Ｓ１−１１）。次いでＷｅｂＳｏｃｋｅｔ用にデータ変換を行い（Ｓ１−１２）、Ｗｅｂサービスデータをクライアント２００に送信する（Ｓ１−１３）。
【００３１】
次に本実施の形態におけるゲートウェイ装置１００の動作の詳細について説明する。図３はリクエスト送信におけるゲートウェイ装置１００の動作を示すフローチャートである。
【００３２】
Ｓ２−１：ＷｅｂＳｏｃｋｅｔコネクションの確立
クライアントとハンドシェイクを行い、ＷｅｂＳｏｃｋｅｔコネクションを確立する。なおＷｅｂＳｏｃｋｅｔコネクションの確立手法は標準技術であるため、手法自体の説明は省略する。
【００３３】
Ｓ２−２：クライアントからデータの受信
ゲートウェイ装置１００は、ＷｅｂＳｏｃｋｅｔを介してクライアントからデータを受信する。データは、ＷｅｂＳｏｃｋｅｔ通信部１により受信される。ＷｅｂＳｏｃｋｅｔ通信部１は受信したデータをＷｅｂＳｏｃｋｅｔデータ解析部２へ出力する。
【００３４】
Ｓ２−３：データの解析
ＷｅｂＳｏｃｋｅｔデータ解析部２は事前に定められたインターフェース仕様に基づきデータの解析を実施し、変換シナリオ部３へ出力する。
【００３５】
なお、クライアントとゲートウェイ装置１００の間のインターフェース仕様はＷｅｂＳｏｃｋｅｔのデータフォーマット形式である。このデータフォーマットを、利用するＷｅｂサービスに因らない形式としておくと、クライアントにおける本装置利用の敷居を下げるものとなる。図４にデータフォーマットの具体例を示す。図４に示すように、データには利用するＷｅｂサービスのＵＲＬおよびＷｅｂサービス・リクエストに含むパラメータ情報が含まれる。また、パラメータのうちコールバックＵＲＬが設定される部分には、特定文字列を設定することで、変換シナリオにおいて決定するコールバックＵＲＬへの置き換えを実施可能とする。図４の例ではコールバックＵＲＬを、＿ＣＡＬＬＢＡＣＫＵＲＬ＿としている。なお、図４のデータフォーマットは実際にはバイナリ形式のデータである。
【００３６】
Ｓ２−４：適用シナリオの決定
変換シナリオ部３は、入力されたデータを元に、その通信に対し適用する変換シナリオを決定する。変換シナリオの決定手法については実装に依存するが、ＷｅｂサービスＵＲＬ毎にシナリオを決定するのが最も容易な方法である。例えばＵＲＬが異なるＷｅｂサービスがある場合、それぞれのサービス毎に特有のシーケンスフロー、信号フォーマットを有する。シナリオ保持部８は、このような変換ルールを、ＵＲＬをキーとしたテーブルに保持している。
【００３７】
Ｓ２−５：識別子情報・コールバックＵＲＬの決定、保存
変換シナリオ部３は、変換シナリオを元に識別子に用いるパラメータ情報を決定する。識別子の特定は変換シナリオ内に規定され、検索可能とする。
【００３８】
識別子は、ＷｅｂＳｏｃｋｅｔとＷｅｂサービスの紐付け、Ｗｅｂサービス・リクエストとＷｅｂサービス・レスポンスの紐付けに用いる情報となる。通常、非同期Ｗｅｂサービスにおいては、リクエストとレスポンスを紐付ける一意のパラメータが規定されるため、本装置で規定するパラメータも基本的にはこれと同一のものとなる。
【００３９】
なお、非同期Ｗｅｂサービスにおいてリクエストとレスポンスを一意に紐付けるパラメータは、クライアント側が決定してリクエストに設定するパターン、Ｗｅｂサービス側が決定しレスポンスに設定するパターンなどが存在するが、それらの差分は変換シナリオにより吸収される。ここではリクエストに設定するパターンで記載する。
【００４０】
また変換シナリオ部３は、変換シナリオを元にコールバックＵＲＬを決定し、決定されたコールバックＵＲＬを有効化する。コールバックＵＲＬは非同期Ｗｅｂサービスにおいて、レスポンスの送信先となる。コールバックＵＲＬの内容は実装に依存するが、全てのサービス・リクエストで同一にしてもよいし、識別子情報を元に全てのサービス・リクエストで異なるものにしてもよい。図５に一例を示す。図５では、コールバックＵＲＬに識別子情報を含むように規定している。変換シナリオ部３は、図５のように、決定された識別子とそれに紐付くセッションの情報、およびコールバックＵＲＬと紐付く変換シナリオ情報を紐付け情報保持部４へ保存する。
【００４１】
図６にＷｅｂサービス・レスポンスの一例を示す。図６では、レスポンスにおけるＷｅｂサービスパラメータ内の、ｃｏｒｒｅｌａｔｅｒパラメータ（＜ｃｏｒｒｅｌａｔｏｒ＞〜＜／ｃｏｒｒｅｌａｔｏｒ＞で囲まれた部分）を識別子として利用するように規定している。
【００４２】
Ｓ２−６：データフォーマット変換・リクエスト生成
変換シナリオ部３は、続いてデータフォーマット変換を実施する。ＷｅｂＳｏｃｋｅｔにおける通信データと、Ｗｅｂサービスのリクエストフォーマットのデータマッピングは変換シナリオに規定され、その情報を元にデータフォーマットの変換を実施し、Ｗｅｂサービスデータ生成部５へ出力する。データフォーマット変換例を図７に示す。ここでは、Ｗｅｂサービス通信がＨＴＴＰで行われる場合の例を示している。概要は次の通りである。１）ＷｅｂサービスＵＲＬを元にＨＴＴＰ電文のリクエストラインを生成、２）ＨＴＴＰヘッダの自動設定、３）ＷｅｂサービスパラメータをＨＴＴＰボディに自動設定、４）ゲートウェイ装置にて決定したコールバックＵＲＬで＿ＣＡＬＬＢＡＣＫＵＲＬ＿を置換。Ｗｅｂサービスデータ生成部５は、入力された情報を元にＷｅｂサービスに送信するＷｅｂサービスのリクエスト電文を作成し、Ｗｅｂサービス通信部６へ出力する。
【００４３】
Ｓ２−７：Ｗｅｂサービス要求リクエスト送信
Ｗｅｂサービス通信部６は、ＷｅｂサービスＵＲＬを元にＷｅｂサービスサーバとの間でコネクションを確立する。コネクションの確立については標準技術であるため説明は割愛する。コネクションの確立後、Ｗｅｂサービス通信部５は、Ｗｅｂサービスデータ生成部４から入力された要求リクエスト電文をＷｅｂサービスサーバ３００へ送信する。
【００４４】
次にレスポンス受信動作について説明する。図８はゲートウェイ装置１００のＷｅｂサービス・レスポンス受信からＷｅｂＳｏｃｋｅｔデータ送信までの動作を示すフローチャートである。
【００４５】
Ｓ３−１：Ｗｅｂサービスからレスポンス受信
Ｗｅｂサービスからのレスポンスは、Ｗｅｂサービス通信部６において用意されたコールバックＵＲＬにて受信され、Ｗｅｂサービスデータ解析部７へ出力される。
【００４６】
Ｓ３−２：データの解析
Ｗｅｂサービスデータ解析部６は事前に定められたインターフェース仕様に基づきデータの解析を実施し、結果を変換シナリオ部３へ出力する。
【００４７】
Ｓ３−３：紐付けられたリクエストを決定
変換シナリオ部３はデータ解析により得られた情報から識別子を決定し、紐付け情報保持部４の検索を行い、紐付けられた要求リクエストを決定する。
【００４８】
紐付けられた要求リクエストの決定は実装に依存し、それぞれの実装に適切な方法により実施される。例えば、図６に示したようにコールバックＵＲＬから適用される変換シナリオを特定する。そして変換シナリオを元に、レスポンスメッセージ内から識別子情報を取得し、得られた識別子から紐付けられたリクエストを決定する。
【００４９】
Ｓ３−４：データフォーマット変換・ＷｅｂＳｏｃｋｅｔデータ作成
変換シナリオ部３は、続いてデータフォーマット変換を実施する。Ｗｅｂサービスのリクエストフォーマットと、ＷｅｂＳｏｃｋｅｔにおける通信データのデータマッピングは変換シナリオに規定され、その情報を元にデータフォーマットの変換を実施し、ＷｅｂＳｏｃｋｅｔデータ生成部９へ出力する。
【００５０】
ＷｅｂＳｏｃｋｅｔデータ生成部９は、入力された情報を元にクライアントに送信するデータを作成し、ＷｅｂＳｏｃｋｅｔ通信部１へ出力する。
【００５１】
Ｓ３−５：ＷｅｂＳｏｃｋｅｔデータ送信
ＷｅｂＳｏｃｋｅｔ通信部１は、データ生成部８から入力されたデータを、Ｓ２−５で紐付けられた通信に対し送信する。
【００５２】
以上説明したように、本実施の形態のゲートウェイ装置を用いれば、ＷｅｂＳｏｃｋｅｔ非対応のＷｅｂサービスを利用する場合においても、クライアントは非同期双方向の通信を行うことができる。また、クライアントは本発明のゲートウェイ装置とＷｅｂＳｏｃｋｅｔで通信しているため、ＷｅｂサービスサーバがＷｅｂＳｏｃｋｅｔ対応か非対応かに関わらず、非同期双方向通信を利用することが出来る。
（第２の実施の形態）
本実施の形態のゲートウェイ装置１００は、第１の実施の形態の機能に加えて、ルータ機能部１１０を備えている。図９は本発明第２の実施の形態を示すブロック図である。ゲートウェイ装置１００に複数のクライアント２００、クライアント２００ａ、クライアント２００ｂ、クライアント２００ｃ、・・・が接続されている。ゲートウェイ装置１００はインターネット４００に接続されている。それぞれのクライアント２００がインターネット４００に接続するＷｅｂサービスを利用する際には、クライアント２００とゲートウェイ装置１００の間にはＷｅｂＳｏｃｋｅｔコネクションが確立される。あるクライアント２００からのリクエストは、当該クライアントのプライベートＩＰアドレスと紐付けられ、第１の実施の形態と同様にＷｅｂサービスからのレスポンスとも紐付けられる。このようにして、本実施の形態によれば、複数のクライアント２００が、ＷｅｂＳｏｃｋｅｔを用いてＷｅｂサービスを利用することができる。
【符号の説明】
【００５３】
１    ＷｅｂＳｏｃｋｅｔ通信部
２    ＷｅｂＳｏｃｋｅｔデータ解析部
３    変換シナリオ部
４    Ｗｅｂサービスデータ生成部
５    Ｗｅｂサービス通信部
６    Ｗｅｂサービスデータ解析部
７    紐付け情報保持部
８    シナリオ保持部
９    ＷｅｂＳｏｃｋｅｔデータ生成部
１００    ゲートウェイ装置
１１０    ルータ機能部
２００    クライアント
【図１】
2015045897.tif 000003
【図２】
2015045897.tif 000004
【図３】
2015045897.tif 000005
【図４】
2015045897.tif 000006
【図５】
2015045897.tif 000007
【図６】
2015045897.tif 000008
【図７】
2015045897.tif 000009
【図８】
2015045897.tif 000010
【図９】
2015045897.tif 000011