図7に、本実施の形態に係るシステム全体の模式図を示す。例えばイントラネットである社内ネットワーク9とインターネット1とはファイアウォール7を介して接続されている。インターネット1には、SaaSアプリケーション501を実行しているSaaSサーバ5と、本実施の形態において主要な処理を実施する外部中継サーバ3とが接続されている。SaaSアプリケーション501は、例えば商談管理アプリケーション513と、社内Webサービス(ここでは在庫管理サービス)を呼び出す、ユーザ企業によるカスタマイズコード511とを含む。また、SaaSサーバ5は、ユーザ企業の部門Aの商談情報を蓄積する部門A商談データベース(DB)51を管理しており、SaaSアプリケーション501の商談管理アプリケーション513はこの部門A商談DB51のデータを処理するようになっている。さらに、商談管理アプリケーション513を実行中、特定の場面においてカスタマイズコード511が実行され、当該カスタマイズコード511により在庫管理サービスも併せてユーザに提供されるようになる。なお、SaaSサーバ5は、1以上のコンピュータで実施され、商談管理サービス以外のサービスを提供する場合もある。
また、社内ネットワーク9には、部門Aのユーザが操作し且つWebブラウザを実行する複数の部門Aユーザ端末11と、本実施の形態の主要な処理を実施する内部中継サーバ13と、通常は社内ネットワーク9からでしか使用できない在庫管理サービスを提供する在庫管理システム15とが接続されている。
図8に、外部中継サーバ3の機能ブロック図を示す。外部中継サーバ3は、アクセス許可情報格納部31と、リクエスト受信部32と、Webサービス制御部33と、受信待機中パス一覧格納部38と、Webサービスリプライ送信部34と、Webサービスリクエスト受信部35と、アクセス要求処理部36と、リプライ送信部37とを有する。リクエスト受信部32は、内部中継サーバ13からリクエストを受信し、アクセス許可情報格納部31に格納されているデータを用いて処理を行い、Webサービス制御部33とアクセス要求処理部36とリプライ送信部37と連携する。リプライ送信部37は、アクセス要求処理部36とリクエスト受信部32と連携して内部中継サーバ13にレスポンスを送信する。また、Webサービス制御部33は、受信待機中パス一覧格納部38にデータを格納すると共にデータを読み出し、リクエスト受信部32及びアクセス要求処理部36と連携する。Webサービスリクエスト受信部35は、SaaSサーバ5からWebサービスリクエストを受信し、アクセス要求処理部36に出力する。Webサービスリプライ送信部34は、アクセス要求処理部36からWebサービスリクエストに対するレスポンスのデータを受信し、SaaSサーバに送信する。アクセス要求処理部36は、リクエスト受信部32、Webサービス制御部33、Webサービスリクエスト受信部35、Webサービスリプライ送信部34及びリプライ送信部37と連携して処理を実施する。
図9に、内部中継サーバ13の機能ブロック図を示す。内部中継サーバ13は、リクエスト受信部131と、リプライ送信部132と、ユーザ情報格納部133と、接続情報管理部134と、セッション一覧情報格納部135と、セッション管理部136と、外部インタフェース部137と、アクセス要求処理部138と、接続認証情報格納部139と、社内Webサービスインタフェース部140とを有する。リクエスト受信部131は、部門Aユーザ端末11からの中継セッション開始リクエストを受信し、接続情報管理部134に出力する。リプライ送信部132は、中継セッション開始リクエストに対応する応答を部門Aユーザ端末11に送信する。接続情報管理部134は、ユーザ情報格納部133に格納されているデータを用いて処理を行い、セッション管理部136と連携する。セッション管理部136は、セッション一覧情報格納部135に対してデータを格納すると共にデータを読み出し、接続情報管理部134、外部インタフェース部137及びアクセス要求処理部138と連携する。外部インタフェース部137は、外部中継サーバ3に対するインタフェースであり、リクエスト送信部1371及びリプライ受信部1372を有する。そして、外部インタフェース部137は、セッション管理部136とアクセス要求処理部138と連携する。アクセス要求処理部138は、接続認証情報格納部139に格納されているデータを用いて処理を行い、セッション管理部136と外部インタフェース部137と社内Webサービスインタフェース部140と連携する。社内Webサービスインタフェース部140は、社内システムの一例である在庫管理システム15に対するインタフェースであり、Webサービスリクエスト送信部1411とWebサービスリプライ受信部1412とを有する。そして、社内Webサービスインタフェース部140は、アクセス要求処理部138と連携する。
次に、図10乃至図13Bを用いて、図7に示したシステムの処理の概要を説明する。まず、企業の部門Aのユーザは、部門Aユーザ端末11を操作して、SaaSサーバ5にアクセスさせる(図10:ステップ(1))。例えばSaaSサーバ5のURIがsaasapps.comであるとすると、当該URIにリクエストを送信する。このリクエストに応答して、SaaSサーバ5のSaaSアプリケーション501は処理を開始する。上でも述べたように、SaaSアプリケーション501は、商談管理アプリケーション513の通常の処理ロジックに加えて、カスタマイズコード511を含んでおり、ここでは、カスタマイズコード511には、予め定められた中継URIであるhttp://myproxy.com/usr/usr1/zaikoに対して在庫管理のWebサービスを呼び出すコードが含まれるものとする。なお、インターネット1におけるDNS(Domain Name Server。図示せず。)には、この中継URIのドメインに対して外部中継サーバのIPアドレスが登録されているものとする。
図11の処理の説明に移行して、企業の部門Aのユーザは、部門Aユーザ端末11を操作して、内部中継サーバ13に対して、中継セッション開始リクエストを送信させる(図11:ステップ(2))。内部中継サーバ13は、中継セッション開始リクエストを受信すると、当該中継セッション開始リクエストを予め定められた中継URI”http://myproxy.com/usr/usr1/zaiko”についてのHTTPリクエストに変換する。そして、内部中継サーバ13は、このHTTPリクエストを外部中継サーバ3に送信して、中継セッション開始を外部中継サーバ3に指示する(ステップ(3))。外部中継サーバ3は、このHTTPリクエストを受信すると、このHTTPリクエストに対してレスポンスを返すことなく、SaaSサーバ5からの中継URI”http://myproxy.com/usr/usr1/zaiko”についてのリクエストを待機する(ステップ(4))。このようにファイアウォール内部から外部へリクエストを送信することによって、当該リクエストへのレスポンスとしてファイアウォール外部から内部にファイアウォールに遮断されることなくデータを送信することができるようになる。
図12の処理の説明に移行して、そしてSaaSサーバ5において、SaaSアプリケーション501のカスタマイズコード511が実行されるようになると、SaaSサーバ5は、所定の中継URI”http://myproxy.com/usr/usr1/zaiko”についてのHTTPリクエストを、社内Webサービス呼び出しとして、外部中継サーバ3に送信する(図12:ステップ(5))。外部中継サーバ3は、SaaSサーバ5から所定の中継URI”http://myproxy.com/usr/usr1/zaiko”についてのHTTPリクエストを受信すると、処理しても良いHTTPリクエストであるかを確認する。その上で外部中継サーバ3は、SaaSサーバ5からのHTTPリクエストを、内部中継サーバ13から受信した、中継セッション開始指示についてのHTTPリクエストに対するレスポンスに変換し、内部中継サーバ13に送信する(ステップ(6))。内部中継サーバ13は、外部中継サーバ3から、HTTPレスポンスの形式での、SaaSサーバ5からのHTTPリクエストを、在庫管理システム15に中継してもよいかその是非を判断する(ステップ(7))。例えば、SaaSサーバ5のIPアドレスなどから中継の是非を判断する。
図13Aの処理の説明に移行して、内部中継サーバ13は、SaaSサーバ5からのHTTPリクエストを中継しても良いと判断した場合には、在庫管理システム15に対するWebサービス呼び出しとしてHTTPリクエストを生成して、在庫管理システム15に送信する(ステップ(8))。在庫管理システム15は、内部中継サーバ13からのHTTPリクエストに応答して処理を実施して、処理結果をHTTPレスポンスとして内部中継サーバ13に返信する(ステップ(9))。内部中継サーバ13は、処理結果のレスポンスを、中継URI”http://myproxy.com/usr/usr1/zaiko”についてのHTTPリクエストに変換し、外部中継サーバ3に送信する(ステップ(10))。このように処理結果のレスポンスを、再度のHTTPリクエストの形式で外部中継サーバ3に出力する。
図13Bの処理の説明に移行して、外部中継サーバ3は、内部中継サーバ13から、社内Webサービスの処理結果を含むHTTPリクエストを受信すると、当該社内Webサービスの処理結果を含むHTTPレスポンスを生成して、ステップ(5)におけるHTTPリクエストに対するレスポンスとして、SaaSサーバ5に返信する(ステップ(11))。SaaSサーバ5におけるSaaSアプリケーション501は、外部中継サーバ3から社内Webサービスの処理結果を含むHTTPレスポンスを受信すると、当該社内Webサービスの処理結果を反映させたHTTPレスポンスを、ステップ(1)に対するレスポンスとして生成して、部門Aユーザ端末11に返信する(ステップ(12))。
このようにして、ファイアウォールの外部のSaaSサーバ5におけるSaaSアプリケーション501と、ファイアウォール内部の社内Webサービス提供システム(図では在庫管理システム15)とが連携できるようになり、両者の処理結果を反映させたデータをファイアウォール内部の部門Aユーザ端末11に届けることができるようになる。なお、ファイアウォール7の設定の変更は不要であり、セキュリティレベルを下げずに、このような効果を得ている。
なお、外部中継サーバ3は、内部中継サーバ13からHTTPリクエストを受信した状態であるから、中継待ちの状態となっており、SaaSサーバ5からの社内Webサービス呼び出しが必要となれば、応答することができる。
また、部門Aユーザ端末11のユーザが、例えばSaaSサーバ5からログオフする場合など、SaaSサーバ5で提供されるWebサービスの利用を終了する場合には、部門Aユーザ端末11のユーザは、部門Aユーザ端末11に対して、中継セッション中止リクエストを、内部中継サーバ13に送信させる。
内部中継サーバ13は、中継セッション中止リクエストに応答して、自らが保持する所定の中継URI”http://myproxy.com/usr/usr1/zaiko”についてのセッション情報を破棄すると共に、外部中継サーバ3に対しても受信待機中パスについてのデータを破棄させるためのメッセージを送信する。外部中継サーバ3は、内部中継サーバ13から上記のようなメッセージを受信すると、受信待機中パスについてのデータを破棄し、中継待ち受けの状態を脱する。なお、中継セッション中止リクエストを送信せずとも、例えば所定時間以上経過した場合には、内部中継サーバ13でも外部中継サーバ3でも、セッション情報や受信待機中パスについてのデータを破棄するようにすれば、中継待ち受けの状態を脱するようになる。
次に、図14乃至図42を用いて、図7に示したシステムの処理の詳細を説明する。最初に、図14乃至図17を用いて、部門Aユーザ端末11から中継セッション開始リクエストを受信する際の処理を説明する。最初に、例えばリクエスト受信部131は、部門Aユーザ端末11からのアクセスに応じて、例えばリクエストのためのデータの入力画面を表示させるWebページデータを送信する。部門Aユーザ端末11は、リクエスト受信部131から上で述べたようなWebページデータを受信し、表示装置に表示する。例えば図14に示すような画面が表示される。
図14の例では、内部中継サーバ13に対するユーザID及びパスワードの入力欄と、外部中継サーバ名と当該外部中継サーバ3に対するユーザID及びパスワードの入力欄と、社内WebサービスURIの入力欄と、Webサービス中継URIの入力欄と、アクセス許可ホスト名の入力欄とを含む。社内WebサービスURIは、例えば図7における在庫管理システム15のURIである。Webサービス中継URIは、内部中継サーバ13及び外部中継サーバ3でどの中継セッションであるかを特定するためのキーとなる中継URIである。
ユーザは、図14における画面の入力欄にデータを入力して開始ボタンをクリックし、部門Aユーザ端末11に対して中継セッション開始リクエストの送信指示を入力する。部門Aユーザ端末11は、中継セッション開始リクエストの送信指示を受け付け、入力されたデータを含む中継セッション開始リクエストを、内部中継サーバ13に送信する。
内部中継サーバ13のリクエスト受信部131は、部門Aユーザ端末11から中継セッション開始リクエストを受信し(図15:ステップS1)、接続情報管理部134に出力する。接続情報管理部134は、上で述べたようなデータを含む中継セッション開始リクエストを受信すると、受信したユーザIDでユーザ情報格納部133を検索して一致するパスワードを取得し、受信したパスワードと一致するかを判断する照合処理を実施する(ステップS3)。
ユーザ情報格納部133に格納されているデータの一例を図16に示す。図16の例では、例えば部門AのユーザのユーザIDと、パスワードとが登録されるようになっている。
一致する場合、すなわち照合成功の場合には、図14に示したデータをセッション管理部136に出力する(ステップS9)。セッション管理部136は、接続情報管理部134から受信したデータをセッション一覧情報格納部135に格納する。
セッション一覧情報格納部135には、例えば図17に示すようなデータが格納される。図17の例では、内部中継サーバ13に対するユーザIDと、社内WebサービスURIと、外部中継サーバ名と、Webサービス中継URIと、アクセス許可ホスト名と、外部中継サーバ3に対するユーザID及びパスワードとを登録するようになっている。このテーブルの一行分のデータを、セッション情報と呼ぶことにする。セッション管理部136は、このセッション情報を、外部インタフェース部137に出力する。
また、接続情報管理部134は、リプライ送信部132に中継セッション開始成功を表すレスポンスを部門Aユーザ端末11へ送信させる(ステップS11)。部門Aユーザ端末11は、リプライ送信部132から中継セッション開始成功を表すレスポンスを受信し、表示装置に表示する。ユーザは、中継セッション開始成功を認識することができる。
一方、ステップS3で照合に失敗すると(ステップS5:Noルート)、接続情報管理部134は、リプライ送信部132に、中継セッション開始失敗を、部門Aユーザ端末11へ送信させる(ステップS7)。部門Aユーザ端末11は、リプライ送信部132から中継セッション開始失敗を表すレスポンスを受信し、表示装置に表示する。ユーザは、中継セッション開始失敗、すなわちユーザIDとパスワードとの少なくともいずれかの入力を誤ったことを認識することができる。
以上のような処理を実施して、外部中継サーバ3への中継セッション開始通知の準備が完了する。なお、セッション情報については、ユーザ毎に内部中継サーバ13内に保持しておき、ユーザからの中継セッション開始リクエストに応じて、そのセッション情報を読み出すようにしても良い。
次に、図18及び図19を用いて、HTTPリクエストの送信処理(1回目)について説明する。内部中継サーバ13の外部インタフェース部137は、セッション管理部136からセッション情報を受信し(ステップS21)、メインメモリ等の記憶装置に格納しておく。このセッション情報は、外部中継サーバ3との通信で用いるセッションIDとソケットIDとのうち少なくともいずれかなどによって管理しておく。そして、リクエスト送信部1371及びリプライ受信部1372で共用する。又は、セッション情報のうち少なくともWebサービス中継URI等キーとなるデータと、セッションIDとソケットIDとのうち少なくともいずれかなどとを関連付けて保持しておく。
リクエスト送信部1371は、セッション情報から外部中継サーバ名を抽出し、今回送信するHTTPリクエストの宛先ホストに設定すると共に、宛先ホストの所定のパス(ここでは/control/index.html。予め保持しておく。)もHTTPリクエストのパス名として設定する(ステップS23)。
さらに、リクエスト送信部1371は、セッション情報から外部中継サーバ3に対するユーザID及びパスワードを抽出し、HTTPリクエストのAuthorizationフィールドに設定する(ステップS25)。また、リクエスト送信部1371は、セッション情報からWebサービス中継URIのパス部分を抽出し、HTTPリクエストのX-RelayURIフィールドに設定する(ステップS27)。そして、リクエスト送信部1371は、セッション情報からアクセス許可ホスト名を抽出し、X-AllowDomainフィールドに設定する(ステップS29)。このようにしてセッション情報からHTTPリクエストが生成されたことになる。そして、リクエスト送信部1371は、生成されたHTTPリクエストを外部中継サーバ3に送信する(ステップS31)。なお、リクエスト送信部1371は、リプライ受信部1372に対して、レスポンスの待機を指示する(ステップS33)。リプライ受信部1372は、上で述べたようにHTTPリクエスト送信時のセッションIDやソケットIDを保持しておき、今回送信したHTTPリクエストに対するHTTPレスポンスを識別できるようにする。
図19に、ステップS31で外部中継サーバ3に送信されるHTTPリクエストの一例を示す。図19の例では、POSTメソッドが定義されており、パス名には”/control/index.html”が設定されている。また、ホスト名には、外部中継サーバ3のホスト名”myproxy.com”が設定されている。Authorizationフィールドには、ユーザID及びパスワードを連結した上でBASE64でエンコードしたものが設定されている。X-RelayURIフィールドには、上で述べたように中継URIのパス部分”/usr/usr1/zaiko”が設定されており、X-AllowDomainフィールドにはアクセス許可ホスト名”saasapps.com”が設定されている。
このようにして最初のHTTPリクエストが内部中継サーバ13から外部中継サーバ3へ送信される。
次に、外部中継サーバ3におけるリクエスト受信処理について図20乃至図24を用いて説明する。外部中継サーバ3のリクエスト受信部32は、内部中継サーバ13からHTTPリクエストを受信し、メインメモリ等の記憶装置に格納すると共に、受信したHTTPリクエストのソケットから送信元のIPアドレス及びソケットIDを取得する(ステップS41)。さらに、リクエスト受信部32は、HTTPリクエストのヘッダからユーザID及びパスワードを抽出する(ステップS43)。そして、リクエスト受信部32は、送信元IPアドレス、ユーザID及びパスワードのセットがアクセス許可情報格納部31に格納されているアクセス許可情報に含まれるか確認する(ステップS45)。
図21に、アクセス許可情報格納部31に格納されるデータの一例を示す。図21の例では、送信元IPアドレスと、ユーザIDと、パスワードとを登録するようになっている。ステップS45では、いずれかのレコードのデータと、ステップS41及びS43で取得されたデータとが一致するか判断する。
そして、リクエスト受信部32は、アクセス許可情報にステップS41及びS43で取得されたデータが含まれる、すなわちアクセス許可ありであるか判断する(ステップS47)。許可がない場合には端子Aを介してステップS67に移行する。一方、アクセス許可ありと判断された場合、リクエスト受信部32は、HTTPリクエストのヘッダのX-RelayURIフィールドから中継URIのパス部分を抽出する(ステップS49)。そして、リクエスト受信部32は、Webサービス制御部33に、抽出された中継URIに該当するエントリを受信待機中パス一覧から取得するように依頼し、Webサービス制御部33から結果を取得する(ステップS51)。
受信待機中パス一覧格納部38に格納されている受信待機中パス一覧の一例を図22に示す。図22の例では、中継URIと、アクセス許可ホスト名と、外部中継サーバ3についてのユーザIDと、外部中継サーバ3についてのパスワードと、内部中継サーバ13に対する返信用ソケットIDと、SaaSサーバ5のWebサービスに対する返信用ソケットIDとが登録されるようになっている。特定のユーザについて最初のHTTPリクエストが外部中継サーバ3に送信された場合には、まだ受信待機中パス一覧にはエントリが存在しない。一方、2回目のHTTPリクエストが外部中継サーバ3に送信された場合には、既に同様のエントリが受信待機中パス一覧に登録されている。
リクエスト受信部32は、Webサービス制御部33からの処理結果に基づき、該当エントリが受信待機中パス一覧に存在するか判断する(ステップS53)。該当エントリが存在しない場合には、最初のHTTPリクエストであり、端子Bを介してステップS61に移行する。一方、該当エントリが存在する場合には、2回目以降のHTTPリクエストであり、端子Cを介してステップS55に移行する。2回目以降のHTTPリクエストについては、まだ実施されないので、ここでは、端子A及び端子B以降の処理を説明する。
図23の処理の説明に移行して、端子Aの後に、リクエスト受信部32は、リプライ送信部37にエラー情報を内部中継サーバ13へ送信させる(ステップS67)。以下、詳細な説明を省略するが、内部中継サーバ13では、エラー情報を受信すると、エラー情報を蓄積しておくと共に、管理者やユーザにメールその他の手法でエラー発生を通知する。
次に、端子Bの後に、リクエスト受信部32は、受信したHTTPリクエストのヘッダにおけるX-AllowDomainフィールドから、アクセス許可ホスト名を抽出する(ステップS61)。さらに、リクエスト受信部32は、Webサービス制御部33に、この中継URIについての待機指示を出力する(ステップS63)。Webサービス制御部33は、SaaSサーバ5から中継URIについてのリクエストを待機する状態になる。なお、アクセス要求処理部36も、SaaSサーバ5からのこの中継URIについてのリクエストを待機する。
さらに、リクエスト受信部32は、中継URIとアクセス許可ホスト名とユーザIDと内部中継サーバ13に対する返信用ソケットIDとを含む中継URIデータを出力して、受信待機中パス一覧格納部38に登録させる(ステップS65)。図24に、中継URIデータの一例を示す。図24の例では、内部中継サーバへの返信用ソケットIDと、ユーザID及びパスワードと、中継URIのパスと、アクセス許可ホスト名とが含まれる。Webサービス制御部33は、このような中継URIデータを、図22に示したテーブルに登録する。但し、この段階では、待機中であるから、SaaSサーバ5のWebサービスに対する返信用ソケットIDは登録されない。
このようにして、SaaSサーバ5からの社内Webサービスの呼び出しに係る、所定の中継URIについてのHTTPリクエストを待機する状態になる。
次に、図25乃至図27を用いて、SaaSサーバ5から所定の中継URIについてのHTTPリクエストを受信した際の処理を説明する。まず、外部中継サーバ3のWebサービスリクエスト受信部35は、SaaSサーバ5のSaaSアプリケーション501から、所定の中継URIについてのHTTPリクエストを受信する。このHTTPリクエストの一例を図25に示す。図25の例では、このHTTPリクエストのヘッダには、GETメソッドで、部門Aユーザ端末11のユーザについての中継URIのパス部分”/usr/usr1/zaiko”とパラメータ部分”?code=1256”とが含まれる。さらに、このHTTPリクエストのヘッダには、外部中継サーバ3のホスト名”myproxy.com”と、外部中継サーバ3に対する認証情報(ユーザID及びパスワードを連結した上でBASE64でエンコードしたもの)と、メッセージ・ボディの長さ”Content-Length:0”とが含まれている。
そして、アクセス要求処理部36は、Webサービスリクエスト受信部35からHTTPリクエスト自体、アクセス元(SaaSサーバ5)のIPアドレス及び当該受信HTTPリクエストのためのソケットのソケットID(SaaSサーバ5のWebサービスに対する返信用ソケットID)を取得する(図26:ステップS71)。
その後、アクセス要求処理部36は、Webサービス制御部33に、受信HTTPリクエストに含まれる中継URIで受信待機中パス一覧を検索させ(ステップS73)、該当エントリを読み出させる。なお、Webサービスに対する返信用ソケットIDが登録されていないエントリを抽出する。該当エントリがあれば、これでこの中継URIについての待機状態から復帰する。そして、アクセス要求処理部36は、Webサービス制御部33から結果を取得し、該当エントリが存在するか確認し(ステップS75)、該当エントリが存在しない場合には、端子Dを介してステップS91に移行する。該当エントリがない場合には中継できない。
一方、該当エントリが存在する場合には、アクセス要求処理部36は、DNSからアクセス元IPアドレスに対するホスト名を取得する(ステップS77)。そして、アクセス要求処理部36は、アクセス元のホスト名と該当エントリ内のアクセス許可ホスト名とが一致するか判断する(ステップS79)。不一致の場合には、中継できないので端子Dを介してステップS91に移行する。一方、アクセス元のホスト名と該当エントリ内のアクセス許可ホスト名とが一致する場合には、アクセス要求処理部36は、受信したHTTPリクエストのヘッダのAuthorizationフィールドから、ユーザID及びパスワードを抽出する(ステップS81)。
そして、アクセス要求処理部36は、抽出したユーザIDと該当エントリに含まれるユーザIDとが一致するか判断する(ステップS83)。一致しない場合には、端子Dを介してステップS91に移行する。一方、一致する場合には、端子Eを介して図27の処理に移行する。
図27の処理の説明に移行して、端子Eの後に、アクセス要求処理部36は、HTTPリクエストから抽出したユーザID及びパスワードが、該当エントリのユーザID及びパスワードと一致するか判断する(ステップS85)。一致しない場合にはステップS91に移行する。一方、一致する場合には、アクセス要求処理部36は、Webサービス制御部33に、受信待機中パス一覧の該当エントリに、ステップS41で取得されたWebサービスに対するソケットIDを、Webサービスに対する返信用ソケットIDとして登録させる(ステップS87)。これにて、社内Webサービスを提供する在庫管理システム15からレスポンスを受信した際に用いるデータが受信待機中パス一覧に用意されたことになる。
そして、アクセス要求処理部36は、リプライ送信部37に、内部中継サーバ13のためのソケットID(該当エントリにおける内部中継サーバ13に対する返信用ソケットID)と、受信したHTTPリクエストのデータを出力し、社内Webサービス呼び出しとしてHTTPレスポンスを内部中継サーバ13へ送信させる(ステップS89)。リプライ送信部37は、社内Webサービス呼び出しとしてのHTTPレスポンスを生成して、内部中継サーバ13へ送信する。具体的な処理については、図28及び図29を用いて説明する。
なお、端子Dの後には、アクセス要求処理部36は、Webサービスリプライ送信部34に、エラー通知をSaaSサーバ5へ返信するように指示する(ステップS91)。Webサービスリプライ送信部34は、指示に応じてエラー通知をSaaSサーバ5へ返信する。この処理については主要部ではないのでこれ以上述べない。
このような処理を行えば、SaaSサーバ5からの社内Webサービス呼び出しに対応する待機中の適切なHTTPリクエストを特定でき、このHTTPリクエストに対するHTTPレスポンスを生成できるようになる。
このHTTPレスポンスの生成及び送信についての外内リプライ送信処理について図28及び図29を用いて説明する。
リプライ送信部37は、アクセス要求処理部36から受信したデータに含まれるアクセス元のIPアドレスを、HTTPレスポンスのヘッダにおけるX-RequestHostフィールドに設定する(ステップS101)。また、リプライ送信部37は、受信したHTTPリクエストのデータに含まれるコマンド名(メソッド名)を、HTTPレスポンスのヘッダにおけるX-Commandフィールドに設定する(ステップS103)。さらに、リプライ送信部37は、受信したデータに含まれる中継URIのパスに付加されているパラメータをX-Argumentsフィールドに設定する(ステップS105)。また、リプライ送信部37は、受信したHTTPリクエストのヘッダの各フィールドを、X-OrigHeader-を前置して設定する(ステップS107)。最後に、リプライ送信部37は、このようにして生成されたHTTPレスポンスを、内部中継サーバ13に対する返信用ソケットIDを用いて、内部中継サーバ13へ送信する(ステップS109)。
例えば図29に示すようなHTTPレスポンスが生成される。図29の例では、HTTPレスポンスでは、SaaSサーバ5のIPアドレスがX-RequestHostフィールドに設定され、受信したHTTPリクエストのコマンド(メソッド)名がX-Commandフィールドに設定され、中継URIにおけるパラメータ”?code=1256”を例えばBASE64でエンコードした値をX-Argumentsフィールドに設定し、受信したHTTPリクエストに含まれる認証データをX-OrigHeader-の後に設定し、さらにメッセージボディのサイズをX-OrigHeaderフィールドに設定している。図29には含まれていないが、中継URIのパス自体を、このHTTPレスポンスに含めるようにしても良い。さらに、SaaSサーバ5からのHTTPリクエストに含まれた認証データについては含めないようにしても良い。
次に、図30乃至図37を用いて、内部中継サーバ13が、社内Webサービス呼び出しとしてのHTTPレスポンスを受信した際の処理について説明する。まず、リプライ受信部1372は、外部中継サーバ3からHTTPレスポンスを受信すると、そのHTTPレスポンスのソケットIDやセッションIDなどから、対応するHTTPリクエスト送信時のセッション情報を特定する(ステップS111)。なお、外部インタフェース部137が保持しているセッション情報を特定するか、当該ソケットID等と対応付けて保持している中継URI等のキーをセッション管理部136に出力して、セッション管理部136にセッション一覧情報格納部135から抽出させるようにしてもよい。リプライ受信部1372は、特定したセッション情報を、受信したHTTPレスポンスのデータと共にアクセス要求処理部138に出力する。ここでは、例えば図17の第1行目に相当する図31のようなセッション情報が特定されたものとする。
アクセス要求処理部138は、HTTPレスポンスのデータ及びセッション情報を取得すると、当該HTTPレスポンスのヘッダから、アクセス元のIPアドレスを抽出する(ステップS113)。そして、アクセス要求処理部138は、アクセス元のIPアドレスに対応するホスト名をDNSから取得し、抽出したIPアドレスに対応するホスト名と、セッション情報に含まれるアクセス許可ホスト名と一致するか判断する(ステップS115)。一致しない場合には、以後の処理を実施することはできないので、アクセス要求処理部138は、リクエスト送信部1371に、アクセス拒否通知を外部中継サーバ3へ送信させる(ステップS117)。そして端子Fを介して処理を終了する。
なお、例えばHTTPレスポンスに中継URIのパス名を含めておき、セッション情報に含まれる中継URIのパス名と比較するようにしても良い。
一方、抽出したIPアドレスに対応するホスト名とセッション情報に含まれるアクセス許可ホスト名とが一致する場合、アクセス要求処理部138は、セッション情報から社内WebサービスURI及びユーザIDを抽出する(ステップS119)。また、アクセス要求処理部138は、抽出された社内WebサービスURI及びユーザIDを用いて、接続認証情報から社内Webサービスに対するユーザID及びパスワードを抽出する(ステップS121)。例えば接続認証情報格納部139に格納されているデータの一例を図32に示す。図32の例では、ユーザIDと、社内WebサービスURIと、社内WebサービスのためのユーザID及びパスワードとが登録されるようになっている。なお、このデータは、予め内部中継サーバ13の管理者等によって登録しておく。
さらに、アクセス要求処理部138は、この処理において抽出されたデータ、HTTPレスポンスのヘッダ中のコマンド及びパラメータ等をWebサービスリクエスト送信部1411に出力して、社内Webサービスの呼び出しを行わせる(ステップS123)。そして、アクセス要求処理部138は、Webサービスリプライ受信部1412からのレスポンスを待機する(ステップS125)。ここまでが、外部中継サーバ3からHTTPレスポンスを受信した後に、在庫管理システム15などへHTTPリクエストを送信するまでの処理である。端子J以降の処理は、在庫管理システム15などからレスポンスを受信した後の処理であるので、後で説明する。
次に、図33を用いて、Webサービスリクエスト送信部1411の処理について説明する。Webサービスリクエスト送信部1411は、受信したHTTPレスポンスのヘッダにおけるX-Commandフィールドから、コマンド種別(メソッド種別)を取得し、送信すべきHTTPリクエストのヘッダに設定する(ステップS131)。また、Webサービスリクエスト送信部1411は、受信したHTTPレスポンスのヘッダにおけるX-Argumentsフィールドの値をBASE64でデコードして、URIに付加すべきパラメータを復元する(ステップS133)。そして、Webサービスリクエスト送信部1411は、受信した社内WebサービスURIのパスに、復元したパラメータを付加し、送信すべきHTTPリクエストのヘッダに設定する(ステップS135)。
また、Webサービスリクエスト送信部1411は、受信したHTTPレスポンスにX-OrigHeader-が前置されたフィールドがあれば、X-OrigHeader-を削除した上で、送信すべきHTTPリクエストヘッダに設定する(ステップS137)。さらに、Webサービスリクエスト送信部1411は、送信すべきHTTPリクエストのヘッダのHostフィールドに、社内Webサービスのホスト名(アクセス許可ホスト名)を設定する(ステップS139)。処理は端子Lを介して図34の処理に移行する。
図34の処理の説明に移行して、Webサービスリクエスト送信部1411は、受信した接続認証情報から、上で抽出されたユーザID及びパスワードを、BASE64でエンコードした上で、Authorizationフィールドに設定する(ステップS141)。ステップS137で、X-OrigHeader-を削除した場合にAuthorizationフィールドが出現するのであれば、値をステップS141でエンコードした値で上書きする。さらに、Webサービスリクエスト送信部1411は、受信したHTTPレスポンスのヘッダに付加されたデータ(メッセージボディのデータ)を、送信すべきHTTPリクエストのヘッダ以降に追加する(ステップS143)。
最後に、Webサービスリクエスト送信部1411は、このようにして生成されたHTTPリクエストを、在庫管理システム15に送信する(ステップS145)。
例えば図35のようなHTTPリクエストが生成される。SaaSサーバ5から送信されてくるHTTPリクエスト(図25)と比較すると、Authorizationフィールドの値以外は同一であり、内部中継サーバ13により、SaaSサーバ5が送信してきたHTTPリクエストを適切な形式で復元したことになる。このようにして、SaaSサーバ5による社内Webサービス呼び出しが、外部中継サーバ3及び内部中継サーバ13を介して行われたことになる。
社内Webサービスの一つである在庫管理システム15の処理内容については従来と同じであり、ここでは説明を省略する。ここでは、図36に示すようなHTTPレスポンスが、在庫管理システム15から送られてきて、Webサービスリプライ受信部1412がそのHTTPレスポンスを受信するものとする。図36の例では、HTTPレスポンスのヘッダに、XML(eXtensible Markup Language)によるメッセージボディが添付されている。
Webサービスリプライ受信部1412は、このHTTPレスポンスをアクセス要求処理部138に出力する。そうすると、図30の端子J以降の処理が実施される。
端子Jを介して図37の処理の説明に移行して、アクセス要求処理部138は、Webサービスリプライ受信部1412からHTTPレスポンスのデータを受信して、メインメモリ等の記憶装置に格納する(ステップS151)。そして、アクセス要求処理部138は、受信したHTTPレスポンスのデータ及び当該HTTPレスポンスに対応するHTTPリクエストについて該当するセッション情報を、外部インタフェース部137に出力する(ステップS153)。
次に、図38乃至図40を用いて、社内WebサービスからのHTTPレスポンスをHTTPリクエストとして外部中継サーバ3に送信する際の処理について説明する。この処理の一部は図18と同じである。
内部中継サーバ13の外部インタフェース部137は、アクセス要求処理部138からセッション情報を受信し(ステップS161)、メインメモリ等の記憶装置に格納しておく。このセッション情報は、外部中継サーバ3との通信で用いるセッションIDとソケットIDとのうち少なくともいずれかなどによって管理しておく。そして、リクエスト送信部1371及びリプライ受信部1372で共用する。又は、セッション情報のうち少なくともWebサービス中継URI等キーとなるデータと、セッションIDとソケットIDとのうち少なくともいずれかなどとを関連付けて保持しておく。
リクエスト送信部1371は、セッション情報から外部中継サーバ名を抽出し、今回送信するHTTPリクエストの宛先ホストに設定すると共に、宛先ホストの所定のパス(ここでは/control/index.html)もHTTPリクエストのパス名として設定する(ステップS163)。
さらに、リクエスト送信部1371は、セッション情報から外部中継サーバ3に対するユーザID及びパスワードを抽出し、HTTPリクエストのAuthorizationフィールドに設定する(ステップS165)。また、リクエスト送信部1371は、セッション情報からWebサービス中継URIのパス部分を抽出し、HTTPリクエストのX-RelayURIフィールドに設定する(ステップS167)。そして、リクエスト送信部1371は、セッション情報からアクセス許可ホスト名を抽出し、X-AllowDomainフィールドに設定する(ステップS169)。処理は端子Gを介して図39の処理に移行する。
図39の処理の説明に移行して、リクエスト送信部1371は、受信したHTTPリクエストのヘッダを、X-OrigHeader-を前置して、送信すべきHTTPリクエストのヘッダに設定する(ステップS171)。さらに、リクエスト送信部1371は、受信したHTTPリクエストに添付されているデータ部分(メッセージボディ部分)を、送信すべきHTTPリクエストのヘッダの後ろに追加する(ステップS173)。このようにしてセッション情報及び在庫管理システム15からのHTTPレスポンスからHTTPリクエストが生成されたことになる。
そして、リクエスト送信部1371は、生成されたHTTPリクエストを外部中継サーバ3に送信する(ステップS175)。なお、リクエスト送信部1371は、リプライ受信部1372に対して、レスポンスの待機を指示する(ステップS177)。リプライ受信部1372は、上で述べたようにHTTPリクエスト送信時のセッションIDやソケットIDを保持しておき、今回送信したHTTPリクエストに対するHTTPレスポンスを識別できるようにする。
図40に、ステップS175で外部中継サーバ3に送信されるHTTPリクエストの一例を示す。図40の例では、POSTメソッド(コマンド)が定義されており、パス名は”/control/index.html”が設定されている。また、ホスト名には、外部中継サーバ3のホスト名”myproxy.com”が設定されている。Authorizationフィールドには、ユーザID及びパスワードを連結した上でBASE64でエンコードしたものが設定されている。X-RelayURIフィールドには、上で述べたように中継URIのパス部分”/usr/usr1/zaiko”が設定されており、X-AllowDomainフィールドにはアクセス許可ホスト名”saasapps.com”が設定されている。さらに、HTTPレスポンスには、Dateフィールドが存在していたので、X-OrigHeader-が前置されているが、Dateフィールドのデータも設定されている。さらに、HTTPレスポンスのボディのデータも、HTTPリクエストのボディに設定されている。
このようにして社内WebサービスのレスポンスであるHTTPリクエストが内部中継サーバ13から外部中継サーバ3へ送信される。
外部中継サーバ3のリクエスト受信部32は、HTTPリクエストを内部中継サーバ13から受信して、図20及び図23の処理を実施する。図20及び図23の一部については最初のHTTPリクエスト受信時と同じ処理であるが、再度図40のHTTPリクエストを受信したものとして説明する。
外部中継サーバ3のリクエスト受信部32は、内部中継サーバ13からHTTPリクエストを受信し、受信したHTTPリクエストのソケットから送信元のIPアドレス及びソケットIDを取得する(ステップS41)。さらに、リクエスト受信部32は、HTTPリクエストのヘッダからユーザID及びパスワードを抽出する(ステップS43)。そして、リクエスト受信部32は、送信元IPアドレス、ユーザID及びパスワードのセットがアクセス許可情報格納部31に格納されているアクセス許可情報に含まれるか確認する(ステップS45)。
そして、リクエスト受信部32は、アクセス許可情報にステップS41及びS43で取得されたデータが含まれる、すなわちアクセス許可ありであるか判断する(ステップS47)。許可がない場合には端子Aを介してステップS67に移行する。一方、アクセス許可ありと判断された場合、リクエスト受信部32は、HTTPリクエストのヘッダのX-RelayURIフィールド及びHostフィールドから中継URIを抽出する(ステップS49)。そして、リクエスト受信部32は、Webサービス制御部33に、抽出された中継URIに該当するエントリを受信待機中パス一覧から取得するように依頼し、Webサービス制御部33から結果を取得する(ステップS51)。
リクエスト受信部32は、Webサービス制御部33からの処理結果に基づき、該当エントリが受信待機中パス一覧に存在するか判断する(ステップS53)。2度目のHTTPリクエストであるから、今回は通常であれば該当エントリが存在する。該当エントリが存在する場合には、2回目以降のHTTPリクエストであり、端子Cを介してステップS55に移行する。
図23の処理の説明に移行して、端子Cの後に、リクエスト受信部32は、抽出されたエントリのユーザIDとHTTPリクエストのヘッダから抽出されたユーザIDが一致するか判断する(ステップS55)。一致しない場合には、何らかの問題が発生したということで、ステップS67に移行する。
一方、抽出されたエントリのユーザIDとHTTPリクエストのヘッダから抽出されたユーザIDが一致する場合には、リクエスト受信部32は、さらに抽出されたエントリにWebサービスのためのソケットIDが設定されているか判断する(ステップS57)。このソケットIDが設定されていないと、SaaSサーバ5にレスポンスを返すことができないので、このソケットIDが設定されていない場合には、ステップS67に移行する。
このソケットIDがエントリに設定されている場合には、リクエスト受信部32は、HTTPリクエストのデータを含むリクエスト応答指示をアクセス要求処理部36に出力する(ステップS59)。これによって、SaaSサーバ5への応答を送信する準備に入る。
さらに、リクエスト受信部32は、受信したHTTPリクエストのヘッダにおけるX-AllowDomainフィールドから、アクセス許可ホスト名を抽出する(ステップS61)。また、リクエスト受信部32は、Webサービス制御部33に、待機指示を出力する(ステップS63)。Webサービス制御部33は、SaaSサーバ5から中継URIについてのリクエストを待機する状態になる。なお、アクセス要求処理部36も、SaaSサーバ5からのこの中継URIについてのリクエストを待機する。
さらに、リクエスト受信部32は、中継URIとアクセス許可ホスト名とユーザIDと内部中継サーバ13に対する返信用ソケットIDとを含む中継URIデータを出力して、Webサービス制御部33に受信待機中パス一覧格納部38へ登録させる(ステップS65)。この段階で、Webサービスに対する返信用ソケットIDが登録されていないエントリと登録されているエントリのほぼ同一の2つのエントリが登録されることになる。
このようにして、アクセス要求処理部36に処理を要求した上で、SaaSサーバ5のSaaSアプリケーション501からの次のHTTPリクエストを待機する状態になる。
なお、ステップS55及びS57でエラーを検出した場合及び端子Aの後に、リクエスト受信部32は、リプライ送信部37にエラー情報を内部中継サーバ13へ送信させる(ステップS67)。
次に、図41及び図42を用いて、外部中継サーバ3からSaaSサーバ5へHTTPレスポンスを送信するための処理について説明する。アクセス要求処理部36は、リクエスト受信部32からHTTPリクエストデータを受信し、メインメモリ等の記憶装置に格納する(ステップS181)。そして、アクセス要求処理部36は、受信したHTTPリクエストのヘッダにおけるX-RelayURIフィールドから中継URIのパスを抽出すると共に、ホスト名をも抽出する(ステップS183)。また、アクセス要求処理部36は、Webサービス制御部33に、受信待機中パス一覧において、抽出された中継URIのパス+ホスト名を中継URIとして含み且つWebサービスのためのソケットIDが登録済みのエントリが存在するか判断させる(ステップS185)。Webサービス制御部33は、指示に従って受信待機中パス一覧格納部38を検索して、該当エントリがあればアクセス要求処理部36に出力し、該当エントリがなければ該当エントリがない旨をアクセス要求処理部36に出力する。
アクセス要求処理部36は、Webサービス制御部33からの結果を受信して、該当エントリが存在するか判断する(ステップS187)。該当エントリが存在しない場合には、何らかのエラーが発生しているので、アクセス要求処理部36は、受信したHTTPリクエストのデータを破棄する(ステップS189)。そして、端子Iを介して本処理を終了する。
一方、該当するエントリが存在する場合には、アクセス要求処理部36は、受信待機中パス一覧内の該当エントリからWebサービスのためのソケットIDを抽出する(ステップS191)。また、アクセス要求処理部36は、受信したHTTPリクエストのヘッダ中のX-OrigHeader-が前置されているフィールドの名前及びその値を抽出し、送信すべきHTTPレスポンスのヘッダのフィールドとして設定する(ステップS193)。処理は、端子Hを介して図42の処理に移行する。
図42の処理の説明に移行して、端子Hの後に、アクセス要求処理部36は、受信したHTTPリクエストのヘッダ以降のデータを、送信すべきHTTPレスポンスのデータ(メッセージボディのデータ)として設定する(ステップS195)。そして、アクセス要求処理部36は、Webサービスリプライ送信部34に、WebサービスのためのソケットIDを用いて、生成されたHTTPレスポンスをSaaSサーバ5へ送信するように指示する(ステップS197)。Webサービスリプライ送信部34は、生成されたHTTPレスポンスのデータを受信して、同じく受信したWebサービスのためのソケットIDを用いて、SaaSサーバ5へHTTPレスポンスを返信する。なお、ここで送信されるHTTPレスポンスは、図36に示したHTTPレスポンスと同じである。図36は、在庫管理システム15から受信したHTTPレスポンスであり、これによって外部中継サーバ3においてHTTPレスポンスが復元されて、SaaSサーバ5へ送信されたことになる。SaaSサーバ5では、あたかも直接社内Webサービスからのレスポンスを受信したように見えるため、そのまま処理を行うことができる。
なお、アクセス要求処理部36は、Webサービス制御部33に、受信待機中パス一覧から、今回用いたエントリを削除するように指示する(ステップS199)。Webサービス制御部33は、アクセス要求処理部36からの指示に応じて、該当エントリを受信待機中パス一覧格納部38から削除する。
以上のような処理を実施することによって、ファイアウォール外部からファイアウォール内部のWebサービスを利用することができるようになる。よって、SaaSサーバ5の利用拡大が期待される。
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、外部中継サーバ3及び内部中継サーバ13の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。また、SaaSサーバ5で提供されるWebサービスと社内Webサービスとの組み合わせは、任意であって上で述べたものは一例に過ぎない。さらに、処理フローについても、処理結果が変わらない限りステップの順番を入れ替えたり、並列に実行するようにすることもできる。例えばヘッダの設定順番はHTTPの定義に従っている限りにおいては特に問題はない。
なお、上で述べた外部中継サーバ3及び内部中継サーバ13並びに他のサーバなどは、コンピュータ装置であって、図43に示すように、メモリ2501とプロセッサ(CPU2503)とハードディスク・ドライブ(HDD)2505と表示装置2509に接続される表示制御部2507とリムーバブル・ディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施例における処理を実施するためのアプリケーション・プログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。必要に応じてCPU2503は、表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ2501に格納され、必要があればHDD2505に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウエアとOS及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
以上述べた本実施の形態をまとめると、以下のようになる。
本実施の形態における第1の態様に係る中継処理方法は、ファイアウォール内部に設置され且つファイアウォール外部の第1中継サーバと協働してファイアウォール外部の第1のサービス提供サーバとファイアウォール内部の第2のサービス提供サーバとを連携させる第2中継サーバにより実行される中継処理方法である。この中継処理方法は、(A)第1のサービス提供サーバに対して処理を要求する端末から第1のサービス提供サーバを第2のサービス提供サーバと連携させるためのリクエストを受信するステップと、(B)リクエストに応答して、所定の中継URI(Uniform Resource Identifier)についての第1HTTP(Hyper Text Transfer Protocol)リクエストをファイアウォールを介して第1中継サーバに送信するステップと、(C)第1中継サーバから、第1HTTPリクエストに対するHTTPレスポンスとして第1のサービス提供サーバからの処理リクエストを受信するステップと、(D)処理リクエストを第2のサービス提供サーバに対する第2のリクエストに変換して、当該第2のサービス提供サーバに送信するステップと、(E)第2のサービス提供サーバから、第2のリクエストに対する応答データを受信するステップと、(F)応答データを、第1のサービス提供サーバへのレスポンスのための第2HTTPリクエストに変換し、第1中継サーバに送信するステップとを含む。
このようにすればファイアウォールによって通常であれば利用することができないファイアウォール内部の第2のサービス提供サーバを、ファイアウォール外部の第1のサービス提供サーバから利用できるようになる。
なお、上で述べた第2HTTPリクエストが、所定の中継URIについてのHTTPリクエストである場合もある。このようにすれば、さらに連続して第1のサービス提供サーバからファイアウォール内部の第2のサービス提供サーバにリクエストを送信する場合にも対処できるようになる。
本実施の形態における第2の態様に係る中継処理方法は、ファイアウォール外部に設置され且つファイアウォール内部の第1中継サーバと協働してファイアウォール外部の第1のサービス提供サーバとファイアウォール内部の第2のサービス提供サーバとを連携させる第2中継サーバにより実行される中継処理方法である。この中継処理方法は、(A)第1中継サーバから所定の中継URI(Uniform Resource Identifier)についての第1HTTP(Hyper Text Transfer Protocol)リクエストをファイアウォールを介して受信するステップと、(B)第1HTTPリクエストの受信に応答して、所定の中継URIについての第2HTTPリクエストを第1のサービス提供サーバから受信するのを待機するステップと、(C)所定の中継URIについての第2HTTPリクエストを第1のサービス提供サーバから受信するステップと、(D)第2HTTPリクエストの受信に応答して、当該第2HTTPリクエストを第1HTTPリクエストに対する第1のHTTPレスポンスに変換して、第1中継サーバに送信するステップと、(E)第1中継サーバから、第2HTTPリクエストへのレスポンスのためのデータを含む第3HTTPリクエストを受信するステップと、(F)第3HTTPリクエストの受信に応答して、当該第3HTTPリクエストに含まれるレスポンスのためのデータを用いて、第2HTTPリクエストへのレスポンスである第2のHTTPレスポンスを生成し、第1のサービス提供サーバに送信するステップとを含む。
このようにすればファイアウォールの設定を変更することなく、ファイルウォール外部の第1のサービス提供サーバからファイアウォール内部の第2のサービス提供サーバを利用することができるようになる。
なお、上で述べた第3HTTPリクエストが、所定の中継URIについてのHTTPリクエストである場合もある。その場合、第3HTTPリクエストの受信に応答して、所定の中継URIについての第4HTTPリクエストを第1のサービス提供サーバから受信するのを待機するステップをさらに含むようにしてもよい。1回だけではなく複数回ファイアウォール外部の第1のサービス提供サーバからファイアウォール内部の第2のサービス提供サーバへアクセスする場合に有用である。
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、CD−ROM、光磁気ディスク、半導体メモリ(例えばROM)、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、RAM等の記憶装置に一時保管される。
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
(付記1)
ファイアウォール内部に設置され且つファイアウォール外部の第1中継サーバと協働して前記ファイアウォール外部の第1のサービス提供サーバと前記ファイアウォール内部の第2のサービス提供サーバとを連携させる第2中継サーバにより実行される中継処理方法であって、
前記第1のサービス提供サーバに対して処理を要求する端末から前記第1のサービス提供サーバを前記第2のサービス提供サーバと連携させるためのリクエストを受信するステップと、
前記リクエストに応答して、所定の中継URI(Uniform Resource Identifier)についての第1HTTP(Hyper Text Transfer Protocol)リクエストを前記ファイアウォールを介して前記第1中継サーバに送信するステップと、
前記第1中継サーバから、前記第1HTTPリクエストに対するHTTPレスポンスとして前記第1のサービス提供サーバからの処理リクエストを受信するステップと、
前記処理リクエストを前記第2のサービス提供サーバに対する第2のリクエストに変換して、当該第2のサービス提供サーバに送信するステップと、
前記第2のサービス提供サーバから、前記第2のリクエストに対する応答データを受信するステップと、
前記応答データを、前記第1のサービス提供サーバへのレスポンスのための第2HTTPリクエストに変換し、前記第1中継サーバに送信するステップと、
を含む中継処理方法。
(付記2)
前記第2HTTPリクエストが、前記所定の中継URIについてのHTTPリクエストである
付記1記載の中継処理方法。
(付記3)
ファイアウォール外部に設置され且つファイアウォール内部の第1中継サーバと協働して前記ファイアウォール外部の第1のサービス提供サーバと前記ファイアウォール内部の第2のサービス提供サーバとを連携させる第2中継サーバにより実行される中継処理方法であって、
前記第1中継サーバから所定の中継URI(Uniform Resource Identifier)についての第1HTTP(Hyper Text Transfer Protocol)リクエストを前記ファイアウォールを介して受信するステップと、
前記第1HTTPリクエストの受信に応答して、前記所定の中継URIについての第2HTTPリクエストを前記第1のサービス提供サーバから受信するのを待機するステップと、
前記所定の中継URIについての前記第2HTTPリクエストを前記第1のサービス提供サーバから受信するステップと、
前記第2HTTPリクエストの受信に応答して、当該第2HTTPリクエストを前記第1HTTPリクエストに対する第1のHTTPレスポンスに変換して、前記第1中継サーバに送信するステップと、
前記第1中継サーバから、前記第2HTTPリクエストへのレスポンスのためのデータを含む第3HTTPリクエストを受信するステップと、
前記第3HTTPリクエストの受信に応答して、当該第3HTTPリクエストに含まれる前記レスポンスのためのデータを用いて、前記第2HTTPリクエストへのレスポンスである第2のHTTPレスポンスを生成し、前記第1のサービス提供サーバに送信するステップと、
を含む中継処理方法。
(付記4)
前記第3HTTPリクエストが、前記所定の中継URIについてのHTTPリクエストであり、
前記第3HTTPリクエストの受信に応答して、前記所定の中継URIについての第4HTTPリクエストを前記第1のサービス提供サーバから受信するのを待機するステップ
をさらに含む付記3記載の中継処理方法。
(付記5)
付記1乃至4のいずれか1つ記載の中継処理方法をコンピュータに実行させるためのプログラム。
(付記6)
ファイアウォール内部に設置され且つファイアウォール外部の第1中継サーバと協働して前記ファイアウォール外部の第1のサービス提供サーバと前記ファイアウォール内部の第2のサービス提供サーバとを連携させる内部中継サーバであって、
前記第1のサービス提供サーバに対して処理を要求する端末から前記第1のサービス提供サーバを前記第2のサービス提供サーバと連携させるためのリクエストを受信するリクエスト受信部と、
前記リクエストに応答して、所定の中継URI(Uniform Resource Identifier)についての第1HTTP(Hyper Text Transfer Protocol)リクエストを前記ファイアウォールを介して前記第1中継サーバに送信するリクエスト送信部と、
前記第1中継サーバから、前記第1HTTPリクエストに対するHTTPレスポンスとして前記第1のサービス提供サーバからの処理リクエストを受信するリプライ受信部と、
前記処理リクエストを前記第2のサービス提供サーバに対する第2のリクエストに変換して、当該第2のサービス提供サーバに送信するサービスリクエスト送信部と、
前記第2のサービス提供サーバから、前記第2のリクエストに対する応答データを受信するサービスリプライ受信部と、
を有し、
前記リクエスト送信部が、
前記応答データを、前記第1のサービス提供サーバへのレスポンスのための第2HTTPリクエストに変換し、前記第1中継サーバに送信する
内部中継サーバ。
(付記7)
ファイアウォール外部に設置され且つファイアウォール内部の第1中継サーバと協働して前記ファイアウォール外部の第1のサービス提供サーバと前記ファイアウォール内部の第2のサービス提供サーバとを連携させる外部中継サーバであって、
前記第1中継サーバから所定の中継URI(Uniform Resource Identifier)についての第1HTTP(Hyper Text Transfer Protocol)リクエストを前記ファイアウォールを介して受信するリクエスト受信部と、
前記第1HTTPリクエストの受信に応答して、前記所定の中継URIについての第2HTTPリクエストを前記第1のサービス提供サーバから受信するのを待機した後、前記所定の中継URIについての前記第2HTTPリクエストを前記第1のサービス提供サーバから受信するサービスリクエスト受信部と、
前記第2HTTPリクエストの受信に応答して、当該第2HTTPリクエストを前記第1HTTPリクエストに対する第1のHTTPレスポンスに変換して、前記第1中継サーバに送信するリプライ送信部と、
を有し、
前記リクエスト受信部が、
前記第1中継サーバから、前記第2HTTPリクエストへのレスポンスのためのデータを含む第3HTTPリクエストを受信し、
前記外部中継サーバが、
前記第3HTTPリクエストの受信に応答して、当該第3HTTPリクエストに含まれる前記レスポンスのためのデータを用いて、前記第2HTTPリクエストへのレスポンスである第2のHTTPレスポンスを生成し、前記第1のサービス提供サーバに送信するサービスリプライ送信部、
をさらに有する外部中継サーバ。