(57)【特許請求の範囲】
【請求項１】
コンピュータに、
ネットワーク外からのアクセスを前記コンピュータについて選択的に許容する第１ネットワークに接続された情報処理システムに対するリクエストを、前記第１ネットワークとは異なる第２ネットワークに接続された端末装置から受信し、
前記リクエストを前記情報処理システムに送信した結果得られたレスポンスに、前記第１ネットワーク内のアクセス先を示す所在情報が含まれる場合、該所在情報から前記情報処理システムにアクセスする所在情報への変更を、前記変更を行う際の規則を定義する定義情報と前記レスポンスに含まれる所在情報の文字列とに基づいて行い、
変更された所在情報を含む前記レスポンスを前記端末装置に送信する、
処理を実行させ、
前記変更において、前記定義情報で定義される複数の文字列と前記レスポンスに含まれる所在情報の文字列とを先頭から順番に一致する検索を行い、前記定義情報で定義される前記複数の文字列のうち一致した先頭からの文字数が最も多い文字列を、変更する対象の文字列として特定する、
ことを特徴とする通信制御プログラム。
【請求項２】
前記コンピュータに、
前記変更された所在情報を含むリクエストを前記端末装置から受信し、
前記リクエストに含まれる前記所在情報を、前記第１ネットワーク内のアクセス先を示す所在情報に変更し、
変更された前記所在情報が示すアクセス先に前記リクエストを送信する、
処理を実行させることを特徴とする請求項１記載の通信制御プログラム。
【請求項３】
前記コンピュータに、
前記レスポンスに含まれる所在情報のうち、アクセス先を示す第１文字列の末尾に第２文字列が付加される場合、変更後の前記所在情報に前記第２文字列を付加する、
処理を実行させることを特徴とする請求項１記載の通信制御プログラム。
【請求項４】
前記コンピュータに、
前記定義情報に、前記レスポンスに含まれる所在情報を変更する定義がされており、且つ前記複数の文字列と前記レスポンスに含まれる所在情報とが一致しない場合、前記レスポンスに含まれる所在情報を変更しない、
処理を実行させることを特徴とする請求項１または３記載の通信制御プログラム。
【請求項５】
前記コンピュータに、
前記所在情報の変更を行う際の規則を定義する定義情報と前記リクエストに含まれる所在情報の文字列とに基づいて、前記リクエストに含まれる所在情報を前記情報処理システムにアクセスする所在情報に変更する、
処理を実行させることを特徴とする請求項２記載の通信制御プログラム。
【請求項６】
コンピュータが、
ネットワーク外からのアクセスを前記コンピュータについて選択的に許容する第１ネットワークに接続された情報処理システムに対するリクエストを、前記第１ネットワークとは異なる第２ネットワークに接続された端末装置から受信し、
前記リクエストを前記情報処理システムに送信した結果得られたレスポンスに、前記第１ネットワーク内のアクセス先を示す所在情報が含まれる場合、該所在情報から前記情報処理システムにアクセスする所在情報への変更を、前記変更を行う際の規則を定義する定義情報と前記レスポンスに含まれる所在情報の文字列とに基づいて行い、
変更された所在情報を含む前記レスポンスを前記端末装置に送信する、
処理を実行し、
前記変更において、前記定義情報で定義される複数の文字列と前記レスポンスに含まれる所在情報の文字列とを先頭から順番に一致する検索を行い、前記定義情報で定義される前記複数の文字列のうち一致した先頭からの文字数が最も多い文字列を、変更する対象の文字列として特定する、
ことを特徴とする通信制御方法。
【請求項７】
通信制御装置であって、
ネットワーク外からのアクセスを前記通信制御装置について選択的に許容する第１ネットワークに接続された情報処理システムに対するリクエストを、前記第１ネットワークとは異なる第２ネットワークに接続された端末装置から受信する通信部と、
前記リクエストを前記情報処理システムに送信した結果得られたレスポンスに、前記第１ネットワーク内のアクセス先を示す所在情報が含まれる場合、該所在情報から前記情報処理システムにアクセスする所在情報への変更を、前記変更を行う際の規則を定義する定義情報と前記レスポンスに含まれる所在情報の文字列とに基づいて行う変更部と、を備え、
前記変更部は、前記変更において、前記定義情報で定義される複数の文字列と前記レスポンスに含まれる所在情報の文字列とを先頭から順番に一致する検索を行い、前記定義情報で定義される前記複数の文字列のうち一致した先頭からの文字数が最も多い文字列を、変更する対象の文字列として特定し、
前記通信部は、変更された所在情報を含む前記レスポンスを前記端末装置に送信する、
ことを特徴とする通信制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御プログラム、通信制御方法および通信制御装置に関する。
【背景技術】
【０００２】
複数のサーバにより実現されるシステム（以下、業務システム）が、イントラネットワーク内で運用される場合がある。この場合、業務システムに対するアクセスは、イントラネットワーク内からのアクセスを前提とする。
【０００３】
このような業務システムにおいて、イントラネットワークとは異なる外部ネットワーク（例えば、インターネット）から業務システムに対してアクセスが行われる場合、例えば、ゲートウェイ等の中間サーバにより、アクセス制御が行われる。
【０００４】
関連する技術として、イントラネットに含まれる装置である内部装置と、イントラネットに含まれない外部装置の間の、インターネットを介した通信を仲介する技術が提案されている（例えば、特許文献１を参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−６９６２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
業務システムは、リクエストに対してレスポンスをアクセス元に対して送信する。送信されるレスポンスには、アクセス元に対して次にアクセスさせるアクセス先を示すUniform Resource Locator(URL)が含まれる場合がある。
【０００７】
この場合、レスポンスに含まれるＵＲＬは、業務システムが運用される所定のネットワークの内部からのアクセスについては有効である。
【０００８】
一方、レスポンスに含まれるＵＲＬは、外部のネットワークからのアクセスに対しては有効ではないため、中間サーバにより、該ＵＲＬに基づく外部ネットワークからのアクセスが拒否される。このため、外部ネットワークから業務システムに対してアクセスすることが難しくなる。
【０００９】
１つの側面として、本発明は、中間サーバを介した外部のネットワークからのアクセスを可能にすることを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様では、通信制御プログラムは、コンピュータに、ネットワーク外からのアクセスを前記コンピュータについて選択的に許容する第１ネットワークに接続された情報処理システムに対するリクエストを、前記第１ネットワークとは異なる第２ネットワークに接続された端末装置から受信し、前記リクエストを前記情報処理システムに送信した結果得られたレスポンスに、前記第１ネットワーク内のアクセス先を示す所在情報が含まれる場合、該所在情報から前記情報処理システムにアクセスする所在情報への変更を、前記変更を行う際の規則を定義する定義情報と前記レスポンスに含まれる所在情報の文字列とに基づいて行い、変更された所在情報を含む前記レスポンスを前記端末装置に送信する、処理を実行させ、前記変更において、前記定義情報で定義される複数の文字列と前記レスポンスに含まれる所在情報の文字列とを先頭から順番に一致する検索を行い、前記定義情報で定義される前記複数の文字列のうち一致した先頭からの文字数が最も多い文字列を、変更する対象の文字列として特定する。
【発明の効果】
【００１１】
１つの側面によれば、中間サーバを介した外部のネットワークからのアクセスを可能にすることができる。
【図面の簡単な説明】
【００１２】
【図１】業務システムを含むシステム全体構成の一例を示す図である。
【図２】中間サーバの一例を示す機能ブロック図である。
【図３】定義情報登録処理の一例を示すフローチャートである。
【図４】定義情報の一例を示す図である。
【図５】各種テーブルの一例を示す図である。
【図６】リクエストおよびレスポンスの処理の流れの一例を示すシーケンスチャート（その１）である。
【図７】モバイル端末から中間サーバに送信されるリクエストの一例を示す図である。
【図８】リクエストで指定されたＵＲＬを変更する処理の一例を示すフローチャートである。
【図９】リクエストで指定されたＵＲＬを変更する処理の具体例を示す図（その１）である。
【図１０】モバイル端末が受信するレスポンスおよびモバイル端末が送信するリクエストの一例を示す図である。
【図１１】リクエストおよびレスポンスの処理の流れの一例を示すシーケンスチャート（その２）である。
【図１２】リクエストで指定されたＵＲＬを変更する処理の具体例を示す図（その２）である。
【図１３】レスポンスで指定されたＵＲＬを変更する処理の一例を示すフローチャートである。
【図１４】レスポンスで指定されたＵＲＬを変更する処理の具体例を示す図である。
【図１５】リクエストおよびレスポンスの処理の流れの一例を示すシーケンスチャート（その３）である。
【図１６】リクエストで指定されたＵＲＬを変更する処理の具体例を示す図（その３）である。
【図１７】中間サーバのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、実施形態について説明する。図１は、実施形態のシステムの全体構成の一例を示す。図１の例において、業務システム１は、所定の業務を運用するシステムである。
【００１４】
業務システム１は、１または複数の業務サーバ２を含む。実施形態では、業務システム１は、複数の業務サーバ２を含むものとする。業務システム１に含まれる業務サーバ２は１つであってもよい。
【００１５】
各業務サーバ２は、所定の業務を運用するための各種の処理を実行するサーバである。各業務サーバ２により業務システム１が実現される。業務システム１は、情報処理システムの一例である。
【００１６】
複数の業務サーバ２は、物理的に異なるサーバであってもよいし、１台のサーバにより実現される仮想的な複数のサーバであってもよい。
【００１７】
定義情報データベース３は、業務システム１に対するリクエストおよびレスポンスに含まれるＵＲＬの変更を行う際の規則が定義された１または複数の定義情報を記憶する。
【００１８】
定義情報データベース３は、第１ネットワーク４と第２ネットワーク６との間に設置される。実施形態では、定義情報データベース３は、中間サーバ５と接続される。図１の例では、定義情報データベースは、「定義情報ＤＢ」と表記される。
【００１９】
業務システム１は、第１ネットワーク４と接続される。第１ネットワーク４は、例えば、企業内ネットワーク等のイントラネットワークであってもよい。この場合、業務システム１は、イントラネットワーク内に存在する。
【００２０】
中間サーバ５は、第１ネットワーク４と第２ネットワーク６との間に配置され、第１ネットワーク４と第２ネットワーク６との間の通信制御を行う。中間サーバ５は、通信制御装置またはコンピュータの一例である。
【００２１】
第１ネットワーク４と第２ネットワーク６とは異なるネットワークである。例えば、第２ネットワーク６は、インターネット網であってもよい。
【００２２】
第２ネットワーク６には、複数のモバイル端末７および管理端末８が接続される。モバイル端末７は、端末装置の一例である。該端末装置は、実施形態で例示される無線通信を行うモバイル端末であってもよいし、有線通信を行う固定式の端末であってもよい。また、第２ネットワーク６に接続されるモバイル端末７は１台であってもよい。
【００２３】
管理端末８は、中間サーバ５の管理を行う端末である。管理端末８は、該管理端末８を操作する操作者（例えば、管理者）の入力操作を受け付けて、受け付けた操作に関する情報を中間サーバ５に送信する。
【００２４】
実施形態では、業務システム１は、第１ネットワーク４内で利用されることを前提とする。例えば、第１ネットワーク４内の何らかの端末装置が業務システム１を利用する場合、該端末装置は、業務システム１に対してリクエスト（リクエストデータ）を送信する。
【００２５】
リクエストには、アクセス先を示すＵＲＬが含まれる。端末装置からのリクエストは、業務システム１のうち、リクエストで指定されたＵＲＬが示すアクセス先に対して送信される。業務システム１は、リクエストに対して、レスポンス（レスポンスデータ）をアクセス元の端末装置に送信する。ＵＲＬは所在情報の一例である。
【００２６】
レスポンスには、例えば、リクエストに対する応答結果（成功または失敗を示す結果）や所定の情報が含まれる場合がある。また、レスポンスには、端末装置に対して、再び業務システム１にアクセスさせるためのＵＲＬが含まれる場合がある。
【００２７】
例えば、業務システム１のうち、リクエストに対する処理を行った業務サーバ２が、該業務サーバ２とは異なる業務サーバ２に対してアクセスさせるためのＵＲＬをレスポンスに含める場合がある。
【００２８】
また、業務システム１の各業務サーバ２に対する負荷を分散させるために、リクエストに対する処理を行った業務サーバ２は、該業務サーバ２とは異なる業務サーバ２に対してアクセスさせるためのＵＲＬをレスポンスに含める場合がある。
【００２９】
なお、リクエストに対する処理を行った業務サーバ２が、自身の業務サーバ２にアクセスさせるためのＵＲＬをレスポンスに含めてもよい。
【００３０】
第１ネットワーク内４の端末装置は、レスポンスに上記のＵＲＬが含まれる場合、業務システム１のうち、該ＵＲＬが示すアクセス先にアクセスする。上記のＵＲＬは、第１ネットワーク４内で有効なＵＲＬであるため、第１ネットワーク内４の端末装置は、該ＵＲＬが示すアクセス先にアクセスすることができる。
【００３１】
実施形態では、第１ネットワーク４内だけではなく、第１ネットワーク４とは異なる第２ネットワーク６から業務システム１に対するアクセスも許容する。ただし、業務システム１のセキュリティの確保等のために、第２ネットワーク６から業務システム１に対するアクセスは、中間サーバ５が一括的に制御する。
【００３２】
図１の例では、複数のモバイル端末７が第２ネットワーク６に接続される。各モバイル端末７は、業務システム１に対して直接リクエストを送信するのではなく、中間サーバ５に対してリクエストを送信する。
【００３３】
中間サーバ５は、各モバイル端末７から受信したリクエストに基づいて、業務システム１にリクエストを送信する。また、中間サーバ５は、業務システム１からレスポンスを受信し、リクエストの送信元であるモバイル端末７にレスポンスを送信する。従って、中間サーバ５は、第２ネットワーク６からのアクセスを一括的に制御する。
【００３４】
上述したように、業務システム１は、再び業務システム１にアクセスさせるＵＲＬをレスポンスに含める場合がある。レスポンスに含まれるＵＲＬは、第１ネットワーク４内で有効なＵＲＬである。
【００３５】
中間サーバ５が第２ネットワーク６からのアクセスを一括的に制御するため、アクセス元のモバイル端末７は、レスポンスに含まれるＵＲＬが指定されたリクエストを中間サーバ５に対して送信する。
【００３６】
指定されたＵＲＬは、第１ネットワーク４内で有効なＵＲＬであり、第２ネットワーク６内で有効なＵＲＬではない。有効でないＵＲＬに基づくアクセスであるため、中間サーバ５は、モバイル端末７が送信したリクエストを拒否する。従って、業務システム１は、リクエストを受信しない。
【００３７】
実施形態の中間サーバ５は、第１ネットワーク４の外部からのアクセス制御を可能にするために、リクエストおよびレスポンスに含まれるＵＲＬの変更を行う。
【００３８】
次に、図２の例を参照して、中間サーバ５の一例について説明する。中間サーバ５は、通信部１１と制御部１２とゲートウェイ機能部１３とシステム連携部１４と変更部１５と記憶部１６とを含む。
【００３９】
通信部１１は、第１ネットワーク４および第２ネットワーク６を介した通信を行う。第１ネットワーク４を介した通信と第２ネットワーク６を介した通信とは異なる通信部（通信インタフェース）により実現されてもよい。
【００４０】
制御部１２は、各種の制御を行う。ゲートウェイ機能部１３は、第２ネットワーク６との間の通信の制御を行う。
【００４１】
例えば、ゲートウェイ機能部１３は、第２ネットワーク６からのアクセスに対して、認証等を行う。中間サーバ５が、第２ネットワーク６から業務システム１に対するアクセスを一括的に制御することで、業務システム１のセキュリティが確保される。
【００４２】
システム連携部１４は、業務システム１との間の通信制御を行う。例えば、ゲートウェイ機能部１３が第２ネットワーク６から送信されたリクエストについて認証を行った結果、認証に成功した場合に、システム連携部１４にその結果を通知する。システム連携部１４は、該結果に基づいて、業務システム１にリクエストを送信する制御を行ってもよい。
【００４３】
変更部１５は、第２ネットワーク６から受信したリクエストに含まれるＵＲＬおよび第１ネットワーク４から受信したレスポンスに含まれるＵＲＬを変更する。変更部１５は、ゲートウェイ機能部１３およびシステム連携部１４にそれぞれ含まれてもよい。
【００４４】
実施形態の変更部１５は、リクエストまたはレスポンスに含まれるＵＲＬと定義情報データベース３に記憶された定義情報とに基づいて、ＵＲＬを変更する。記憶部１６は、各種の情報を記憶する。
【００４５】
＜定義情報の一例＞
次に、定義情報の登録の一例について説明する。図３は、定義情報登録処理の一例を示すフローチャートである。管理端末８を操作する操作者（例えば、上述した管理者）は、定義情報を管理端末８に入力する。該管理端末８は、定義情報の入力を受け付ける（ステップＳ１）。
【００４６】
管理端末８は、第２ネットワーク６を介して、受け付けた定義情報を中間サーバ５に送信する（ステップＳ２）。中間サーバ５は、定義情報を定義情報データベース３に送信する（ステップＳ３）。
【００４７】
定義情報データベース３は、受信した定義情報を記憶する（ステップＳ４）。これにより、定義情報が定義情報データベース３に登録される。ステップＳ１乃至Ｓ４の処理が複数回実行されると、複数の定義情報が定義情報データベース３に登録される。
【００４８】
次に、図４の例を参照して、定義情報の一例について説明する。実施形態では、定義情報は、Application Programming Interface(API)に関する定義情報である。以下、ＡＰＩに関する定義をＡＰＩ定義と称することがある。
【００４９】
定義情報は、ＡＰＩ定義名とゲートウェイ定義とバックエンド定義とリソース定義との項目を含む。定義情報は、他の項目を含んでもよい。
【００５０】
ＡＰＩ定義名は、定義情報の名称を表す文字列である。ゲートウェイ定義は、ロケーションヘッダを変更するか否かを表す。
【００５１】
ロケーションヘッダは、レスポンスのヘッダ部分に含まれる情報であり、レスポンスの宛先に対して、次にアクセスさせるアクセス先のＵＲＬを示す。バックエンド定義は、業務システム１における最終的なアクセス先を定義する情報である。
【００５２】
バックエンド定義の項目は、バックエンド定義名とエンドポイントＵＲＬとの対応関係を規定する。エンドポイントＵＲＬは、業務システム１における最終的なアクセス先を示すＵＲＬである。
【００５３】
エンドポイントＵＲＬは、クライアント（実施形態では、モバイル端末７）が任意に指定することができる。図４の例では、エンドポイントＵＲＬの指定方法が「クライアント指定」である場合に、エンドポイントＵＲＬが任意に指定される。
【００５４】
また、バックエンド定義名において、パスの追加が指定される場合がある。バックエンド定義名に「追加するパス」が指定されている場合、指定されたパスが任意に指定されたエンドポイントＵＲＬに追加される。
【００５５】
リソース定義の項目では、受信したリクエストＵＲＬに含まれるリソースパスとバックエンド定義名との対応関係を規定する。リソースパスは、該ＵＲＬに含まれる文字列であり、バックエンド定義との関係を規定する。
【００５６】
実施形態では、定義情報は、各種のテーブルで規定される。各種テーブルの一例について、図５の例を参照して説明する。
【００５７】
ＡＰＩ定義テーブルは、「apiId」と「apiName」と「gatewayId」との項目を含む。「apiId」は、ＡＰＩを識別するIdentification(ID)である。「apiName」は、ＡＰＩの名称であり、上述したＡＰＩ定義名と対応する。
【００５８】
「gatewayId」はロケーションヘッダの変更の有無が指定されるゲートウェイ定義テーブルを検索する際にキーとなるＩＤである。「locationHeaderConvert」の値が「true」の場合は、レスポンスに含まれるロケーションヘッダの変更が行われ、「false」の場合は、該ロケーションヘッダの変更は行われない。
【００５９】
リソース定義テーブルは、「apiId」と「Path」と「backendId」との項目を含む。「Path」の項目は、上述したリソースパスを示す。「backendId」の項目は、バックエンド定義テーブルを検索する際にキーとなるＩＤである。
【００６０】
バックエンド定義テーブルは、「backendId」と「apiId」と「backendName」との項目を含む。「backendName」は、バックエンドの定義名を表す。
【００６１】
バックエンドパラメータテーブルは、「backendId」と「key」と「value」との項目を含む。「key」は「backendId」に対応する。１つの「backendId」に複数の「key」が対応することがある。「key」と「value」とは１対１で対応する。
【００６２】
図５の例に示される各テーブルにより、図４の例に示される定義情報が規定される。図４の例に示される定義情報は、図５の例で示される各種のテーブル以外の任意の手法で規定されてもよい。
【００６３】
＜リクエストおよびレスポンスの処理の流れを示す一例＞
次に、実施形態におけるリクエストおよびレスポンスの処理の流れについて説明する。図６の例に示されるように、モバイル端末７は、第２ネットワーク６を介して、中間サーバ５にリクエストを送信する（ステップＳ１１）。
【００６４】
モバイル端末７には予めアプリケーション（アプリケーションプログラム）が記憶されているものとする。モバイル端末７を操作する操作者（例えば、ユーザ）は、アプリケーションを起動して所定の操作を行う。
【００６５】
モバイル端末７は、該操作を受け付ける。モバイル端末７は、該操作に基づくリクエストを、中間サーバ５に送信する。該リクエストは、上記のアプリケーション起動後の最初のリクエストであるものとする。
【００６６】
図７は、モバイル端末７から中間サーバ５に送信されるリクエストの一例を示す。該リクエストにおいてＵＲＬが指定される。図７の例では、リクエストで指定されるＵＲＬは、エントリポイントＵＲＬとリソースパスとパススルーとを含む。このＵＲＬは、第２ネットワーク６では有効であるが、第１ネットワーク４では有効でないＵＲＬである。
【００６７】
エントリポイントＵＲＬは、業務システム１のうち利用するサービスのＵＲＬを指定する入り口のＵＲＬを示す。エントリポイントＵＲＬのうち、最後の「weather」が定義情報のＡＰＩ定義名を示す。
【００６８】
リクエストで指定されるＵＲＬには、エントリポイントＵＲＬに続いて、上述したリソースパスが記述される。また、リソースパスに続いて、パススルーが記述される。リソースパスは、第１文字列の一例であり、パススルーは、第２文字列の一例である。
【００６９】
パススルーは、例えば、業務サーバ２に実行させるクエリやアプリケーションプログラム等のパスを指定する情報である。
【００７０】
図６の例において、中間サーバ５は、リクエストを受信する（ステップＳ１２）。ゲートウェイ機能部１３は、リクエストを受信すると、該リクエストの認証等を行う。これにより、業務システム１のセキュリティの確保が図られる。
【００７１】
制御部１２は、リクエストで指定されたＵＲＬに含まれるリソースパスを抽出する（ステップＳ１３）。上述した例では、「weather」という文字列が抽出される。制御部１２は、定義情報データベース３から、ＡＰＩ定義名が「weather」である定義情報を取得する（ステップＳ１４）。
【００７２】
変更部１５は、リクエストで指定されたＵＲＬと取得された定義情報とに基づいて、ＵＲＬを変更する（ステップＳ１５）。ＵＲＬの変更について、図８および図９の例を参照して説明する。
【００７３】
図８は、リクエストで指定されたＵＲＬを変更する処理の一例を示すフローチャートである。変更部１５は、リクエストで指定されたＵＲＬのうちリソースパスを抽出する（ステップＳ１５−１）。
【００７４】
図９の例の場合、抽出されるリソースパスは「first」である。変更部１５は、抽出されたリソースパスに基づいて、エンドポイントＵＲＬを特定する（ステップＳ１５−２）。このために、変更部１５は、抽出されたリソースパス「first」と一致するリソース定義の項目を検索する。
【００７５】
図９の例の場合、リソースパス「first」と一致するバックエンド定義「weatherFirst」が検出される。
【００７６】
変更部１５は、バックエンド定義の中から、検出された「weatherFirst」と一致する項目を検索する。図９の例の場合、バックエンド定義名「weatherFirst」と一致する項目が検出される。
【００７７】
変更部１５は、検出されたバックエンド定義名に対応するエンドポイントＵＲＬを特定する。図９の例の場合、特定されるエンドポイントＵＲＬは「https://weather.com」である。これにより、抽出されたリソースパスに基づいて、エンドポイントＵＲＬが特定される。
【００７８】
変更部１５は、リクエストで指定されたＵＲＬを、上記のエンドポイントＵＲＬに変更する（ステップＳ１５−３）。変更部１５は、リクエストで指定されたＵＲＬにパススルーが含まれるかを判定する（ステップＳ１５−４）。
【００７９】
パススルーが含まれる場合（ステップＳ１５−４でＹＥＳ）、変更部１５は、特定されたエンドポイントＵＲＬにパススルーを付加する（ステップＳ１５−５）。該パススルーが含まれない場合（ステップＳ１５−４でＮＯ）、ステップＳ１５−５の処理は行われない。
【００８０】
図９の例の場合、リクエストはパススルー「xxx」を含む。変更部１５は、リクエストで指定されたＵＲＬを、上述したエンドポイントＵＲＬにパススルーを付加したＵＲＬに変更する。図９の例の場合、変更されたＵＲＬは、「https://weather.com/xxx」である。変更後のリクエストは、第１ネットワーク４内で有効なＵＲＬである。
【００８１】
次に、図６の例に示されるように、システム連携部１４は、変更後のＵＲＬが指定された、業務システム１に対するリクエストを作成する（ステップＳ１６）。
【００８２】
通信部１１は、第１ネットワーク４を介して、作成されたリクエストを業務システム１に送信する（ステップＳ１７）。該リクエストは、業務システム１のうち、リクエストで指定されたＵＲＬ（変更後のＵＲＬ）をアクセス先とした業務サーバ２に送信される。
【００８３】
リクエストを受信した業務サーバ２は、リクエストに対してレスポンスを中間サーバ５に送信する（ステップＳ１８）。業務サーバ２は、例えば負加分散や他の業務サーバ２に処理を行わせるために、リクエストの送信元に対して、再びリクエストを送信させる場合がある。
【００８４】
この場合、このレスポンスのボディまたはヘッダには、リクエストの送信元に対して次にアクセスさせるＵＲＬが含まれる。ステップＳ１８では、次にアクセスさせるＵＲＬは、レスポンスのボディに含まれるものとする。
【００８５】
中間サーバ５は、受信したレスポンスを、リクエストの送信元であるモバイル端末７に送信する（ステップＳ１９）。レスポンスを受信したモバイル端末７は、レスポンスのボディから上記のＵＲＬを抽出し、該抽出されたＵＲＬをヘッダに含めたリクエストを作成する（ステップＳ２１）。
【００８６】
例えば、図１０の例では、モバイル端末７が受信するレスポンスのボディには、次のアクセス先を示すＵＲＬ（図１０の例のターゲットＵＲＬ）に「https://weather01.com」が含まれる。モバイル端末７は、次のアクセス先を示すＵＲＬ「https://weather01.com」がヘッダに含まれるリクエストを作成する。
【００８７】
次に、モバイル端末７がレスポンスに応じたリクエストを送信する以降の処理について、図１１の例を参照して説明する。
【００８８】
図１１の例に示すように、モバイル端末７は、第２ネットワーク６を介して、作成されたリクエストを中間サーバ５に送信する（ステップＳ２２）。中間サーバ５は、リクエストを受信する（ステップＳ２３）。ゲートウェイ機能部１３は、上述したように、リクエストを受信すると、該リクエストの認証等を行う。
【００８９】
認証が成功した場合、ゲートウェイ機能部１３は、リクエストで指定されたＵＲＬのうち、エントリポイントＵＲＬを記憶部１６に記憶する。
【００９０】
中間サーバ５が受信するリクエストは、「https://host/api/tenant01/weather/real」であり、エントリポイントＵＲＬは「https://host/api/tenant01/weather」である。このエントリポイントＵＲＬが記憶部１６に記憶される。
【００９１】
制御部１２は、リクエストで指定されたＵＲＬに含まれるリソースパスを抽出する（ステップＳ２４）。上述したように、エントリポイントＵＲＬの末尾の文字列は「weather」であるため、該文字列が抽出される。
【００９２】
制御部１２は、定義情報データベース３から、ＡＰＩ定義名が「weather」である定義情報を取得する（ステップＳ２５）。変更部１５は、リクエストで指定されたＵＲＬと取得された定義情報とに基づいて、ＵＲＬを変更する（ステップＳ２６）。
【００９３】
ＵＲＬの変更について、図１２の例を参照して説明する。変更部１５は、リクエストで指定されたＵＲＬのうちリソースパスを抽出する。図１２の例の場合、リソースパスは「real」である。変更部１５は、取得した定義情報のうち、抽出されたリソースパスと一致するリソース定義の項目を検索する。
【００９４】
図１２の例の場合、リソース定義の中からリソースパス「real」と一致する項目が検出される。変更部１５は、検出されたリソース定義の項目に対応するバックエンド定義「weatherReal」を抽出する。
【００９５】
変更部１５は、バックエンド定義の中から、抽出された「weatherReal」と一致する項目を検索する。図８の例の場合、バックエンド定義名「weatherReal」と一致する項目が検出される。
【００９６】
バックエンド定義名「weatherReal」では、エンドポイントＵＲＬはクライアント指定として規定されている。エンドポイントＵＲＬがクライアント指定として規定される場合、エンドポイントＵＲＬは任意に指定できる。
【００９７】
実施形態では、リクエストのヘッダに含まれるＵＲＬがエンドポイントＵＲＬに指定されるものとする。図１２の例では、リクエストのヘッダには「https://weather01.com」が含まれる。このＵＲＬがエンドポイントＵＲＬに指定される。
【００９８】
また、定義情報のうち、バックエンド定義名「weatherReal」では、追加するパス「/tokyo」が指定されている。変更部１５は、上記のエンドポイントＵＲＬの末尾にパスを追加する。
【００９９】
変更部１５は、リクエストで指定されたＵＲＬを変更する。変更後のＵＲＬは、図１２の例に示されるように、上記のエンドポイントＵＲＬの末尾にパスが追加された「https://weather01.com/tokyo」である。変更後のＵＲＬは、定義情報に基づくＵＲＬであり、第１ネットワーク４内で有効なＵＲＬである。
【０１００】
図１１の例に示されるように、システム連携部１４は、変更後のＵＲＬが指定されたリクエストを作成する（ステップＳ２７）。このリクエストは、業務システム１に対するリクエストである。
【０１０１】
通信部１１は、第１ネットワーク４を介して、作成されたリクエストを業務システム１に送信する（ステップＳ２８）。リクエストは、業務システム１のうち、リクエストで指定されたＵＲＬをアクセス先とした業務サーバ２に送信される。
【０１０２】
リクエストを受信した業務サーバ２は、リクエストに対してレスポンスを中間サーバ５に送信する（ステップＳ２９）。業務サーバ２は、上述したように、リクエストの送信元に対して、再びリクエストを送信させる場合がある。
【０１０３】
この場合、レスポンスのヘッダまたはボディに、リクエストの送信元に対して、次にアクセスさせるＵＲＬが含まれる。ステップＳ２９では、次にアクセスさせるＵＲＬは、レスポンスのヘッダに含まれるロケーションヘッダで指定されるものとする。
【０１０４】
中間サーバ５の通信部１１は、業務サーバ２から送信されたレスポンスを受信し、変更部１５は、レスポンスのロケーションヘッダで指定されたＵＲＬを変更する（ステップＳ３０）。レスポンスのロケーションヘッダで指定されたＵＲＬの変更処理について、図１３および図１４の例を参照して説明する。
【０１０５】
図１３は、レスポンスのロケーションヘッダで指定されたＵＲＬの変更処理の流れの一例を示すフローチャートである。上述したように、中間サーバ５は、ＡＰＩ定義名が「weather」である定義情報を既に取得している。
【０１０６】
変更部１５は、定義情報のうちゲートウェイ定義の項目を参照し、ロケーションヘッダの変更が「true」であるかを判定する（ステップＳ３０−１）。ロケーションヘッダの変更が「ＮＯ」の場合（ステップＳ３０−１でＮＯ）、レスポンスに含まれるロケーションヘッダで指定されたＵＲＬの変更は行われない。
【０１０７】
ロケーションヘッダの変更が「true」の場合（ステップＳ３０−１でＹＥＳ）、変更部１５は、レスポンスに含まれるロケーションヘッダで指定されたＵＲＬを抽出する（ステップＳ３０−２）。
【０１０８】
例えば、図１４の例では、業務システム１から中間サーバ５へのレスポンスに含まれるロケーションヘッダで指定されたＵＲＬは「https://tokyo.weather.com/shinagawa」である。変更部１５は、このＵＲＬを抽出する。
【０１０９】
変更部１５は、バックエンドパラメータテーブルの「value」とロケーションヘッダで指定されたＵＲＬとの文字列を前方一致で比較する（ステップＳ２０−３）。つまり、変更部１５は、バックエンドパラメータテーブルの「value」の各文字列とロケーションヘッダで指定されたＵＲＬとの文字列とを先頭から順番に一致する検索を行う。
【０１１０】
変更部１５は、一致する文字列があるかを判定する（ステップＳ３０−４）。一致する文字列がない場合（ステップＳ３０−４でＮＯ）、定義情報のうちゲートウェイ定義においてロケーションヘッダの変更が「true」に設定されていたとしても、変更部１５は、ロケーションヘッダで指定されたＵＲＬを変更しない。
【０１１１】
一致する文字列がある場合（ステップＳ３０−４でＹＥＳ）、変更部１５は、一致する文字数が最も多い値を抽出する（ステップＳ３０−５）。
【０１１２】
図１４の例の場合、バックエンドパラメータテーブルの「value」のうち、２つの文字列「https://weather.com」および「https://tokyo.weather.com」と、上述したロケーションヘッダで指定されたＵＲＬとは「https://」の文字列が前方一致する。
【０１１３】
そして、上記の２つの文字列のうち「https://tokyo.weather.com」の文字列が、一致する文字数が最も多い。変更部１５は、文字列「https://tokyo.weather.com」を抽出する。
【０１１４】
変更部１５は、抽出された文字列「https://tokyo.weather.com」に基づいて、リソースパスを特定する（ステップＳ３０−６）。
【０１１５】
図１４の例の場合、抽出された文字列「https://tokyo.weather.com」に対応する「backendId」の値「88889999」がバックエンドパラメータテーブルから特定する。変更部１５はこの値をキーとして、リソース定義テーブルから「Path」を検索し、「tokyo」をリソースパスとして検出する。これにより、リソースパスが特定される。
【０１１６】
変更部１５は、記憶部１６に記憶されたエントリポイントＵＲＬを取得する（ステップＳ３０−７）。上述したように、制御部１２は、モバイル端末７から第２ネットワーク６を介してリクエストを受信した際に、リクエストで指定されたＵＲＬのうちエントリポイントＵＲＬを記憶部１６に記憶する。
【０１１７】
業務システム１からのレスポンスは、リクエストに応じたレスポンスであり、変更部１５は、該レスポンスに対応するリクエストで指定されたエントリポイントＵＲＬを記憶部１６から取得する。
【０１１８】
上述したように、中間サーバ５が、モバイル端末７から受信したリクエストで指定されたＵＲＬのうちエントリポイントＵＲＬは「https://host/api/tenant01/weather」である。変更部１５は、このエントリポイントＵＲＬを記憶部１６から取得する。
【０１１９】
変更部１５は、エントリポイントＵＲＬの末尾に、特定されたリソースパスを付加する（ステップＳ３０−８）。そして、変更部１５は、業務システム１からのレスポンスにパススルーが含まれているかを判定する（ステップＳ３０−９）。
【０１２０】
パススルーが含まれていない場合（ステップＳ３０−９でＮＯ）、パススルーは付加されない。パススルーが含まれている場合（ステップＳ３０−９でＹＥＳ）、変更部１５は、エントリポイントＵＲＬに付加されたリソースパスの末尾にパススルーを付加する。
【０１２１】
図１４の例の場合、業務システム１からのレスポンスに「/shinagawa」というパススルーが含まれる。従って、変更部１５は、このパススルーをリソースパスの末尾に付加する。これにより、図１４の例に示されるように、レスポンスのロケーションヘッダで指定されたＵＲＬの変更が行われる。
【０１２２】
変更後のＵＲＬは、第２ネットワーク６で有効なＵＲＬであり、第１ネットワーク４で有効なＵＲＬではない。ただし、変更後のＵＲＬは、モバイル端末７が、中間サーバ５を介して、業務システム１にアクセスすることが可能なＵＲＬである。これにより、モバイル端末７は、中間サーバ５を介して、業務システム１にアクセスすることができる。
【０１２３】
図１１の例に示されるように、中間サーバ５は、ロケーションヘッダで指定されたＵＲＬが変更された後、変更後のＵＲＬが指定されたロケーションヘッダを含むレスポンスを、第２ネットワーク６を介して、モバイル端末７に送信する（ステップＳ３１）。
【０１２４】
モバイル端末７は、該レスポンスを受信する（ステップＳ３２）。該レスポンスを受信した後の処理について、図１５のシーケンスチャートの例を参照して、説明する。
【０１２５】
モバイル端末７は、受信したレスポンスにロケーションヘッダが含まれる場合、該ロケーションヘッダで指定されたＵＲＬを宛先としたリクエストを作成し、第２ネットワーク６を介して、該リクエストを中間サーバ５に送信する（ステップＳ３１）。
【０１２６】
中間サーバ５は、該リクエストを受信する（ステップＳ３２）。ゲートウェイ機能部１３は、リクエストを受信すると、該リクエストの認証等を行う。制御部１２は、リクエストで指定されたＵＲＬに含まれるリソースパスを抽出する（ステップＳ３３）。
【０１２７】
制御部１２は、定義情報データベース３から、抽出したリソースパスに対応する定義情報を取得する（ステップＳ３４）。変更部１５は、リクエストで指定されたＵＲＬと取得された定義情報とに基づいて、ＵＲＬを変更する（ステップＳ３５）。ＵＲＬの変更について、図１６の例を参照して説明する。
【０１２８】
変更部１５は、リクエストで指定されたＵＲＬのうちリソースパスを抽出する。図１６の例の場合、リソースパスは「tokyo」である。変更部１５は、取得した定義情報のうち、抽出されたリソースパスと一致するリソース定義の項目を検索する。
【０１２９】
図１６の例の場合、リソース定義の中からリソースパス「tokyo」と一致する項目が検出される。変更部１５は、検出されたリソース定義の項目に対応するバックエンド定義「weatherTokyo」を抽出する。
【０１３０】
変更部１５は、バックエンド定義の中から、抽出された「weathertTokyo」と一致する項目を検索する。図１６の例の場合、バックエンド定義名「weatherTokyo」と一致する項目が検出される。
【０１３１】
変更部１５は、検出されたバックエンド定義名に対応するエンドポイントＵＲＬである「https://tokyo.weather.com」を抽出する。変更部１５は、リクエストで指定されたＵＲＬを、上記のエンドポイントＵＲＬに変更する。
【０１３２】
リクエストで指定されたＵＲＬにはパススルー「/shinagwa」が含まれる。変更部１５は、変更されたエンドポイントＵＲＬの末尾にパススルーを付加する。これにより、モバイル端末７から受信したＵＲＬは、図１６の例に示されるＵＲＬに変更される。
【０１３３】
ステップＳ３５のＵＲＬ変更処理は、図９および図１０で示した例と同様の処理である。変更後のＵＲＬは、第１ネットワーク４内で有効なＵＲＬである。
【０１３４】
リクエストで指定されたＵＲＬは、モバイル端末７が受信したレスポンスに含まれるロケーションヘッダで指定されたＵＲＬである。ロケーションヘッダで指定されたＵＲＬは、業務システム１から受信したレスポンスに含まれるロケーションヘッダで指定されたＵＲＬを変更部１５が変更したＵＲＬである。
【０１３５】
上述したように、変更部１５は、モバイル端末７が中間サーバ５を介して業務システム１にアクセスできるように、レスポンスに含まれるロケーションヘッダで指定されたＵＲＬを変更する。
【０１３６】
図１６の例の場合、「https://host/api/tenant01/weather/tokyo/shinagawa」にＵＲＬが変更される。変更部１５は、このＵＲＬに基づいて、リクエストで指定されたＵＲＬを、業務システム１にアクセス可能なＵＲＬ（第１ネットワーク４内で有効なＵＲＬ）に変更することができる。
【０１３７】
従って、中間サーバ５は、モバイル端末７から受信したリクエストを業務システム１に送信することができる。
【０１３８】
図１５の例に示されるように、システム連携部１４は、変更後のＵＲＬが指定された、業務システム１に対するリクエストを作成する（ステップＳ３６）。
【０１３９】
通信部１１は、第１ネットワーク４を介して、作成されたリクエストを業務システム１に送信する（ステップＳ３７）。リクエストは、業務システム１のうち、リクエストで指定されたＵＲＬをアクセス先とした業務サーバ２に送信される。
【０１４０】
リクエストを受信した業務サーバ２は、リクエストに対してレスポンスを中間サーバ５に送信する（ステップＳ３８）。このレスポンスのヘッダに、リクエストの送信元に対して、次にアクセスさせるＵＲＬが含まれる場合がある。
【０１４１】
この場合、変更部１５は、上述したステップＳ３０と同様の処理を行い、レスポンスのヘッダに含まれるＵＲＬを変更する（ステップＳ３９）。
【０１４２】
中間サーバ５はレスポンスを受信する。システム連携部１４はゲートウェイ機能部１３を制御して、受信したレスポンスを、リクエストの送信元であるモバイル端末７に送信する（ステップＳ４０）。モバイル端末７は、レスポンスを受信する（ステップＳ４１）。
【０１４３】
上述したように、業務サーバ２は、リクエストを受信した際に、アクセス元に対して、次にアクセスさせるアクセス先を示すＵＲＬをレスポンスに含める場合がある。このＵＲＬは、第１ネットワーク４内では有効であるが、第１ネットワーク４とは異なる第２ネットワーク６では有効ではない。
【０１４４】
業務システム１に対するセキュリティの観点等から、第２ネットワーク６からのアクセスに対しては、中間サーバ５がアクセス制御を行う。中間サーバ５は、業務システム１から、次のアクセス先のＵＲＬを示すレスポンスを受信した場合、レスポンスに含まれるＵＲＬの変更を行う。
【０１４５】
この際、中間サーバ５の変更部１５は、モバイル端末７が中間サーバ５を介して業務システム１にアクセスできるようにＵＲＬを変更する。
【０１４６】
これにより、モバイル端末７からレスポンスに基づくリクエストを中間サーバ５が受信した際、該リクエストを拒否することなく、レスポンスで指定された業務システム１のＵＲＬに対してリクエストを送信できる。
【０１４７】
また、中間サーバ５がＵＲＬの変更処理を行うため、業務システム１に対して、何らかの改変が行われなくても、モバイル端末７からレスポンスに基づくリクエストを中間サーバ５が受信した際、該リクエストが拒否されなくなる。
【０１４８】
＜中間サーバのハードウェア構成の一例＞
次に、図１７の例を参照して、中間サーバ５のハードウェア構成の一例を説明する。図１７の例に示すように、バス１００に対して、プロセッサ１１１とＲＡＭ１１２とＲＯＭ１１３と補助記憶装置１１４と媒体接続部１１５と通信インタフェース１１６とが接続されている。
【０１４９】
プロセッサ１１１は任意の処理回路である。プロセッサ１１１はＲＡＭ１１２に展開されたプログラムを実行する。実行されるプログラムとしては、実施形態の処理を行うプログラムを適用してもよい。ＲＯＭ１１３はＲＡＭ１１２に展開されるプログラムを記憶する不揮発性の記憶装置である。
【０１５０】
補助記憶装置１１４は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等を補助記憶装置１１４に適用してもよい。媒体接続部１１５は、可搬型記録媒体１１９と接続可能に設けられている。
【０１５１】
可搬型記録媒体１１９としては、可搬型のメモリや光学式ディスク（例えば、Compact Disc(CD)やDigital Versatile Disc(DVD)等）を適用してもよい。この可搬型記録媒体１１９に実施形態の処理を行うプログラムが記録されていてもよい。
【０１５２】
中間サーバ５のうち、通信部１１は、通信インタフェース１１６により実現されてもよい。記憶部１６は、ＲＡＭ１１２や補助記憶装置１１４等により実現されてもよい。
【０１５３】
制御部１２とゲートウェイ機能部１３とシステム連携部１４と変更部１５とは、与えられた通信制御プログラムをプロセッサ１１１が実行することにより実現されてもよい。
【０１５４】
ＲＡＭ１１２、ＲＯＭ１１３、補助記憶装置１１４および可搬型記録媒体１１９は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。
【０１５５】
＜その他＞
本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【符号の説明】
【０１５６】
１    業務システム
２    業務サーバ
３    定義情報データベース
４    第１ネットワーク
５    中間サーバ
６    第２ネットワーク
７    モバイル端末
８    管理端末
１１    通信部
１２    制御部
１３    ゲートウェイ機能部
１４    システム連携部
１５    変更部
１６    記憶部
１１１    プロセッサ
１１２    ＲＡＭ
１１３    ＲＯＭ
【図１】
0006575320.tif 000002
【図２】
0006575320.tif 000003
【図３】
0006575320.tif 000004
【図４】
0006575320.tif 000005
【図５】
0006575320.tif 000006
【図６】
0006575320.tif 000007
【図７】
0006575320.tif 000008
【図８】
0006575320.tif 000009
【図９】
0006575320.tif 000010
【図１０】
0006575320.tif 000011
【図１１】
0006575320.tif 000012
【図１２】
0006575320.tif 000013
【図１３】
0006575320.tif 000014
【図１４】
0006575320.tif 000015
【図１５】
0006575320.tif 000016
【図１６】
0006575320.tif 000017
【図１７】
0006575320.tif 000018