JP2018536935A

JP2018536935A - アクセス要求変換方法および装置

Info

Publication number: JP2018536935A
Application number: JP2018524479A
Authority: JP
Inventors: リウ，シン; ヒー，ジャオウェイ; チェン，ティンリャン
Original assignee: アリババグループホウルディングリミテッド
Priority date: 2015-12-08
Filing date: 2016-11-28
Publication date: 2018-12-13
Anticipated expiration: 2036-11-28
Also published as: CN106856434A; EP3389219A4; US20180288187A1; EP3389219B1; JP6912469B2; EP3389219A1; WO2017097123A1; US11647009B2; CN106856434B

Abstract

方法は、クライアントサイドにより送信されたアクセス要求を受信するステップであって、アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含むステップと、アクセス要求の対象サービスタイプを、ＵＲＬおよびパラメータ情報に基づいて判断するステップと、アクセス要求を対象サービスタイプに基づいて変換するステップと、対象サービスタイプに基づいて変換されたアクセス要求に基づいて、サーバサイドが結果情報を返すように、対象サービスタイプに基づいて変換されたアクセス要求を、対象サービスタイプに対応するサーバサイドに送信するステップを含む。本出願の実施形態で提供されるアクセス要求変換方法の使用によって、受信されたアクセス要求の対象サービスタイプがアクセス要求に基づいて判断され、アクセス要求が対象サービスタイプに対応するデータ構造に解析され、対応するサーバサイドにデータ構造が提供され、よって大規模なデータプラットフォーム環境の複数のネットワークについて一体化された要求インタフェースの機能を達成し、システム間の依存状態を切り離し、モジュールに関するシステムの管理メカニズム機能を向上する。
【選択図】図２

Description

本出願は、２０１５年１２月８日出願の中国特許出願第２０１５１０８９６１２２．８号”ＡＣＣＥＳＳＲＥＱＵＥＳＴＣＯＮＶＥＲＳＩＯＮＭＥＴＨＯＤＡＮＤＡＰＰＡＲＡＴＵＳ”の優先権を主張し、その全体の内容は参照により本明細書に組み込まれる。

本発明はデータの展開に関し、特にアクセス要求変換方法および装置に関する。

大規模なデータプラットフォームシステムでは、それらのそれぞれの機能を達成するのに複数のモジュールが必要とされる。モジュールは、異なる開発者によって設計および開発される必要がある。開発者は、機能および性能の要件を満たすよう、種々の種類のモジュラインタフェースを設計する。例えば、遠隔処理手続き呼出しプロトコル（ＲＰＣ）やカスタムバイナリプロトコルなどについて、開発者は全てのプロトコルの相互作用パターンに基づいて開発を行う必要があり、これにより、モジュール間の高度な接続をもたらす。

モジュール間の接続の程度を減少するため、ＮｇｉｎｘＭｏｄｕｌｅｓおよびＳｅｒｖｉｃｅＭｉｘのようないくつかの中間プロトコル変換装置が大規模なデータプラットフォームで使用される。図１に示されるようなＮｇｉｎｘＭｏｄｕｌｅシステムで、要求が受信されるとき、受信された要求は構成ファイルをサーチすることによりローカルデータテーブル内へマッピングされ、ローカルデータテーブル内に格納された命令を起動し、ハンドラモジュールおよび複数のフィルタモジュールに対してそれらのそれぞれの作業を完了して応答を返すように指示する。ハンドラモジュールは、要求を処理し、応答内容を生成する責任を負う。フィルタモジュールは、応答内容を処理する。ＳｅｒｖｉｃｅＭｉｘシステムでは多数のプロトコルがサポート可能であるが、必要に応じてプロトコル拡張もまた行なうことが可能である。

しかし、ＮｇｉｎｘＭｏｄｕｌｅシステムおよびＳｅｒｖｉｃｅＭｉｘシステムでは、システム間の依存性が比較的高く、システム間の負荷分散およびモジュールのフェイルオーバのようなクラスタ管理メカニズム機能が比較的弱い。

本発明の実施形態は、システム間の依存状態を解決し、モジュールに関するシステムの管理メカニズム機能を向上するアクセス要求変換方法および装置を提供する。

