JP2012003763A - バイナリパケット中継システムおよび方法 - Google Patents

Abstract

【課題】バイナリパケット中継システムおよび方法を提供する。
【解決手段】中継システムは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。中継システムによれば、バイナリプロトコルを用いるアプリケーションサーバとＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【選択図】図５

Description

本発明は、バイナリパケット中継システムおよび方法に関し、より詳しくは、互いに異なるプロトコルを用いる複数のサーバから情報を受信し、送信する対象のサーバが用いるプロトコルに応じて変換して送信することによって、情報を中継することのできる中継システムおよび方法に関する。

オンラインゲームの発展に伴ってゲーム中にもゲーム上でウェブサービスを利用しようとすることがあり、ウェブサービス中にゲームを提供することが必要な場合も生じている。

しかし、ゲームを実行するゲームサーバとウェブサービスを実行するウェブサービスサーバとは互いに使用しているプロトコルが異なるので中継のためのシステムが求められている。

したがって、非同期通信基盤のゲームサーバと同期通信基盤のウェブサービスサーバとの情報を中継することによって、ゲーム上でもウェブサービスを容易に用いることのできるシステムおよび方法が求められている。

本発明は、バイナリプロトコルを用いるアプリケーションサーバと、ＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることのできるシステムおよび方法を提供することを目的とする。

また、本発明は、アプリケーションサーバに対してＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することのできるシステムおよび方法を提供することを目的とする。

本発明の一実施形態に係る中継サーバは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。

本発明の一実施形態に係るパケット中継方法は、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、前記バイナリパケットをＨＴＴＰパケットに変換するステップと、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップとを含む。

本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバと、ＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。

また、本発明の一実施形態によれば、アプリケーションサーバに対してＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することができる。

本発明の一実施形態に係る中継システムの構成を示す図である。 本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。 本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。 本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。 本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。 本発明のコンバータ部がバイナリパケットをＨＴＴＰパケットに変換する過程の一例である。 本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。 本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。 本発明の一実施形態に係るパケット中継方法を示すフローチャートである。 本発明の一実施形態によってバイナリパケットをＨＴＴＰパケットに変換して中継する方法を示すフローチャートである。

以下、本発明の実施形態を添付された図面を用いて詳細に説明する。本発明の一実施形態に係る中継方法は中継システムによって行われてもよい。

図１は、本発明の一実施形態に係る中継システムの構成を示す図である。

本発明の一実施形態に係る中継システムは、バイナリプロトコルを用いるアプリケーションサーバ１１０とＨＴＴＰプロトコルを用いるウェブサービスサーバ１２０との間のパケット送受信を中継する中継サーバ１３０、および中継サーバ１３０をモニタリングするモニタリングサーバ１４０から構成されてもよい。ここで、アプリケーションサーバ１１０はゲームサーバであってもよい。

ここで、中継サーバ１３０は、アプリケーションサーバ１１０とはＴＣＰに接続されてバイナリ（ｂｉｎａｒｙ）ＨＴＴＰプロトコル基盤のメッセージを送受信し、ウェブサービスサーバ１２０とは標準ＨＴＴＰに接続されてＨＴＴＰプロトコルメッセージを送受信してもよい。

ここで、中継サーバ１３０は、アプリケーションサーバ１１０とは永久接続（ｐｅｒｍａｎｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）され、ウェブサービスサーバ１２０と必要に応じて接続（ｏｎ−ｄｅｍａｎｄ ｃｏｎｎｅｃｔｉｏｎ）されてもよい。

また、中継サーバ１３０は、アプリケーションサーバ１１０から受信したバイナリパケットをＨＴＴＰパケットに変換してウェブサービスサーバ１２０に送信し、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットをバイナリパケットに変換してアプリケーションサーバ１１０に送信してもよい。

中継サーバ１３０の詳細な構成は、以下に図２を参照して詳細に説明する。

モニタリングサーバ１４０は、ＪＭＸ（Ｊａｖａ Ｍａｎａｇｅｍｅｎｔ ｅＸｔｅｎｓｉｏｎｓ）（登録商標）を用いて中継サーバ１３０の接続を制御し、モニタリングしてもよい。

モニタリングサーバ１４０の詳細な構成は以下に図８を参照して詳細に説明する。

図２は、本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。

