バイナリパケット中継システムおよび方法
【課題】バイナリパケット中継システムおよび方法を提供する。
【解決手段】中継システムは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。中継システムによれば、バイナリプロトコルを用いるアプリケーションサーバとＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【解決手段】中継システムは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。中継システムによれば、バイナリプロトコルを用いるアプリケーションサーバとＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バイナリパケット中継システムおよび方法に関し、より詳しくは、互いに異なるプロトコルを用いる複数のサーバから情報を受信し、送信する対象のサーバが用いるプロトコルに応じて変換して送信することによって、情報を中継することのできる中継システムおよび方法に関する。
【背景技術】
【０００２】
オンラインゲームの発展に伴ってゲーム中にもゲーム上でウェブサービスを利用しようとすることがあり、ウェブサービス中にゲームを提供することが必要な場合も生じている。
【０００３】
しかし、ゲームを実行するゲームサーバとウェブサービスを実行するウェブサービスサーバとは互いに使用しているプロトコルが異なるので中継のためのシステムが求められている。
【０００４】
したがって、非同期通信基盤のゲームサーバと同期通信基盤のウェブサービスサーバとの情報を中継することによって、ゲーム上でもウェブサービスを容易に用いることのできるシステムおよび方法が求められている。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、バイナリプロトコルを用いるアプリケーションサーバと、ＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることのできるシステムおよび方法を提供することを目的とする。
【０００６】
また、本発明は、アプリケーションサーバに対してＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することのできるシステムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一実施形態に係る中継サーバは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。
【０００８】
本発明の一実施形態に係るパケット中継方法は、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、前記バイナリパケットをＨＴＴＰパケットに変換するステップと、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップとを含む。
【発明の効果】
【０００９】
本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバと、ＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【００１０】
また、本発明の一実施形態によれば、アプリケーションサーバに対してＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係る中継システムの構成を示す図である。
【図２】本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。
【図３】本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。
【図４】本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。
【図５】本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。
【図６】本発明のコンバータ部がバイナリパケットをＨＴＴＰパケットに変換する過程の一例である。
【図７】本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。
【図８】本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。
【図９】本発明の一実施形態に係るパケット中継方法を示すフローチャートである。
【図１０】本発明の一実施形態によってバイナリパケットをＨＴＴＰパケットに変換して中継する方法を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態を添付された図面を用いて詳細に説明する。本発明の一実施形態に係る中継方法は中継システムによって行われてもよい。
【００１３】
図１は、本発明の一実施形態に係る中継システムの構成を示す図である。
【００１４】
本発明の一実施形態に係る中継システムは、バイナリプロトコルを用いるアプリケーションサーバ１１０とＨＴＴＰプロトコルを用いるウェブサービスサーバ１２０との間のパケット送受信を中継する中継サーバ１３０、および中継サーバ１３０をモニタリングするモニタリングサーバ１４０から構成されてもよい。ここで、アプリケーションサーバ１１０はゲームサーバであってもよい。
【００１５】
ここで、中継サーバ１３０は、アプリケーションサーバ１１０とはＴＣＰに接続されてバイナリ（ｂｉｎａｒｙ）ＨＴＴＰプロトコル基盤のメッセージを送受信し、ウェブサービスサーバ１２０とは標準ＨＴＴＰに接続されてＨＴＴＰプロトコルメッセージを送受信してもよい。
【００１６】
ここで、中継サーバ１３０は、アプリケーションサーバ１１０とは永久接続（ｐｅｒｍａｎｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）され、ウェブサービスサーバ１２０と必要に応じて接続（ｏｎ−ｄｅｍａｎｄ ｃｏｎｎｅｃｔｉｏｎ）されてもよい。
【００１７】
また、中継サーバ１３０は、アプリケーションサーバ１１０から受信したバイナリパケットをＨＴＴＰパケットに変換してウェブサービスサーバ１２０に送信し、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットをバイナリパケットに変換してアプリケーションサーバ１１０に送信してもよい。
【００１８】
中継サーバ１３０の詳細な構成は、以下に図２を参照して詳細に説明する。
【００１９】
モニタリングサーバ１４０は、ＪＭＸ（Ｊａｖａ Ｍａｎａｇｅｍｅｎｔ ｅＸｔｅｎｓｉｏｎｓ）（登録商標）を用いて中継サーバ１３０の接続を制御し、モニタリングしてもよい。
【００２０】
モニタリングサーバ１４０の詳細な構成は以下に図８を参照して詳細に説明する。
【００２１】
図２は、本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。
【００２２】
図２に示すように、中継サーバ１３０は、バイナリ送受信部２１０、変換部２２０、およびウェブ送受信部２３０を備えてもよい。
【００２３】
バイナリ送受信部２１０は、アプリケーションサーバ１１０からバイナリパケットを受信して変換部２２０に送信し、変換部２２０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求をアプリケーションサーバ１１０に送信してもよい。
【００２４】
バイナリ送受信部２１０の構成は以下に図３を参照して詳細に説明する。
【００２５】
変換部２２０は、バイナリ送受信部２１０が受信したバイナリパケットをＨＴＴＰパケットに変換してウェブ送受信部２３０に送信してもよい。
【００２６】
また、変換部２２０は、ウェブ送受信部２３０が受信したＨＴＴＰパケットをバイナリパケットに変換してバイナリ送受信部２１０に送信してもよい。このとき、モニタリングサーバ１４０は、図２に示すように変換部２２０と接続されて変換過程を制御し、モニタリングしてもよい。
【００２７】
変換部２２０の詳細な構成は以下に図４を参照して詳細に説明する。
【００２８】
ウェブ送受信部２３０は、変換部２２０に変換されたＨＴＴＰパケットをウェブサービスサーバに送信してもよい。
【００２９】
一例として、ウェブ送受信部２３０は、ＲＥＳＴｆｕｌウェブサービスを実現するためのＡＰＩおよびウェブクライアントから構成されてもよい。
【００３０】
ウェブ送受信部２３０の詳細な構成は、以下に図７を参照して詳細に説明する。
【００３１】
図３は、本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。
【００３２】
図３に示すように、バイナリ送受信部２１０は、ＴＣＰサーバ部３１０、セッションマネージャ部３２０、およびＴＣＰクライアント部３３０から構成されてもよい。
【００３３】
ここで、ＴＣＰサーバ部３１０は、アプリケーションサーバ１１０からＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いて送信されたバイナリパケットを受信してもよい。
【００３４】
また、ＴＣＰクライアント部３３０は、ＴＣＰを用いて変換部２２０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求をアプリケーションサーバ１１０に送信してもよい。
【００３５】
また、セッションマネージャ部３２０は、アプリケーションサーバ１１０との接続セッションを管理してＴＣＰサーバ部３１０、およびＴＣＰクライアント部３３０の動作を制御してもよい。
【００３６】
図４は、本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。
【００３７】
図４に示すように、変換部２２０は、コーディング部４１０、ログ管理部４２０、コンバータ部４３０、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０、ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０、コンフィグ管理部４６０、および制御部４７０を備えてもよい。
【００３８】
コーディング部４１０は、バイナリ送受信部２１０が受信したバイナリパケットを復号化したり、ウェブ送受信部２３０が受信したＨＴＴＰパケットを符号化して予め設定されたデータフォーマットに変換したりしてもよい。
【００３９】
一例として、コーディング部４１０は、ＨＴＴＰパケットを符号化してマップタイプに変換してもよい。このとき、マップオブジェクトはＨＴＴＰ要求または応答に対する抽象化されたモデルをそれぞれ定義してもよい。具体的に、コーディング部４１０は、要求または応答に応じて、予め定義されたモデルに変換してコンバータ部４３０に送信すると、コンバータ部４３０が受信したモデルを用いて要求または応答に対応するパケットを生成してもよい。
【００４０】
ここで、コーディング部４１０は、バイナリ送受信部２１０が受信したバイナリパケット、またはウェブ送受信部２３０が受信したＨＴＴＰパケットをログ管理部４２０に送信してもよい。
【００４１】
また、コーディング部４１０は、予め設定されたデータフォーマットに変換したモデルをログ管理部４２０に送信してもよい。
【００４２】
ログ管理部４２０は、コーディング部４１０が送信した情報をログに設定してロギング（ｌｏｇｇｉｎｇ）して管理してもよい。
【００４３】
コンバータ部４３０は、コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換してもよい。
【００４４】
具体的に、コンバータ部４３０は、受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義し、定義された抽象クラスを組み合わせてＨＴＴＰパケットを生成してもよい。
【００４５】
コンバータ部４３０の詳細な構成および動作は、以下に図５および図６を参照して詳細に説明する。
【００４６】
ＴｏＷｅｂＨａｎｄｌｅｒ部４４０は、コンバータ部４３０が生成したＨＴＴＰパケットをウェブ送受信部２３０に送信してもよい。
【００４７】
ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ウェブ送受信部２３０から送信されたウェブサービスサーバ１２０の要求を受信してコーディング部４１０に送信してもよい。
【００４８】
コンフィグ管理部４６０は、バイナリ送受信部２１０、ウェブ送受信部２３０、コーディング部４１０、ログ管理部４２０、ウェブハンドラ（ＷｅｂＨａｎｄｌｅｒ）、制御部４７０、およびウェブハンドラ部の処理流れに対する設定を格納して管理してもよい。このとき、ウェブハンドラは、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０およびＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０を備えてもよい。
【００４９】
ここで、ウェブハンドラは、連鎖（ｃｈａｉｎｉｎｇ）されてウェブサービスサーバ１１０からＨＴＴＰパケットを受信するアップストリーム（ｕｐｓｔｒｅａｍ）およびウェブサービスサーバ１２０にＨＴＴＰパケットを送信するダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）の処理を行なってもよい。
【００５０】
制御部４７０は、アクセス制御マネージャ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｎａｇｅｒ）を用いて上記の構成に対する動作を制御し、上記の構成に対する動作をモニタリングサーバ１４０に送信してもよい。
【００５１】
図５は、本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。
【００５２】
図５に示すように、コンバータ部４３０は、クラス定義部５１０、ＨＴＴＰパケット生成部５２０、バイナリパート生成部５３０、およびバイナリパケット生成部５４０を備えてもよい。
【００５３】
クラス定義部５１０は、受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義してもよい。
【００５４】
ＴＣＰ基盤のバイナリパケットは、それぞれの意味を有する複数のパートに構成してもよい。
【００５５】
ここで、クラス定義部５１０は、バイナリパケットのパートを抽象化してバイナリパケット全体をパケット（ｐａｃｋｅｔ）というインタフェースに定義し、パートをそれぞれパケットパート（ｐａｃｋｅｔｐａｒｔ）抽象クラスのように定義してもよい。
【００５６】
ＨＴＴＰパケット生成部５２０は、クラス定義部５１０に定義された少なくとも１つの抽象クラスを組み合わせてアプリケーションサーバ１１０に送信しようとするメッセージが含まれたＨＴＴＰパケットを生成してもよい。
【００５７】
バイナリパート生成部５３０は、受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに含まれる情報を確認し、クラスに対応するバイナリパケットのパートを生成してもよい。
【００５８】
バイナリパケット生成部５４０は、バイナリパート生成部５３０で生成されたバイナリパケットのパートを結合してウェブサービスサーバ１２０の要求が含まれたバイナリパケットを生成してもよい。
【００５９】
図６は、本発明のコンバータ部がバイナリパケットをＨＴＴＰパケットに変換する過程の一例である。
【００６０】
アプリケーションサーバ１１０から受信したＴＣＰ基盤のバイナリパケット６１０は、図６に示すように複数のパート６１１から構成されてもよい。
【００６１】
ここで、クラス定義部５１０は、バイナリパケットのパート６１１を抽象化してバイナリパケットの全体をパケットいうインタフェース６２０に定義し、パート６１１をそれぞれパケットパート抽象クラス６２１に定義してもよい。このとき、各抽象クラスは、対応するバイナリパケットのパート６１１のディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。
【００６２】
また、ＨＴＴＰパケット生成部５２０は、クラス定義部５１０に定義された抽象クラス６２１を組み合わせてジャバ（ｊａｖａ（登録商標））クラス６３０を生成してもよい。このとき、ＨＴＴＰパケット生成部５２０が生成したジャバクラス６３０は、抽象クラス６２１を引用する記述６３１を含んでもよい。
【００６３】
次にＨＴＴＰパケット生成部５２０は、ジャバクラス６３０に基づいてアプリケーションサーバ１１０に送信しようとするメッセージが含まれたＨＴＴＰパケットを生成してもよい。
【００６４】
また、コンバータ部がＨＴＴＰパケットをバイナリパケットに変換する過程は前述した過程の逆順である。
【００６５】
具体的に、まず、バイナリパート生成部５３０は、受信したＨＴＴＰパケットでジャバクラス６３０を復元してもよい。
【００６６】
その後、バイナリパート生成部５３０は、予め設定されたライブラリを用いてジャバクラス６３０に基づいてバイナリパケットのパート６１１を生成してもよい。
【００６７】
ここで、ライブラリは、ジャバクラス６３０に対応するバイナリパケットのパート６１１に関する情報が含まれたライブラリであってもよい。
【００６８】
最後に、バイナリパケット生成部５４０は、バイナリパート生成部５３０で生成されたバイナリパケットのパート６１１を結合してウェブサービスサーバ１２０の要求が含まれたバイナリパケット６１０を生成してもよい。
【００６９】
ここで、パケットインタフェース６２０はシリアライズ方法（ｓｅｒｉａｌｉｚｅ ｍｅｔｈｏｄ）およびデシリアライズ方法（ｄｅｓｅｒｉａｌｉｚｅ ｍｅｔｈｏｄ）を含んでもよい。
【００７０】
ここで、シリアライズは、ジャバオブジェクトをバイナリストリームに変換する方法であり、デシリアライズは、バイナリストリームをジャバオブジェクトに変換する方法である。
【００７１】
また、パケットインタフェース６２０は、バイナリパケットとマッチングされるジャバタイプをメッセージタイプ（ｍｅｓｓａｇｅＴｙｐｅ）に格納してもよい。
【００７２】
また、パケットパート抽象クラス６２１は、パケットインタフェース６２０のようにシリアライズ方法およびデシリアライズ方法を含んでもよい。
【００７３】
図７は、本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。
【００７４】
図７に示すように、ウェブ送受信部２３０は、ウェブクライアント部７１０、ＲＥＳＴｆｕｌ ＡＰＩ部７２０、アクションマップ（ＡｃｔｉｏｎＭａｐｐｅｒ）部７３０、およびサーブレット（ｓｅｒｖｌｅｔ）部７４０を備えてもよい。
【００７５】
ウェブクライアント部７１０は、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０から受信したＨＴＴＰパケットをウェブサービスサーバ１２０に送信し、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットをＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０に送信してもよい。このとき、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットは、ウェブサービスサーバ１２０の要求メッセージであってもよい。
【００７６】
ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、ウェブサービスサーバ１２０が提供するウェブサービスをＲＥＳＴｆｕｌウェブサービスに変換して実現してもよい。
【００７７】
具体的に、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、Ｌｕｃｙ／Ｗｅｂｗｏｒｋ基盤アクションに注釈（ａｎｎｏｔａｔｉｏｎ）を追加することによってＲＥＳＴｆｕｌウェブサービスを実現することができる。
【００７８】
ここで、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、指定したクラスがＲＥＳＴｆｕｌ Ｒｅｓｏｕｒｃｅであることを表す＠ＲｅｓｔｆｕｌＲｅｓｏｕｒｃｅ関数、および方法が処理するＨＴＴＰ Ｍｅｔｈｏｄを指定する＠Ｇｅｔ、＠Ｐｏｓｔ、＠Ｐｕｔ、＠Ｄｅｌｅｔｅ関数を含んでもよい。
【００７９】
また、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、ＲＥＳＴｆｕｌ ＨＴＴＰ要求および応答処理のためのユーティリティクラスであるＲｅｓｔｆｕｌＳｅｒｖｉｃｅＵｔｉｌを含んでもよい。
【００８０】
アクションマップ部７３０は、ＲＥＳＴｆｕｌ要求に対するアクションマッピングを行なってもよい。
【００８１】
具体的に、アクションマップ部７３０は、ＬｕｃｙのＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒを相続するアクションマップを実現してアクションマッピングを行なってもよい。
【００８２】
また、アクションマップ部７３０は、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒ、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒ、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐを含んでもよい。
【００８３】
ここで、ＲｅｓｔｆｕｌＡｃｔｉｏｎＩｎｆｏＭａｎａｇｅｒは、ｘｗｏｒｋ ａｃｔｉｏｎ ｃｌａｓｓのうち＠ＲｅｓｔｆｕｌＲｅｓｏｕｃｅに指定されたアクションクラスの情報をロードし、ＨＴＴＰ方法、ＵＲＩ、Ａｃｃｅｐｔヘッダを因子としてマッピングされるアクション情報を返してもよい。
【００８４】
また、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求がＲＥＳＴｆｕｌ要求である場合にマッチングされるアクション情報に対してマッピング情報を生成して返してもよい。このとき、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求がＲＥＳＴｆｕｌ要求ではない場合、直ちにｎｕｌｌを返してもよい。
【００８５】
また、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求に対して適するマッピングを生成して返してもよい。このとき、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒは、ＲＥＳＴｆｕｌ要求ではない場合、ＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒからマッピング情報を収集して返してもよい。
【００８６】
サーブレット部７４０は、アクションマップ部７３０で処理されたアクションマッピングの結果をウェブサービスとして用いるデータ形式であるＪＳＯＮに変換し、サーブレット応答ストリーム（Ｓｅｒｖｌｅｔ Ｒｅｓｐｏｎｓｅ Ｓｔｒｅａｍ）に挿入してもよい。このとき、サーブレット応答ストリームは、ＨＴＴＰ要求による応答ストリームであってもよい。
【００８７】
図８は、本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。
【００８８】
図８に示すように、モニタリングサーバ１４０は、モニタリング部８１０、表示部８２０、および制御部８３０を備えてもよい。
【００８９】
モニタリング部８１０は、中継サーバ１３０のモニタリングおよび制御のためのＪＭＸコンポーネントであってもよい。
【００９０】
ここで、モニタリング部８１０は、中継サーバ１３０の変換部２２０でメモリ、スレッド、クラス、ＣＰＵ、ＶＭサマリー、パケットスループット、接続状況のうち少なくとも１つの変化をモニタリングしてもよい。
【００９１】
表示部８２０は、モニタリング部８１０がモニタリングした情報を管理者に表示してもよい。
【００９２】
制御部８３０は、制御部４７０の接続制御を管理し、モニタリング部８１０のＪＭＸ基盤モニタリングを制御するためのウェブアプリケーションであってもよい。
【００９３】
ここで、制御部８３０は、ＷＳＭ Ａｄｍｉｎに基づいて生成されたＡｄｍｉｎ Ｗｅｂであってもよい。
【００９４】
また、制御部８３０は、モニタリング部８１０に含まれてモニタリングを制御してもよい。
【００９５】
図９は、本発明の一実施形態に係るパケット中継方法を示すフローチャートである。
【００９６】
ステップＳ９１０において、変換部２２０は変換しようとするパケットを受信してもよい。
【００９７】
一例として、変換部２２０は、バイナリ送受信部２１０がアプリケーションサーバ１１０から受信したバイナリパケットや、ウェブ送受信部２３０がウェブサービスサーバ１２０から受信したＨＴＴＰパケットを受信してもよい。
【００９８】
ステップＳ９２０において、コーディング部４１０は、ステップＳ９１０で受信したパケットをコーディングしてパケットに含まれる情報を確認してもよい。
【００９９】
一例として、コーディング部４１０は、バイナリパケットを復号化してバイナリパケットに含まれる情報を確認したり、ＨＴＴＰパケットを符号化してＨＴＴＰパケットに含まれる情報を確認したりしてもよい。
【０１００】
ステップＳ９３０において、ログ管理部４２０は、ステップＳ９２０で確認された情報をログに格納して管理してもよい。
【０１０１】
ステップＳ９４０において、コンバータ部４３０は、ステップＳ９２０で確認された情報をステップＳ９１０で受信したパケットの種類に応じて変換してもよい。
【０１０２】
一例として、コンバータ部４３０は、ステップＳ９１０でバイナリパケットを受信すると、受信したバイナリパケットをＨＴＴＰパケットに変換し、ステップＳ９１０でＨＴＴＰパケットを受信すると、受信したＨＴＴＰパケットをバイナリパケットに変換してもよい。
【０１０３】
ステップＳ９５０において、変換部２２０はステップＳ９４０に変換されたパケットを送信してもよい。
【０１０４】
一例として、変換部２２０は、ステップＳ９４０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求を、バイナリ送受信部２１０を介してアプリケーションサーバ１１０に送信してもよい。
【０１０５】
他の一例として、変換部２２０は、ステップＳ９４０でＨＴＴＰパケットに変換されたアプリケーションサーバ１１０の要求を、ウェブ送受信部２３０を介してウェブサービスサーバ１２０に送信してもよい。
【０１０６】
図１０は、本発明の一実施形態によってバイナリパケットをＨＴＴＰパケットに変換して中継する方法を示すフローチャートである。
【０１０７】
ステップＳ１０１０において、バイナリ送受信部２１０のセッションマネージャ部３２０は、アプリケーションサーバ１１０からバイナリパケットが含まれたストリームを受信してもよい。
【０１０８】
ステップＳ１０２０において、セッションマネージャ部３２０は、ステップＳ１０１０で受信したバイナリパケットをコーディング部４１０に送信して復号化を要求してもよい。
【０１０９】
ステップＳ１０３０において、コーディング部４１０は、ステップＳ１０２０で受信したバイナリパケットを復号化してバイナリパケットに含まれる情報を確認し、確認された情報をログ管理部４２０に送信してもよい。このとき、ログ管理部４２０は受信した情報をログに格納して管理してもよい。
【０１１０】
ステップＳ１０４０において、コーディング部４１０は、コンバータ部４３０がステップＳ１０２０で確認された情報を変換して生成したＨＴＴＰパケットをセッションマネージャ部３２０に送信してもよい。
【０１１１】
ステップＳ１０４５において、セッションマネージャ部３２０は、ステップＳ１０４０で受信したＨＴＴＰパケットをウェブハンドラ（ＷｅｂＨａｎｄｌｅｒ）のうちＴｏＷｅｂＨａｎｄｌｅｒ部４４０に送信してもよい。
【０１１２】
ステップＳ１０５０において、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０は、ステップＳ１０４５で受信したＨＴＴＰパケットをウェブ送受信部２３０のウェブクライアント部７１０に送信してもよい。
【０１１３】
ステップＳ１０５５において、ウェブハンドラのうちＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ウェブクライアント部７１０からステップＳ１０５０に送信した情報に対する応答を受信してもよい。
【０１１４】
ステップＳ１０６０において、ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ステップＳ１０５５で受信した応答をセッションマネージャ部３２０に送信してもよい。
【０１１５】
ステップＳ１０７０において、セッションマネージャ部３２０は、ステップＳ１０６０で受信した応答をコーディング部４１０に送信して符号化を要求してもよい。
【０１１６】
ステップＳ１０８０において、コーディング部４１０は、ステップＳ１０７０で受信した応答を符号化して応答のＨＴＴＰパケットに含まれる情報を確認し、確認された情報をログ管理部４２０に送信してもよい。このとき、ログ管理部４２０は受信した情報をログに格納して管理してもよい。
【０１１７】
ステップＳ１０９０において、コーディング部４１０は、コンバータ部４３０がステップＳ１０８０で確認された情報を変換して生成したバイナリパケットをセッションマネージャ部３２０に送信してもよい。
【０１１８】
ステップＳ１０９５において、セッションマネージャ部３２０は、ステップＳ１０９０で受信したバイナリパケットをアプリケーションサーバ１１０に送信してもよい。
【０１１９】
すなわち、本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバおよびＨＴＴＰプロトコルを用いるウェブサービスサーバ間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【０１２０】
また、アプリケーションサーバとはＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することができる。
【０１２１】
また、ウェブサービスサーバとはＲＥＳＴｆｕｌ ＨＴＴＰを用いて情報を送受信することによって、既に用いたウェブサービスを最小限に変更することで用いることができる。
【０１２２】
上述したように、本発明は、限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態を基に多様な修正および変形が可能である。
【０１２３】
したがって、本発明の範囲は説明された実施形態に限定されるものではなく、特許請求の範囲のみならず、この特許請求の範囲と均等なものなどによって定められなければならない。
【符号の説明】
【０１２４】
１３０ 中継サーバ
１４０ モニタリングサーバ
２２０ 変換部
２３０ ウェブ送受信部
４１０ コーディング部
４２０ ログ管理部
４３０ コンバータ部
【技術分野】
【０００１】
本発明は、バイナリパケット中継システムおよび方法に関し、より詳しくは、互いに異なるプロトコルを用いる複数のサーバから情報を受信し、送信する対象のサーバが用いるプロトコルに応じて変換して送信することによって、情報を中継することのできる中継システムおよび方法に関する。
【背景技術】
【０００２】
オンラインゲームの発展に伴ってゲーム中にもゲーム上でウェブサービスを利用しようとすることがあり、ウェブサービス中にゲームを提供することが必要な場合も生じている。
【０００３】
しかし、ゲームを実行するゲームサーバとウェブサービスを実行するウェブサービスサーバとは互いに使用しているプロトコルが異なるので中継のためのシステムが求められている。
【０００４】
したがって、非同期通信基盤のゲームサーバと同期通信基盤のウェブサービスサーバとの情報を中継することによって、ゲーム上でもウェブサービスを容易に用いることのできるシステムおよび方法が求められている。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、バイナリプロトコルを用いるアプリケーションサーバと、ＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることのできるシステムおよび方法を提供することを目的とする。
【０００６】
また、本発明は、アプリケーションサーバに対してＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することのできるシステムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一実施形態に係る中継サーバは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。
【０００８】
本発明の一実施形態に係るパケット中継方法は、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、前記バイナリパケットをＨＴＴＰパケットに変換するステップと、前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップとを含む。
【発明の効果】
【０００９】
本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバと、ＨＴＴＰプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【００１０】
また、本発明の一実施形態によれば、アプリケーションサーバに対してＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係る中継システムの構成を示す図である。
【図２】本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。
【図３】本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。
【図４】本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。
【図５】本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。
【図６】本発明のコンバータ部がバイナリパケットをＨＴＴＰパケットに変換する過程の一例である。
【図７】本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。
【図８】本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。
【図９】本発明の一実施形態に係るパケット中継方法を示すフローチャートである。
【図１０】本発明の一実施形態によってバイナリパケットをＨＴＴＰパケットに変換して中継する方法を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態を添付された図面を用いて詳細に説明する。本発明の一実施形態に係る中継方法は中継システムによって行われてもよい。
【００１３】
図１は、本発明の一実施形態に係る中継システムの構成を示す図である。
【００１４】
本発明の一実施形態に係る中継システムは、バイナリプロトコルを用いるアプリケーションサーバ１１０とＨＴＴＰプロトコルを用いるウェブサービスサーバ１２０との間のパケット送受信を中継する中継サーバ１３０、および中継サーバ１３０をモニタリングするモニタリングサーバ１４０から構成されてもよい。ここで、アプリケーションサーバ１１０はゲームサーバであってもよい。
【００１５】
ここで、中継サーバ１３０は、アプリケーションサーバ１１０とはＴＣＰに接続されてバイナリ（ｂｉｎａｒｙ）ＨＴＴＰプロトコル基盤のメッセージを送受信し、ウェブサービスサーバ１２０とは標準ＨＴＴＰに接続されてＨＴＴＰプロトコルメッセージを送受信してもよい。
【００１６】
ここで、中継サーバ１３０は、アプリケーションサーバ１１０とは永久接続（ｐｅｒｍａｎｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）され、ウェブサービスサーバ１２０と必要に応じて接続（ｏｎ−ｄｅｍａｎｄ ｃｏｎｎｅｃｔｉｏｎ）されてもよい。
【００１７】
また、中継サーバ１３０は、アプリケーションサーバ１１０から受信したバイナリパケットをＨＴＴＰパケットに変換してウェブサービスサーバ１２０に送信し、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットをバイナリパケットに変換してアプリケーションサーバ１１０に送信してもよい。
【００１８】
中継サーバ１３０の詳細な構成は、以下に図２を参照して詳細に説明する。
【００１９】
モニタリングサーバ１４０は、ＪＭＸ（Ｊａｖａ Ｍａｎａｇｅｍｅｎｔ ｅＸｔｅｎｓｉｏｎｓ）（登録商標）を用いて中継サーバ１３０の接続を制御し、モニタリングしてもよい。
【００２０】
モニタリングサーバ１４０の詳細な構成は以下に図８を参照して詳細に説明する。
【００２１】
図２は、本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。
【００２２】
図２に示すように、中継サーバ１３０は、バイナリ送受信部２１０、変換部２２０、およびウェブ送受信部２３０を備えてもよい。
【００２３】
バイナリ送受信部２１０は、アプリケーションサーバ１１０からバイナリパケットを受信して変換部２２０に送信し、変換部２２０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求をアプリケーションサーバ１１０に送信してもよい。
【００２４】
バイナリ送受信部２１０の構成は以下に図３を参照して詳細に説明する。
【００２５】
変換部２２０は、バイナリ送受信部２１０が受信したバイナリパケットをＨＴＴＰパケットに変換してウェブ送受信部２３０に送信してもよい。
【００２６】
また、変換部２２０は、ウェブ送受信部２３０が受信したＨＴＴＰパケットをバイナリパケットに変換してバイナリ送受信部２１０に送信してもよい。このとき、モニタリングサーバ１４０は、図２に示すように変換部２２０と接続されて変換過程を制御し、モニタリングしてもよい。
【００２７】
変換部２２０の詳細な構成は以下に図４を参照して詳細に説明する。
【００２８】
ウェブ送受信部２３０は、変換部２２０に変換されたＨＴＴＰパケットをウェブサービスサーバに送信してもよい。
【００２９】
一例として、ウェブ送受信部２３０は、ＲＥＳＴｆｕｌウェブサービスを実現するためのＡＰＩおよびウェブクライアントから構成されてもよい。
【００３０】
ウェブ送受信部２３０の詳細な構成は、以下に図７を参照して詳細に説明する。
【００３１】
図３は、本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。
【００３２】
図３に示すように、バイナリ送受信部２１０は、ＴＣＰサーバ部３１０、セッションマネージャ部３２０、およびＴＣＰクライアント部３３０から構成されてもよい。
【００３３】
ここで、ＴＣＰサーバ部３１０は、アプリケーションサーバ１１０からＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いて送信されたバイナリパケットを受信してもよい。
【００３４】
また、ＴＣＰクライアント部３３０は、ＴＣＰを用いて変換部２２０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求をアプリケーションサーバ１１０に送信してもよい。
【００３５】
また、セッションマネージャ部３２０は、アプリケーションサーバ１１０との接続セッションを管理してＴＣＰサーバ部３１０、およびＴＣＰクライアント部３３０の動作を制御してもよい。
【００３６】
図４は、本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。
【００３７】
図４に示すように、変換部２２０は、コーディング部４１０、ログ管理部４２０、コンバータ部４３０、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０、ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０、コンフィグ管理部４６０、および制御部４７０を備えてもよい。
【００３８】
コーディング部４１０は、バイナリ送受信部２１０が受信したバイナリパケットを復号化したり、ウェブ送受信部２３０が受信したＨＴＴＰパケットを符号化して予め設定されたデータフォーマットに変換したりしてもよい。
【００３９】
一例として、コーディング部４１０は、ＨＴＴＰパケットを符号化してマップタイプに変換してもよい。このとき、マップオブジェクトはＨＴＴＰ要求または応答に対する抽象化されたモデルをそれぞれ定義してもよい。具体的に、コーディング部４１０は、要求または応答に応じて、予め定義されたモデルに変換してコンバータ部４３０に送信すると、コンバータ部４３０が受信したモデルを用いて要求または応答に対応するパケットを生成してもよい。
【００４０】
ここで、コーディング部４１０は、バイナリ送受信部２１０が受信したバイナリパケット、またはウェブ送受信部２３０が受信したＨＴＴＰパケットをログ管理部４２０に送信してもよい。
【００４１】
また、コーディング部４１０は、予め設定されたデータフォーマットに変換したモデルをログ管理部４２０に送信してもよい。
【００４２】
ログ管理部４２０は、コーディング部４１０が送信した情報をログに設定してロギング（ｌｏｇｇｉｎｇ）して管理してもよい。
【００４３】
コンバータ部４３０は、コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換してもよい。
【００４４】
具体的に、コンバータ部４３０は、受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義し、定義された抽象クラスを組み合わせてＨＴＴＰパケットを生成してもよい。
【００４５】
コンバータ部４３０の詳細な構成および動作は、以下に図５および図６を参照して詳細に説明する。
【００４６】
ＴｏＷｅｂＨａｎｄｌｅｒ部４４０は、コンバータ部４３０が生成したＨＴＴＰパケットをウェブ送受信部２３０に送信してもよい。
【００４７】
ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ウェブ送受信部２３０から送信されたウェブサービスサーバ１２０の要求を受信してコーディング部４１０に送信してもよい。
【００４８】
コンフィグ管理部４６０は、バイナリ送受信部２１０、ウェブ送受信部２３０、コーディング部４１０、ログ管理部４２０、ウェブハンドラ（ＷｅｂＨａｎｄｌｅｒ）、制御部４７０、およびウェブハンドラ部の処理流れに対する設定を格納して管理してもよい。このとき、ウェブハンドラは、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０およびＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０を備えてもよい。
【００４９】
ここで、ウェブハンドラは、連鎖（ｃｈａｉｎｉｎｇ）されてウェブサービスサーバ１１０からＨＴＴＰパケットを受信するアップストリーム（ｕｐｓｔｒｅａｍ）およびウェブサービスサーバ１２０にＨＴＴＰパケットを送信するダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）の処理を行なってもよい。
【００５０】
制御部４７０は、アクセス制御マネージャ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｎａｇｅｒ）を用いて上記の構成に対する動作を制御し、上記の構成に対する動作をモニタリングサーバ１４０に送信してもよい。
【００５１】
図５は、本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。
【００５２】
図５に示すように、コンバータ部４３０は、クラス定義部５１０、ＨＴＴＰパケット生成部５２０、バイナリパート生成部５３０、およびバイナリパケット生成部５４０を備えてもよい。
【００５３】
クラス定義部５１０は、受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義してもよい。
【００５４】
ＴＣＰ基盤のバイナリパケットは、それぞれの意味を有する複数のパートに構成してもよい。
【００５５】
ここで、クラス定義部５１０は、バイナリパケットのパートを抽象化してバイナリパケット全体をパケット（ｐａｃｋｅｔ）というインタフェースに定義し、パートをそれぞれパケットパート（ｐａｃｋｅｔｐａｒｔ）抽象クラスのように定義してもよい。
【００５６】
ＨＴＴＰパケット生成部５２０は、クラス定義部５１０に定義された少なくとも１つの抽象クラスを組み合わせてアプリケーションサーバ１１０に送信しようとするメッセージが含まれたＨＴＴＰパケットを生成してもよい。
【００５７】
バイナリパート生成部５３０は、受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに含まれる情報を確認し、クラスに対応するバイナリパケットのパートを生成してもよい。
【００５８】
バイナリパケット生成部５４０は、バイナリパート生成部５３０で生成されたバイナリパケットのパートを結合してウェブサービスサーバ１２０の要求が含まれたバイナリパケットを生成してもよい。
【００５９】
図６は、本発明のコンバータ部がバイナリパケットをＨＴＴＰパケットに変換する過程の一例である。
【００６０】
アプリケーションサーバ１１０から受信したＴＣＰ基盤のバイナリパケット６１０は、図６に示すように複数のパート６１１から構成されてもよい。
【００６１】
ここで、クラス定義部５１０は、バイナリパケットのパート６１１を抽象化してバイナリパケットの全体をパケットいうインタフェース６２０に定義し、パート６１１をそれぞれパケットパート抽象クラス６２１に定義してもよい。このとき、各抽象クラスは、対応するバイナリパケットのパート６１１のディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）であってもよい。
【００６２】
また、ＨＴＴＰパケット生成部５２０は、クラス定義部５１０に定義された抽象クラス６２１を組み合わせてジャバ（ｊａｖａ（登録商標））クラス６３０を生成してもよい。このとき、ＨＴＴＰパケット生成部５２０が生成したジャバクラス６３０は、抽象クラス６２１を引用する記述６３１を含んでもよい。
【００６３】
次にＨＴＴＰパケット生成部５２０は、ジャバクラス６３０に基づいてアプリケーションサーバ１１０に送信しようとするメッセージが含まれたＨＴＴＰパケットを生成してもよい。
【００６４】
また、コンバータ部がＨＴＴＰパケットをバイナリパケットに変換する過程は前述した過程の逆順である。
【００６５】
具体的に、まず、バイナリパート生成部５３０は、受信したＨＴＴＰパケットでジャバクラス６３０を復元してもよい。
【００６６】
その後、バイナリパート生成部５３０は、予め設定されたライブラリを用いてジャバクラス６３０に基づいてバイナリパケットのパート６１１を生成してもよい。
【００６７】
ここで、ライブラリは、ジャバクラス６３０に対応するバイナリパケットのパート６１１に関する情報が含まれたライブラリであってもよい。
【００６８】
最後に、バイナリパケット生成部５４０は、バイナリパート生成部５３０で生成されたバイナリパケットのパート６１１を結合してウェブサービスサーバ１２０の要求が含まれたバイナリパケット６１０を生成してもよい。
【００６９】
ここで、パケットインタフェース６２０はシリアライズ方法（ｓｅｒｉａｌｉｚｅ ｍｅｔｈｏｄ）およびデシリアライズ方法（ｄｅｓｅｒｉａｌｉｚｅ ｍｅｔｈｏｄ）を含んでもよい。
【００７０】
ここで、シリアライズは、ジャバオブジェクトをバイナリストリームに変換する方法であり、デシリアライズは、バイナリストリームをジャバオブジェクトに変換する方法である。
【００７１】
また、パケットインタフェース６２０は、バイナリパケットとマッチングされるジャバタイプをメッセージタイプ（ｍｅｓｓａｇｅＴｙｐｅ）に格納してもよい。
【００７２】
また、パケットパート抽象クラス６２１は、パケットインタフェース６２０のようにシリアライズ方法およびデシリアライズ方法を含んでもよい。
【００７３】
図７は、本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。
【００７４】
図７に示すように、ウェブ送受信部２３０は、ウェブクライアント部７１０、ＲＥＳＴｆｕｌ ＡＰＩ部７２０、アクションマップ（ＡｃｔｉｏｎＭａｐｐｅｒ）部７３０、およびサーブレット（ｓｅｒｖｌｅｔ）部７４０を備えてもよい。
【００７５】
ウェブクライアント部７１０は、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０から受信したＨＴＴＰパケットをウェブサービスサーバ１２０に送信し、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットをＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０に送信してもよい。このとき、ウェブサービスサーバ１２０から受信したＨＴＴＰパケットは、ウェブサービスサーバ１２０の要求メッセージであってもよい。
【００７６】
ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、ウェブサービスサーバ１２０が提供するウェブサービスをＲＥＳＴｆｕｌウェブサービスに変換して実現してもよい。
【００７７】
具体的に、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、Ｌｕｃｙ／Ｗｅｂｗｏｒｋ基盤アクションに注釈（ａｎｎｏｔａｔｉｏｎ）を追加することによってＲＥＳＴｆｕｌウェブサービスを実現することができる。
【００７８】
ここで、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、指定したクラスがＲＥＳＴｆｕｌ Ｒｅｓｏｕｒｃｅであることを表す＠ＲｅｓｔｆｕｌＲｅｓｏｕｒｃｅ関数、および方法が処理するＨＴＴＰ Ｍｅｔｈｏｄを指定する＠Ｇｅｔ、＠Ｐｏｓｔ、＠Ｐｕｔ、＠Ｄｅｌｅｔｅ関数を含んでもよい。
【００７９】
また、ＲＥＳＴｆｕｌ ＡＰＩ部７２０は、ＲＥＳＴｆｕｌ ＨＴＴＰ要求および応答処理のためのユーティリティクラスであるＲｅｓｔｆｕｌＳｅｒｖｉｃｅＵｔｉｌを含んでもよい。
【００８０】
アクションマップ部７３０は、ＲＥＳＴｆｕｌ要求に対するアクションマッピングを行なってもよい。
【００８１】
具体的に、アクションマップ部７３０は、ＬｕｃｙのＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒを相続するアクションマップを実現してアクションマッピングを行なってもよい。
【００８２】
また、アクションマップ部７３０は、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒ、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒ、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐを含んでもよい。
【００８３】
ここで、ＲｅｓｔｆｕｌＡｃｔｉｏｎＩｎｆｏＭａｎａｇｅｒは、ｘｗｏｒｋ ａｃｔｉｏｎ ｃｌａｓｓのうち＠ＲｅｓｔｆｕｌＲｅｓｏｕｃｅに指定されたアクションクラスの情報をロードし、ＨＴＴＰ方法、ＵＲＩ、Ａｃｃｅｐｔヘッダを因子としてマッピングされるアクション情報を返してもよい。
【００８４】
また、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求がＲＥＳＴｆｕｌ要求である場合にマッチングされるアクション情報に対してマッピング情報を生成して返してもよい。このとき、ＲｅｓｔｆｕｌＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求がＲＥＳＴｆｕｌ要求ではない場合、直ちにｎｕｌｌを返してもよい。
【００８５】
また、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒは、ＨＴＴＰ要求に対して適するマッピングを生成して返してもよい。このとき、ＲｅｓｔｆｕｌＥｎａｂｌｅｄＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒは、ＲＥＳＴｆｕｌ要求ではない場合、ＤｉｓｐａｔｃｈＡｃｔｉｏｎＭａｐｐｅｒからマッピング情報を収集して返してもよい。
【００８６】
サーブレット部７４０は、アクションマップ部７３０で処理されたアクションマッピングの結果をウェブサービスとして用いるデータ形式であるＪＳＯＮに変換し、サーブレット応答ストリーム（Ｓｅｒｖｌｅｔ Ｒｅｓｐｏｎｓｅ Ｓｔｒｅａｍ）に挿入してもよい。このとき、サーブレット応答ストリームは、ＨＴＴＰ要求による応答ストリームであってもよい。
【００８７】
図８は、本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。
【００８８】
図８に示すように、モニタリングサーバ１４０は、モニタリング部８１０、表示部８２０、および制御部８３０を備えてもよい。
【００８９】
モニタリング部８１０は、中継サーバ１３０のモニタリングおよび制御のためのＪＭＸコンポーネントであってもよい。
【００９０】
ここで、モニタリング部８１０は、中継サーバ１３０の変換部２２０でメモリ、スレッド、クラス、ＣＰＵ、ＶＭサマリー、パケットスループット、接続状況のうち少なくとも１つの変化をモニタリングしてもよい。
【００９１】
表示部８２０は、モニタリング部８１０がモニタリングした情報を管理者に表示してもよい。
【００９２】
制御部８３０は、制御部４７０の接続制御を管理し、モニタリング部８１０のＪＭＸ基盤モニタリングを制御するためのウェブアプリケーションであってもよい。
【００９３】
ここで、制御部８３０は、ＷＳＭ Ａｄｍｉｎに基づいて生成されたＡｄｍｉｎ Ｗｅｂであってもよい。
【００９４】
また、制御部８３０は、モニタリング部８１０に含まれてモニタリングを制御してもよい。
【００９５】
図９は、本発明の一実施形態に係るパケット中継方法を示すフローチャートである。
【００９６】
ステップＳ９１０において、変換部２２０は変換しようとするパケットを受信してもよい。
【００９７】
一例として、変換部２２０は、バイナリ送受信部２１０がアプリケーションサーバ１１０から受信したバイナリパケットや、ウェブ送受信部２３０がウェブサービスサーバ１２０から受信したＨＴＴＰパケットを受信してもよい。
【００９８】
ステップＳ９２０において、コーディング部４１０は、ステップＳ９１０で受信したパケットをコーディングしてパケットに含まれる情報を確認してもよい。
【００９９】
一例として、コーディング部４１０は、バイナリパケットを復号化してバイナリパケットに含まれる情報を確認したり、ＨＴＴＰパケットを符号化してＨＴＴＰパケットに含まれる情報を確認したりしてもよい。
【０１００】
ステップＳ９３０において、ログ管理部４２０は、ステップＳ９２０で確認された情報をログに格納して管理してもよい。
【０１０１】
ステップＳ９４０において、コンバータ部４３０は、ステップＳ９２０で確認された情報をステップＳ９１０で受信したパケットの種類に応じて変換してもよい。
【０１０２】
一例として、コンバータ部４３０は、ステップＳ９１０でバイナリパケットを受信すると、受信したバイナリパケットをＨＴＴＰパケットに変換し、ステップＳ９１０でＨＴＴＰパケットを受信すると、受信したＨＴＴＰパケットをバイナリパケットに変換してもよい。
【０１０３】
ステップＳ９５０において、変換部２２０はステップＳ９４０に変換されたパケットを送信してもよい。
【０１０４】
一例として、変換部２２０は、ステップＳ９４０でバイナリパケットに変換されたウェブサービスサーバ１２０の要求を、バイナリ送受信部２１０を介してアプリケーションサーバ１１０に送信してもよい。
【０１０５】
他の一例として、変換部２２０は、ステップＳ９４０でＨＴＴＰパケットに変換されたアプリケーションサーバ１１０の要求を、ウェブ送受信部２３０を介してウェブサービスサーバ１２０に送信してもよい。
【０１０６】
図１０は、本発明の一実施形態によってバイナリパケットをＨＴＴＰパケットに変換して中継する方法を示すフローチャートである。
【０１０７】
ステップＳ１０１０において、バイナリ送受信部２１０のセッションマネージャ部３２０は、アプリケーションサーバ１１０からバイナリパケットが含まれたストリームを受信してもよい。
【０１０８】
ステップＳ１０２０において、セッションマネージャ部３２０は、ステップＳ１０１０で受信したバイナリパケットをコーディング部４１０に送信して復号化を要求してもよい。
【０１０９】
ステップＳ１０３０において、コーディング部４１０は、ステップＳ１０２０で受信したバイナリパケットを復号化してバイナリパケットに含まれる情報を確認し、確認された情報をログ管理部４２０に送信してもよい。このとき、ログ管理部４２０は受信した情報をログに格納して管理してもよい。
【０１１０】
ステップＳ１０４０において、コーディング部４１０は、コンバータ部４３０がステップＳ１０２０で確認された情報を変換して生成したＨＴＴＰパケットをセッションマネージャ部３２０に送信してもよい。
【０１１１】
ステップＳ１０４５において、セッションマネージャ部３２０は、ステップＳ１０４０で受信したＨＴＴＰパケットをウェブハンドラ（ＷｅｂＨａｎｄｌｅｒ）のうちＴｏＷｅｂＨａｎｄｌｅｒ部４４０に送信してもよい。
【０１１２】
ステップＳ１０５０において、ＴｏＷｅｂＨａｎｄｌｅｒ部４４０は、ステップＳ１０４５で受信したＨＴＴＰパケットをウェブ送受信部２３０のウェブクライアント部７１０に送信してもよい。
【０１１３】
ステップＳ１０５５において、ウェブハンドラのうちＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ウェブクライアント部７１０からステップＳ１０５０に送信した情報に対する応答を受信してもよい。
【０１１４】
ステップＳ１０６０において、ＦｒｏｍＷｅｂＨａｎｄｌｅｒ部４５０は、ステップＳ１０５５で受信した応答をセッションマネージャ部３２０に送信してもよい。
【０１１５】
ステップＳ１０７０において、セッションマネージャ部３２０は、ステップＳ１０６０で受信した応答をコーディング部４１０に送信して符号化を要求してもよい。
【０１１６】
ステップＳ１０８０において、コーディング部４１０は、ステップＳ１０７０で受信した応答を符号化して応答のＨＴＴＰパケットに含まれる情報を確認し、確認された情報をログ管理部４２０に送信してもよい。このとき、ログ管理部４２０は受信した情報をログに格納して管理してもよい。
【０１１７】
ステップＳ１０９０において、コーディング部４１０は、コンバータ部４３０がステップＳ１０８０で確認された情報を変換して生成したバイナリパケットをセッションマネージャ部３２０に送信してもよい。
【０１１８】
ステップＳ１０９５において、セッションマネージャ部３２０は、ステップＳ１０９０で受信したバイナリパケットをアプリケーションサーバ１１０に送信してもよい。
【０１１９】
すなわち、本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバおよびＨＴＴＰプロトコルを用いるウェブサービスサーバ間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。
【０１２０】
また、アプリケーションサーバとはＨＴＴＰに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをＨＴＴＰパケットに変換することができる。
【０１２１】
また、ウェブサービスサーバとはＲＥＳＴｆｕｌ ＨＴＴＰを用いて情報を送受信することによって、既に用いたウェブサービスを最小限に変更することで用いることができる。
【０１２２】
上述したように、本発明は、限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態を基に多様な修正および変形が可能である。
【０１２３】
したがって、本発明の範囲は説明された実施形態に限定されるものではなく、特許請求の範囲のみならず、この特許請求の範囲と均等なものなどによって定められなければならない。
【符号の説明】
【０１２４】
１３０ 中継サーバ
１４０ モニタリングサーバ
２２０ 変換部
２３０ ウェブ送受信部
４１０ コーディング部
４２０ ログ管理部
４３０ コンバータ部
【特許請求の範囲】
【請求項１】
バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、
前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、
前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
を備えることを特徴とする中継サーバ。
【請求項２】
前記変換部は、
前記受信したバイナリパケットを復号化するコーディング部と、
前記コーディング部が復号化したバイナリパケットの情報をログに管理するログ管理部と、
前記コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換するコンバータ部と、
を備えることを特徴とする請求項１に記載の中継サーバ。
【請求項３】
前記コンバータ部は、
受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義するクラス定義部と、
少なくとも１つの前記抽象クラスを組み合わせて前記ＨＴＴＰパケットを生成するＨＴＴＰパケット生成部と、
を備えることを特徴とする請求項２に記載の中継サーバ。
【請求項４】
前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項２に記載の中継サーバ。
【請求項５】
前記コンバータ部は、
受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに対応するバイナリパケットのパートを生成するバイナリパート生成部と、
生成したバイナリパケットのパートを結合してバイナリパケットを生成するバイナリパケット生成部と、
を備えることを特徴とする請求項４に記載の中継サーバ。
【請求項６】
バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、
前記バイナリパケットをＨＴＴＰパケットに変換するステップと、
前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップと、
を含むことを特徴とするパケット中継方法。
【請求項７】
前記変換するステップは、
前記受信したバイナリパケットを復号化するステップと、
復号化したバイナリパケットの情報をログに格納するステップと、
前記復号化したバイナリパケットをＨＴＴＰパケットに変換するステップと、
を含むことを特徴とする請求項６に記載のパケット中継方法。
【請求項８】
前記ＨＴＴＰパケットに変換するステップは、
受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義するステップと、
少なくとも１つの前記抽象クラスを組み合わせて前記ＨＴＴＰパケットを生成するステップと、
を含むことを特徴とする請求項７に記載のパケット中継方法。
【請求項９】
前記変換するステップは、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項７に記載のパケット中継方法。
【請求項１０】
前記変換するステップは、
受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに対応するバイナリパケットのパートを生成するステップと、
生成したバイナリパケットのパートを結合してバイナリパケットを生成するステップと、
を含むことを特徴とする請求項９に記載のパケット中継方法。
【請求項１】
バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、
前記バイナリパケットをＨＴＴＰパケットに変換する変換部と、
前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、
を備えることを特徴とする中継サーバ。
【請求項２】
前記変換部は、
前記受信したバイナリパケットを復号化するコーディング部と、
前記コーディング部が復号化したバイナリパケットの情報をログに管理するログ管理部と、
前記コーディング部が復号化したバイナリパケットをＨＴＴＰパケットに変換するコンバータ部と、
を備えることを特徴とする請求項１に記載の中継サーバ。
【請求項３】
前記コンバータ部は、
受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義するクラス定義部と、
少なくとも１つの前記抽象クラスを組み合わせて前記ＨＴＴＰパケットを生成するＨＴＴＰパケット生成部と、
を備えることを特徴とする請求項２に記載の中継サーバ。
【請求項４】
前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項２に記載の中継サーバ。
【請求項５】
前記コンバータ部は、
受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに対応するバイナリパケットのパートを生成するバイナリパート生成部と、
生成したバイナリパケットのパートを結合してバイナリパケットを生成するバイナリパケット生成部と、
を備えることを特徴とする請求項４に記載の中継サーバ。
【請求項６】
バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、
前記バイナリパケットをＨＴＴＰパケットに変換するステップと、
前記ＨＴＴＰパケットをＨＴＴＰプロトコルを用いるウェブサービスサーバに送信するステップと、
を含むことを特徴とするパケット中継方法。
【請求項７】
前記変換するステップは、
前記受信したバイナリパケットを復号化するステップと、
復号化したバイナリパケットの情報をログに格納するステップと、
前記復号化したバイナリパケットをＨＴＴＰパケットに変換するステップと、
を含むことを特徴とする請求項６に記載のパケット中継方法。
【請求項８】
前記ＨＴＴＰパケットに変換するステップは、
受信したバイナリパケットを構成する少なくとも１つのパートを抽象化して各抽象クラスに定義するステップと、
少なくとも１つの前記抽象クラスを組み合わせて前記ＨＴＴＰパケットを生成するステップと、
を含むことを特徴とする請求項７に記載のパケット中継方法。
【請求項９】
前記変換するステップは、前記ウェブ送受信部が前記ウェブサービスサーバから受信したＨＴＴＰパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項７に記載のパケット中継方法。
【請求項１０】
前記変換するステップは、
受信したＨＴＴＰパケットに含まれる少なくとも１つのクラスに対応するバイナリパケットのパートを生成するステップと、
生成したバイナリパケットのパートを結合してバイナリパケットを生成するステップと、
を含むことを特徴とする請求項９に記載のパケット中継方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−３７６３（Ｐ２０１２−３７６３Ａ）
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願番号】特願２０１１−１３１１７０（Ｐ２０１１−１３１１７０）
【出願日】平成２３年６月１３日（２０１１．６．１３）
【出願人】（５０５２０５８１２）エヌエイチエヌ コーポレーション (408)
【Ｆターム（参考）】
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願日】平成２３年６月１３日（２０１１．６．１３）
【出願人】（５０５２０５８１２）エヌエイチエヌ コーポレーション (408)
【Ｆターム（参考）】
[ Back to top ]