第１の態様で本発明は、クライアントサイドにより送信されたアクセス要求を受信するステップであって、アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含むステップと、アクセス要求の対象サービスタイプを、ＵＲＬおよびパラメータ情報に基づいて判断するステップと、アクセス要求を対象サービスタイプに基づいて変換するステップと、対象サービスタイプに基づいて変換されたアクセス要求に基づいてサーバサイドが結果情報を返すように、対象サービスタイプに基づいて変換されたアクセス要求を、対象サービスタイプに対応するサーバサイドに送信するステップを含むアクセス要求変換方法を提供する。

第２の態様で本発明の実施形態は、クライアントサイドにより送信されたアクセス要求を受信するよう構成され、アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含む、受信モジュールと、アクセス要求の対象サービスタイプを、ＵＲＬおよびパラメータ情報に基づいて判断するよう構成された判断モジュールと、アクセス要求を対象サービスタイプに基づいて変換するよう構成された変換モジュールと、対象サービスタイプに基づいて変換されたアクセス要求に基づいてサーバサイドが結果情報を返すように、対象サービスタイプに基づいて変換されたアクセス要求を、対象サービスタイプに対応するサーバサイドへ送信するよう構成された送信モジュールと、を備える装置を提供する。

本発明の実施形態で提供されるアクセス要求変換方法および装置に基づき、受信されたアクセス要求の対象サービスタイプがアクセス要求に基づいて判断され、アクセス要求が対象サービスタイプに対応するデータ構造に解析され、対応するサーバサイドにデータ構造が提供され、よって大規模なデータプラットフォーム環境の複数のネットワークについて一体化された要求インタフェースの機能を達成し、システム間の依存状態を切り離し、モジュールに関するシステムの管理メカニズム機能を向上させる。

本発明の実施形態による技術的解決をより明らかに説明するため、本発明の実施形態で使用される添付の図を以下に簡潔に紹介する。後述する添付の図は、本発明の単にいくつかの実施形態であることは明らかである。当業者は、あらゆる独創的な努力なしに、添付の図によりさらに他の図を得ることができる。

先行技術のＮｇｉｎｘＬｕａシステムの概略構造図である。本出願の実施形態によるアクセス要求変換方法のフローチャートである。本出願の実施形態による装置の概略構造図である。本出願の他の実施形態によるアクセス要求変換方法のフローチャートである。本出願の他の実施形態による装置の概略構造図である。

本発明の実施形態の技術的解決を、本発明の実施形態の添付の図を参照して明白および十分に後述する。記載された実施形態は、本発明の実施形態の全てではなく一部にすぎないことは明らかである。あらゆる独創的な努力なしに本発明の実施形態に基づき当業者が得られる全ての他の実施形態は、本発明の保護範囲内に入る。

本出願の実施形態で提供されるアクセス要求変換方法および装置は、大規模なデータプラットフォームの状況に適用可能である。プロトコルを使用しクライアント側により送信されるアクセス要求、例えばｈｔｔｐ／ｈｔｔｐｓプロトコルを用いたアクセス要求を受信することにより、アクセス要求変換装置は、対象のリソースについてクライアントサイドの要件を満たすよう、ＲＰＣおよびカスタムバイナリプロトコルのような複数のプロトコルをサポートするサーバサイドにアクセス可能である。

本出願の実施形態で、クライアントサイドはサーバサイドに対応するプログラムに照会して顧客にローカルサービスを提供する。クライアントサイドは、クライアントまたはユーザサイドとして照会されることも可能であることに注目すべきである。クライアントサイドは、通常一般的な顧客サービスマシンにインストールされる。クライアントサイドは、ソケットプロトコル、ｈｔｔｐ／ｈｔｔｐｓプロトコル、およびＲＰＣプロトコルのようなさまざまなプロトコルを通して他のクライアントサイドと相互作用が可能である。アクセス要求は、クライアントサイドがプロトコル要求−応答パターンでサーバサイドと相互作用するときに生成される要求メッセージである。サーバサイドは広い意味のサーバであり、ネットワーク内の他のデバイスへサービスを提供可能なコンピュータシステムである。サーバサイドは、受信されたアクセス要求に基づいて応答を作成し、処理を実行する必要がある。サーバサイドは、アクセスサービスを引き受け、サービスの品質を確実にする能力を有する。サーバサイドは、様々なサービスの種類に基づいて、データベースサーバサイド、アプリケーションサーバサイド、Ｗｅｂサーバサイドなどを有してもよい。