図２に示すように、中継サーバ１３０は、バイナリ送受信部２１０、変換部２２０、およびウェブ送受信部２３０を備えてもよい。

バイナリ送受信部２１０は、アプリケーションサーバ１１０からバイナリパケットを受信して変換部２２０に送信し、変換部２２０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求をアプリケーションサーバ１１０に送信してもよい。

バイナリ送受信部２１０の構成は以下に図３を参照して詳細に説明する。

変換部２２０は、バイナリ送受信部２１０が受信したバイナリパケットをＨＴＴＰパケットに変換してウェブ送受信部２３０に送信してもよい。

また、変換部２２０は、ウェブ送受信部２３０が受信したＨＴＴＰパケットをバイナリパケットに変換してバイナリ送受信部２１０に送信してもよい。このとき、モニタリングサーバ１４０は、図２に示すように変換部２２０と接続されて変換過程を制御し、モニタリングしてもよい。

変換部２２０の詳細な構成は以下に図４を参照して詳細に説明する。

ウェブ送受信部２３０は、変換部２２０に変換されたＨＴＴＰパケットをウェブサービスサーバに送信してもよい。

一例として、ウェブ送受信部２３０は、ＲＥＳＴｆｕｌウェブサービスを実現するためのＡＰＩおよびウェブクライアントから構成されてもよい。

ウェブ送受信部２３０の詳細な構成は、以下に図７を参照して詳細に説明する。

図３は、本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。

図３に示すように、バイナリ送受信部２１０は、ＴＣＰサーバ部３１０、セッションマネージャ部３２０、およびＴＣＰクライアント部３３０から構成されてもよい。

ここで、ＴＣＰサーバ部３１０は、アプリケーションサーバ１１０からＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いて送信されたバイナリパケットを受信してもよい。

また、ＴＣＰクライアント部３３０は、ＴＣＰを用いて変換部２２０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求をアプリケーションサーバ１１０に送信してもよい。

また、セッションマネージャ部３２０は、アプリケーションサーバ１１０との接続セッションを管理してＴＣＰサーバ部３１０、およびＴＣＰクライアント部３３０の動作を制御してもよい。

図４は、本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。

図４に示すように、変換部２２０は、コーディング部４１０、ログ管理部４２０、コンバータ部４３０、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０、ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０、コンフィグ管理部４６０、および制御部４７０を備えてもよい。

コーディング部４１０は、バイナリ送受信部２１０が受信したバイナリパケットを復号化したり、ウェブ送受信部２３０が受信したＨＴＴＰパケットを符号化して予め設定されたデータフォーマットに変換したりしてもよい。

一例として、コーディング部４１０は、ＨＴＴＰパケットを符号化してマップタイプに変換してもよい。このとき、マップオブジェクトはＨＴＴＰ要求または応答に対する抽象化されたモデルをそれぞれ定義してもよい。具体的に、コーディング部４１０は、要求または応答に応じて、予め定義されたモデルに変換してコンバータ部４３０に送信すると、コンバータ部４３０が受信したモデルを用いて要求または応答に対応するパケットを生成してもよい。

ここで、コーディング部４１０は、バイナリ送受信部２１０が受信したバイナリパケット、またはウェブ送受信部２３０が受信したＨＴＴＰパケットをログ管理部４２０に送信してもよい。

また、コーディング部４１０は、予め設定されたデータフォーマットに変換したモデルをログ管理部４２０に送信してもよい。

ログ管理部４２０は、コーディング部４１０が送信した情報をログに設定してロギング（ｌｏｇｇｉｎｇ）して管理してもよい。

コンバータ部４３０は、コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換してもよい。

具体的に、コンバータ部４３０は、受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義し、定義された抽象クラスを組み合わせてＨＴＴＰパケットを生成してもよい。

コンバータ部４３０の詳細な構成および動作は、以下に図５および図６を参照して詳細に説明する。

ＴｏＷｅｂＨａｎｄｌｅｒ部４４０は、コンバータ部４３０が生成したＨＴＴＰパケットをウェブ送受信部２３０に送信してもよい。

ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ウェブ送受信部２３０から送信されたウェブサービスサーバ１２０の要求を受信してコーディング部４１０に送信してもよい。

