バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをHTTPパケットに変換する変換部と、前記HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部と、を備えることを特徴とする中継サーバ。前記変換部は、前記受信したバイナリパケットを復号化するコーディング部と、前記コーディング部が復号化したバイナリパケットの情報をログに管理するログ管理部と、前記コーディング部が復号化したバイナリパケットをHTTPパケットに変換するコンバータ部と、を備えることを特徴とする請求項1に記載の中継サーバ。前記コンバータ部は、受信したバイナリパケットを構成する少なくとも1つのパートを抽象化して各抽象クラスに定義するクラス定義部と、少なくとも1つの前記抽象クラスを組み合わせて前記HTTPパケットを生成するHTTPパケット生成部と、を備えることを特徴とする請求項2に記載の中継サーバ。前記変換部は、前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTPパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項2に記載の中継サーバ。前記コンバータ部は、受信したHTTPパケットに含まれる少なくとも1つのクラスに対応するバイナリパケットのパートを生成するバイナリパート生成部と、生成したバイナリパケットのパートを結合してバイナリパケットを生成するバイナリパケット生成部と、を備えることを特徴とする請求項4に記載の中継サーバ。バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、前記バイナリパケットをHTTPパケットに変換するステップと、前記HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信するステップと、を含むことを特徴とするパケット中継方法。前記変換するステップは、前記受信したバイナリパケットを復号化するステップと、復号化したバイナリパケットの情報をログに格納するステップと、前記復号化したバイナリパケットをHTTPパケットに変換するステップと、を含むことを特徴とする請求項6に記載のパケット中継方法。前記HTTPパケットに変換するステップは、受信したバイナリパケットを構成する少なくとも1つのパートを抽象化して各抽象クラスに定義するステップと、少なくとも1つの前記抽象クラスを組み合わせて前記HTTPパケットを生成するステップと、を含むことを特徴とする請求項7に記載のパケット中継方法。前記変換するステップは、前記ウェブ送受信部が前記ウェブサービスサーバから受信したHTTPパケットをバイナリパケットに変換して前記アプリケーションサーバに送信することを特徴とする請求項7に記載のパケット中継方法。前記変換するステップは、受信したHTTPパケットに含まれる少なくとも1つのクラスに対応するバイナリパケットのパートを生成するステップと、生成したバイナリパケットのパートを結合してバイナリパケットを生成するステップと、を含むことを特徴とする請求項9に記載のパケット中継方法。本発明は、バイナリプロトコルを用いるアプリケーションサーバと、HTTPプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることのできるシステムおよび方法を提供することを目的とする。また、本発明は、アプリケーションサーバに対してHTTPに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをHTTPパケットに変換することのできるシステムおよび方法を提供することを目的とする。本発明の一実施形態に係る中継サーバは、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するバイナリ送受信部と、前記バイナリパケットをHTTPパケットに変換する変換部と、前記HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信するウェブ送受信部とを備える。本発明の一実施形態に係るパケット中継方法は、バイナリプロトコルを用いるアプリケーションサーバからバイナリパケットを受信するステップと、前記バイナリパケットをHTTPパケットに変換するステップと、前記HTTPパケットをHTTPプロトコルを用いるウェブサービスサーバに送信するステップとを含む。本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバと、HTTPプロトコルを用いるウェブサービスサーバとの間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。また、本発明の一実施形態によれば、アプリケーションサーバに対してHTTPに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをHTTPパケットに変換することができる。以下、本発明の実施形態を添付された図面を用いて詳細に説明する。本発明の一実施形態に係る中継方法は中継システムによって行われてもよい。図1は、本発明の一実施形態に係る中継システムの構成を示す図である。本発明の一実施形態に係る中継システムは、バイナリプロトコルを用いるアプリケーションサーバ110とHTTPプロトコルを用いるウェブサービスサーバ120との間のパケット送受信を中継する中継サーバ130、および中継サーバ130をモニタリングするモニタリングサーバ140から構成されてもよい。ここで、アプリケーションサーバ110はゲームサーバであってもよい。ここで、中継サーバ130は、アプリケーションサーバ110とはTCPに接続されてバイナリbinaryHTTPプロトコル基盤のメッセージを送受信し、ウェブサービスサーバ120とは標準HTTPに接続されてHTTPプロトコルメッセージを送受信してもよい。ここで、中継サーバ130は、アプリケーションサーバ110とは永久接続permanentconnectionされ、ウェブサービスサーバ120と必要に応じて接続on-demandconnectionされてもよい。また、中継サーバ130は、アプリケーションサーバ110から受信したバイナリパケットをHTTPパケットに変換してウェブサービスサーバ120に送信し、ウェブサービスサーバ120から受信したHTTPパケットをバイナリパケットに変換してアプリケーションサーバ110に送信してもよい。中継サーバ130の詳細な構成は、以下に図2を参照して詳細に説明する。モニタリングサーバ140は、JMXJavaManagementeXtensions登録商標を用いて中継サーバ130の接続を制御し、モニタリングしてもよい。モニタリングサーバ140の詳細な構成は以下に図8を参照して詳細に説明する。図2は、本発明の一実施形態に係る中継サーバの構成を示すブロックダイアグラムである。図2に示すように、中継サーバ130は、バイナリ送受信部210、変換部220、およびウェブ送受信部230を備えてもよい。バイナリ送受信部210は、アプリケーションサーバ110からバイナリパケットを受信して変換部220に送信し、変換部220でバイナリパケットに変換されたウェブサービスサーバ120の要求をアプリケーションサーバ110に送信してもよい。バイナリ送受信部210の構成は以下に図3を参照して詳細に説明する。変換部220は、バイナリ送受信部210が受信したバイナリパケットをHTTPパケットに変換してウェブ送受信部230に送信してもよい。また、変換部220は、ウェブ送受信部230が受信したHTTPパケットをバイナリパケットに変換してバイナリ送受信部210に送信してもよい。このとき、モニタリングサーバ140は、図2に示すように変換部220と接続されて変換過程を制御し、モニタリングしてもよい。変換部220の詳細な構成は以下に図4を参照して詳細に説明する。ウェブ送受信部230は、変換部220に変換されたHTTPパケットをウェブサービスサーバに送信してもよい。一例として、ウェブ送受信部230は、RESTfulウェブサービスを実現するためのAPIおよびウェブクライアントから構成されてもよい。ウェブ送受信部230の詳細な構成は、以下に図7を参照して詳細に説明する。図3は、本発明の一実施形態に係るバイナリ送受信部の構成を示すブロックダイアグラムである。図3に示すように、バイナリ送受信部210は、TCPサーバ部310、セッションマネージャ部320、およびTCPクライアント部330から構成されてもよい。ここで、TCPサーバ部310は、アプリケーションサーバ110からTCPTransmissionControlProtocolを用いて送信されたバイナリパケットを受信してもよい。また、TCPクライアント部330は、TCPを用いて変換部220でバイナリパケットに変換されたウェブサービスサーバ120の要求をアプリケーションサーバ110に送信してもよい。また、セッションマネージャ部320は、アプリケーションサーバ110との接続セッションを管理してTCPサーバ部310、およびTCPクライアント部330の動作を制御してもよい。図4は、本発明の一実施形態に係る変換部の構成を示すブロックダイアグラムである。図4に示すように、変換部220は、コーディング部410、ログ管理部420、コンバータ部430、ToWebHandler部440、FromWebHandler部450、コンフィグ管理部460、および制御部470を備えてもよい。コーディング部410は、バイナリ送受信部210が受信したバイナリパケットを復号化したり、ウェブ送受信部230が受信したHTTPパケットを符号化して予め設定されたデータフォーマットに変換したりしてもよい。一例として、コーディング部410は、HTTPパケットを符号化してマップタイプに変換してもよい。このとき、マップオブジェクトはHTTP要求または応答に対する抽象化されたモデルをそれぞれ定義してもよい。具体的に、コーディング部410は、要求または応答に応じて、予め定義されたモデルに変換してコンバータ部430に送信すると、コンバータ部430が受信したモデルを用いて要求または応答に対応するパケットを生成してもよい。ここで、コーディング部410は、バイナリ送受信部210が受信したバイナリパケット、またはウェブ送受信部230が受信したHTTPパケットをログ管理部420に送信してもよい。また、コーディング部410は、予め設定されたデータフォーマットに変換したモデルをログ管理部420に送信してもよい。ログ管理部420は、コーディング部410が送信した情報をログに設定してロギングloggingして管理してもよい。コンバータ部430は、コーディング部が復号化したバイナリパケットをHTTPパケットに変換してもよい。具体的に、コンバータ部430は、受信したバイナリパケットを構成する少なくとも1つのパートを抽象化して各抽象クラスに定義し、定義された抽象クラスを組み合わせてHTTPパケットを生成してもよい。コンバータ部430の詳細な構成および動作は、以下に図5および図6を参照して詳細に説明する。ToWebHandler部440は、コンバータ部430が生成したHTTPパケットをウェブ送受信部230に送信してもよい。FromWebHandler部450は、ウェブ送受信部230から送信されたウェブサービスサーバ120の要求を受信してコーディング部410に送信してもよい。コンフィグ管理部460は、バイナリ送受信部210、ウェブ送受信部230、コーディング部410、ログ管理部420、ウェブハンドラWebHandler、制御部470、およびウェブハンドラ部の処理流れに対する設定を格納して管理してもよい。このとき、ウェブハンドラは、ToWebHandler部440およびFromWebHandler部450を備えてもよい。ここで、ウェブハンドラは、連鎖chainingされてウェブサービスサーバ110からHTTPパケットを受信するアップストリームupstreamおよびウェブサービスサーバ120にHTTPパケットを送信するダウンストリームdownstreamの処理を行なってもよい。制御部470は、アクセス制御マネージャAccessControlManagerを用いて上記の構成に対する動作を制御し、上記の構成に対する動作をモニタリングサーバ140に送信してもよい。図5は、本発明の一実施形態に係るコンバータ部の構成を示すブロックダイアグラムである。図5に示すように、コンバータ部430は、クラス定義部510、HTTPパケット生成部520、バイナリパート生成部530、およびバイナリパケット生成部540を備えてもよい。クラス定義部510は、受信したバイナリパケットを構成する少なくとも1つのパートを抽象化して各抽象クラスに定義してもよい。TCP基盤のバイナリパケットは、それぞれの意味を有する複数のパートに構成してもよい。ここで、クラス定義部510は、バイナリパケットのパートを抽象化してバイナリパケット全体をパケットpacketというインタフェースに定義し、パートをそれぞれパケットパートpacketpart抽象クラスのように定義してもよい。HTTPパケット生成部520は、クラス定義部510に定義された少なくとも1つの抽象クラスを組み合わせてアプリケーションサーバ110に送信しようとするメッセージが含まれたHTTPパケットを生成してもよい。バイナリパート生成部530は、受信したHTTPパケットに含まれる少なくとも1つのクラスに含まれる情報を確認し、クラスに対応するバイナリパケットのパートを生成してもよい。バイナリパケット生成部540は、バイナリパート生成部530で生成されたバイナリパケットのパートを結合してウェブサービスサーバ120の要求が含まれたバイナリパケットを生成してもよい。図6は、本発明のコンバータ部がバイナリパケットをHTTPパケットに変換する過程の一例である。アプリケーションサーバ110から受信したTCP基盤のバイナリパケット610は、図6に示すように複数のパート611から構成されてもよい。ここで、クラス定義部510は、バイナリパケットのパート611を抽象化してバイナリパケットの全体をパケットいうインタフェース620に定義し、パート611をそれぞれパケットパート抽象クラス621に定義してもよい。このとき、各抽象クラスは、対応するバイナリパケットのパート611のディスクリプションdescriptionであってもよい。また、HTTPパケット生成部520は、クラス定義部510に定義された抽象クラス621を組み合わせてジャバjava登録商標クラス630を生成してもよい。このとき、HTTPパケット生成部520が生成したジャバクラス630は、抽象クラス621を引用する記述631を含んでもよい。次にHTTPパケット生成部520は、ジャバクラス630に基づいてアプリケーションサーバ110に送信しようとするメッセージが含まれたHTTPパケットを生成してもよい。また、コンバータ部がHTTPパケットをバイナリパケットに変換する過程は前述した過程の逆順である。具体的に、まず、バイナリパート生成部530は、受信したHTTPパケットでジャバクラス630を復元してもよい。その後、バイナリパート生成部530は、予め設定されたライブラリを用いてジャバクラス630に基づいてバイナリパケットのパート611を生成してもよい。ここで、ライブラリは、ジャバクラス630に対応するバイナリパケットのパート611に関する情報が含まれたライブラリであってもよい。最後に、バイナリパケット生成部540は、バイナリパート生成部530で生成されたバイナリパケットのパート611を結合してウェブサービスサーバ120の要求が含まれたバイナリパケット610を生成してもよい。ここで、パケットインタフェース620はシリアライズ方法serializemethodおよびデシリアライズ方法deserializemethodを含んでもよい。ここで、シリアライズは、ジャバオブジェクトをバイナリストリームに変換する方法であり、デシリアライズは、バイナリストリームをジャバオブジェクトに変換する方法である。また、パケットインタフェース620は、バイナリパケットとマッチングされるジャバタイプをメッセージタイプmessageTypeに格納してもよい。また、パケットパート抽象クラス621は、パケットインタフェース620のようにシリアライズ方法およびデシリアライズ方法を含んでもよい。図7は、本発明の一実施形態に係るウェブ送受信部の構成を示すブロックダイアグラムである。図7に示すように、ウェブ送受信部230は、ウェブクライアント部710、RESTfulAPI部720、アクションマップActionMapper部730、およびサーブレットservlet部740を備えてもよい。ウェブクライアント部710は、ToWebHandler部440から受信したHTTPパケットをウェブサービスサーバ120に送信し、ウェブサービスサーバ120から受信したHTTPパケットをFromWebHandler部450に送信してもよい。このとき、ウェブサービスサーバ120から受信したHTTPパケットは、ウェブサービスサーバ120の要求メッセージであってもよい。RESTfulAPI部720は、ウェブサービスサーバ120が提供するウェブサービスをRESTfulウェブサービスに変換して実現してもよい。具体的に、RESTfulAPI部720は、Lucy/Webwork基盤アクションに注釈annotationを追加することによってRESTfulウェブサービスを実現することができる。ここで、RESTfulAPI部720は、指定したクラスがRESTfulResourceであることを表すRestfulResource関数、および方法が処理するHTTPMethodを指定するGet、Post、Put、Delete関数を含んでもよい。また、RESTfulAPI部720は、RESTfulHTTP要求および応答処理のためのユーティリティクラスであるRestfulServiceUtilを含んでもよい。アクションマップ部730は、RESTful要求に対するアクションマッピングを行なってもよい。具体的に、アクションマップ部730は、LucyのDispatchActionMapperを相続するアクションマップを実現してアクションマッピングを行なってもよい。また、アクションマップ部730は、RestfulEnabledDispatchActionMapper、RestfulActionMapper、RestfulActionMapを含んでもよい。ここで、RestfulActionInfoManagerは、xworkactionclassのうちRestfulResouceに指定されたアクションクラスの情報をロードし、HTTP方法、URI、Acceptヘッダを因子としてマッピングされるアクション情報を返してもよい。また、RestfulActionMapperは、HTTP要求がRESTful要求である場合にマッチングされるアクション情報に対してマッピング情報を生成して返してもよい。このとき、RestfulActionMapperは、HTTP要求がRESTful要求ではない場合、直ちにnullを返してもよい。また、RestfulEnabledDispatchActionMapperは、HTTP要求に対して適するマッピングを生成して返してもよい。このとき、RestfulEnabledDispatchActionMapperは、RESTful要求ではない場合、DispatchActionMapperからマッピング情報を収集して返してもよい。サーブレット部740は、アクションマップ部730で処理されたアクションマッピングの結果をウェブサービスとして用いるデータ形式であるJSONに変換し、サーブレット応答ストリームServletResponseStreamに挿入してもよい。このとき、サーブレット応答ストリームは、HTTP要求による応答ストリームであってもよい。図8は、本発明の一実施形態に係るモニタリングサーバの構成を示すブロックダイアグラムである。図8に示すように、モニタリングサーバ140は、モニタリング部810、表示部820、および制御部830を備えてもよい。モニタリング部810は、中継サーバ130のモニタリングおよび制御のためのJMXコンポーネントであってもよい。ここで、モニタリング部810は、中継サーバ130の変換部220でメモリ、スレッド、クラス、CPU、VMサマリー、パケットスループット、接続状況のうち少なくとも1つの変化をモニタリングしてもよい。表示部820は、モニタリング部810がモニタリングした情報を管理者に表示してもよい。制御部830は、制御部470の接続制御を管理し、モニタリング部810のJMX基盤モニタリングを制御するためのウェブアプリケーションであってもよい。ここで、制御部830は、WSMAdminに基づいて生成されたAdminWebであってもよい。また、制御部830は、モニタリング部810に含まれてモニタリングを制御してもよい。図9は、本発明の一実施形態に係るパケット中継方法を示すフローチャートである。ステップS910において、変換部220は変換しようとするパケットを受信してもよい。一例として、変換部220は、バイナリ送受信部210がアプリケーションサーバ110から受信したバイナリパケットや、ウェブ送受信部230がウェブサービスサーバ120から受信したHTTPパケットを受信してもよい。ステップS920において、コーディング部410は、ステップS910で受信したパケットをコーディングしてパケットに含まれる情報を確認してもよい。一例として、コーディング部410は、バイナリパケットを復号化してバイナリパケットに含まれる情報を確認したり、HTTPパケットを符号化してHTTPパケットに含まれる情報を確認したりしてもよい。ステップS930において、ログ管理部420は、ステップS920で確認された情報をログに格納して管理してもよい。ステップS940において、コンバータ部430は、ステップS920で確認された情報をステップS910で受信したパケットの種類に応じて変換してもよい。一例として、コンバータ部430は、ステップS910でバイナリパケットを受信すると、受信したバイナリパケットをHTTPパケットに変換し、ステップS910でHTTPパケットを受信すると、受信したHTTPパケットをバイナリパケットに変換してもよい。ステップS950において、変換部220はステップS940に変換されたパケットを送信してもよい。一例として、変換部220は、ステップS940でバイナリパケットに変換されたウェブサービスサーバ120の要求を、バイナリ送受信部210を介してアプリケーションサーバ110に送信してもよい。他の一例として、変換部220は、ステップS940でHTTPパケットに変換されたアプリケーションサーバ110の要求を、ウェブ送受信部230を介してウェブサービスサーバ120に送信してもよい。図10は、本発明の一実施形態によってバイナリパケットをHTTPパケットに変換して中継する方法を示すフローチャートである。ステップS1010において、バイナリ送受信部210のセッションマネージャ部320は、アプリケーションサーバ110からバイナリパケットが含まれたストリームを受信してもよい。ステップS1020において、セッションマネージャ部320は、ステップS1010で受信したバイナリパケットをコーディング部410に送信して復号化を要求してもよい。ステップS1030において、コーディング部410は、ステップS1020で受信したバイナリパケットを復号化してバイナリパケットに含まれる情報を確認し、確認された情報をログ管理部420に送信してもよい。このとき、ログ管理部420は受信した情報をログに格納して管理してもよい。ステップS1040において、コーディング部410は、コンバータ部430がステップS1020で確認された情報を変換して生成したHTTPパケットをセッションマネージャ部320に送信してもよい。ステップS1045において、セッションマネージャ部320は、ステップS1040で受信したHTTPパケットをウェブハンドラWebHandlerのうちToWebHandler部440に送信してもよい。ステップS1050において、ToWebHandler部440は、ステップS1045で受信したHTTPパケットをウェブ送受信部230のウェブクライアント部710に送信してもよい。ステップS1055において、ウェブハンドラのうちFromWebHandler部450は、ウェブクライアント部710からステップS1050に送信した情報に対する応答を受信してもよい。ステップS1060において、FromWebHandler部450は、ステップS1055で受信した応答をセッションマネージャ部320に送信してもよい。ステップS1070において、セッションマネージャ部320は、ステップS1060で受信した応答をコーディング部410に送信して符号化を要求してもよい。ステップS1080において、コーディング部410は、ステップS1070で受信した応答を符号化して応答のHTTPパケットに含まれる情報を確認し、確認された情報をログ管理部420に送信してもよい。このとき、ログ管理部420は受信した情報をログに格納して管理してもよい。ステップS1090において、コーディング部410は、コンバータ部430がステップS1080で確認された情報を変換して生成したバイナリパケットをセッションマネージャ部320に送信してもよい。ステップS1095において、セッションマネージャ部320は、ステップS1090で受信したバイナリパケットをアプリケーションサーバ110に送信してもよい。すなわち、本発明の一実施形態によれば、バイナリプロトコルを用いるアプリケーションサーバおよびHTTPプロトコルを用いるウェブサービスサーバ間の情報を中継することによって、アプリケーションサーバでウェブサービスサーバを容易に用いることができる。また、アプリケーションサーバとはHTTPに対応するバイナリプロトコルを用いて情報を送受信することによって、ウェブサービスが必要な場合に、容易にバイナリパケットをHTTPパケットに変換することができる。また、ウェブサービスサーバとはRESTfulHTTPを用いて情報を送受信することによって、既に用いたウェブサービスを最小限に変更することで用いることができる。上述したように、本発明は、限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態を基に多様な修正および変形が可能である。したがって、本発明の範囲は説明された実施形態に限定されるものではなく、特許請求の範囲のみならず、この特許請求の範囲と均等なものなどによって定められなければならない。