記載を容易にするため、本出願の実施形態の技術的解決を、図２を参照して詳細に記載する。これは単に本出願の実施形態の技術的解決を記載する例であって、本出願の実施形態にあらゆる限定を課さないことを理解するべきである。

図２は、本出願の実施形態によるアクセス要求変換方法のフローチャートである。方法を、デバイス、システム、または処理機能を有する装置、例えば、中間プロトコル変換装置により実行してもよい。図２に示されるように、方法は具体的に、後述のステップを有する。

ステップ２１０。クライアントサイドにより送信されたアクセス要求が受信され、アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含む。

アクセス要求はクライアントサイドによりプロトコルを通して送信された要求メッセージであり、例えばｈｔｔｐ要求である。要求メッセージは、ＵＲＬ、パラメータ情報、およびメッセージ本体を含んでもよい。ＵＲＬはインターネット上で利用可能なリソースの場所およびアクセス方法の簡潔な表現であり、インターネット上での標準リソースのアドレスである。インターネット上のそれぞれのファイルは、一意のＵＲＬを有する。ＵＲＬ内の情報は、リソースの場所情報およびクライアントサイドの処理方法を含む。パラメータ情報は、ＵＲＬにより識別された対応するリソースを取得するパラメータＧＥＴ、ＵＲＬにより識別されたリソースの後に新しいデータを付けるパラメータＰＯＳＴ、ＵＲＬにより識別されたリソースのアクセス要求取得の応答メッセージヘッダＨＥＡＤ、アクセス要求のセキュリティ情報に関する認証パラメータ、または他の関連するパラメータを含んでもよい。

任意選択的に、アクセス要求が受信された後、ＵＲＬ、パラメータ情報、メッセージ本体、および他の対応する情報がアクセス要求から取得されるように、アクセス要求は解析される。

アクセス要求内の対応する情報が取得された後、方法は、アクセス要求に対して予め規定された処理を実行し、予め規定された処理はアクセス要求の認証を含む。方法は、認証が成功するとき、ＵＲＬおよびパラメータ情報に基づいて対象サービスタイプを判断するステップを含んでもよい。

具体的に、アクセス要求に対して予め規定された処理を実行するステップは、予め規定されたデータ修正およびアクセス要求の認証のような処理を含んでもよい。例えば、ステップは、フィルタ構成要素を用いることにより実行可能であり、フィルタ構成要素は、図３に示されるように、装置に登録され、開発者によりカスタム開発される。

本出願の実施形態で、アクセス要求の認証は、アクセス要求内の認証パラメータ情報をトークンセンタのトークン情報とマッチングするステップであって、認証パラメータ情報がトークン情報と合致するときアクセス要求の認証が成功するステップを含んでもよい。

具体的に、トークンセンタがアクセス要求内の情報により計算を実行してトークン情報を得て、該トークン情報をアクセス要求内の認証パラメータ情報とマッチングするように、フィルタ構成要素はアクセス要求をトークンセンタへ送信する。トークン情報が認証パラメータ情報と合致するときアクセス要求の認証は成功し、アクセス要求が有効性の認証を通ったことを示す。そうでなければ、アクセス要求は認証を通らない。

アクセス要求が認証を通らないとき、アクセス要求が認証を通らないことをユーザに示すエラー情報がクライアントサイドに返され、よってクライアントサイドによる情報の取得を促進する。アクセス要求が認証を通るとき、ステップ２２０が実行される。

ステップ２２０。アクセス要求の対象サービスタイプが、ＵＲＬおよびパラメータ情報に基づいて判断される。

具体的に、本出願の実施形態で、対象サービスタイプは、サーバサイドによりサポート可能なプロトコルタイプ、例えば、ＨＳＦ、ＭｏｃｋおよびＰｒｏｔｏｂｕｆｆｅｒである。プロトコルは、他のプロトコルタイプを含むように拡張可能であり、これに対し本出願の実施形態では制限がない。

本出願の実施形態で、ＵＲＬおよびパラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するステップは、具体的に、ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうか判断するステップと、ＵＲＬパスに対応するサービスが存在するとき、パラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するステップを含む。