コンフィグ管理部４６０は、バイナリ送受信部２１０、ウェブ送受信部２３０、コーディング部４１０、ログ管理部４２０、ウェブハンドラ（ＷｅｂＨａｎｄｌｅｒ）、制御部４７０、およびウェブハンドラ部の処理流れに対する設定を格納して管理してもよい。このとき、ウェブハンドラは、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０およびＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０を備えてもよい。

ここで、ウェブハンドラは、連鎖（ｃｈａｉｎｉｎｇ）されてウェブサービスサーバ１１０からＨＴＴＰパケットを受信するアップストリーム（ｕｐｓｔｒｅａｍ）およびウェブサービスサーバ１２０にＨＴＴＰパケットを送信するダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）の処理を行なってもよい。

制御部４７０は、アクセス制御マネージャ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｎａｇｅｒ）を用いて上記の構成に対する動作を制御し、上記の構成に対する動作をモニタリングサーバ１４０に送信してもよい。

図５は、本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。

図５に示すように、コンバータ部４３０は、クラス定義部５１０、ＨＴＴＰパケット生成部５２０、バイナリパート生成部５３０、およびバイナリパケット生成部５４０を備えてもよい。

クラス定義部５１０は、受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義してもよい。

ＴＣＰ基盤のバイナリパケットは、それぞれの意味を有する複数のパートに構成してもよい。

ここで、クラス定義部５１０は、バイナリパケットのパートを抽象化してバイナリパケット全体をパケット（ｐａｃｋｅｔ）というインタフェースに定義し、パートをそれぞれパケットパート（ｐａｃｋｅｔｐａｒｔ）抽象クラスのように定義してもよい。

ＨＴＴＰパケット生成部５２０は、クラス定義部５１０に定義された少なくとも１つの抽象クラスを組み合わせてアプリケーションサーバ１１０に送信しようとするメッセージが含まれたＨＴＴＰパケットを生成してもよい。

バイナリパート生成部５３０は、受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに含まれる情報を確認し、クラスに対応するバイナリパケットのパートを生成してもよい。

バイナリパケット生成部５４０は、バイナリパート生成部５３０で生成されたバイナリパケットのパートを結合してウェブサービスサーバ１２０の要求が含まれたバイナリパケットを生成してもよい。

図６は、本発明のコンバータ部がバイナリパケットをＨＴＴＰパケットに変換する過程の一例である。

アプリケーションサーバ１１０から受信したＴＣＰ基盤のバイナリパケット６１０は、図６に示すように複数のパート６１１から構成されてもよい。

ここで、クラス定義部５１０は、バイナリパケットのパート６１１を抽象化してバイナリパケットの全体をパケットいうインタフェース６２０に定義し、パート６１１をそれぞれパケットパート抽象クラス６２１に定義してもよい。このとき、各抽象クラスは、対応するバイナリパケットのパート６１１のディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。

また、ＨＴＴＰパケット生成部５２０は、クラス定義部５１０に定義された抽象クラス６２１を組み合わせてジャバ（ｊａｖａ（登録商標））クラス６３０を生成してもよい。このとき、ＨＴＴＰパケット生成部５２０が生成したジャバクラス６３０は、抽象クラス６２１を引用する記述６３１を含んでもよい。

次にＨＴＴＰパケット生成部５２０は、ジャバクラス６３０に基づいてアプリケーションサーバ１１０に送信しようとするメッセージが含まれたＨＴＴＰパケットを生成してもよい。

また、コンバータ部がＨＴＴＰパケットをバイナリパケットに変換する過程は前述した過程の逆順である。

具体的に、まず、バイナリパート生成部５３０は、受信したＨＴＴＰパケットでジャバクラス６３０を復元してもよい。

その後、バイナリパート生成部５３０は、予め設定されたライブラリを用いてジャバクラス６３０に基づいてバイナリパケットのパート６１１を生成してもよい。

ここで、ライブラリは、ジャバクラス６３０に対応するバイナリパケットのパート６１１に関する情報が含まれたライブラリであってもよい。

最後に、バイナリパケット生成部５４０は、バイナリパート生成部５３０で生成されたバイナリパケットのパート６１１を結合してウェブサービスサーバ１２０の要求が含まれたバイナリパケット６１０を生成してもよい。