具体的に、装置はテーブルを検索することにより、ＵＲＬパスに対応するサービスが存在するかどうかを判断可能である。例えば、対応するパスがテーブル内に存在するかどうかを判断するのに、表１をＵＲＬパスによってサーチ可能である。例えば、アクセス要求内のＵＲＬパスがパス１であり、テーブルを検索することによりパス１が存在するかどうかが判断される。アクセス要求内のＵＲＬパスがテーブル内に存在するとき、ＵＲＬパスに対応するサービスが存在すると判断される。そうでなければ、パスに対応するサービスは存在しない。

本出願の実施形態で、表１は単に本出願の技術的解決を詳細に説明するよう意図されたものであることを理解するべきである。表１の内容は本出願の実施形態にあらゆる限定を課さず、本出願の実施形態の内容にいかなる限定もなされない。

ＵＲＬに基づいて、ＵＲＬパスに対応するサービスが存在すると判断されるとき、アクセス要求が変換される対象サービスタイプがパラメータ情報に基づいて判断される。例えば、対象サービスタイプを、テーブルの検索により判断可能である。図１に示されるように、存在することが見出されたパス１に基づき、問い合わせられた対応する対象サービスタイプはＨＳＦである。具体的には、図３に示されるように対象サービスをルーティングエンジン構成要素により判断可能である。ルーティングエンジン構成要素は、開発者が開発したプログラムであってもよく、ＵＲＬおよびアクセス要求内のパラメータ情報に基づいて対象サービスタイプを判断する機能を有し、シャーディング構成要素およびフェイルオーバ構成要素を有する。シャーディング構成要素は、アクセス要求のサーバサイドにより構成されたフェイルオーバストラテジおよび負荷分散ストラテジ（ＨＳＦ＿プロバイダ１、ＨＳＦ＿プロバイダ２、ＰＢサービス＿１およびＰＢサービス＿２）に基づき、判断された対象サービスタイプに基づいてアクセス要求を分配し、アクセス要求を、ＨＳＦ、ＭｏｃｋおよびＰｒｏｔｏｂｕｆｆｅｒのような対応する対象サービスタイプのエンジン構成要素へ送信するよう構成される。フェイルオーバは、装置内のデータまたはファイルが損傷または失われたとき、装置が損傷または失われたデータまたはファイルをアクシデントが起こる前の状態に自動的に復旧し、装置の正常な実行を確実にすることを意味する。負荷分散は、アクセス要求を処理するタスクがサーバサイドによって共に完了されるように、処理のための複数のエンジン構成要素に対応するＨＳＦ＿プロバイダ１、ＨＳＦ＿プロバイダ２、ＰＢサービス＿１およびＰＢサービスＳ＿２のようなサーバサイドへ、アクセス要求を分散することを意味する。

本出願の実施形態で、フェイルオーバ構成要素は、サーバサイドの構成を記録する機能を有し、これにより、ルーティングエンジンが、負荷分散を実行するため、フェイルオーバ構成要素内のサーバサイドの構成を問い合わせることにより、対応する対象サービスタイプのエンジン構成要素へアクセス要求を分散することが可能となる。言い換えれば、対象サービスタイプに基づいて変換されたアクセス要求を対象サービスタイプに対応するサーバサイドへ送信するステップの前に、方法はさらに、負荷分散を実行するため、対象サービスタイプに基づいて、およびサーバサイドの構成に基づいて、アクセス要求の情報が、対応するサーバサイドへ分散されるように、対象サービスタイプに基づいて、対象サービスタイプに対応しフェイルオーバ構成要素内に記録されたサーバサイドを問い合わせるステップを含む。

本出願の実施形態で、装置がＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうか判断するとき、またはパラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するとき、ＵＲＬパスまたは対象サービスタイプに対応するサービスが存在しない場合、クライアントサイドを使用しているユーザがエラーの理由を認識可能なように、エラーの理由を示すエラー情報がクライアントサイドに返される。

ステップ２３０。アクセス要求が対象サービスタイプに基づいて変換される。

具体的に、アクセス要求を受信するとき、エンジン構成要素は、対象サービスタイプに基づいて、受信されたアクセス要求のデータ構造をサーバサイドがサポート可能なプロトコルタイプに変換する。例えば図３に示されるように、エンジン構成要素ＨＳＦ、ＭｏｃｋまたはＰｒｏｔｏｂｕｆｆｅｒにより、アクセス要求を、ＨＳＦ＿プロバイダ１、ＨＳＦ＿プロバイダ２、Ｍｏｃｋサーバサイド、ＰＢサービス＿１、またはＰＢサービス＿２がサポート可能なプロトコルタイプへ変換可能である。ここで、ＰＢサービスはＰｒｏｔｏｂｕｆｆｅｒサービスの略称である。

ステップ２４０。対象サービスタイプに基づいて変換されたアクセス要求は、対象サービスタイプに対応するサーバサイドに送信され、これにより、サーバサイドは、対象サービスタイプに基づいて変換されたアクセス要求に基づいて結果情報を返す。

具体的に、エンジン構成要素が、アクセス要求を、対応する対象サービスタイプのアクセス要求に変換するとき、エンジン構成要素は、変換されたアクセス要求を対応するサーバサイドにそれぞれ送信し、これにより、対応するサーバサイドが、対応するアクセス要求に基づいて応答を作成し、結果情報を返す。結果情報は、クライアントサイドのアクセス要求に関するリソース情報であり、テキスト、画像、ビデオ、または他の情報であってもよい。

本出願の実施形態で、方法はさらに、結果情報を受信するステップ、結果情報を処理するステップ、および処理された結果情報をクライアントサイドへ送信するステップを含んでもよく、これにより、クライアントサイドが、処理された結果情報に基づいて対応する動作を実行する。

具体的には、エンジン構成要素は、サーバサイドにより送信された結果情報を受信し、それをルーティングエンジン構成要素へ送信する。ルーティングエンジン構成要素は、様々なエンジン構成要素により送信された受信結果情報のデータを、一体化されたデータ構造に構造化し、それを図３に記載のハンドラ構成要素へ返す。この構成要素は開発者が開発したプログラムであり、返された結果情報をクライアントサイドが受信可能なデータ構造に処理する機能を有する。例えば構成要素は、アクセス要求の結果情報の圧縮、ロギング、データ修正およびマスキングを実行可能である。ロギングによって、クライアントサイドからアクセス要求が送信された時点から、アクセス要求についての結果情報がクライアントサイドに返された時点までの時間についての情報のログを取ることが可能である。マスキングによって、マスキング規則に基づいて結果情報内の慎重に扱うべき情報のデータ変換が実行され、これにより、慎重に扱うべきプライベートデータを確実に保護することができる。本出願の実施形態で、必要に応じて複数のハンドラ構成要素を設定してもよい。結果情報を処理するプロセスで、結果情報を次のハンドラ構成要素へ順次送信可能であり、これにより、結果情報のデータを柔軟および透過的に変更することができる。

本出願の実施形態で、アクセス要求の例が１＋１＝？であり、返された結果が２であり、ハンドラ構成要素は、予め規定された処理方法に基づいて、返された結果の２を処理する。例えばハンドラ構成要素は、返された結果を圧縮し、これにより、クライアントサイドは、情報の受信後、情報に基づいて対応する処理を実行する。返された結果が他の数、例えば３であるとき、ハンドラ構成要素は、返された結果の３、および付加的な結果エラー情報を、予め規定された処理方法に基づいてクライアントサイドへ送信可能である。

本出願の実施形態で提供されるアクセス要求変換方法に基づき、受信されたアクセス要求の対象サービスタイプはアクセス要求に基づいて判断され、アクセス要求は対象サービスタイプに対応するデータ構造に解析され、データ構造が、対応するサーバサイドに提供され、よって大規模なデータプラットフォーム環境の複数のネットワークについて一体化された要求インタフェースの機能を達成し、システム間の依存状態を切り離し、モジュールに関するシステムの管理メカニズム機能を向上する。

本出願の実施形態で、図３のフィルタ構成要素およびハンドラ構成要素を、プラグインの方法でロード可能であることを理解するべきである。開発者は、必要に応じて、アクセス要求すなわち、ｈｔｔｐ要求に基づき、データ修正、認証、統計、圧縮、または他の機能を開発可能である。ユーザは、基本情報を提供することにより、フィルタ構成要素およびハンドラ構成要素のリンクを登録可能である。装置の電源が入れられるとき、システムは予め規定された機能を持つ構成要素を動的にロードする。