ここで、パケットインタフェース６２０はシリアライズ方法（ｓｅｒｉａｌｉｚｅ ｍｅｔｈｏｄ）およびデシリアライズ方法（ｄｅｓｅｒｉａｌｉｚｅ ｍｅｔｈｏｄ）を含んでもよい。

ここで、シリアライズは、ジャバオブジェクトをバイナリストリームに変換する方法であり、デシリアライズは、バイナリストリームをジャバオブジェクトに変換する方法である。

また、パケットインタフェース６２０は、バイナリパケットとマッチングされるジャバタイプをメッセージタイプ（ｍｅｓｓａｇｅＴｙｐｅ）に格納してもよい。

また、パケットパート抽象クラス６２１は、パケットインタフェース６２０のようにシリアライズ方法およびデシリアライズ方法を含んでもよい。

図７は、本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。

図７に示すように、ウェブ送受信部２３０は、ウェブクライアント部７１０、ＲＥＳＴｆｕｌ ＡＰＩ部７２０、アクションマップ（ＡｃｔｉｏｎＭａｐｐｅｒ）部７３０、およびサーブレット（ｓｅｒｖｌｅｔ）部７４０を備えてもよい。

ウェブクライアント部７１０は、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０から受信したＨＴＴＰパケットをウェブサービスサーバ１２０に送信し、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットをＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０に送信してもよい。このとき、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットは、ウェブサービスサーバ１２０の要求メッセージであってもよい。

ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、ウェブサービスサーバ１２０が提供するウェブサービスをＲＥＳＴｆｕｌウェブサービスに変換して実現してもよい。

具体的に、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、Ｌｕｃｙ／Ｗｅｂｗｏｒｋ基盤アクションに注釈（ａｎｎｏｔａｔｉｏｎ）を追加することによってＲＥＳＴｆｕｌウェブサービスを実現することができる。

ここで、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、指定したクラスがＲＥＳＴｆｕｌ Ｒｅｓｏｕｒｃｅであることを表す＠ＲｅｓｔｆｕｌＲｅｓｏｕｒｃｅ関数、および方法が処理するＨＴＴＰ Ｍｅｔｈｏｄを指定する＠Ｇｅｔ、＠Ｐｏｓｔ、＠Ｐｕｔ、＠Ｄｅｌｅｔｅ関数を含んでもよい。

また、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、ＲＥＳＴｆｕｌ ＨＴＴＰ要求および応答処理のためのユーティリティクラスであるＲｅｓｔｆｕｌＳｅｒｖｉｃｅＵｔｉｌを含んでもよい。

アクションマップ部７３０は、ＲＥＳＴｆｕｌ要求に対するアクションマッピングを行なってもよい。

具体的に、アクションマップ部７３０は、ＬｕｃｙのＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒを相続するアクションマップを実現してアクションマッピングを行なってもよい。

また、アクションマップ部７３０は、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒ、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒ、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐを含んでもよい。

ここで、ＲｅｓｔｆｕｌＡｃｔｉｏｎＩｎｆｏＭａｎａｇｅｒは、ｘｗｏｒｋ ａｃｔｉｏｎ ｃｌａｓｓのうち＠ＲｅｓｔｆｕｌＲｅｓｏｕｃｅに指定されたアクションクラスの情報をロードし、ＨＴＴＰ方法、ＵＲＩ、Ａｃｃｅｐｔヘッダを因子としてマッピングされるアクション情報を返してもよい。

また、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求がＲＥＳＴｆｕｌ要求である場合にマッチングされるアクション情報に対してマッピング情報を生成して返してもよい。このとき、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求がＲＥＳＴｆｕｌ要求ではない場合、直ちにｎｕｌｌを返してもよい。

また、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求に対して適するマッピングを生成して返してもよい。このとき、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒは、ＲＥＳＴｆｕｌ要求ではない場合、ＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒからマッピング情報を収集して返してもよい。

サーブレット部７４０は、アクションマップ部７３０で処理されたアクションマッピングの結果をウェブサービスとして用いるデータ形式であるＪＳＯＮに変換し、サーブレット応答ストリーム（Ｓｅｒｖｌｅｔ Ｒｅｓｐｏｎｓｅ Ｓｔｒｅａｍ）に挿入してもよい。このとき、サーブレット応答ストリームは、ＨＴＴＰ要求による応答ストリームであってもよい。

図８は、本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。