本出願の実施形態で、異なるサーバサイドにサポートされた通信プロトコルを一緒に取り扱えるように、装置はアクセス要求を汎用的な中間データ構造に変換する。汎用的なデータ構造は、種々の開発されたエンジン構成要素を用いることにより自動的に固定構造に変換可能であり、開発者は、特定のプロトコルをサポートするシステムを柔軟に開発可能である。ＮｇｉｎｘＬｕａの開発と異なり、本出願の実施形態では、フィルタ構成要素およびハンドラ構成要素内で複数のデータ構造を実行する必要がなく、その結果、開発サイクルが短縮される。同様に、ＮｇｉｎｘＬｕａの開発で必要であるようなデータ構造の詳細な理解の必要がなく、その結果、開発コストが減少される。

本出願の実施形態で、クライアントサイドはｈｔｔｐ／ｈｔｔｐｓ、ソケット、または（ＨＳＦおよびＰｒｏｔｏｂｕｆｆｅｒのような）ＲＰＣのようなプロトコルを用いてアクセス要求を提供してもよいことに注目すべきである。サーバサイドは、ＨＳＦ、Ｍｏｃｋ、およびＰｒｏｔｏｂｕｆｆｅｒのようなプロトコルをサポート可能である。クライアントサイドおよびサーバサイドはさらに他のプロトコルをサポート可能であり、本出願の実施形態でそれらに限定はなされない。

本出願の実施形態はＪａｖｅ言語で実施可能であることを、さらに注目すべきである。

任意選択的に、本出願の別の実施形態では、クライアントサイドがアクセス要求により必要とされるリソース情報をより迅速に取得可能なように、方法内で、図４に示されるように装置がアクセス要求内の対応する情報を取得した後に、ＵＲＬに基づいて、ＵＲＬパスに対応するサービスが存在するかどうか判断するステップをまず実行可能である。

ＵＲＬパスに対応するサービスが存在すると判断されるとき、アクセス要求に対応する前処理および認証が実行され、アクセス要求の認証が成功するとき、装置はパラメータ情報に基づいてアクセス要求の対象サービスタイプの判断のステップを実行する。

かかる特定のステップは、図２のステップ２２０のように実行可能であり、ここでは簡単にするためにさらなる記載はしない。

本出願の実施形態で、装置がＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうか判断するとき、またはパラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するときにおいて、ＵＲＬパスまたは対象サービスタイプに対応するサービスが存在しない場合、クライアントサイドを使用しているユーザがエラーの理由を認識可能なように、エラーの理由を示すエラー情報がクライアントサイドに返されることに注目すべきである。

本出願の実施形態によるアクセス要求変換方法を、図２から図４を参照して詳細に前述した。本出願の実施形態で提供される装置を、図５を参照して詳細に後述する。

図５は、本出願による装置の概略構造図である。図５に示されるように、装置は受信モジュール５１０、判断モジュール５２０、変換モジュール５３０、および送信モジュール５４０を有する。受信モジュール５１０は、クライアントサイドにより送信されたアクセス要求を受信するよう構成され、アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含む。

判断モジュール５２０は、ＵＲＬおよびパラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するよう構成される。

変換モジュール５３０は、対象サービスタイプに基づいてアクセス要求を変換するよう構成される。

送信モジュール５４０は、対象サービスタイプに基づいて変換されたアクセス要求を、対象サービスタイプに対応するサーバサイドへ送信するよう構成され、これにより、サーバサイドは、対象サービスタイプに基づいて変換されたアクセス要求に基づいて、結果情報を返す。

任意選択的に、本出願の他の実施形態として、判断モジュール５２０は、アクセス要求に対して予め規定された処理を実行し、予め規定された処理はアクセス要求の認証を含み、認証が成功しているとき、ＵＲＬおよびパラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するようさらに構成される。

任意選択的に、本出願の他の実施形態として、判断モジュール５２０は特に、アクセス要求内の認証パラメータ情報をトークンセンタのトークン情報とマッチングし、認証パラメータ情報がトークン情報と合致するとき、アクセス要求の認証が成功するよう構成される。

任意選択的に、本出願の他の実施形態として、判断モジュールは特に、ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうかを判断し、ＵＲＬパスに対応するサービスが存在するとき、パラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するよう構成される。

任意選択的に、本出願の他の実施形態として、判断モジュール５２０は、ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうかを判断し、アクセス要求の認証が成功しているとき、パラメータ情報に基づいてアクセス要求の対象サービスタイプを判断するよう構成される。

任意選択的に、本出願の他の実施形態として、受信モジュール５１０は、結果情報を受信するようさらに構成され、処理モジュールは結果情報を処理するようさらに構成され、送信モジュール５４０は、処理された結果情報をクライアントサイドへ送信するようさらに構成され、これにより、クライアントサイドは、処理された結果情報に基づいて対応する動作を実行する。

ここで処理は、データ修正、圧縮およびマスキングのうちいずれか１つまたは複数を含む。

任意選択的に、本出願の他の実施形態として、装置は、対象サービスタイプに基づいて、対象サービスタイプに対応しフェイルオーバ構成要素内に記録されたサーバサイドに対して問い合わせるよう構成された問い合わせモジュールをさらに有する。

本出願の実施形態で提供された装置に基づき、受信されたアクセス要求の対象サービスタイプがアクセス要求に基づいて判断され、アクセス要求が対象サービスタイプに対応するデータ構造に解析され、データ構造が対応するサーバサイドに提供され、よって大規模なデータプラットフォーム環境の複数のネットワークについて一体化された要求インタフェースの機能を達成し、システム間の依存状態を切り離し、モジュールに関するシステムの管理メカニズム機能を向上する。

本出願の実施形態で、図５に提示される装置のモジュールの前述および他の動作および／または機能を、図３の装置のモジュールを用いることにより実行可能であり、図２および図４の方法の対応するプロセスをそれぞれ実行可能であることに注目すべきであり、簡潔にするためそれらはここではさらに記載しない。

本明細書中に開示された実施形態と組み合わせて記載された例におけるユニットおよびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはコンピュータソフトウェアと電子ハードウェアの組み合わせで実行してもよいことを専門家はさらに理解すべきである。ハードウェアとソフトウェア間の互換性を明白に示すため、例の構成要素およびステップを前述では機能によって一般的に説明した。機能をハードウェアまたはソフトウェアの方法のどちらで実行するかは、技術的解決の特定の適用および設計の制約による。それぞれの特定の適用について、当業者は異なる方法を用いて記載された機能を実行してもよい。しかし、そのような実施は、本発明の範囲を超えると解釈されるべきではない。

本明細書中に開示された実施形態と組み合わせて記載された方法またはアルゴリズムのステップは、ハードウェア、プロセッサが実行するソフトウェアモジュール、または両方の組み合わせの使用により実行可能である。ソフトウェアモジュールは、ランダムアクセスメモリ（ＲＡＭ）、メモリ、読み出し専用メモリ（ＲＯＭ）、電気的にプログラム可能なＲＯＭ、電気的に消去可能プログラム可能なＲＯＭ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または技術的分野で公知のあらゆる形態の記憶媒体内に配置可能である。

前述の特定の実施態様は、さらに、本発明の目的、技術的解決策、および有益な効果を詳細に説明する。前述の記載は単に本発明の特定の実施方法であり、本発明の保護範囲の限定を意図しないことを理解するべきである。本発明の趣旨および原理内でなされたあらゆる修正、均等物の置換、改良などは、本発明の保護範囲内に入る。

Claims