図８に示すように、モニタリングサーバ１４０は、モニタリング部８１０、表示部８２０、および制御部８３０を備えてもよい。

モニタリング部８１０は、中継サーバ１３０のモニタリングおよび制御のためのＪＭＸコンポーネントであってもよい。

ここで、モニタリング部８１０は、中継サーバ１３０の変換部２２０でメモリ、スレッド、クラス、ＣＰＵ、ＶＭサマリー、パケットスループット、接続状況のうち少なくとも１つの変化をモニタリングしてもよい。

表示部８２０は、モニタリング部８１０がモニタリングした情報を管理者に表示してもよい。

制御部８３０は、制御部４７０の接続制御を管理し、モニタリング部８１０のＪＭＸ基盤モニタリングを制御するためのウェブアプリケーションであってもよい。

ここで、制御部８３０は、ＷＳＭ Ａｄｍｉｎに基づいて生成されたＡｄｍｉｎ Ｗｅｂであってもよい。

また、制御部８３０は、モニタリング部８１０に含まれてモニタリングを制御してもよい。

図９は、本発明の一実施形態に係るパケット中継方法を示すフローチャートである。

ステップＳ９１０において、変換部２２０は変換しようとするパケットを受信してもよい。

一例として、変換部２２０は、バイナリ送受信部２１０がアプリケーションサーバ１１０から受信したバイナリパケットや、ウェブ送受信部２３０がウェブサービスサーバ１２０から受信したＨＴＴＰパケットを受信してもよい。

ステップＳ９２０において、コーディング部４１０は、ステップＳ９１０で受信したパケットをコーディングしてパケットに含まれる情報を確認してもよい。

一例として、コーディング部４１０は、バイナリパケットを復号化してバイナリパケットに含まれる情報を確認したり、ＨＴＴＰパケットを符号化してＨＴＴＰパケットに含まれる情報を確認したりしてもよい。

ステップＳ９３０において、ログ管理部４２０は、ステップＳ９２０で確認された情報をログに格納して管理してもよい。

ステップＳ９４０において、コンバータ部４３０は、ステップＳ９２０で確認された情報をステップＳ９１０で受信したパケットの種類に応じて変換してもよい。

一例として、コンバータ部４３０は、ステップＳ９１０でバイナリパケットを受信すると、受信したバイナリパケットをＨＴＴＰパケットに変換し、ステップＳ９１０でＨＴＴＰパケットを受信すると、受信したＨＴＴＰパケットをバイナリパケットに変換してもよい。

ステップＳ９５０において、変換部２２０はステップＳ９４０に変換されたパケットを送信してもよい。

一例として、変換部２２０は、ステップＳ９４０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求を、バイナリ送受信部２１０を介してアプリケーションサーバ１１０に送信してもよい。

他の一例として、変換部２２０は、ステップＳ９４０でＨＴＴＰパケットに変換されたアプリケーションサーバ１１０の要求を、ウェブ送受信部２３０を介してウェブサービスサーバ１２０に送信してもよい。

図１０は、本発明の一実施形態によってバイナリパケットをＨＴＴＰパケットに変換して中継する方法を示すフローチャートである。

ステップＳ１０１０において、バイナリ送受信部２１０のセッションマネージャ部３２０は、アプリケーションサーバ１１０からバイナリパケットが含まれたストリームを受信してもよい。

ステップＳ１０２０において、セッションマネージャ部３２０は、ステップＳ１０１０で受信したバイナリパケットをコーディング部４１０に送信して復号化を要求してもよい。

ステップＳ１０３０において、コーディング部４１０は、ステップＳ１０２０で受信したバイナリパケットを復号化してバイナリパケットに含まれる情報を確認し、確認された情報をログ管理部４２０に送信してもよい。このとき、ログ管理部４２０は受信した情報をログに格納して管理してもよい。

ステップＳ１０４０において、コーディング部４１０は、コンバータ部４３０がステップＳ１０２０で確認された情報を変換して生成したＨＴＴＰパケットをセッションマネージャ部３２０に送信してもよい。

ステップＳ１０４５において、セッションマネージャ部３２０は、ステップＳ１０４０で受信したＨＴＴＰパケットをウェブハンドラ（ＷｅｂＨａｎｄｌｅｒ）のうちＴｏＷｅｂＨａｎｄｌｅｒ部４４０に送信してもよい。

ステップＳ１０５０において、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０は、ステップＳ１０４５で受信したＨＴＴＰパケットをウェブ送受信部２３０のウェブクライアント部７１０に送信してもよい。

ステップＳ１０５５において、ウェブハンドラのうちＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ウェブクライアント部７１０からステップＳ１０５０に送信した情報に対する応答を受信してもよい。

ステップＳ１０６０において、ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ステップＳ１０５５で受信した応答をセッションマネージャ部３２０に送信してもよい。

ステップＳ１０７０において、セッションマネージャ部３２０は、ステップＳ１０６０で受信した応答をコーディング部４１０に送信して符号化を要求してもよい。

ステップＳ１０８０において、コーディング部４１０は、ステップＳ１０７０で受信した応答を符号化して応答のＨＴＴＰパケットに含まれる情報を確認し、確認された情報をログ管理部４２０に送信してもよい。このとき、ログ管理部４２０は受信した情報をログに格納して管理してもよい。

ステップＳ１０９０において、コーディング部４１０は、コンバータ部４３０がステップＳ１０８０で確認された情報を変換して生成したバイナリパケットをセッションマネージャ部３２０に送信してもよい。

ステップＳ１０９５において、セッションマネージャ部３２０は、ステップＳ１０９０で受信したバイナリパケットをアプリケーションサーバ１１０に送信してもよい。

すなわち、本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバおよびＨＴＴＰプロトコルを用いるウェブサービスサーバ間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。

また、アプリケーションサーバとはＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することができる。

また、ウェブサービスサーバとはＲＥＳＴｆｕｌ ＨＴＴＰを用いて情報を送受信することによって、既に用いたウェブサービスを最小限に変更することで用いることができる。

上述したように、本発明は、限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態を基に多様な修正および変形が可能である。

したがって、本発明の範囲は説明された実施形態に限定されるものではなく、特許請求の範囲のみならず、この特許請求の範囲と均等なものなどによって定められなければならない。

１３０ 中継サーバ
１４０ モニタリングサーバ
２２０ 変換部
２３０ ウェブ送受信部
４１０ コーディング部
４２０ ログ管理部
４３０ コンバータ部

Claims (10)

1. バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、
   前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、
   前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
   を備えることを特徴とする中継サーバ。
2. 前記変換部は、
   前記受信したバイナリパケットを復号化するコーディング部と、
   前記コーディング部が復号化したバイナリパケットの情報をログに管理するログ管理部と、
   前記コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換するコンバータ部と、
   を備えることを特徴とする請求項１に記載の中継サーバ。
3. 前記コンバータ部は、
   受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義するクラス定義部と、
   少なくとも１つの前記抽象クラスを組み合わせて前記ＨＴＴＰパケットを生成するＨＴＴＰパケット生成部と、
   を備えることを特徴とする請求項２に記載の中継サーバ。
4. 前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項２に記載の中継サーバ。
5. 前記コンバータ部は、
   受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに対応するバイナリパケットのパートを生成するバイナリパート生成部と、
   生成したバイナリパケットのパートを結合してバイナリパケットを生成するバイナリパケット生成部と、
   を備えることを特徴とする請求項４に記載の中継サーバ。
6. バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、
   前記バイナリパケットをＨＴＴＰパケットに変換するステップと、
   前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップと、
   を含むことを特徴とするパケット中継方法。
7. 前記変換するステップは、
   前記受信したバイナリパケットを復号化するステップと、
   復号化したバイナリパケットの情報をログに格納するステップと、
   前記復号化したバイナリパケットをＨＴＴＰパケットに変換するステップと、
   を含むことを特徴とする請求項６に記載のパケット中継方法。
8. 前記ＨＴＴＰパケットに変換するステップは、
   受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義するステップと、
   少なくとも１つの前記抽象クラスを組み合わせて前記ＨＴＴＰパケットを生成するステップと、
   を含むことを特徴とする請求項７に記載のパケット中継方法。
9. 前記変換するステップは、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項７に記載のパケット中継方法。
10. 前記変換するステップは、
    受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに対応するバイナリパケットのパートを生成するステップと、
    生成したバイナリパケットのパートを結合してバイナリパケットを生成するステップと、
    を含むことを特徴とする請求項９に記載のパケット中継方法。

Images