クライアントサイドにより送信されたアクセス要求を受信するステップであって、前記アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含むステップと、
前記アクセス要求の対象サービスタイプを、前記ＵＲＬおよび前記パラメータ情報により判断するステップと、
前記アクセス要求を前記対象サービスタイプに基づいて変換するステップと、
前記対象サービスタイプに基づいて変換された前記アクセス要求に基づいて、サーバサイドが結果情報を返すように、前記対象サービスタイプに基づいて変換された前記アクセス要求を、前記対象サービスタイプに対応する前記サーバサイドに送信するステップと、を含む、
アクセス要求変換方法。
前記クライアントサイドにより送信されたアクセス要求を受信するステップの後、前記方法が、
前記アクセス要求に対して予め規定された処理を実行するステップであって、前記予め規定された処理が前記アクセス要求の認証を含むステップと、
前記認証が成功するとき、前記ＵＲＬおよび前記パラメータ情報に基づいて前記アクセス要求の前記対象サービスタイプを判断するステップと、をさらに含む、
請求項１に記載の方法。
前記アクセス要求の前記認証が、
前記アクセス要求内の認証パラメータ情報をトークンセンタのトークン情報とマッチングするステップであって、前記認証パラメータ情報が前記トークン情報と合致するとき前記アクセス要求の前記認証が成功するステップを含む、
請求項２に記載の方法。
前記アクセス要求の対象サービスタイプを前記ＵＲＬおよび前記パラメータ情報に基づいて判断するステップが、
前記ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうか判断するステップと、
前記ＵＲＬパスに対応するサービスが存在するとき、前記パラメータ情報に基づいて前記アクセス要求の前記対象サービスタイプを判断するステップとを含む、
請求項１から請求項３のうちのいずれかに記載の方法。
前記アクセス要求に対して予め規定された処理を実行するステップの前に、前記方法が、
前記ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうか判断し、前記アクセス要求の前記認証が成功するとき、前記パラメータ情報に基づいて前記アクセス要求の前記対象サービスタイプを判断するステップを含む、
請求項２に記載の方法。
前記方法が、
前記結果情報を受信するステップと、
前記結果情報を処理するステップと、
前記クライアントサイドが前記処理された結果情報に基づいて対応動作を実行するように、前記処理された結果情報を前記クライアントサイドへ送信するステップと、をさらに含む、
請求項１から請求項５のうちのいずれかに記載の方法。
前記処理が、データ修正、圧縮およびマスキングのうちのいずれか１つまたは複数を含む、請求項６に記載の方法。
前記対象サービスタイプに基づいて変換された前記アクセス要求を、前記対象サービスタイプに対応するサーバサイドに送信するステップの前に、前記方法が、
前記対象サービスタイプに基づいて、前記対象サービスタイプに対応し、かつフェイルオーバ構成要素内に記録された前記サーバサイドを問い合わせるステップをさらに含む、
請求項１に記載の方法。
クライアントサイドにより送信されたアクセス要求を受信するよう構成され、前記アクセス要求はユニフォームリソースロケータ（ＵＲＬ）およびパラメータ情報を含む、受信モジュールと、
前記アクセス要求の対象サービスタイプを、前記ＵＲＬおよび前記パラメータ情報に基づいて判断するよう構成された判断モジュールと、
前記アクセス要求を前記対象サービスタイプに基づいて変換するよう構成された変換モジュールと、
前記対象サービスタイプに基づいて変換された前記アクセス要求に基づいて、サーバサイドが結果情報を返すように、前記対象サービスタイプにより変換された前記アクセス要求を、前記対象サービスタイプに対応する前記サーバサイドへ送信するよう構成された送信モジュールと、を備える、
装置。
前記判断モジュールが、
前記アクセス要求に対して予め規定された処理を実行し、前記予め規定された処理が前記アクセス要求の認証を含み、
前記認証が成功するとき、前記ＵＲＬおよび前記パラメータ情報に基づいて前記アクセス要求の前記対象サービスタイプを判断するようさらに構成される、
請求項９に記載の装置。
前記判断モジュールが、
前記アクセス要求内の認証パラメータ情報をトークンセンタのトークン情報とマッチングするように特に構成され、
前記認証パラメータ情報が前記トークン情報と合致するとき前記アクセス要求の前記認証が成功する、
請求項１０に記載の装置。
前記判断モジュールが、
前記ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうかを判断し、
前記ＵＲＬパスに対応するサービスが存在するとき、前記パラメータ情報に基づいて前記アクセス要求の前記対象サービスタイプを判断するよう特に構成される、
請求項９から請求項１１のうちのいずれかに記載の装置。
前記判断モジュールが、
前記ＵＲＬに基づいてＵＲＬパスに対応するサービスが存在するかどうかを判断し、前記アクセス要求の前記認証が成功するとき、前記パラメータ情報に基づいて前記アクセス要求の前記対象サービスタイプを判断するよう構成される、
請求項１０に記載の装置。
前記受信モジュールが前記結果情報を受信するようさらに構成され、
前記処理モジュールが前記結果情報を処理するようさらに構成され、
前記送信モジュールが、前記クライアントサイドが前記処理された結果情報に基づいて対応動作を実行するように、前記処理された結果情報を前記クライアントサイドへ送信するようさらに構成される、
請求項９から請求項１３のうちのいずれかに記載の装置。
前記処理が、データ修正、圧縮およびマスキングのうちのいずれか１つまたは複数を含む、請求項１４に記載の装置。
前記装置が、前記対象サービスタイプに基づいて、前記対象サービスタイプに対応し、かつフェイルオーバ構成要素内に記録された前記サーバサイドに問い合わせを行うよう構成された問い合わせモジュールをさらに備える、請求項９に記載の装置。