中継処理方法、プログラム及び装置
【課題】ファイアウォールに対して設定変更などを行わずに外部のＷｅｂアプリケーションからファイアウォール内部のサービスを呼び出すことができるようにする。
【解決手段】ファイアウォールの両側に中継サーバを用意して、最初に内部中継サーバから外部中継サーバにリクエストを出力しておき、ファイアウォール外部のＷｅｂサービスを提供するサーバからのリクエストを待機する。そして、外部中継サーバでファイアウォール外部のサーバから内部に対するサービス要求を受信した場合には、上記リクエストに対するレスポンスとして内部中継サーバに伝えることによって、ファイアウォールを越えてＷｅｂサービス呼び出しが可能となる。
【解決手段】ファイアウォールの両側に中継サーバを用意して、最初に内部中継サーバから外部中継サーバにリクエストを出力しておき、ファイアウォール外部のＷｅｂサービスを提供するサーバからのリクエストを待機する。そして、外部中継サーバでファイアウォール外部のサーバから内部に対するサービス要求を受信した場合には、上記リクエストに対するレスポンスとして内部中継サーバに伝えることによって、ファイアウォールを越えてＷｅｂサービス呼び出しが可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、外部のウェブ（Ｗｅｂ）アプリケーションからファイアウォールを介してファイアウォール内部のサービスを呼び出すための技術に関する。
【背景技術】
【０００２】
従来、コンピュータプログラムを利用する際には、プログラムを記録した記録媒体又はプログラムの使用権を購入し、自分の所有するコンピュータにインストールを行ってから実行するのが普通であった。しかし、近年、このような事前の購入やインストールを行うことなく、Ｗｅｂブラウザでプログラム提供者のＷｅｂサイトにアクセスし、使用料を支払うだけでプログラムを利用するという形態が注目を集めている。このような提供形態はＡＳＰ（Application Service Provide）やＳａａＳ（Software as a Service）と呼ばれ、ソフトウェアをサービスとして提供し、サービスの利用料として対価を得るという点で、これまでのソフトウェア提供モデルとは異なった特徴がある。
【０００３】
図１に示すように、ＳａａＳのためのサーバ（以下ＳａａＳサーバと呼ぶ）には、例えば顧客管理アプリケーション、サプライチェーン管理アプリケーションやグループウェアなどのアプリケーションが用意されており、さらにユーザ企業（例えば企業Ａ及びＢ）のデータをも保管されている。企業Ａ及びＢのユーザは、このＳａａＳサーバにインターネットなどを介してＷｅｂブラウザでアクセスして、利用契約を行ったアプリケーションを利用する。その処理結果のデータは、ユーザ端末に返信し、必要があればＳａａＳサーバ内に保管される。通常、各企業のシステムが接続されているイントラネット等の社内ネットワークとインターネットなどの外部ネットワークとの間にはファイアウォールが設けられており、外部ネットワークからのアクセスはブロックされる。
【０００４】
ＳａａＳアプリケーションは、ユーザ端末への事前のインストールを不要とするため、Ｗｅｂブラウザだけで実行できるＷｅｂアプリケーションと呼ばれる形態のプログラムとなっているのが通常である。図２に、典型的なＳａａＳアプリケーションの構成を模式的に示す。図２に示したように、ＳａａＳサーバには、Ｗｅｂアプリケーションの処理ロジック及びそのためのデータが保持されており、ユーザは、ユーザ端末を操作して、社内ネットワーク、ファイアウォール及びインターネットを経由してＳａａＳサーバにアクセスする。すなわち、ユーザ端末からＳａａＳサーバにリクエストを送信する。ＳａａＳサーバは、受信したリクエストに対するＷｅｂページを生成して、アクセス元のユーザ端末に送信する。このように外部ネットワークからのデータ送信であっても、リクエストに対する応答である場合には、ファイアウォールを越えることができる。ユーザ端末は、受信したＷｅｂページデータを表示装置に表示し、ユーザは、入力欄にデータを入力したり、ボタンをクリックするなどして、さらにリクエストをＳａａＳサーバに送信する。このような処理を繰り返すことによって、ＳａａＳサーバにＷｅｂアプリケーションの処理を行わせる。
【０００５】
ＳａａＳアプリケーションでは、セルフカスタマイズと呼ばれる、ユーザ自身がアプリケーションの機能の一部を変更することもよく行われている。これによってユーザは、アプリケーションで扱うデータの内容を追加・変更したり、データに関する処理をプログラム言語によって記述することができる。また、別のサイトが提供するＷｅｂサービスを呼び出してその結果を利用するようなことも可能となっている。例えばＳａａＳアプリケーションで商談情報を管理する際に、インターネット上で公開されている企業情報データベースを利用し、顧客企業の最新状況を表示するようなことが容易に実現できるようになっている。図３に模式的に示すように、ユーザはユーザ作成ロジックを追加で用意しておき、標準で提供される処理ロジックに加えて特別な処理を行わせる場合もある。さらに、ユーザ作成ロジックによって、他のＷｅｂサービス提供元サイトで提供されるＷｅｂサービスを呼び出し、そのＷｅｂサービスの応答を用いた処理を行う場合もある。
【０００６】
ＳａａＳアプリケーションは即座に利用を開始することができ、利用を中止することも容易であるため、小規模な企業だけでなく、大企業でも各部門や職場といった単位で、自分のニーズに応じたカスタマイズを行いながら利用するというスタイルが広まりつつある。
【０００７】
このような連携を、インターネット上の公開サービスだけではなく、イントラネット内の社内システムに対しても行いたいという要望がある。例えば、図４に示すように、ＳａａＳサーバにおける商談管理アプリケーションと社内の在庫管理システムとを連携させて商品の発注指示まで一緒に行いたいというようなニーズがある。しかしながら、インターネットからイントラネット内へのアクセスはセキュリティ上大きな問題となるため、ファイアウォールで遮断されるのが一般的である。従って、ファイアウォール外部のＳａａＳサーバで実行されるＳａａＳアプリケーションから、Ｗｅｂサービス呼び出しによって社内のＷｅｂサービス（例えば在庫管理サービス）を直接呼び出すことはできない。
【０００８】
このような問題に対して、図５及び図６に示すように、一般にＤＭＺ（Demilitarized Zone）と呼ばれるイントラネット内の隔離領域に中継サーバを配置し、このサーバがインターネットからのＷｅｂサービス呼び出しを受け付け、それをイントラネット内のＷｅｂサービスに中継する。図５に示すように、ＤＭＺ内の中継サーバは、予め定義されているポートやＵＲＬで外部（すなわちインターネット側）からの接続を待機する。そして、中継サーバは、予め定義されているポートやＵＲＬでアクセスされると、アクセス許可リストで、許可されているアクセスであるかを確認する。そして、図６に示すように、許可されているアクセスである場合には、中継サーバは、イントラネットに接続された社内サーバにアクセスを転送し、当該社内サーバからのレスポンスを、要求元の外部サーバに転送する。しかし、全社的なファイアウォールに対して特定のサーバからのアクセスを許可するといった設定変更が必要になり、セキュリティ上のリスクが高いことから、利用部門のみの権限では実施することができない。セキュリティ上のリスクが高いので、このような方法は好ましいものとは考えられていない。
【０００９】
さらに、イントラネット内とインターネット上にそれぞれ中継サーバを配置し、両者がセッションを維持しつつ専用プロトコルで通信することで、インターネット上の中継サーバがＷｅｂサービス呼び出しを受け付け、イントラネット内の中継サーバに中継する方法も提案されている。このような専用プロトコルを使用する場合にも、ＤＭＺの場合のようにファイアウォールに対して設定変更が必要となる。
【００１０】
さらに、イントラネットとＳａａＳサーバとの間を専用線接続又はＶＰＮ（Virtual Private Network）接続によって結び、この接続を経由してイントラネット内のＷｅｂサービスを呼び出すようにする方法も存在する。しかし、特別な回線を用意しなければならず、運用コストが高くなる。また、ＶＰＮ等の設定もセキュリティ上の問題を発生し得るものである。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００４−２９５１６６号公報
【特許文献２】特表２０００−５０５２７０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
従って、本技術の目的は、ファイアウォールに対して設定変更などを行わずに外部のＷｅｂアプリケーションからファイアウォール内部のサービスを呼び出すことができるようにするための技術を提供することである。
【課題を解決するための手段】
【００１３】
第１の態様に係る中継処理方法は、ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１のサービス提供サーバに対して処理を要求する端末から第１のサービス提供サーバを第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、（Ｂ）リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して第１中継サーバに送信するステップと、（Ｃ）第１中継サーバから、第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして第１のサービス提供サーバからの処理リクエストを受信するステップと、（Ｄ）処理リクエストを第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、（Ｅ）第２のサービス提供サーバから、第２のリクエストに対する応答データを受信するステップと、（Ｆ）応答データを、第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、第１中継サーバに送信するステップとを含む。
【００１４】
第２の態様に係る中継処理方法は、ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して受信するステップと、（Ｂ）第１ＨＴＴＰリクエストの受信に応答して、所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するのを待機するステップと、（Ｃ）所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するステップと、（Ｄ）第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、第１中継サーバに送信するステップと、（Ｅ）第１中継サーバから、第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、（Ｆ）第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれるレスポンスのためのデータを用いて、第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、第１中継サーバに送信するステップとを含む。
【発明の効果】
【００１５】
ファイアウォールに対して設定変更などを行わずに外部のＷｅｂアプリケーションからファイアウォール内部のサービスを呼び出すことができるようになる。
【図面の簡単な説明】
【００１６】
【図１】図１は、ＳａａＳについて説明するための図である。
【図２】図２は、ＳａａＳについて説明するための図である。
【図３】図３は、ＳａａＳについて説明するための図である。
【図４】図４は、従来技術の問題を説明するための図である。
【図５】図５は、従来技術を説明するための図である。
【図６】図６は、従来技術を説明するための図である。
【図７】図７は、システム全体の模式図である。
【図８】図８は、外部中継サーバの機能ブロック図である。
【図９】図９は、内部中継サーバの機能ブロック図である。
【図１０】図１０は、システムの処理の概要を説明するための図である。
【図１１】図１１は、システムの処理の概要を説明するための図である。
【図１２】図１２は、システムの処理の概要を説明するための図である。
【図１３Ａ】図１３Ａは、システムの処理の概要を説明するための図である。
【図１３Ｂ】図１３Ｂは、システムの処理の概要を説明するための図である。
【図１４】図１４は、部門Ａユーザ端末に表示される初期画面の一例を示す図である。
【図１５】図１５は、中継セッション開始リクエストを受信した際の処理の処理フローを示す図である。
【図１６】図１６は、ユーザ情報格納部に格納されるデータの一例を示す図である。
【図１７】図１７は、セッション一覧情報格納部に格納されるデータの一例を示す図である。
【図１８】図１８は、内部中継サーバから外部中継サーバへＨＴＴＰリクエストを最初に送信する際の処理の処理フローを示す図である。
【図１９】図１９は、内部中継サーバから外部中継サーバへ送信される最初のＨＴＴＰリクエストの例を示す図である。
【図２０】図２０は、外部中継サーバが内部中継サーバからリクエストを受信した際の処理の処理フローを示す図である。
【図２１】図２１は、アクセス許可情報格納部に格納されるデータの一例を示す図である。
【図２２】図２２は、受信待機中パス一覧格納部に格納されるデータの一例を示す図である。
【図２３】図２３は、外部中継サーバが内部中継サーバからリクエストを受信した際の処理の処理フローを示す図である。
【図２４】図２４は、中継ＵＲＩデータの一例を示す図である。
【図２５】図２５は、ＳａａＳサーバから受信するＨＴＴＰリクエストの一例を示す図である。
【図２６】図２６は、ＳａａＳサーバからＨＴＴＰリクエストを受信した際の処理の処理フローを示す図である。
【図２７】図２７は、ＳａａＳサーバからＨＴＴＰリクエストを受信した際の処理の処理フローを示す図である。
【図２８】図２８は、外部中継サーバから内部中継サーバへのＨＴＴＰレスポンスの生成及び送信の処理の処理フローを示す図である。
【図２９】図２９は、外部中継サーバから内部中継サーバへのＨＴＴＰレスポンスの一例を示す図である。
【図３０】図３０は、内部中継サーバが外部中継サーバから社内Ｗｅｂサービス呼び出しとしてのＨＴＴＰレスポンスを受信した際の処理の処理フローを示す図である。
【図３１】図３１は、特定されたセッション情報の一例を示す図である。
【図３２】図３２は、接続認証情報格納部に格納されるデータの一例を示す図である。
【図３３】図３３は、社内Ｗｅｂサービスを提供するサーバに対するＨＴＴＰリクエストを生成するための処理を説明するための図である。
【図３４】図３４は、社内Ｗｅｂサービスを提供するサーバに対するＨＴＴＰリクエストを生成するための処理を説明するための図である。
【図３５】図３５は、社内Ｗｅｂサービスを提供するサーバへのＨＴＴＰリクエストの一例を示す図である。
【図３６】図３６は、社内Ｗｅｂサービスを提供するサーバからのＨＴＴＰレスポンスの一例を示す図である。
【図３７】図３７は、社内Ｗｅｂサービスを提供するサーバからのＨＴＴＰレスポンスを受信した際の処理の処理フローを示す図である。
【図３８】図３８は、内部中継サーバから外部中継サーバへＨＴＴＰリクエストを２回目に送信する際の処理の処理フローを示す図である。
【図３９】図３９は、内部中継サーバから外部中継サーバへＨＴＴＰリクエストを２回目に送信する際の処理の処理フローを示す図である。
【図４０】図４０は、内部中継サーバから外部中継サーバへ送信される２度目のＨＴＴＰリクエストの例を示す図である。
【図４１】図４１は、外部中継サーバからＳａａＳサーバへＨＴＴＰレスポンスを送信する際の処理の処理フローを示す図である。
【図４２】図４２は、外部中継サーバからＳａａＳサーバへＨＴＴＰレスポンスを送信する際の処理の処理フローを示す図である。
【図４３】図４３は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１７】
図７に、本実施の形態に係るシステム全体の模式図を示す。例えばイントラネットである社内ネットワーク９とインターネット１とはファイアウォール７を介して接続されている。インターネット１には、ＳａａＳアプリケーション５０１を実行しているＳａａＳサーバ５と、本実施の形態において主要な処理を実施する外部中継サーバ３とが接続されている。ＳａａＳアプリケーション５０１は、例えば商談管理アプリケーション５１３と、社内Ｗｅｂサービス（ここでは在庫管理サービス）を呼び出す、ユーザ企業によるカスタマイズコード５１１とを含む。また、ＳａａＳサーバ５は、ユーザ企業の部門Ａの商談情報を蓄積する部門Ａ商談データベース（ＤＢ）５１を管理しており、ＳａａＳアプリケーション５０１の商談管理アプリケーション５１３はこの部門Ａ商談ＤＢ５１のデータを処理するようになっている。さらに、商談管理アプリケーション５１３を実行中、特定の場面においてカスタマイズコード５１１が実行され、当該カスタマイズコード５１１により在庫管理サービスも併せてユーザに提供されるようになる。なお、ＳａａＳサーバ５は、１以上のコンピュータで実施され、商談管理サービス以外のサービスを提供する場合もある。
【００１８】
また、社内ネットワーク９には、部門Ａのユーザが操作し且つＷｅｂブラウザを実行する複数の部門Ａユーザ端末１１と、本実施の形態の主要な処理を実施する内部中継サーバ１３と、通常は社内ネットワーク９からでしか使用できない在庫管理サービスを提供する在庫管理システム１５とが接続されている。
【００１９】
図８に、外部中継サーバ３の機能ブロック図を示す。外部中継サーバ３は、アクセス許可情報格納部３１と、リクエスト受信部３２と、Ｗｅｂサービス制御部３３と、受信待機中パス一覧格納部３８と、Ｗｅｂサービスリプライ送信部３４と、Ｗｅｂサービスリクエスト受信部３５と、アクセス要求処理部３６と、リプライ送信部３７とを有する。リクエスト受信部３２は、内部中継サーバ１３からリクエストを受信し、アクセス許可情報格納部３１に格納されているデータを用いて処理を行い、Ｗｅｂサービス制御部３３とアクセス要求処理部３６とリプライ送信部３７と連携する。リプライ送信部３７は、アクセス要求処理部３６とリクエスト受信部３２と連携して内部中継サーバ１３にレスポンスを送信する。また、Ｗｅｂサービス制御部３３は、受信待機中パス一覧格納部３８にデータを格納すると共にデータを読み出し、リクエスト受信部３２及びアクセス要求処理部３６と連携する。Ｗｅｂサービスリクエスト受信部３５は、ＳａａＳサーバ５からＷｅｂサービスリクエストを受信し、アクセス要求処理部３６に出力する。Ｗｅｂサービスリプライ送信部３４は、アクセス要求処理部３６からＷｅｂサービスリクエストに対するレスポンスのデータを受信し、ＳａａＳサーバに送信する。アクセス要求処理部３６は、リクエスト受信部３２、Ｗｅｂサービス制御部３３、Ｗｅｂサービスリクエスト受信部３５、Ｗｅｂサービスリプライ送信部３４及びリプライ送信部３７と連携して処理を実施する。
【００２０】
図９に、内部中継サーバ１３の機能ブロック図を示す。内部中継サーバ１３は、リクエスト受信部１３１と、リプライ送信部１３２と、ユーザ情報格納部１３３と、接続情報管理部１３４と、セッション一覧情報格納部１３５と、セッション管理部１３６と、外部インタフェース部１３７と、アクセス要求処理部１３８と、接続認証情報格納部１３９と、社内Ｗｅｂサービスインタフェース部１４０とを有する。リクエスト受信部１３１は、部門Ａユーザ端末１１からの中継セッション開始リクエストを受信し、接続情報管理部１３４に出力する。リプライ送信部１３２は、中継セッション開始リクエストに対応する応答を部門Ａユーザ端末１１に送信する。接続情報管理部１３４は、ユーザ情報格納部１３３に格納されているデータを用いて処理を行い、セッション管理部１３６と連携する。セッション管理部１３６は、セッション一覧情報格納部１３５に対してデータを格納すると共にデータを読み出し、接続情報管理部１３４、外部インタフェース部１３７及びアクセス要求処理部１３８と連携する。外部インタフェース部１３７は、外部中継サーバ３に対するインタフェースであり、リクエスト送信部１３７１及びリプライ受信部１３７２を有する。そして、外部インタフェース部１３７は、セッション管理部１３６とアクセス要求処理部１３８と連携する。アクセス要求処理部１３８は、接続認証情報格納部１３９に格納されているデータを用いて処理を行い、セッション管理部１３６と外部インタフェース部１３７と社内Ｗｅｂサービスインタフェース部１４０と連携する。社内Ｗｅｂサービスインタフェース部１４０は、社内システムの一例である在庫管理システム１５に対するインタフェースであり、Ｗｅｂサービスリクエスト送信部１４１１とＷｅｂサービスリプライ受信部１４１２とを有する。そして、社内Ｗｅｂサービスインタフェース部１４０は、アクセス要求処理部１３８と連携する。
【００２１】
次に、図１０乃至図１３Ｂを用いて、図７に示したシステムの処理の概要を説明する。まず、企業の部門Ａのユーザは、部門Ａユーザ端末１１を操作して、ＳａａＳサーバ５にアクセスさせる（図１０：ステップ（１））。例えばＳａａＳサーバ５のＵＲＩがsaasapps.comであるとすると、当該ＵＲＩにリクエストを送信する。このリクエストに応答して、ＳａａＳサーバ５のＳａａＳアプリケーション５０１は処理を開始する。上でも述べたように、ＳａａＳアプリケーション５０１は、商談管理アプリケーション５１３の通常の処理ロジックに加えて、カスタマイズコード５１１を含んでおり、ここでは、カスタマイズコード５１１には、予め定められた中継ＵＲＩであるhttp://myproxy.com/usr/usr1/zaikoに対して在庫管理のＷｅｂサービスを呼び出すコードが含まれるものとする。なお、インターネット１におけるＤＮＳ（Domain Name Server。図示せず。）には、この中継ＵＲＩのドメインに対して外部中継サーバのＩＰアドレスが登録されているものとする。
【００２２】
図１１の処理の説明に移行して、企業の部門Ａのユーザは、部門Ａユーザ端末１１を操作して、内部中継サーバ１３に対して、中継セッション開始リクエストを送信させる（図１１：ステップ（２））。内部中継サーバ１３は、中継セッション開始リクエストを受信すると、当該中継セッション開始リクエストを予め定められた中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストに変換する。そして、内部中継サーバ１３は、このＨＴＴＰリクエストを外部中継サーバ３に送信して、中継セッション開始を外部中継サーバ３に指示する（ステップ（３））。外部中継サーバ３は、このＨＴＴＰリクエストを受信すると、このＨＴＴＰリクエストに対してレスポンスを返すことなく、ＳａａＳサーバ５からの中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのリクエストを待機する（ステップ（４））。このようにファイアウォール内部から外部へリクエストを送信することによって、当該リクエストへのレスポンスとしてファイアウォール外部から内部にファイアウォールに遮断されることなくデータを送信することができるようになる。
【００２３】
図１２の処理の説明に移行して、そしてＳａａＳサーバ５において、ＳａａＳアプリケーション５０１のカスタマイズコード５１１が実行されるようになると、ＳａａＳサーバ５は、所定の中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストを、社内Ｗｅｂサービス呼び出しとして、外部中継サーバ３に送信する（図１２：ステップ（５））。外部中継サーバ３は、ＳａａＳサーバ５から所定の中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストを受信すると、処理しても良いＨＴＴＰリクエストであるかを確認する。その上で外部中継サーバ３は、ＳａａＳサーバ５からのＨＴＴＰリクエストを、内部中継サーバ１３から受信した、中継セッション開始指示についてのＨＴＴＰリクエストに対するレスポンスに変換し、内部中継サーバ１３に送信する（ステップ（６））。内部中継サーバ１３は、外部中継サーバ３から、ＨＴＴＰレスポンスの形式での、ＳａａＳサーバ５からのＨＴＴＰリクエストを、在庫管理システム１５に中継してもよいかその是非を判断する（ステップ（７））。例えば、ＳａａＳサーバ５のＩＰアドレスなどから中継の是非を判断する。
【００２４】
図１３Ａの処理の説明に移行して、内部中継サーバ１３は、ＳａａＳサーバ５からのＨＴＴＰリクエストを中継しても良いと判断した場合には、在庫管理システム１５に対するＷｅｂサービス呼び出しとしてＨＴＴＰリクエストを生成して、在庫管理システム１５に送信する（ステップ（８））。在庫管理システム１５は、内部中継サーバ１３からのＨＴＴＰリクエストに応答して処理を実施して、処理結果をＨＴＴＰレスポンスとして内部中継サーバ１３に返信する（ステップ（９））。内部中継サーバ１３は、処理結果のレスポンスを、中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストに変換し、外部中継サーバ３に送信する（ステップ（１０））。このように処理結果のレスポンスを、再度のＨＴＴＰリクエストの形式で外部中継サーバ３に出力する。
【００２５】
図１３Ｂの処理の説明に移行して、外部中継サーバ３は、内部中継サーバ１３から、社内Ｗｅｂサービスの処理結果を含むＨＴＴＰリクエストを受信すると、当該社内Ｗｅｂサービスの処理結果を含むＨＴＴＰレスポンスを生成して、ステップ（５）におけるＨＴＴＰリクエストに対するレスポンスとして、ＳａａＳサーバ５に返信する（ステップ（１１））。ＳａａＳサーバ５におけるＳａａＳアプリケーション５０１は、外部中継サーバ３から社内Ｗｅｂサービスの処理結果を含むＨＴＴＰレスポンスを受信すると、当該社内Ｗｅｂサービスの処理結果を反映させたＨＴＴＰレスポンスを、ステップ（１）に対するレスポンスとして生成して、部門Ａユーザ端末１１に返信する（ステップ（１２））。
【００２６】
このようにして、ファイアウォールの外部のＳａａＳサーバ５におけるＳａａＳアプリケーション５０１と、ファイアウォール内部の社内Ｗｅｂサービス提供システム（図では在庫管理システム１５）とが連携できるようになり、両者の処理結果を反映させたデータをファイアウォール内部の部門Ａユーザ端末１１に届けることができるようになる。なお、ファイアウォール７の設定の変更は不要であり、セキュリティレベルを下げずに、このような効果を得ている。
【００２７】
なお、外部中継サーバ３は、内部中継サーバ１３からＨＴＴＰリクエストを受信した状態であるから、中継待ちの状態となっており、ＳａａＳサーバ５からの社内Ｗｅｂサービス呼び出しが必要となれば、応答することができる。
【００２８】
また、部門Ａユーザ端末１１のユーザが、例えばＳａａＳサーバ５からログオフする場合など、ＳａａＳサーバ５で提供されるＷｅｂサービスの利用を終了する場合には、部門Ａユーザ端末１１のユーザは、部門Ａユーザ端末１１に対して、中継セッション中止リクエストを、内部中継サーバ１３に送信させる。
【００２９】
内部中継サーバ１３は、中継セッション中止リクエストに応答して、自らが保持する所定の中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのセッション情報を破棄すると共に、外部中継サーバ３に対しても受信待機中パスについてのデータを破棄させるためのメッセージを送信する。外部中継サーバ３は、内部中継サーバ１３から上記のようなメッセージを受信すると、受信待機中パスについてのデータを破棄し、中継待ち受けの状態を脱する。なお、中継セッション中止リクエストを送信せずとも、例えば所定時間以上経過した場合には、内部中継サーバ１３でも外部中継サーバ３でも、セッション情報や受信待機中パスについてのデータを破棄するようにすれば、中継待ち受けの状態を脱するようになる。
【００３０】
次に、図１４乃至図４２を用いて、図７に示したシステムの処理の詳細を説明する。最初に、図１４乃至図１７を用いて、部門Ａユーザ端末１１から中継セッション開始リクエストを受信する際の処理を説明する。最初に、例えばリクエスト受信部１３１は、部門Ａユーザ端末１１からのアクセスに応じて、例えばリクエストのためのデータの入力画面を表示させるＷｅｂページデータを送信する。部門Ａユーザ端末１１は、リクエスト受信部１３１から上で述べたようなＷｅｂページデータを受信し、表示装置に表示する。例えば図１４に示すような画面が表示される。
【００３１】
図１４の例では、内部中継サーバ１３に対するユーザＩＤ及びパスワードの入力欄と、外部中継サーバ名と当該外部中継サーバ３に対するユーザＩＤ及びパスワードの入力欄と、社内ＷｅｂサービスＵＲＩの入力欄と、Ｗｅｂサービス中継ＵＲＩの入力欄と、アクセス許可ホスト名の入力欄とを含む。社内ＷｅｂサービスＵＲＩは、例えば図７における在庫管理システム１５のＵＲＩである。Ｗｅｂサービス中継ＵＲＩは、内部中継サーバ１３及び外部中継サーバ３でどの中継セッションであるかを特定するためのキーとなる中継ＵＲＩである。
【００３２】
ユーザは、図１４における画面の入力欄にデータを入力して開始ボタンをクリックし、部門Ａユーザ端末１１に対して中継セッション開始リクエストの送信指示を入力する。部門Ａユーザ端末１１は、中継セッション開始リクエストの送信指示を受け付け、入力されたデータを含む中継セッション開始リクエストを、内部中継サーバ１３に送信する。
【００３３】
内部中継サーバ１３のリクエスト受信部１３１は、部門Ａユーザ端末１１から中継セッション開始リクエストを受信し（図１５：ステップＳ１）、接続情報管理部１３４に出力する。接続情報管理部１３４は、上で述べたようなデータを含む中継セッション開始リクエストを受信すると、受信したユーザＩＤでユーザ情報格納部１３３を検索して一致するパスワードを取得し、受信したパスワードと一致するかを判断する照合処理を実施する（ステップＳ３）。
【００３４】
ユーザ情報格納部１３３に格納されているデータの一例を図１６に示す。図１６の例では、例えば部門ＡのユーザのユーザＩＤと、パスワードとが登録されるようになっている。
【００３５】
一致する場合、すなわち照合成功の場合には、セッション管理部１３６に、図１４に示したデータをセッション管理部１３６に出力する（ステップＳ９）。セッション管理部１３６は、接続情報管理部１３４から受信したデータをセッション一覧情報格納部１３５に格納する。
【００３６】
セッション一覧情報格納部１３５には、例えば図１７に示すようなデータが格納される。図１７の例では、内部中継サーバ１３に対するユーザＩＤと、社内ＷｅｂサービスＵＲＩと、外部中継サーバ名と、Ｗｅｂサービス中継ＵＲＩと、アクセス許可ホスト名と、外部中継サーバ３に対するユーザＩＤ及びパスワードとを登録するようになっている。このテーブルの一行分のデータを、セッション情報と呼ぶことにする。セッション管理部１３６は、このセッション情報を、外部インタフェース部１３７に出力する。
【００３７】
また、接続情報管理部１３４は、リプライ送信部１３２に中継セッション開始成功を表すレスポンスを部門Ａユーザ端末１１へ送信させる（ステップＳ１１）。部門Ａユーザ端末１１は、リプライ送信部１３２から中継セッション開始成功を表すレスポンスを受信し、表示装置に表示する。ユーザは、中継セッション開始成功を認識することができる。
【００３８】
一方、ステップＳ３で照合に失敗すると（ステップＳ５：Ｎｏルート）、接続情報管理部１３４は、リプライ送信部１３２に、中継セッション開始失敗を、部門Ａユーザ端末１１へ送信させる（ステップＳ７）。部門Ａユーザ端末１１は、リプライ送信部１３２から中継セッション開始失敗を表すレスポンスを受信し、表示装置に表示する。ユーザは、中継セッション開始失敗、すなわちユーザＩＤとパスワードとの少なくともいずれかの入力を誤ったことを認識することができる。
【００３９】
以上のような処理を実施して、外部中継サーバ３への中継セッション開始通知の準備が完了する。なお、セッション情報については、ユーザ毎に内部中継サーバ１３内に保持しておき、ユーザからの中継セッション開始リクエストに応じて、そのセッション情報を読み出すようにしても良い。
【００４０】
次に、図１８及び図１９を用いて、ＨＴＴＰリクエストの送信処理（１回目）について説明する。内部中継サーバ１３の外部インタフェース部１３７は、セッション管理部１３６からセッション情報を受信し（ステップＳ２１）、メインメモリ等の記憶装置に格納しておく。このセッション情報は、外部中継サーバ３との通信で用いるセッションＩＤとソケットＩＤとのうち少なくともいずれかなどによって管理しておく。そして、リクエスト送信部１３７１及びリプライ受信部１３７２で共用する。又は、セッション情報のうち少なくともＷｅｂサービス中継ＵＲＩ等キーとなるデータと、セッションＩＤとソケットＩＤとのうち少なくともいずれかなどとを関連付けて保持しておく。
【００４１】
リクエスト送信部１３７１は、セッション情報から外部中継サーバ名を抽出し、今回送信するＨＴＴＰリクエストの宛先ホストに設定すると共に、宛先ホストの所定のパス（ここでは/control/index.html。予め保持しておく。）もＨＴＴＰリクエストのパス名として設定する（ステップＳ２３）。
【００４２】
さらに、リクエスト送信部１３７１は、セッション情報から外部中継サーバ３に対するユーザＩＤ及びパスワードを抽出し、ＨＴＴＰリクエストのAuthorizationフィールドに設定する（ステップＳ２５）。また、リクエスト送信部１３７１は、セッション情報からＷｅｂサービス中継ＵＲＩのパス部分を抽出し、ＨＴＴＰリクエストのX-RelayURIフィールドに設定する（ステップＳ２７）。そして、リクエスト送信部１３７１は、セッション情報からアクセス許可ホスト名を抽出し、X-AllowDomainフィールドに設定する（ステップＳ２９）。このようにしてセッション情報からＨＴＴＰリクエストが生成されたことになる。そして、リクエスト送信部１３７１は、生成されたＨＴＴＰリクエストを外部中継サーバ３に送信する（ステップＳ３１）。なお、リクエスト送信部１３７１は、リプライ受信部１３７２に対して、レスポンスの待機を指示する（ステップＳ３３）。リプライ受信部１３７２は、上で述べたようにＨＴＴＰリクエスト送信時のセッションＩＤやソケットＩＤを保持しておき、今回送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを識別できるようにする。
【００４３】
図１９に、ステップＳ３１で外部中継サーバ３に送信されるＨＴＴＰリクエストの一例を示す。図１９の例では、ＰＯＳＴメソッドが定義されており、パス名には”/control/index.html”が設定されている。また、ホスト名には、外部中継サーバ３のホスト名”myproxy.com”が設定されている。Authorizationフィールドには、ユーザＩＤ及びパスワードを連結した上でBASE64でエンコードしたものが設定されている。X-RelayURIフィールドには、上で述べたように中継ＵＲＩのパス部分”/usr/usr1/zaiko”が設定されており、X-AllowDomainフィールドにはアクセス許可ホスト名”saasapps.com”が設定されている。
【００４４】
このようにして最初のＨＴＴＰリクエストが内部中継サーバ１３から外部中継サーバ３へ送信される。
【００４５】
次に、外部中継サーバ３におけるリクエスト受信処理について図２０乃至図２４を用いて説明する。外部中継サーバ３のリクエスト受信部３２は、内部中継サーバ１３からＨＴＴＰリクエストを受信し、メインメモリ等の記憶装置に格納すると共に、受信したＨＴＴＰリクエストのソケットから送信元のＩＰアドレス及びソケットＩＤを取得する（ステップＳ４１）。さらに、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダからユーザＩＤ及びパスワードを抽出する（ステップＳ４３）。そして、リクエスト受信部３２は、送信元ＩＰアドレス、ユーザＩＤ及びパスワードのセットがアクセス許可情報格納部３１に格納されているアクセス許可情報に含まれるか確認する（ステップＳ４５）。
【００４６】
図２１に、アクセス許可情報格納部３１に格納されるデータの一例を示す。図２１の例では、送信元ＩＰアドレスと、ユーザＩＤと、パスワードとを登録するようになっている。ステップＳ４５では、いずれかのレコードのデータと、ステップＳ４１及びＳ４３で取得されたデータとが一致するか判断する。
【００４７】
そして、リクエスト受信部３２は、アクセス許可情報にステップＳ４１及びＳ４３で取得されたデータが含まれる、すなわちアクセス許可ありであるか判断する（ステップＳ４７）。許可がない場合には端子Ａを介してステップＳ６７に移行する。一方、アクセス許可ありと判断された場合、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダのX-RelayURIフィールドから中継ＵＲＩのパス部分を抽出する（ステップＳ４９）。そして、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、抽出された中継ＵＲＩに該当するエントリを受信待機パス一覧から取得するように依頼し、Ｗｅｂサービス制御部３３から結果を取得する（ステップＳ５１）。
【００４８】
受信待機パス一覧格納部３８に格納されている受信待機パス一覧の一例を図２２に示す。図２２の例では、中継ＵＲＩと、アクセス許可ホスト名と、外部中継サーバ３についてのユーザＩＤと、外部中継サーバ３についてのパスワードと、内部中継サーバ１３に対する返信用ソケットＩＤと、ＳａａＳサーバ５のＷｅｂサービスに対する返信用ソケットＩＤとが登録されるようになっている。特定のユーザについて最初のＨＴＴＰリクエストが外部中継サーバ３に送信された場合には、まだ中継待機中パス一覧にはエントリが存在しない。一方、２回目のＨＴＴＰリクエストが外部中継サーバ３に送信された場合には、既に同様のエントリが中継待機中パス一覧に登録されている。
【００４９】
リクエスト受信部３２は、Ｗｅｂサービス制御部３３からの処理結果に基づき、該当エントリが中継待機中パス一覧に存在するか判断する（ステップＳ５３）。該当エントリが存在しない場合には、最初のＨＴＴＰリクエストであり、端子Ｂを介してステップＳ６１に移行する。一方、該当エントリが存在する場合には、２回目以降のＨＴＴＰリクエストであり、端子Ｃを介してステップＳ５５に移行する。２回目以降のＨＴＴＰリクエストについては、まだ実施されないので、ここでは、端子Ａ及び端子Ｂ以降の処理を説明する。
【００５０】
図２３の処理の説明に移行して、端子Ａの後に、リクエスト受信部３２は、リプライ送信部３７にエラー情報を内部中継サーバ１３へ送信させる（ステップＳ６７）。以下、詳細な説明を省略するが、内部中継サーバ１３では、エラー情報を受信すると、エラー情報を蓄積しておくと共に、管理者やユーザにメールその他の手法でエラー発生を通知する。
【００５１】
次に、端子Ｂの後に、リクエスト受信部３２は、受信したＨＴＴＰリクエストのヘッダにおけるX-AllowDomainフィールドから、アクセス許可ホスト名を抽出する（ステップＳ６１）。さらに、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、この中継ＵＲＩについての待機指示を出力する（ステップＳ６３）。Ｗｅｂサービス制御部３３は、ＳａａＳサーバ５から中継ＵＲＩについてのリクエストを待機する状態になる。なお、アクセス要求処理部３６も、ＳａａＳサーバ５からのこの中継ＵＲＩについてのリクエストを待機する。
【００５２】
さらに、リクエスト受信部３２は、中継ＵＲＩとアクセス許可ホスト名とユーザＩＤと内部中継サーバ１３に対する返信用ソケットＩＤとを含む中継ＵＲＩデータを出力して、受信待機パス一覧格納部３８に登録させる（ステップＳ６５）。図２４に、中継ＵＲＩデータの一例を示す。図２４の例では、内部中継サーバへの返信用ソケットＩＤと、ユーザＩＤ及びパスワードと、中継ＵＲＩのパスと、アクセス許可ホスト名とが含まれる。Ｗｅｂサービス制御部３３は、このような中継ＵＲＩデータを、図２２に示したテーブルに登録する。但し、この段階では、待機中であるから、ＳａａＳサーバ５のＷｅｂサービスに対する返信用ソケットＩＤは登録されない。
【００５３】
このようにして、ＳａａＳサーバ５からの社内Ｗｅｂサービスの呼び出しに係る、所定の中継ＵＲＩについてのＨＴＴＰリクエストを待機する状態になる。
【００５４】
次に、図２５乃至図２７を用いて、ＳａａＳサーバ５から所定の中継ＵＲＩについてのＨＴＴＰリクエストを受信した際の処理を説明する。まず、外部中継サーバ３のＷｅｂサービスリクエスト受信部３５は、ＳａａＳサーバ５のＳａａＳアプリケーション５０１から、所定の中継ＵＲＩについてのＨＴＴＰリクエストを受信する。このＨＴＴＰリクエストの一例を図２５に示す。図２５の例では、このＨＴＴＰリクエストのヘッダには、ＧＥＴメソッドで、部門Ａユーザ端末１１のユーザについての中継ＵＲＩのパス部分”/usr/usr1/zaiko”とパラメータ部分”?code=1256”とが含まれる。さらに、このＨＴＴＰリクエストのヘッダには、外部中継サーバ３のホスト名”myproxy.com”と、外部中継サーバ３に対する認証情報（ユーザＩＤ及びパスワードを連結した上でBASE64でエンコードしたもの）と、メッセージ・ボディの長さ”Content-Length:0”とが含まれている。
【００５５】
そして、アクセス要求処理部３６は、Ｗｅｂサービスリクエスト受信部３５からＨＴＴＰリクエスト自体、アクセス元（ＳａａＳサーバ５）のＩＰアドレス及び当該受信ＨＴＴＰリクエストのためのソケットのソケットＩＤ（ＳａａＳサーバ５のＷｅｂサービスに対する返信用ソケットＩＤ）を取得する（図２６：ステップＳ７１）。
【００５６】
その後、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信ＨＴＴＰリクエストに含まれる中継ＵＲＩで受信待機パス一覧を検索させ（ステップＳ７３）、該当エントリを読み出させる。なお、Ｗｅｂサービスに対する返信用ソケットＩＤが登録されていないエントリを抽出する。該当エントリがあれば、これでこの中継ＵＲＩについての待機状態から復帰する。そして、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３から結果を取得し、該当エントリが存在するか確認し（ステップＳ７５）、該当エントリが存在しない場合には、端子Ｄを介してステップＳ９１に移行する。該当エントリがない場合には中継できない。
【００５７】
一方、該当エントリが存在する場合には、アクセス要求処理部３６は、ＤＮＳからアクセス元ＩＰアドレスに対するホスト名を取得する（ステップＳ７７）。そして、アクセス要求処理部３６は、アクセス元のホスト名と該当エントリ内のアクセス許可ホスト名とが一致するか判断する（ステップＳ７９）。不一致の場合には、中継できないので端子Ｄを介してステップＳ９１に移行する。一方、アクセス元のホスト名と該当エントリ内のアクセス許可ホスト名とが一致する場合には、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダのAuthorizationフィールドから、ユーザＩＤ及びパスワードを抽出する（ステップＳ８１）。
【００５８】
そして、アクセス要求処理部３６は、抽出したユーザＩＤと該当エントリに含まれるユーザＩＤとが一致するか判断する（ステップＳ８３）。一致しない場合には、端子Ｄを介してステップＳ９１に移行する。一方、一致する場合には、端子Ｅを介して図２７の処理に移行する。
【００５９】
図２７の処理の説明に移行して、端子Ｅの後に、アクセス要求処理部３６は、ＨＴＴＰリクエストから抽出したユーザＩＤ及びパスワードが、該当エントリのユーザＩＤ及びパスワードと一致するか判断する（ステップＳ８５）。一致しない場合にはステップＳ９１に移行する。一方、一致する場合には、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信待機パス一覧の該当エントリに、ステップＳ４１で取得されたＷｅｂサービスに対するソケットＩＤを、Ｗｅｂサービスに対する返信用ソケットＩＤとして登録させる（ステップＳ８７）。これにて、社内Ｗｅｂサービスを提供する在庫管理システム１５からレスポンスを受信した際に用いるデータが受信待機パス一覧に用意されたことになる。
【００６０】
そして、アクセス要求処理部３６は、リプライ送信部３７に、内部中継サーバ１３のためのソケットＩＤ（該当エントリにおける内部中継サーバ１３に対する返信用ソケットＩＤ）と、受信したＨＴＴＰリクエストのデータを出力し、社内Ｗｅｂサービス呼び出しとしてＨＴＴＰレスポンスを内部中継サーバ１３へ送信させる（ステップＳ８９）。リプライ送信部３７は、社内Ｗｅｂサービス呼び出しとしてのＨＴＴＰレスポンスを生成して、内部中継サーバ１３へ送信する。具体的な処理については、図２８及び図２９を用いて説明する。
【００６１】
なお、端子Ｄの後には、アクセス要求処理部３６は、Ｗｅｂサービスリプライ送信部３４に、エラー通知をＳａａＳサーバ５へ返信するように指示する（ステップＳ９１）。Ｗｅｂサービスリプライ送信部３４は、指示に応じてエラー通知をＳａａＳサーバ５へ返信する。この処理については主要部ではないのでこれ以上述べない。
【００６２】
このような処理を行えば、ＳａａＳサーバ５からの社内Ｗｅｂサービス呼び出しに対応する待機中の適切なＨＴＴＰリクエストを特定でき、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスを生成できるようになる。
【００６３】
このＨＴＴＰレスポンスの生成及び送信についての外内リプライ送信処理について図２８及び図２９を用いて説明する。
【００６４】
リプライ送信部３７は、アクセス要求処理部３６から受信したデータに含まれるアクセス元のＩＰアドレスを、ＨＴＴＰレスポンスのヘッダにおけるX-RequestHostフィールドに設定する（ステップＳ１０１）。また、リプライ送信部３７は、受信したＨＴＴＰリクエストのデータに含まれるコマンド名（メソッド名）を、ＨＴＴＰレスポンスのヘッダにおけるX-Commandフィールドに設定する（ステップＳ１０３）。さらに、リプライ送信部３７は、受信したデータに含まれる中継ＵＲＩのパスに付加されているパラメータをX-Argumentsフィールドに設定する（ステップＳ１０５）。また、リプライ送信部３７は、受信したＨＴＴＰリクエストのヘッダの各フィールドを、X-OrigHeader-を前置して設定する（ステップＳ１０７）。最後に、リプライ送信部３７は、このようにして生成されたＨＴＴＰレスポンスを、内部中継サーバ１３に対する返信用ソケットＩＤを用いて、内部中継サーバ１３へ送信する（ステップＳ１０９）。
【００６５】
例えば図２９に示すようなＨＴＴＰレスポンスが生成される。図２９の例では、ＨＴＴＰレスポンスでは、ＳａａＳサーバ５のＩＰアドレスがX-RequestHostフィールドに設定され、受信したＨＴＴＰリクエストのコマンド（メソッド）名がX-Commandフィールドに設定され、中継ＵＲＩにおけるパラメータ”?code=1256”を例えばBASE64でエンコードした値をX-Argumentsフィールドに設定し、受信したＨＴＴＰリクエストに含まれる認証データをX-OrigHeader-の後に設定し、さらにメッセージボディのサイズをX-OrigHeaderフィールドに設定している。図２９には含まれていないが、中継ＵＲＩのパス自体を、このＨＴＴＰレスポンスに含めるようにしても良い。さらに、ＳａａＳサーバ５からのＨＴＴＰリクエストに含まれた認証データについては含めないようにしても良い。
【００６６】
次に、図３０乃至図３７を用いて、内部中継サーバ１３が、社内Ｗｅｂサービス呼び出しとしてのＨＴＴＰレスポンスを受信した際の処理について説明する。まず、リプライ受信部１３７２は、外部中継サーバ３からＨＴＴＰレスポンスを受信すると、そのＨＴＴＰレスポンスのソケットＩＤやセッションＩＤなどから、対応するＨＴＴＰリクエスト送信時のセッション情報を特定する（ステップＳ１１１）。なお、外部インタフェース部１３７が保持しているセッション情報を特定するか、当該ソケットＩＤ等と対応付けて保持している中継ＵＲＩ等のキーをセッション管理部１３６に出力して、セッション管理部１３６にセッション一覧情報格納部１３５から抽出させるようにしてもよい。リプライ受信部１３７２は、特定したセッション情報を、受信したＨＴＴＰレスポンスのデータと共にアクセス要求処理部１３８に出力する。ここでは、例えば図１７の第１行目に相当する図３１のようなセッション情報が特定されたものとする。
【００６７】
アクセス要求処理部１３８は、ＨＴＴＰレスポンスのデータ及びセッション情報を取得すると、当該ＨＴＴＰレスポンスのヘッダから、アクセス元のＩＰアドレスを抽出する（ステップＳ１１３）。そして、アクセス要求処理部１３８は、アクセス元のＩＰアドレスに対応するホスト名をＤＮＳから取得し、抽出したＩＰアドレスに対応するホスト名と、セッション情報に含まれるアクセス許可ホスト名と一致するか判断する（ステップＳ１１５）。一致しない場合には、以後の処理を実施することはできないので、アクセス要求処理部１３８は、リクエスト送信部１３７１に、アクセス拒否通知を外部中継サーバ３へ送信させる（ステップＳ１１７）。そして端子Ｆを介して処理を終了する。
【００６８】
なお、例えばＨＴＴＰレスポンスに中継ＵＲＩのパス名を含めておき、セッション情報に含まれる中継ＵＲＩのパス名と比較するようにしても良い。
【００６９】
一方、抽出したＩＰアドレスに対応するホスト名とセッション情報に含まれるアクセス許可ホスト名とが一致する場合、アクセス要求処理部１３８は、セッション情報から社内ＷｅｂサービスＵＲＩ及びユーザＩＤを抽出する（ステップＳ１１９）。また、アクセス要求処理部１３８は、抽出された社内ＷｅｂサービスＵＲＩ及びユーザＩＤを用いて、接続認証情報から社内Ｗｅｂサービスに対するユーザＩＤ及びパスワードを抽出する（ステップＳ１２１）。例えば接続認証情報格納部１３９に格納されているデータの一例を図３２に示す。図３２の例では、ユーザＩＤと、社内ＷｅｂサービスＵＲＩと、社内ＷｅｂサービスのためのユーザＩＤ及びパスワードとが登録されるようになっている。なお、このデータは、予め内部中継サーバ１３の管理者等によって登録しておく。
【００７０】
さらに、アクセス要求処理部１３８は、この処理において抽出されたデータ、ＨＴＴＰレスポンスのヘッダ中のコマンド及びパラメータ等をＷｅｂサービスリクエスト送信部１４１１に出力して、社内Ｗｅｂサービスの呼び出しを行わせる（ステップＳ１２３）。そして、アクセス要求処理部１３８は、Ｗｅｂサービスリプライ受信部１４１２からのレスポンスを待機する（ステップＳ１２５）。ここまでが、外部中継サーバ３からＨＴＴＰレスポンスを受信した後に、在庫管理システム１５などへＨＴＴＰリクエストを送信するまでの処理である。端子Ｊ以降の処理は、在庫管理システム１５などからレスポンスを受信した後の処理であるので、後で説明する。
【００７１】
次に、図３３を用いて、Ｗｅｂサービスリクエスト送信部１４１１の処理について説明する。Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスのヘッダにおけるX-Commandフィールドから、コマンド種別（メソッド種別）を取得し、送信すべきＨＴＴＰリクエストのヘッダに設定する（ステップＳ１３１）。また、Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスのヘッダにおけるX-Argumentsフィールドの値をBASE64でデコードして、ＵＲＩに付加すべきパラメータを復元する（ステップＳ１３３）。そして、Ｗｅｂサービスリクエスト送信部１４１１は、受信した社内ＷｅｂサービスＵＲＩのパスに、復元したパラメータを付加し、送信すべきＨＴＴＰリクエストのヘッダに設定する（ステップＳ１３５）。
【００７２】
また、Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスにX-OrigHeader-が前置されたフィールドがあれば、X-OrigHeader-を削除した上で、送信すべきＨＴＴＰリクエストヘッダに設定する（ステップＳ１３７）。さらに、Ｗｅｂサービスリクエスト送信部１４１１は、送信すべきＨＴＴＰリクエストのヘッダのHostフィールドに、社内Ｗｅｂサービスのホスト名（アクセス許可ホスト名）を設定する（ステップＳ１３９）。処理は端子Ｌを介して図３４の処理に移行する。
【００７３】
図３４の処理の説明に移行して、Ｗｅｂサービスリクエスト送信部１４１１は、受信した接続認証情報から、上で抽出されたユーザＩＤ及びパスワードを、BASE64でエンコードした上で、Authorizationフィールドに設定する（ステップＳ１４１）。ステップＳ１３７で、X-OrigHeader-を削除した場合にAuthorizationフィールドが出現するのであれば、値をステップＳ１４１でエンコードした値で上書きする。さらに、Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスのヘッダに付加されたデータ（メッセージボディのデータ）を、送信すべきＨＴＴＰリクエストのヘッダ以降に追加する（ステップＳ１４３）。
【００７４】
最後に、Ｗｅｂサービスリクエスト送信部１４１１は、このようにして生成されたＨＴＴＰリクエストを、在庫管理システム１５に送信する（ステップＳ１４５）。
【００７５】
例えば図３５のようなＨＴＴＰリクエストが生成される。ＳａａＳサーバ５から送信されてくるＨＴＴＰリクエスト（図２５）と比較すると、Authorizationフィールドの値以外は同一であり、内部中継サーバ１３により、ＳａａＳサーバ５が送信してきたＨＴＴＰリクエストを適切な形式で復元したことになる。このようにして、ＳａａＳサーバ５による社内Ｗｅｂサービス呼び出しが、外部中継サーバ３及び内部中継サーバ１３を介して行われたことになる。
【００７６】
社内Ｗｅｂサービスの一つである在庫管理システム１５の処理内容については従来と同じであり、ここでは説明を省略する。ここでは、図３６に示すようなＨＴＴＰレスポンスが、在庫管理システム１５から送られてきて、Ｗｅｂサービスリプライ受信部１４１２がそのＨＴＴＰレスポンスを受信するものとする。図３６の例では、ＨＴＴＰレスポンスのヘッダに、ＸＭＬ（eXtensible Markup Language）によるメッセージボディが添付されている。
【００７７】
Ｗｅｂサービスリプライ受信部１４１２は、このＨＴＴＰレスポンスをアクセス要求処理部１３８に出力する。そうすると、図３０の端子Ｊ以降の処理が実施される。
【００７８】
端子Ｊを介して図３７の処理の説明に移行して、アクセス要求処理部１３８は、Ｗｅｂサービスリプライ受信部１４１２からＨＴＴＰレスポンスのデータを受信して、メインメモリ等の記憶装置に格納する（ステップＳ１５１）。そして、アクセス要求処理部１３８は、受信したＨＴＴＰレスポンスのデータ及び当該ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストについて該当するセッション情報を、外部インタフェース部１３７に出力する（ステップＳ１５３）。
【００７９】
次に、図３８乃至図４０を用いて、社内ＷｅｂサービスからのＨＴＴＰレスポンスをＨＴＴＰリクエストとして外部中継サーバ３に送信する際の処理について説明する。この処理の一部は図１８と同じである。
【００８０】
内部中継サーバ１３の外部インタフェース部１３７は、アクセス要求処理部１３８からセッション情報を受信し（ステップＳ１６１）、メインメモリ等の記憶装置に格納しておく。このセッション情報は、外部中継サーバ３との通信で用いるセッションＩＤとソケットＩＤとのうち少なくともいずれかなどによって管理しておく。そして、リクエスト送信部１３７及びリプライ受信部１３７２で共用する。又は、セッション情報のうち少なくともＷｅｂサービス中継ＵＲＩ等キーとなるデータと、セッションＩＤとソケットＩＤとのうち少なくともいずれかなどとを関連付けて保持しておく。
【００８１】
リクエスト送信部１３７１は、セッション情報から外部中継サーバ名を抽出し、今回送信するＨＴＴＰリクエストの宛先ホストに設定すると共に、宛先ホストの所定のパス（ここでは/control/index.html）もＨＴＴＰリクエストのパス名として設定する（ステップＳ１６３）。
【００８２】
さらに、リクエスト送信部１３７１は、セッション情報から外部中継サーバ３に対するユーザＩＤ及びパスワードを抽出し、ＨＴＴＰリクエストのAuthorizationフィールドに設定する（ステップＳ１６５）。また、リクエスト送信部１３７１は、セッション情報からＷｅｂサービス中継ＵＲＩのパス部分を抽出し、ＨＴＴＰリクエストのX-RelayURIフィールドに設定する（ステップＳ１６７）。そして、リクエスト送信部１３７１は、セッション情報からアクセス許可ホスト名を抽出し、X-AllowDomainフィールドに設定する（ステップＳ１６９）。処理は端子Ｇを介して図３９の処理に移行する。
【００８３】
図３９の処理の説明に移行して、リクエスト送信部１３７１は、受信したＨＴＴＰリクエストのヘッダを、X-OrigHeader-を前置して、送信すべきＨＴＴＰリクエストのヘッダに設定する（ステップＳ１７１）。さらに、リクエスト送信部１３７１は、受信したＨＴＴＰリクエストに添付されているデータ部分（メッセージボディ部分）を、送信すべきＨＴＴＰリクエストのヘッダの後ろに追加する（ステップＳ１７３）。このようにしてセッション情報及び在庫管理システム１５からのＨＴＴＰレスポンスからＨＴＴＰリクエストが生成されたことになる。
【００８４】
そして、リクエスト送信部１３７１は、生成されたＨＴＴＰリクエストを外部中継サーバ３に送信する（ステップＳ１７５）。なお、リクエスト送信部１３７１は、リプライ受信部１３７２に対して、レスポンスの待機を指示する（ステップＳ１７７）。リプライ受信部１３７２は、上で述べたようにＨＴＴＰリクエスト送信時のセッションＩＤやソケットＩＤを保持しておき、今回送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを識別できるようにする。
【００８５】
図４０に、ステップＳ１７５で外部中継サーバ３に送信されるＨＴＴＰリクエストの一例を示す。図４０の例では、ＰＯＳＴメソッド（コマンド）が定義されており、パス名は”/control/index.html”が設定されている。また、ホスト名には、外部中継サーバ３のホスト名”myproxy.com”が設定されている。Authorizationフィールドには、ユーザＩＤ及びパスワードを連結した上でBASE64でエンコードしたものが設定されている。X-RelayURIフィールドには、上で述べたように中継ＵＲＩのパス部分”/usr/usr1/zaiko”が設定されており、X-AllowDomainフィールドにはアクセス許可ホスト名”saasapps.com”が設定されている。さらに、ＨＴＴＰレスポンスには、Dateフィールドが存在していたので、X-OrigHeader-が前置されているが、Dateフィールドのデータも設定されている。さらに、ＨＴＴＰレスポンスのボディのデータも、ＨＴＴＰリクエストのボディに設定されている。
【００８６】
このようにして社内ＷｅｂサービスのレスポンスであるＨＴＴＰリクエストが内部中継サーバ１３から外部中継サーバ３へ送信される。
【００８７】
外部中継サーバ３のリクエスト受信部３２は、ＨＴＴＰリクエストを内部中継サーバ１３から受信して、図２０及び図２３の処理を実施する。図２０及び図２３の一部については最初のＨＴＴＰリクエスト受信時と同じ処理であるが、再度図４０のＨＴＴＰリクエストを受信したものとして説明する。
【００８８】
外部中継サーバ３のリクエスト受信部３２は、内部中継サーバ１３からＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストのソケットから送信元のＩＰアドレス及びソケットＩＤを取得する（ステップＳ４１）。さらに、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダからユーザＩＤ及びパスワードを抽出する（ステップＳ４３）。そして、リクエスト受信部３２は、送信元ＩＰアドレス、ユーザＩＤ及びパスワードのセットがアクセス許可情報格納部３１に格納されているアクセス許可情報に含まれるか確認する（ステップＳ４５）。
【００８９】
そして、リクエスト受信部３２は、アクセス許可情報にステップＳ４１及びＳ４３で取得されたデータが含まれる、すなわちアクセス許可ありであるか判断する（ステップＳ４７）。許可がない場合には端子Ａを介してステップＳ６７に移行する。一方、アクセス許可ありと判断された場合、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダのX-RelayURIフィールド及びHostフィールドから中継ＵＲＩを抽出する（ステップＳ４９）。そして、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、抽出された中継ＵＲＩに該当するエントリを受信待機パス一覧から取得するように依頼し、Ｗｅｂサービス制御部３３から結果を取得する（ステップＳ５１）。
【００９０】
リクエスト受信部３２は、Ｗｅｂサービス制御部３３からの処理結果に基づき、該当エントリが中継待機中パス一覧に存在するか判断する（ステップＳ５３）。２度目のＨＴＴＰリクエストであるから、今回は通常であれば該当エントリが存在する。該当エントリが存在する場合には、２回目以降のＨＴＴＰリクエストであり、端子Ｃを介してステップＳ５５に移行する。
【００９１】
図２３の処理の説明に移行して、端子Ｃの後に、リクエスト受信部３２は、抽出されたエントリのユーザＩＤとＨＴＴＰリクエストのヘッダから抽出されたユーザＩＤが一致するか判断する（ステップＳ５５）。一致しない場合には、何らかの問題が発生したということで、ステップＳ６７に移行する。
【００９２】
一方、抽出されたエントリのユーザＩＤとＨＴＴＰリクエストのヘッダから抽出されたユーザＩＤが一致する場合には、リクエスト受信部３２は、さらに抽出されたエントリにＷｅｂサービスのためのソケットＩＤが設定されているか判断する（ステップＳ５７）。このソケットＩＤが設定されていないと、ＳａａＳサーバ５にレスポンスを返すことができないので、このソケットＩＤが設定されていない場合には、ステップＳ６７に移行する。
【００９３】
このソケットＩＤがエントリに設定されている場合には、リクエスト受信部３２は、ＨＴＴＰリクエストのデータを含むリクエスト応答指示をアクセス要求処理部３６に出力する（ステップＳ５９）。これによって、ＳａａＳサーバ５への応答を送信する準備に入る。
【００９４】
さらに、リクエスト受信部３２は、受信したＨＴＴＰリクエストのヘッダにおけるX-AllowDomainフィールドから、アクセス許可ホスト名を抽出する（ステップＳ６１）。また、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、待機指示を出力する（ステップＳ６３）。Ｗｅｂサービス制御部３３は、ＳａａＳサーバ５から中継ＵＲＩについてのリクエストを待機する状態になる。なお、アクセス要求処理部３６も、ＳａａＳサーバ５からのこの中継ＵＲＩについてのリクエストを待機する。
【００９５】
さらに、リクエスト受信部３２は、中継ＵＲＩとアクセス許可ホスト名とユーザＩＤと内部中継サーバ１３に対する返信用ソケットＩＤとを含む中継ＵＲＩデータを出力して、Ｗｅｂサービス制御部３３に受信待機パス一覧格納部３８へ登録させる（ステップＳ６５）。この段階で、Ｗｅｂサービスに対する返信用ソケットＩＤが登録されていないエントリと登録されているエントリのほぼ同一の２つのエントリが登録されることになる。
【００９６】
このようにして、アクセス要求処理部３６に処理を要求した上で、ＳａａＳサーバ５のＳａａＳアプリケーション５０１からの次のＨＴＴＰリクエストを待機する状態になる。
【００９７】
なお、ステップＳ５５及びＳ５７でエラーを検出した場合及び端子Ａの後に、リクエスト受信部３２は、リプライ送信部３７にエラー情報を内部中継サーバ１３へ送信させる（ステップＳ６７）。
【００９８】
次に、図４１及び図４２を用いて、外部中継サーバ３からＳａａＳサーバ５へＨＴＴＰレスポンスを送信するための処理について説明する。アクセス要求処理部３６は、リクエスト受信部３２からＨＴＴＰリクエストデータを受信し、メインメモリ等の記憶装置に格納する（ステップＳ１８１）。そして、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダにおけるX-RelayURIフィールドから中継ＵＲＩのパスを抽出すると共に、ホスト名をも抽出する（ステップＳ１８３）。また、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信待機中パス一覧において、抽出された中継ＵＲＩのパス＋ホスト名を中継ＵＲＩとして含み且つＷｅｂサービスのためのソケットＩＤが登録済みのエントリが存在するか判断させる（ステップＳ１８５）。Ｗｅｂサービス制御部３３は、指示に従って受信待機パス一覧格納部３８を検索して、該当エントリがあればアクセス要求処理部３６に出力し、該当エントリがなければ該当エントリがない旨をアクセス要求処理部３６に出力する。
【００９９】
アクセス要求処理部３６は、Ｗｅｂサービス制御部３３からの結果を受信して、該当エントリが存在するか判断する（ステップＳ１８７）。該当エントリが存在しない場合には、何らかのエラーが発生しているので、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのデータを破棄する（ステップＳ１８９）。そして、端子Ｉを介して本処理を終了する。
【０１００】
一方、該当するエントリが存在する場合には、アクセス要求処理部３６は、受信待機パス一覧内の該当エントリからＷｅｂサービスのためのソケットＩＤを抽出する（ステップＳ１９１）。また、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダ中のX-OrigHeader-が前置されているフィールドの名前及びその値を抽出し、送信すべきＨＴＴＰレスポンスのヘッダのフィールドとして設定する（ステップＳ１９３）。処理は、端子Ｈを介して図４２の処理に移行する。
【０１０１】
図４２の処理の説明に移行して、端子Ｈの後に、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダ以降のデータを、送信すべきＨＴＴＰレスポンスのデータ（メッセージボディのデータ）として設定する（ステップＳ１９５）。そして、アクセス要求処理部３６は、Ｗｅｂサービスリプライ送信部３４に、ＷｅｂサービスのためのソケットＩＤを用いて、生成されたＨＴＴＰレスポンスをＳａａＳサーバ５へ送信するように指示する（ステップＳ１９７）。Ｗｅｂサービスリプライ送信部３４は、生成されたＨＴＴＰレスポンスのデータを受信して、同じく受信したＷｅｂサービスのためのソケットＩＤを用いて、ＳａａＳサーバ５へＨＴＴＰレスポンスを返信する。なお、ここで送信されるＨＴＴＰレスポンスは、図３６に示したＨＴＴＰレスポンスと同じである。図３６は、在庫管理システム１５から受信したＨＴＴＰレスポンスであり、これによって外部中継サーバ３においてＨＴＴＰレスポンスが復元されて、ＳａａＳサーバ５へ送信されたことになる。ＳａａＳサーバ５では、あたかも直接社内Ｗｅｂサービスからのレスポンスを受信したように見えるため、そのまま処理を行うことができる。
【０１０２】
なお、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信待機パス一覧から、今回用いたエントリを削除するように指示する（ステップＳ１９９）。Ｗｅｂサービス制御部３３は、アクセス要求処理部３６からの指示に応じて、該当エントリを受信待機パス一覧格納部３８から削除する。
【０１０３】
以上のような処理を実施することによって、ファイアウォール外部からファイアウォール内部のＷｅｂサービスを利用することができるようになる。よって、ＳａａＳサーバ５の利用拡大が期待される。
【０１０４】
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、外部中継サーバ３及び内部中継サーバ１３の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。また、ＳａａＳサーバ５で提供されるＷｅｂサービスと社内Ｗｅｂサービスとの組み合わせは、任意であって上で述べたものは一例に過ぎない。さらに、処理フローについても、処理結果が変わらない限りステップの順番を入れ替えたり、並列に実行するようにすることもできる。例えばヘッダの設定順番はＨＴＴＰの定義に従っている限りにおいては特に問題はない。
【０１０５】
なお、上で述べた外部中継サーバ３及び内部中継サーバ１３並びに他のサーバなどは、コンピュータ装置であって、図４３に示すように、メモリ２５０１とプロセッサ（ＣＰＵ２５０３）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【０１０６】
以上述べた本実施の形態をまとめると、以下のようになる。
【０１０７】
本実施の形態における第１の態様に係る中継処理方法は、ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１のサービス提供サーバに対して処理を要求する端末から第１のサービス提供サーバを第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、（Ｂ）リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して第１中継サーバに送信するステップと、（Ｃ）第１中継サーバから、第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして第１のサービス提供サーバからの処理リクエストを受信するステップと、（Ｄ）処理リクエストを第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、（Ｅ）第２のサービス提供サーバから、第２のリクエストに対する応答データを受信するステップと、（Ｆ）応答データを、第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、第１中継サーバに送信するステップとを含む。
【０１０８】
このようにすればファイアウォールによって通常であれば利用することができないファイアウォール内部の第２のサービス提供サーバを、ファイアウォール外部の第１のサービス提供サーバから利用できるようになる。
【０１０９】
なお、上で述べた第２ＨＴＴＰリクエストが、所定の中継ＵＲＩについてのＨＴＴＰリクエストである場合もある。このようにすれば、さらに連続して第１のサービス提供サーバからファイアウォール内部の第２のサービス提供サーバにリクエストを送信する場合にも対処できるようになる。
【０１１０】
本実施の形態における第２の態様に係る中継処理方法は、ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して受信するステップと、（Ｂ）第１ＨＴＴＰリクエストの受信に応答して、所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するのを待機するステップと、（Ｃ）所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するステップと、（Ｄ）第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、第１中継サーバに送信するステップと、（Ｅ）第１中継サーバから、第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、（Ｆ）第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれるレスポンスのためのデータを用いて、第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、第１中継サーバに送信するステップとを含む。
【０１１１】
このようにすればファイアウォールの設定を変更することなく、ファイルウォール外部の第１のサービス提供サーバからファイアウォール内部の第２のサービス提供サーバを利用することができるようになる。
【０１１２】
なお、上で述べた第３ＨＴＴＰリクエストが、所定の中継ＵＲＩについてのＨＴＴＰリクエストである場合もある。その場合、第３ＨＴＴＰリクエストの受信に応答して、所定の中継ＵＲＩについての第４ＨＴＴＰリクエストを第１のサービス提供サーバから受信するのを待機するステップをさらに含むようにしてもよい。１回だけではなく複数回ファイアウォール外部の第１のサービス提供サーバからファイアウォール内部の第２のサービス提供サーバへアクセスする場合に有用である。
【０１１３】
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。
【０１１４】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１１５】
（付記１）
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するステップと、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するステップと、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【０１１６】
（付記２）
前記第２ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストである
付記１記載の中継処理方法。
【０１１７】
（付記３）
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するステップと、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップと、
前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するステップと、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【０１１８】
（付記４）
前記第３ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストであり、
前記第３ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第４ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップ
をさらに含む付記３記載の中継処理方法。
【０１１９】
（付記５）
付記１乃至４のいずれか１つ記載の中継処理方法をコンピュータに実行させるためのプログラム。
【０１２０】
（付記６）
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる内部中継サーバであって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するリクエスト受信部と、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するリクエスト送信部と、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するリプライ受信部と、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するサービスリクエスト送信部と、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するサービスリプライ受信部と、
を有し、
前記リクエスト送信部が、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信する
内部中継サーバ。
【０１２１】
（付記７）
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる外部中継サーバであって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するリクエスト受信部と、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機した後、前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するサービスリクエスト受信部と、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するリプライ送信部と、
を有し、
前記リクエスト受信部が、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信し、
前記外部中継サーバが、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するサービスリプライ送信部、
をさらに有する外部中継サーバ。
【符号の説明】
【０１２２】
１ インターネット ３ 外部中継サーバ
５ ＳａａＳサーバ ７ ファイアウォール
９ 内部ネットワーク １１ 部門Ａユーザ端末
１３ 内部中継サーバ １５ 在庫管理システム
３１ アクセス許可情報格納部 ３２ リクエスト受信部
３３ Ｗｅｂサービス制御部
３４ Ｗｅｂサービスリプライ送信部
３５ Ｗｅｂサービスリクエスト受信部
３６ アクセス要求処理部
３７ リプライ送信部
３８ 受信待機中パス一覧格納部
１３１ リクエスト受信部 １３２ リプライ送信部
１３３ ユーザ情報格納部 １３４ 接続情報管理部
１３５ セッション一覧情報格納部 １３６ セッション管理部
１３７ 外部インタフェース部 １３８ アクセス要求処理部
１３９ 接続認証情報格納部
１４０ 社内Ｗｅｂサービスインタフェース部
１４１１ Ｗｅｂサービスリクエスト送信部
１４１２ Ｗｅｂサービスリプライ受信部
１３７１ リクエスト送信部 １３７２ リプライ受信部
【技術分野】
【０００１】
本技術は、外部のウェブ（Ｗｅｂ）アプリケーションからファイアウォールを介してファイアウォール内部のサービスを呼び出すための技術に関する。
【背景技術】
【０００２】
従来、コンピュータプログラムを利用する際には、プログラムを記録した記録媒体又はプログラムの使用権を購入し、自分の所有するコンピュータにインストールを行ってから実行するのが普通であった。しかし、近年、このような事前の購入やインストールを行うことなく、Ｗｅｂブラウザでプログラム提供者のＷｅｂサイトにアクセスし、使用料を支払うだけでプログラムを利用するという形態が注目を集めている。このような提供形態はＡＳＰ（Application Service Provide）やＳａａＳ（Software as a Service）と呼ばれ、ソフトウェアをサービスとして提供し、サービスの利用料として対価を得るという点で、これまでのソフトウェア提供モデルとは異なった特徴がある。
【０００３】
図１に示すように、ＳａａＳのためのサーバ（以下ＳａａＳサーバと呼ぶ）には、例えば顧客管理アプリケーション、サプライチェーン管理アプリケーションやグループウェアなどのアプリケーションが用意されており、さらにユーザ企業（例えば企業Ａ及びＢ）のデータをも保管されている。企業Ａ及びＢのユーザは、このＳａａＳサーバにインターネットなどを介してＷｅｂブラウザでアクセスして、利用契約を行ったアプリケーションを利用する。その処理結果のデータは、ユーザ端末に返信し、必要があればＳａａＳサーバ内に保管される。通常、各企業のシステムが接続されているイントラネット等の社内ネットワークとインターネットなどの外部ネットワークとの間にはファイアウォールが設けられており、外部ネットワークからのアクセスはブロックされる。
【０００４】
ＳａａＳアプリケーションは、ユーザ端末への事前のインストールを不要とするため、Ｗｅｂブラウザだけで実行できるＷｅｂアプリケーションと呼ばれる形態のプログラムとなっているのが通常である。図２に、典型的なＳａａＳアプリケーションの構成を模式的に示す。図２に示したように、ＳａａＳサーバには、Ｗｅｂアプリケーションの処理ロジック及びそのためのデータが保持されており、ユーザは、ユーザ端末を操作して、社内ネットワーク、ファイアウォール及びインターネットを経由してＳａａＳサーバにアクセスする。すなわち、ユーザ端末からＳａａＳサーバにリクエストを送信する。ＳａａＳサーバは、受信したリクエストに対するＷｅｂページを生成して、アクセス元のユーザ端末に送信する。このように外部ネットワークからのデータ送信であっても、リクエストに対する応答である場合には、ファイアウォールを越えることができる。ユーザ端末は、受信したＷｅｂページデータを表示装置に表示し、ユーザは、入力欄にデータを入力したり、ボタンをクリックするなどして、さらにリクエストをＳａａＳサーバに送信する。このような処理を繰り返すことによって、ＳａａＳサーバにＷｅｂアプリケーションの処理を行わせる。
【０００５】
ＳａａＳアプリケーションでは、セルフカスタマイズと呼ばれる、ユーザ自身がアプリケーションの機能の一部を変更することもよく行われている。これによってユーザは、アプリケーションで扱うデータの内容を追加・変更したり、データに関する処理をプログラム言語によって記述することができる。また、別のサイトが提供するＷｅｂサービスを呼び出してその結果を利用するようなことも可能となっている。例えばＳａａＳアプリケーションで商談情報を管理する際に、インターネット上で公開されている企業情報データベースを利用し、顧客企業の最新状況を表示するようなことが容易に実現できるようになっている。図３に模式的に示すように、ユーザはユーザ作成ロジックを追加で用意しておき、標準で提供される処理ロジックに加えて特別な処理を行わせる場合もある。さらに、ユーザ作成ロジックによって、他のＷｅｂサービス提供元サイトで提供されるＷｅｂサービスを呼び出し、そのＷｅｂサービスの応答を用いた処理を行う場合もある。
【０００６】
ＳａａＳアプリケーションは即座に利用を開始することができ、利用を中止することも容易であるため、小規模な企業だけでなく、大企業でも各部門や職場といった単位で、自分のニーズに応じたカスタマイズを行いながら利用するというスタイルが広まりつつある。
【０００７】
このような連携を、インターネット上の公開サービスだけではなく、イントラネット内の社内システムに対しても行いたいという要望がある。例えば、図４に示すように、ＳａａＳサーバにおける商談管理アプリケーションと社内の在庫管理システムとを連携させて商品の発注指示まで一緒に行いたいというようなニーズがある。しかしながら、インターネットからイントラネット内へのアクセスはセキュリティ上大きな問題となるため、ファイアウォールで遮断されるのが一般的である。従って、ファイアウォール外部のＳａａＳサーバで実行されるＳａａＳアプリケーションから、Ｗｅｂサービス呼び出しによって社内のＷｅｂサービス（例えば在庫管理サービス）を直接呼び出すことはできない。
【０００８】
このような問題に対して、図５及び図６に示すように、一般にＤＭＺ（Demilitarized Zone）と呼ばれるイントラネット内の隔離領域に中継サーバを配置し、このサーバがインターネットからのＷｅｂサービス呼び出しを受け付け、それをイントラネット内のＷｅｂサービスに中継する。図５に示すように、ＤＭＺ内の中継サーバは、予め定義されているポートやＵＲＬで外部（すなわちインターネット側）からの接続を待機する。そして、中継サーバは、予め定義されているポートやＵＲＬでアクセスされると、アクセス許可リストで、許可されているアクセスであるかを確認する。そして、図６に示すように、許可されているアクセスである場合には、中継サーバは、イントラネットに接続された社内サーバにアクセスを転送し、当該社内サーバからのレスポンスを、要求元の外部サーバに転送する。しかし、全社的なファイアウォールに対して特定のサーバからのアクセスを許可するといった設定変更が必要になり、セキュリティ上のリスクが高いことから、利用部門のみの権限では実施することができない。セキュリティ上のリスクが高いので、このような方法は好ましいものとは考えられていない。
【０００９】
さらに、イントラネット内とインターネット上にそれぞれ中継サーバを配置し、両者がセッションを維持しつつ専用プロトコルで通信することで、インターネット上の中継サーバがＷｅｂサービス呼び出しを受け付け、イントラネット内の中継サーバに中継する方法も提案されている。このような専用プロトコルを使用する場合にも、ＤＭＺの場合のようにファイアウォールに対して設定変更が必要となる。
【００１０】
さらに、イントラネットとＳａａＳサーバとの間を専用線接続又はＶＰＮ（Virtual Private Network）接続によって結び、この接続を経由してイントラネット内のＷｅｂサービスを呼び出すようにする方法も存在する。しかし、特別な回線を用意しなければならず、運用コストが高くなる。また、ＶＰＮ等の設定もセキュリティ上の問題を発生し得るものである。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００４−２９５１６６号公報
【特許文献２】特表２０００−５０５２７０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
従って、本技術の目的は、ファイアウォールに対して設定変更などを行わずに外部のＷｅｂアプリケーションからファイアウォール内部のサービスを呼び出すことができるようにするための技術を提供することである。
【課題を解決するための手段】
【００１３】
第１の態様に係る中継処理方法は、ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１のサービス提供サーバに対して処理を要求する端末から第１のサービス提供サーバを第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、（Ｂ）リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して第１中継サーバに送信するステップと、（Ｃ）第１中継サーバから、第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして第１のサービス提供サーバからの処理リクエストを受信するステップと、（Ｄ）処理リクエストを第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、（Ｅ）第２のサービス提供サーバから、第２のリクエストに対する応答データを受信するステップと、（Ｆ）応答データを、第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、第１中継サーバに送信するステップとを含む。
【００１４】
第２の態様に係る中継処理方法は、ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して受信するステップと、（Ｂ）第１ＨＴＴＰリクエストの受信に応答して、所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するのを待機するステップと、（Ｃ）所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するステップと、（Ｄ）第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、第１中継サーバに送信するステップと、（Ｅ）第１中継サーバから、第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、（Ｆ）第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれるレスポンスのためのデータを用いて、第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、第１中継サーバに送信するステップとを含む。
【発明の効果】
【００１５】
ファイアウォールに対して設定変更などを行わずに外部のＷｅｂアプリケーションからファイアウォール内部のサービスを呼び出すことができるようになる。
【図面の簡単な説明】
【００１６】
【図１】図１は、ＳａａＳについて説明するための図である。
【図２】図２は、ＳａａＳについて説明するための図である。
【図３】図３は、ＳａａＳについて説明するための図である。
【図４】図４は、従来技術の問題を説明するための図である。
【図５】図５は、従来技術を説明するための図である。
【図６】図６は、従来技術を説明するための図である。
【図７】図７は、システム全体の模式図である。
【図８】図８は、外部中継サーバの機能ブロック図である。
【図９】図９は、内部中継サーバの機能ブロック図である。
【図１０】図１０は、システムの処理の概要を説明するための図である。
【図１１】図１１は、システムの処理の概要を説明するための図である。
【図１２】図１２は、システムの処理の概要を説明するための図である。
【図１３Ａ】図１３Ａは、システムの処理の概要を説明するための図である。
【図１３Ｂ】図１３Ｂは、システムの処理の概要を説明するための図である。
【図１４】図１４は、部門Ａユーザ端末に表示される初期画面の一例を示す図である。
【図１５】図１５は、中継セッション開始リクエストを受信した際の処理の処理フローを示す図である。
【図１６】図１６は、ユーザ情報格納部に格納されるデータの一例を示す図である。
【図１７】図１７は、セッション一覧情報格納部に格納されるデータの一例を示す図である。
【図１８】図１８は、内部中継サーバから外部中継サーバへＨＴＴＰリクエストを最初に送信する際の処理の処理フローを示す図である。
【図１９】図１９は、内部中継サーバから外部中継サーバへ送信される最初のＨＴＴＰリクエストの例を示す図である。
【図２０】図２０は、外部中継サーバが内部中継サーバからリクエストを受信した際の処理の処理フローを示す図である。
【図２１】図２１は、アクセス許可情報格納部に格納されるデータの一例を示す図である。
【図２２】図２２は、受信待機中パス一覧格納部に格納されるデータの一例を示す図である。
【図２３】図２３は、外部中継サーバが内部中継サーバからリクエストを受信した際の処理の処理フローを示す図である。
【図２４】図２４は、中継ＵＲＩデータの一例を示す図である。
【図２５】図２５は、ＳａａＳサーバから受信するＨＴＴＰリクエストの一例を示す図である。
【図２６】図２６は、ＳａａＳサーバからＨＴＴＰリクエストを受信した際の処理の処理フローを示す図である。
【図２７】図２７は、ＳａａＳサーバからＨＴＴＰリクエストを受信した際の処理の処理フローを示す図である。
【図２８】図２８は、外部中継サーバから内部中継サーバへのＨＴＴＰレスポンスの生成及び送信の処理の処理フローを示す図である。
【図２９】図２９は、外部中継サーバから内部中継サーバへのＨＴＴＰレスポンスの一例を示す図である。
【図３０】図３０は、内部中継サーバが外部中継サーバから社内Ｗｅｂサービス呼び出しとしてのＨＴＴＰレスポンスを受信した際の処理の処理フローを示す図である。
【図３１】図３１は、特定されたセッション情報の一例を示す図である。
【図３２】図３２は、接続認証情報格納部に格納されるデータの一例を示す図である。
【図３３】図３３は、社内Ｗｅｂサービスを提供するサーバに対するＨＴＴＰリクエストを生成するための処理を説明するための図である。
【図３４】図３４は、社内Ｗｅｂサービスを提供するサーバに対するＨＴＴＰリクエストを生成するための処理を説明するための図である。
【図３５】図３５は、社内Ｗｅｂサービスを提供するサーバへのＨＴＴＰリクエストの一例を示す図である。
【図３６】図３６は、社内Ｗｅｂサービスを提供するサーバからのＨＴＴＰレスポンスの一例を示す図である。
【図３７】図３７は、社内Ｗｅｂサービスを提供するサーバからのＨＴＴＰレスポンスを受信した際の処理の処理フローを示す図である。
【図３８】図３８は、内部中継サーバから外部中継サーバへＨＴＴＰリクエストを２回目に送信する際の処理の処理フローを示す図である。
【図３９】図３９は、内部中継サーバから外部中継サーバへＨＴＴＰリクエストを２回目に送信する際の処理の処理フローを示す図である。
【図４０】図４０は、内部中継サーバから外部中継サーバへ送信される２度目のＨＴＴＰリクエストの例を示す図である。
【図４１】図４１は、外部中継サーバからＳａａＳサーバへＨＴＴＰレスポンスを送信する際の処理の処理フローを示す図である。
【図４２】図４２は、外部中継サーバからＳａａＳサーバへＨＴＴＰレスポンスを送信する際の処理の処理フローを示す図である。
【図４３】図４３は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１７】
図７に、本実施の形態に係るシステム全体の模式図を示す。例えばイントラネットである社内ネットワーク９とインターネット１とはファイアウォール７を介して接続されている。インターネット１には、ＳａａＳアプリケーション５０１を実行しているＳａａＳサーバ５と、本実施の形態において主要な処理を実施する外部中継サーバ３とが接続されている。ＳａａＳアプリケーション５０１は、例えば商談管理アプリケーション５１３と、社内Ｗｅｂサービス（ここでは在庫管理サービス）を呼び出す、ユーザ企業によるカスタマイズコード５１１とを含む。また、ＳａａＳサーバ５は、ユーザ企業の部門Ａの商談情報を蓄積する部門Ａ商談データベース（ＤＢ）５１を管理しており、ＳａａＳアプリケーション５０１の商談管理アプリケーション５１３はこの部門Ａ商談ＤＢ５１のデータを処理するようになっている。さらに、商談管理アプリケーション５１３を実行中、特定の場面においてカスタマイズコード５１１が実行され、当該カスタマイズコード５１１により在庫管理サービスも併せてユーザに提供されるようになる。なお、ＳａａＳサーバ５は、１以上のコンピュータで実施され、商談管理サービス以外のサービスを提供する場合もある。
【００１８】
また、社内ネットワーク９には、部門Ａのユーザが操作し且つＷｅｂブラウザを実行する複数の部門Ａユーザ端末１１と、本実施の形態の主要な処理を実施する内部中継サーバ１３と、通常は社内ネットワーク９からでしか使用できない在庫管理サービスを提供する在庫管理システム１５とが接続されている。
【００１９】
図８に、外部中継サーバ３の機能ブロック図を示す。外部中継サーバ３は、アクセス許可情報格納部３１と、リクエスト受信部３２と、Ｗｅｂサービス制御部３３と、受信待機中パス一覧格納部３８と、Ｗｅｂサービスリプライ送信部３４と、Ｗｅｂサービスリクエスト受信部３５と、アクセス要求処理部３６と、リプライ送信部３７とを有する。リクエスト受信部３２は、内部中継サーバ１３からリクエストを受信し、アクセス許可情報格納部３１に格納されているデータを用いて処理を行い、Ｗｅｂサービス制御部３３とアクセス要求処理部３６とリプライ送信部３７と連携する。リプライ送信部３７は、アクセス要求処理部３６とリクエスト受信部３２と連携して内部中継サーバ１３にレスポンスを送信する。また、Ｗｅｂサービス制御部３３は、受信待機中パス一覧格納部３８にデータを格納すると共にデータを読み出し、リクエスト受信部３２及びアクセス要求処理部３６と連携する。Ｗｅｂサービスリクエスト受信部３５は、ＳａａＳサーバ５からＷｅｂサービスリクエストを受信し、アクセス要求処理部３６に出力する。Ｗｅｂサービスリプライ送信部３４は、アクセス要求処理部３６からＷｅｂサービスリクエストに対するレスポンスのデータを受信し、ＳａａＳサーバに送信する。アクセス要求処理部３６は、リクエスト受信部３２、Ｗｅｂサービス制御部３３、Ｗｅｂサービスリクエスト受信部３５、Ｗｅｂサービスリプライ送信部３４及びリプライ送信部３７と連携して処理を実施する。
【００２０】
図９に、内部中継サーバ１３の機能ブロック図を示す。内部中継サーバ１３は、リクエスト受信部１３１と、リプライ送信部１３２と、ユーザ情報格納部１３３と、接続情報管理部１３４と、セッション一覧情報格納部１３５と、セッション管理部１３６と、外部インタフェース部１３７と、アクセス要求処理部１３８と、接続認証情報格納部１３９と、社内Ｗｅｂサービスインタフェース部１４０とを有する。リクエスト受信部１３１は、部門Ａユーザ端末１１からの中継セッション開始リクエストを受信し、接続情報管理部１３４に出力する。リプライ送信部１３２は、中継セッション開始リクエストに対応する応答を部門Ａユーザ端末１１に送信する。接続情報管理部１３４は、ユーザ情報格納部１３３に格納されているデータを用いて処理を行い、セッション管理部１３６と連携する。セッション管理部１３６は、セッション一覧情報格納部１３５に対してデータを格納すると共にデータを読み出し、接続情報管理部１３４、外部インタフェース部１３７及びアクセス要求処理部１３８と連携する。外部インタフェース部１３７は、外部中継サーバ３に対するインタフェースであり、リクエスト送信部１３７１及びリプライ受信部１３７２を有する。そして、外部インタフェース部１３７は、セッション管理部１３６とアクセス要求処理部１３８と連携する。アクセス要求処理部１３８は、接続認証情報格納部１３９に格納されているデータを用いて処理を行い、セッション管理部１３６と外部インタフェース部１３７と社内Ｗｅｂサービスインタフェース部１４０と連携する。社内Ｗｅｂサービスインタフェース部１４０は、社内システムの一例である在庫管理システム１５に対するインタフェースであり、Ｗｅｂサービスリクエスト送信部１４１１とＷｅｂサービスリプライ受信部１４１２とを有する。そして、社内Ｗｅｂサービスインタフェース部１４０は、アクセス要求処理部１３８と連携する。
【００２１】
次に、図１０乃至図１３Ｂを用いて、図７に示したシステムの処理の概要を説明する。まず、企業の部門Ａのユーザは、部門Ａユーザ端末１１を操作して、ＳａａＳサーバ５にアクセスさせる（図１０：ステップ（１））。例えばＳａａＳサーバ５のＵＲＩがsaasapps.comであるとすると、当該ＵＲＩにリクエストを送信する。このリクエストに応答して、ＳａａＳサーバ５のＳａａＳアプリケーション５０１は処理を開始する。上でも述べたように、ＳａａＳアプリケーション５０１は、商談管理アプリケーション５１３の通常の処理ロジックに加えて、カスタマイズコード５１１を含んでおり、ここでは、カスタマイズコード５１１には、予め定められた中継ＵＲＩであるhttp://myproxy.com/usr/usr1/zaikoに対して在庫管理のＷｅｂサービスを呼び出すコードが含まれるものとする。なお、インターネット１におけるＤＮＳ（Domain Name Server。図示せず。）には、この中継ＵＲＩのドメインに対して外部中継サーバのＩＰアドレスが登録されているものとする。
【００２２】
図１１の処理の説明に移行して、企業の部門Ａのユーザは、部門Ａユーザ端末１１を操作して、内部中継サーバ１３に対して、中継セッション開始リクエストを送信させる（図１１：ステップ（２））。内部中継サーバ１３は、中継セッション開始リクエストを受信すると、当該中継セッション開始リクエストを予め定められた中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストに変換する。そして、内部中継サーバ１３は、このＨＴＴＰリクエストを外部中継サーバ３に送信して、中継セッション開始を外部中継サーバ３に指示する（ステップ（３））。外部中継サーバ３は、このＨＴＴＰリクエストを受信すると、このＨＴＴＰリクエストに対してレスポンスを返すことなく、ＳａａＳサーバ５からの中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのリクエストを待機する（ステップ（４））。このようにファイアウォール内部から外部へリクエストを送信することによって、当該リクエストへのレスポンスとしてファイアウォール外部から内部にファイアウォールに遮断されることなくデータを送信することができるようになる。
【００２３】
図１２の処理の説明に移行して、そしてＳａａＳサーバ５において、ＳａａＳアプリケーション５０１のカスタマイズコード５１１が実行されるようになると、ＳａａＳサーバ５は、所定の中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストを、社内Ｗｅｂサービス呼び出しとして、外部中継サーバ３に送信する（図１２：ステップ（５））。外部中継サーバ３は、ＳａａＳサーバ５から所定の中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストを受信すると、処理しても良いＨＴＴＰリクエストであるかを確認する。その上で外部中継サーバ３は、ＳａａＳサーバ５からのＨＴＴＰリクエストを、内部中継サーバ１３から受信した、中継セッション開始指示についてのＨＴＴＰリクエストに対するレスポンスに変換し、内部中継サーバ１３に送信する（ステップ（６））。内部中継サーバ１３は、外部中継サーバ３から、ＨＴＴＰレスポンスの形式での、ＳａａＳサーバ５からのＨＴＴＰリクエストを、在庫管理システム１５に中継してもよいかその是非を判断する（ステップ（７））。例えば、ＳａａＳサーバ５のＩＰアドレスなどから中継の是非を判断する。
【００２４】
図１３Ａの処理の説明に移行して、内部中継サーバ１３は、ＳａａＳサーバ５からのＨＴＴＰリクエストを中継しても良いと判断した場合には、在庫管理システム１５に対するＷｅｂサービス呼び出しとしてＨＴＴＰリクエストを生成して、在庫管理システム１５に送信する（ステップ（８））。在庫管理システム１５は、内部中継サーバ１３からのＨＴＴＰリクエストに応答して処理を実施して、処理結果をＨＴＴＰレスポンスとして内部中継サーバ１３に返信する（ステップ（９））。内部中継サーバ１３は、処理結果のレスポンスを、中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのＨＴＴＰリクエストに変換し、外部中継サーバ３に送信する（ステップ（１０））。このように処理結果のレスポンスを、再度のＨＴＴＰリクエストの形式で外部中継サーバ３に出力する。
【００２５】
図１３Ｂの処理の説明に移行して、外部中継サーバ３は、内部中継サーバ１３から、社内Ｗｅｂサービスの処理結果を含むＨＴＴＰリクエストを受信すると、当該社内Ｗｅｂサービスの処理結果を含むＨＴＴＰレスポンスを生成して、ステップ（５）におけるＨＴＴＰリクエストに対するレスポンスとして、ＳａａＳサーバ５に返信する（ステップ（１１））。ＳａａＳサーバ５におけるＳａａＳアプリケーション５０１は、外部中継サーバ３から社内Ｗｅｂサービスの処理結果を含むＨＴＴＰレスポンスを受信すると、当該社内Ｗｅｂサービスの処理結果を反映させたＨＴＴＰレスポンスを、ステップ（１）に対するレスポンスとして生成して、部門Ａユーザ端末１１に返信する（ステップ（１２））。
【００２６】
このようにして、ファイアウォールの外部のＳａａＳサーバ５におけるＳａａＳアプリケーション５０１と、ファイアウォール内部の社内Ｗｅｂサービス提供システム（図では在庫管理システム１５）とが連携できるようになり、両者の処理結果を反映させたデータをファイアウォール内部の部門Ａユーザ端末１１に届けることができるようになる。なお、ファイアウォール７の設定の変更は不要であり、セキュリティレベルを下げずに、このような効果を得ている。
【００２７】
なお、外部中継サーバ３は、内部中継サーバ１３からＨＴＴＰリクエストを受信した状態であるから、中継待ちの状態となっており、ＳａａＳサーバ５からの社内Ｗｅｂサービス呼び出しが必要となれば、応答することができる。
【００２８】
また、部門Ａユーザ端末１１のユーザが、例えばＳａａＳサーバ５からログオフする場合など、ＳａａＳサーバ５で提供されるＷｅｂサービスの利用を終了する場合には、部門Ａユーザ端末１１のユーザは、部門Ａユーザ端末１１に対して、中継セッション中止リクエストを、内部中継サーバ１３に送信させる。
【００２９】
内部中継サーバ１３は、中継セッション中止リクエストに応答して、自らが保持する所定の中継ＵＲＩ”http://myproxy.com/usr/usr1/zaiko”についてのセッション情報を破棄すると共に、外部中継サーバ３に対しても受信待機中パスについてのデータを破棄させるためのメッセージを送信する。外部中継サーバ３は、内部中継サーバ１３から上記のようなメッセージを受信すると、受信待機中パスについてのデータを破棄し、中継待ち受けの状態を脱する。なお、中継セッション中止リクエストを送信せずとも、例えば所定時間以上経過した場合には、内部中継サーバ１３でも外部中継サーバ３でも、セッション情報や受信待機中パスについてのデータを破棄するようにすれば、中継待ち受けの状態を脱するようになる。
【００３０】
次に、図１４乃至図４２を用いて、図７に示したシステムの処理の詳細を説明する。最初に、図１４乃至図１７を用いて、部門Ａユーザ端末１１から中継セッション開始リクエストを受信する際の処理を説明する。最初に、例えばリクエスト受信部１３１は、部門Ａユーザ端末１１からのアクセスに応じて、例えばリクエストのためのデータの入力画面を表示させるＷｅｂページデータを送信する。部門Ａユーザ端末１１は、リクエスト受信部１３１から上で述べたようなＷｅｂページデータを受信し、表示装置に表示する。例えば図１４に示すような画面が表示される。
【００３１】
図１４の例では、内部中継サーバ１３に対するユーザＩＤ及びパスワードの入力欄と、外部中継サーバ名と当該外部中継サーバ３に対するユーザＩＤ及びパスワードの入力欄と、社内ＷｅｂサービスＵＲＩの入力欄と、Ｗｅｂサービス中継ＵＲＩの入力欄と、アクセス許可ホスト名の入力欄とを含む。社内ＷｅｂサービスＵＲＩは、例えば図７における在庫管理システム１５のＵＲＩである。Ｗｅｂサービス中継ＵＲＩは、内部中継サーバ１３及び外部中継サーバ３でどの中継セッションであるかを特定するためのキーとなる中継ＵＲＩである。
【００３２】
ユーザは、図１４における画面の入力欄にデータを入力して開始ボタンをクリックし、部門Ａユーザ端末１１に対して中継セッション開始リクエストの送信指示を入力する。部門Ａユーザ端末１１は、中継セッション開始リクエストの送信指示を受け付け、入力されたデータを含む中継セッション開始リクエストを、内部中継サーバ１３に送信する。
【００３３】
内部中継サーバ１３のリクエスト受信部１３１は、部門Ａユーザ端末１１から中継セッション開始リクエストを受信し（図１５：ステップＳ１）、接続情報管理部１３４に出力する。接続情報管理部１３４は、上で述べたようなデータを含む中継セッション開始リクエストを受信すると、受信したユーザＩＤでユーザ情報格納部１３３を検索して一致するパスワードを取得し、受信したパスワードと一致するかを判断する照合処理を実施する（ステップＳ３）。
【００３４】
ユーザ情報格納部１３３に格納されているデータの一例を図１６に示す。図１６の例では、例えば部門ＡのユーザのユーザＩＤと、パスワードとが登録されるようになっている。
【００３５】
一致する場合、すなわち照合成功の場合には、セッション管理部１３６に、図１４に示したデータをセッション管理部１３６に出力する（ステップＳ９）。セッション管理部１３６は、接続情報管理部１３４から受信したデータをセッション一覧情報格納部１３５に格納する。
【００３６】
セッション一覧情報格納部１３５には、例えば図１７に示すようなデータが格納される。図１７の例では、内部中継サーバ１３に対するユーザＩＤと、社内ＷｅｂサービスＵＲＩと、外部中継サーバ名と、Ｗｅｂサービス中継ＵＲＩと、アクセス許可ホスト名と、外部中継サーバ３に対するユーザＩＤ及びパスワードとを登録するようになっている。このテーブルの一行分のデータを、セッション情報と呼ぶことにする。セッション管理部１３６は、このセッション情報を、外部インタフェース部１３７に出力する。
【００３７】
また、接続情報管理部１３４は、リプライ送信部１３２に中継セッション開始成功を表すレスポンスを部門Ａユーザ端末１１へ送信させる（ステップＳ１１）。部門Ａユーザ端末１１は、リプライ送信部１３２から中継セッション開始成功を表すレスポンスを受信し、表示装置に表示する。ユーザは、中継セッション開始成功を認識することができる。
【００３８】
一方、ステップＳ３で照合に失敗すると（ステップＳ５：Ｎｏルート）、接続情報管理部１３４は、リプライ送信部１３２に、中継セッション開始失敗を、部門Ａユーザ端末１１へ送信させる（ステップＳ７）。部門Ａユーザ端末１１は、リプライ送信部１３２から中継セッション開始失敗を表すレスポンスを受信し、表示装置に表示する。ユーザは、中継セッション開始失敗、すなわちユーザＩＤとパスワードとの少なくともいずれかの入力を誤ったことを認識することができる。
【００３９】
以上のような処理を実施して、外部中継サーバ３への中継セッション開始通知の準備が完了する。なお、セッション情報については、ユーザ毎に内部中継サーバ１３内に保持しておき、ユーザからの中継セッション開始リクエストに応じて、そのセッション情報を読み出すようにしても良い。
【００４０】
次に、図１８及び図１９を用いて、ＨＴＴＰリクエストの送信処理（１回目）について説明する。内部中継サーバ１３の外部インタフェース部１３７は、セッション管理部１３６からセッション情報を受信し（ステップＳ２１）、メインメモリ等の記憶装置に格納しておく。このセッション情報は、外部中継サーバ３との通信で用いるセッションＩＤとソケットＩＤとのうち少なくともいずれかなどによって管理しておく。そして、リクエスト送信部１３７１及びリプライ受信部１３７２で共用する。又は、セッション情報のうち少なくともＷｅｂサービス中継ＵＲＩ等キーとなるデータと、セッションＩＤとソケットＩＤとのうち少なくともいずれかなどとを関連付けて保持しておく。
【００４１】
リクエスト送信部１３７１は、セッション情報から外部中継サーバ名を抽出し、今回送信するＨＴＴＰリクエストの宛先ホストに設定すると共に、宛先ホストの所定のパス（ここでは/control/index.html。予め保持しておく。）もＨＴＴＰリクエストのパス名として設定する（ステップＳ２３）。
【００４２】
さらに、リクエスト送信部１３７１は、セッション情報から外部中継サーバ３に対するユーザＩＤ及びパスワードを抽出し、ＨＴＴＰリクエストのAuthorizationフィールドに設定する（ステップＳ２５）。また、リクエスト送信部１３７１は、セッション情報からＷｅｂサービス中継ＵＲＩのパス部分を抽出し、ＨＴＴＰリクエストのX-RelayURIフィールドに設定する（ステップＳ２７）。そして、リクエスト送信部１３７１は、セッション情報からアクセス許可ホスト名を抽出し、X-AllowDomainフィールドに設定する（ステップＳ２９）。このようにしてセッション情報からＨＴＴＰリクエストが生成されたことになる。そして、リクエスト送信部１３７１は、生成されたＨＴＴＰリクエストを外部中継サーバ３に送信する（ステップＳ３１）。なお、リクエスト送信部１３７１は、リプライ受信部１３７２に対して、レスポンスの待機を指示する（ステップＳ３３）。リプライ受信部１３７２は、上で述べたようにＨＴＴＰリクエスト送信時のセッションＩＤやソケットＩＤを保持しておき、今回送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを識別できるようにする。
【００４３】
図１９に、ステップＳ３１で外部中継サーバ３に送信されるＨＴＴＰリクエストの一例を示す。図１９の例では、ＰＯＳＴメソッドが定義されており、パス名には”/control/index.html”が設定されている。また、ホスト名には、外部中継サーバ３のホスト名”myproxy.com”が設定されている。Authorizationフィールドには、ユーザＩＤ及びパスワードを連結した上でBASE64でエンコードしたものが設定されている。X-RelayURIフィールドには、上で述べたように中継ＵＲＩのパス部分”/usr/usr1/zaiko”が設定されており、X-AllowDomainフィールドにはアクセス許可ホスト名”saasapps.com”が設定されている。
【００４４】
このようにして最初のＨＴＴＰリクエストが内部中継サーバ１３から外部中継サーバ３へ送信される。
【００４５】
次に、外部中継サーバ３におけるリクエスト受信処理について図２０乃至図２４を用いて説明する。外部中継サーバ３のリクエスト受信部３２は、内部中継サーバ１３からＨＴＴＰリクエストを受信し、メインメモリ等の記憶装置に格納すると共に、受信したＨＴＴＰリクエストのソケットから送信元のＩＰアドレス及びソケットＩＤを取得する（ステップＳ４１）。さらに、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダからユーザＩＤ及びパスワードを抽出する（ステップＳ４３）。そして、リクエスト受信部３２は、送信元ＩＰアドレス、ユーザＩＤ及びパスワードのセットがアクセス許可情報格納部３１に格納されているアクセス許可情報に含まれるか確認する（ステップＳ４５）。
【００４６】
図２１に、アクセス許可情報格納部３１に格納されるデータの一例を示す。図２１の例では、送信元ＩＰアドレスと、ユーザＩＤと、パスワードとを登録するようになっている。ステップＳ４５では、いずれかのレコードのデータと、ステップＳ４１及びＳ４３で取得されたデータとが一致するか判断する。
【００４７】
そして、リクエスト受信部３２は、アクセス許可情報にステップＳ４１及びＳ４３で取得されたデータが含まれる、すなわちアクセス許可ありであるか判断する（ステップＳ４７）。許可がない場合には端子Ａを介してステップＳ６７に移行する。一方、アクセス許可ありと判断された場合、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダのX-RelayURIフィールドから中継ＵＲＩのパス部分を抽出する（ステップＳ４９）。そして、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、抽出された中継ＵＲＩに該当するエントリを受信待機パス一覧から取得するように依頼し、Ｗｅｂサービス制御部３３から結果を取得する（ステップＳ５１）。
【００４８】
受信待機パス一覧格納部３８に格納されている受信待機パス一覧の一例を図２２に示す。図２２の例では、中継ＵＲＩと、アクセス許可ホスト名と、外部中継サーバ３についてのユーザＩＤと、外部中継サーバ３についてのパスワードと、内部中継サーバ１３に対する返信用ソケットＩＤと、ＳａａＳサーバ５のＷｅｂサービスに対する返信用ソケットＩＤとが登録されるようになっている。特定のユーザについて最初のＨＴＴＰリクエストが外部中継サーバ３に送信された場合には、まだ中継待機中パス一覧にはエントリが存在しない。一方、２回目のＨＴＴＰリクエストが外部中継サーバ３に送信された場合には、既に同様のエントリが中継待機中パス一覧に登録されている。
【００４９】
リクエスト受信部３２は、Ｗｅｂサービス制御部３３からの処理結果に基づき、該当エントリが中継待機中パス一覧に存在するか判断する（ステップＳ５３）。該当エントリが存在しない場合には、最初のＨＴＴＰリクエストであり、端子Ｂを介してステップＳ６１に移行する。一方、該当エントリが存在する場合には、２回目以降のＨＴＴＰリクエストであり、端子Ｃを介してステップＳ５５に移行する。２回目以降のＨＴＴＰリクエストについては、まだ実施されないので、ここでは、端子Ａ及び端子Ｂ以降の処理を説明する。
【００５０】
図２３の処理の説明に移行して、端子Ａの後に、リクエスト受信部３２は、リプライ送信部３７にエラー情報を内部中継サーバ１３へ送信させる（ステップＳ６７）。以下、詳細な説明を省略するが、内部中継サーバ１３では、エラー情報を受信すると、エラー情報を蓄積しておくと共に、管理者やユーザにメールその他の手法でエラー発生を通知する。
【００５１】
次に、端子Ｂの後に、リクエスト受信部３２は、受信したＨＴＴＰリクエストのヘッダにおけるX-AllowDomainフィールドから、アクセス許可ホスト名を抽出する（ステップＳ６１）。さらに、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、この中継ＵＲＩについての待機指示を出力する（ステップＳ６３）。Ｗｅｂサービス制御部３３は、ＳａａＳサーバ５から中継ＵＲＩについてのリクエストを待機する状態になる。なお、アクセス要求処理部３６も、ＳａａＳサーバ５からのこの中継ＵＲＩについてのリクエストを待機する。
【００５２】
さらに、リクエスト受信部３２は、中継ＵＲＩとアクセス許可ホスト名とユーザＩＤと内部中継サーバ１３に対する返信用ソケットＩＤとを含む中継ＵＲＩデータを出力して、受信待機パス一覧格納部３８に登録させる（ステップＳ６５）。図２４に、中継ＵＲＩデータの一例を示す。図２４の例では、内部中継サーバへの返信用ソケットＩＤと、ユーザＩＤ及びパスワードと、中継ＵＲＩのパスと、アクセス許可ホスト名とが含まれる。Ｗｅｂサービス制御部３３は、このような中継ＵＲＩデータを、図２２に示したテーブルに登録する。但し、この段階では、待機中であるから、ＳａａＳサーバ５のＷｅｂサービスに対する返信用ソケットＩＤは登録されない。
【００５３】
このようにして、ＳａａＳサーバ５からの社内Ｗｅｂサービスの呼び出しに係る、所定の中継ＵＲＩについてのＨＴＴＰリクエストを待機する状態になる。
【００５４】
次に、図２５乃至図２７を用いて、ＳａａＳサーバ５から所定の中継ＵＲＩについてのＨＴＴＰリクエストを受信した際の処理を説明する。まず、外部中継サーバ３のＷｅｂサービスリクエスト受信部３５は、ＳａａＳサーバ５のＳａａＳアプリケーション５０１から、所定の中継ＵＲＩについてのＨＴＴＰリクエストを受信する。このＨＴＴＰリクエストの一例を図２５に示す。図２５の例では、このＨＴＴＰリクエストのヘッダには、ＧＥＴメソッドで、部門Ａユーザ端末１１のユーザについての中継ＵＲＩのパス部分”/usr/usr1/zaiko”とパラメータ部分”?code=1256”とが含まれる。さらに、このＨＴＴＰリクエストのヘッダには、外部中継サーバ３のホスト名”myproxy.com”と、外部中継サーバ３に対する認証情報（ユーザＩＤ及びパスワードを連結した上でBASE64でエンコードしたもの）と、メッセージ・ボディの長さ”Content-Length:0”とが含まれている。
【００５５】
そして、アクセス要求処理部３６は、Ｗｅｂサービスリクエスト受信部３５からＨＴＴＰリクエスト自体、アクセス元（ＳａａＳサーバ５）のＩＰアドレス及び当該受信ＨＴＴＰリクエストのためのソケットのソケットＩＤ（ＳａａＳサーバ５のＷｅｂサービスに対する返信用ソケットＩＤ）を取得する（図２６：ステップＳ７１）。
【００５６】
その後、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信ＨＴＴＰリクエストに含まれる中継ＵＲＩで受信待機パス一覧を検索させ（ステップＳ７３）、該当エントリを読み出させる。なお、Ｗｅｂサービスに対する返信用ソケットＩＤが登録されていないエントリを抽出する。該当エントリがあれば、これでこの中継ＵＲＩについての待機状態から復帰する。そして、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３から結果を取得し、該当エントリが存在するか確認し（ステップＳ７５）、該当エントリが存在しない場合には、端子Ｄを介してステップＳ９１に移行する。該当エントリがない場合には中継できない。
【００５７】
一方、該当エントリが存在する場合には、アクセス要求処理部３６は、ＤＮＳからアクセス元ＩＰアドレスに対するホスト名を取得する（ステップＳ７７）。そして、アクセス要求処理部３６は、アクセス元のホスト名と該当エントリ内のアクセス許可ホスト名とが一致するか判断する（ステップＳ７９）。不一致の場合には、中継できないので端子Ｄを介してステップＳ９１に移行する。一方、アクセス元のホスト名と該当エントリ内のアクセス許可ホスト名とが一致する場合には、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダのAuthorizationフィールドから、ユーザＩＤ及びパスワードを抽出する（ステップＳ８１）。
【００５８】
そして、アクセス要求処理部３６は、抽出したユーザＩＤと該当エントリに含まれるユーザＩＤとが一致するか判断する（ステップＳ８３）。一致しない場合には、端子Ｄを介してステップＳ９１に移行する。一方、一致する場合には、端子Ｅを介して図２７の処理に移行する。
【００５９】
図２７の処理の説明に移行して、端子Ｅの後に、アクセス要求処理部３６は、ＨＴＴＰリクエストから抽出したユーザＩＤ及びパスワードが、該当エントリのユーザＩＤ及びパスワードと一致するか判断する（ステップＳ８５）。一致しない場合にはステップＳ９１に移行する。一方、一致する場合には、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信待機パス一覧の該当エントリに、ステップＳ４１で取得されたＷｅｂサービスに対するソケットＩＤを、Ｗｅｂサービスに対する返信用ソケットＩＤとして登録させる（ステップＳ８７）。これにて、社内Ｗｅｂサービスを提供する在庫管理システム１５からレスポンスを受信した際に用いるデータが受信待機パス一覧に用意されたことになる。
【００６０】
そして、アクセス要求処理部３６は、リプライ送信部３７に、内部中継サーバ１３のためのソケットＩＤ（該当エントリにおける内部中継サーバ１３に対する返信用ソケットＩＤ）と、受信したＨＴＴＰリクエストのデータを出力し、社内Ｗｅｂサービス呼び出しとしてＨＴＴＰレスポンスを内部中継サーバ１３へ送信させる（ステップＳ８９）。リプライ送信部３７は、社内Ｗｅｂサービス呼び出しとしてのＨＴＴＰレスポンスを生成して、内部中継サーバ１３へ送信する。具体的な処理については、図２８及び図２９を用いて説明する。
【００６１】
なお、端子Ｄの後には、アクセス要求処理部３６は、Ｗｅｂサービスリプライ送信部３４に、エラー通知をＳａａＳサーバ５へ返信するように指示する（ステップＳ９１）。Ｗｅｂサービスリプライ送信部３４は、指示に応じてエラー通知をＳａａＳサーバ５へ返信する。この処理については主要部ではないのでこれ以上述べない。
【００６２】
このような処理を行えば、ＳａａＳサーバ５からの社内Ｗｅｂサービス呼び出しに対応する待機中の適切なＨＴＴＰリクエストを特定でき、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスを生成できるようになる。
【００６３】
このＨＴＴＰレスポンスの生成及び送信についての外内リプライ送信処理について図２８及び図２９を用いて説明する。
【００６４】
リプライ送信部３７は、アクセス要求処理部３６から受信したデータに含まれるアクセス元のＩＰアドレスを、ＨＴＴＰレスポンスのヘッダにおけるX-RequestHostフィールドに設定する（ステップＳ１０１）。また、リプライ送信部３７は、受信したＨＴＴＰリクエストのデータに含まれるコマンド名（メソッド名）を、ＨＴＴＰレスポンスのヘッダにおけるX-Commandフィールドに設定する（ステップＳ１０３）。さらに、リプライ送信部３７は、受信したデータに含まれる中継ＵＲＩのパスに付加されているパラメータをX-Argumentsフィールドに設定する（ステップＳ１０５）。また、リプライ送信部３７は、受信したＨＴＴＰリクエストのヘッダの各フィールドを、X-OrigHeader-を前置して設定する（ステップＳ１０７）。最後に、リプライ送信部３７は、このようにして生成されたＨＴＴＰレスポンスを、内部中継サーバ１３に対する返信用ソケットＩＤを用いて、内部中継サーバ１３へ送信する（ステップＳ１０９）。
【００６５】
例えば図２９に示すようなＨＴＴＰレスポンスが生成される。図２９の例では、ＨＴＴＰレスポンスでは、ＳａａＳサーバ５のＩＰアドレスがX-RequestHostフィールドに設定され、受信したＨＴＴＰリクエストのコマンド（メソッド）名がX-Commandフィールドに設定され、中継ＵＲＩにおけるパラメータ”?code=1256”を例えばBASE64でエンコードした値をX-Argumentsフィールドに設定し、受信したＨＴＴＰリクエストに含まれる認証データをX-OrigHeader-の後に設定し、さらにメッセージボディのサイズをX-OrigHeaderフィールドに設定している。図２９には含まれていないが、中継ＵＲＩのパス自体を、このＨＴＴＰレスポンスに含めるようにしても良い。さらに、ＳａａＳサーバ５からのＨＴＴＰリクエストに含まれた認証データについては含めないようにしても良い。
【００６６】
次に、図３０乃至図３７を用いて、内部中継サーバ１３が、社内Ｗｅｂサービス呼び出しとしてのＨＴＴＰレスポンスを受信した際の処理について説明する。まず、リプライ受信部１３７２は、外部中継サーバ３からＨＴＴＰレスポンスを受信すると、そのＨＴＴＰレスポンスのソケットＩＤやセッションＩＤなどから、対応するＨＴＴＰリクエスト送信時のセッション情報を特定する（ステップＳ１１１）。なお、外部インタフェース部１３７が保持しているセッション情報を特定するか、当該ソケットＩＤ等と対応付けて保持している中継ＵＲＩ等のキーをセッション管理部１３６に出力して、セッション管理部１３６にセッション一覧情報格納部１３５から抽出させるようにしてもよい。リプライ受信部１３７２は、特定したセッション情報を、受信したＨＴＴＰレスポンスのデータと共にアクセス要求処理部１３８に出力する。ここでは、例えば図１７の第１行目に相当する図３１のようなセッション情報が特定されたものとする。
【００６７】
アクセス要求処理部１３８は、ＨＴＴＰレスポンスのデータ及びセッション情報を取得すると、当該ＨＴＴＰレスポンスのヘッダから、アクセス元のＩＰアドレスを抽出する（ステップＳ１１３）。そして、アクセス要求処理部１３８は、アクセス元のＩＰアドレスに対応するホスト名をＤＮＳから取得し、抽出したＩＰアドレスに対応するホスト名と、セッション情報に含まれるアクセス許可ホスト名と一致するか判断する（ステップＳ１１５）。一致しない場合には、以後の処理を実施することはできないので、アクセス要求処理部１３８は、リクエスト送信部１３７１に、アクセス拒否通知を外部中継サーバ３へ送信させる（ステップＳ１１７）。そして端子Ｆを介して処理を終了する。
【００６８】
なお、例えばＨＴＴＰレスポンスに中継ＵＲＩのパス名を含めておき、セッション情報に含まれる中継ＵＲＩのパス名と比較するようにしても良い。
【００６９】
一方、抽出したＩＰアドレスに対応するホスト名とセッション情報に含まれるアクセス許可ホスト名とが一致する場合、アクセス要求処理部１３８は、セッション情報から社内ＷｅｂサービスＵＲＩ及びユーザＩＤを抽出する（ステップＳ１１９）。また、アクセス要求処理部１３８は、抽出された社内ＷｅｂサービスＵＲＩ及びユーザＩＤを用いて、接続認証情報から社内Ｗｅｂサービスに対するユーザＩＤ及びパスワードを抽出する（ステップＳ１２１）。例えば接続認証情報格納部１３９に格納されているデータの一例を図３２に示す。図３２の例では、ユーザＩＤと、社内ＷｅｂサービスＵＲＩと、社内ＷｅｂサービスのためのユーザＩＤ及びパスワードとが登録されるようになっている。なお、このデータは、予め内部中継サーバ１３の管理者等によって登録しておく。
【００７０】
さらに、アクセス要求処理部１３８は、この処理において抽出されたデータ、ＨＴＴＰレスポンスのヘッダ中のコマンド及びパラメータ等をＷｅｂサービスリクエスト送信部１４１１に出力して、社内Ｗｅｂサービスの呼び出しを行わせる（ステップＳ１２３）。そして、アクセス要求処理部１３８は、Ｗｅｂサービスリプライ受信部１４１２からのレスポンスを待機する（ステップＳ１２５）。ここまでが、外部中継サーバ３からＨＴＴＰレスポンスを受信した後に、在庫管理システム１５などへＨＴＴＰリクエストを送信するまでの処理である。端子Ｊ以降の処理は、在庫管理システム１５などからレスポンスを受信した後の処理であるので、後で説明する。
【００７１】
次に、図３３を用いて、Ｗｅｂサービスリクエスト送信部１４１１の処理について説明する。Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスのヘッダにおけるX-Commandフィールドから、コマンド種別（メソッド種別）を取得し、送信すべきＨＴＴＰリクエストのヘッダに設定する（ステップＳ１３１）。また、Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスのヘッダにおけるX-Argumentsフィールドの値をBASE64でデコードして、ＵＲＩに付加すべきパラメータを復元する（ステップＳ１３３）。そして、Ｗｅｂサービスリクエスト送信部１４１１は、受信した社内ＷｅｂサービスＵＲＩのパスに、復元したパラメータを付加し、送信すべきＨＴＴＰリクエストのヘッダに設定する（ステップＳ１３５）。
【００７２】
また、Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスにX-OrigHeader-が前置されたフィールドがあれば、X-OrigHeader-を削除した上で、送信すべきＨＴＴＰリクエストヘッダに設定する（ステップＳ１３７）。さらに、Ｗｅｂサービスリクエスト送信部１４１１は、送信すべきＨＴＴＰリクエストのヘッダのHostフィールドに、社内Ｗｅｂサービスのホスト名（アクセス許可ホスト名）を設定する（ステップＳ１３９）。処理は端子Ｌを介して図３４の処理に移行する。
【００７３】
図３４の処理の説明に移行して、Ｗｅｂサービスリクエスト送信部１４１１は、受信した接続認証情報から、上で抽出されたユーザＩＤ及びパスワードを、BASE64でエンコードした上で、Authorizationフィールドに設定する（ステップＳ１４１）。ステップＳ１３７で、X-OrigHeader-を削除した場合にAuthorizationフィールドが出現するのであれば、値をステップＳ１４１でエンコードした値で上書きする。さらに、Ｗｅｂサービスリクエスト送信部１４１１は、受信したＨＴＴＰレスポンスのヘッダに付加されたデータ（メッセージボディのデータ）を、送信すべきＨＴＴＰリクエストのヘッダ以降に追加する（ステップＳ１４３）。
【００７４】
最後に、Ｗｅｂサービスリクエスト送信部１４１１は、このようにして生成されたＨＴＴＰリクエストを、在庫管理システム１５に送信する（ステップＳ１４５）。
【００７５】
例えば図３５のようなＨＴＴＰリクエストが生成される。ＳａａＳサーバ５から送信されてくるＨＴＴＰリクエスト（図２５）と比較すると、Authorizationフィールドの値以外は同一であり、内部中継サーバ１３により、ＳａａＳサーバ５が送信してきたＨＴＴＰリクエストを適切な形式で復元したことになる。このようにして、ＳａａＳサーバ５による社内Ｗｅｂサービス呼び出しが、外部中継サーバ３及び内部中継サーバ１３を介して行われたことになる。
【００７６】
社内Ｗｅｂサービスの一つである在庫管理システム１５の処理内容については従来と同じであり、ここでは説明を省略する。ここでは、図３６に示すようなＨＴＴＰレスポンスが、在庫管理システム１５から送られてきて、Ｗｅｂサービスリプライ受信部１４１２がそのＨＴＴＰレスポンスを受信するものとする。図３６の例では、ＨＴＴＰレスポンスのヘッダに、ＸＭＬ（eXtensible Markup Language）によるメッセージボディが添付されている。
【００７７】
Ｗｅｂサービスリプライ受信部１４１２は、このＨＴＴＰレスポンスをアクセス要求処理部１３８に出力する。そうすると、図３０の端子Ｊ以降の処理が実施される。
【００７８】
端子Ｊを介して図３７の処理の説明に移行して、アクセス要求処理部１３８は、Ｗｅｂサービスリプライ受信部１４１２からＨＴＴＰレスポンスのデータを受信して、メインメモリ等の記憶装置に格納する（ステップＳ１５１）。そして、アクセス要求処理部１３８は、受信したＨＴＴＰレスポンスのデータ及び当該ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストについて該当するセッション情報を、外部インタフェース部１３７に出力する（ステップＳ１５３）。
【００７９】
次に、図３８乃至図４０を用いて、社内ＷｅｂサービスからのＨＴＴＰレスポンスをＨＴＴＰリクエストとして外部中継サーバ３に送信する際の処理について説明する。この処理の一部は図１８と同じである。
【００８０】
内部中継サーバ１３の外部インタフェース部１３７は、アクセス要求処理部１３８からセッション情報を受信し（ステップＳ１６１）、メインメモリ等の記憶装置に格納しておく。このセッション情報は、外部中継サーバ３との通信で用いるセッションＩＤとソケットＩＤとのうち少なくともいずれかなどによって管理しておく。そして、リクエスト送信部１３７及びリプライ受信部１３７２で共用する。又は、セッション情報のうち少なくともＷｅｂサービス中継ＵＲＩ等キーとなるデータと、セッションＩＤとソケットＩＤとのうち少なくともいずれかなどとを関連付けて保持しておく。
【００８１】
リクエスト送信部１３７１は、セッション情報から外部中継サーバ名を抽出し、今回送信するＨＴＴＰリクエストの宛先ホストに設定すると共に、宛先ホストの所定のパス（ここでは/control/index.html）もＨＴＴＰリクエストのパス名として設定する（ステップＳ１６３）。
【００８２】
さらに、リクエスト送信部１３７１は、セッション情報から外部中継サーバ３に対するユーザＩＤ及びパスワードを抽出し、ＨＴＴＰリクエストのAuthorizationフィールドに設定する（ステップＳ１６５）。また、リクエスト送信部１３７１は、セッション情報からＷｅｂサービス中継ＵＲＩのパス部分を抽出し、ＨＴＴＰリクエストのX-RelayURIフィールドに設定する（ステップＳ１６７）。そして、リクエスト送信部１３７１は、セッション情報からアクセス許可ホスト名を抽出し、X-AllowDomainフィールドに設定する（ステップＳ１６９）。処理は端子Ｇを介して図３９の処理に移行する。
【００８３】
図３９の処理の説明に移行して、リクエスト送信部１３７１は、受信したＨＴＴＰリクエストのヘッダを、X-OrigHeader-を前置して、送信すべきＨＴＴＰリクエストのヘッダに設定する（ステップＳ１７１）。さらに、リクエスト送信部１３７１は、受信したＨＴＴＰリクエストに添付されているデータ部分（メッセージボディ部分）を、送信すべきＨＴＴＰリクエストのヘッダの後ろに追加する（ステップＳ１７３）。このようにしてセッション情報及び在庫管理システム１５からのＨＴＴＰレスポンスからＨＴＴＰリクエストが生成されたことになる。
【００８４】
そして、リクエスト送信部１３７１は、生成されたＨＴＴＰリクエストを外部中継サーバ３に送信する（ステップＳ１７５）。なお、リクエスト送信部１３７１は、リプライ受信部１３７２に対して、レスポンスの待機を指示する（ステップＳ１７７）。リプライ受信部１３７２は、上で述べたようにＨＴＴＰリクエスト送信時のセッションＩＤやソケットＩＤを保持しておき、今回送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを識別できるようにする。
【００８５】
図４０に、ステップＳ１７５で外部中継サーバ３に送信されるＨＴＴＰリクエストの一例を示す。図４０の例では、ＰＯＳＴメソッド（コマンド）が定義されており、パス名は”/control/index.html”が設定されている。また、ホスト名には、外部中継サーバ３のホスト名”myproxy.com”が設定されている。Authorizationフィールドには、ユーザＩＤ及びパスワードを連結した上でBASE64でエンコードしたものが設定されている。X-RelayURIフィールドには、上で述べたように中継ＵＲＩのパス部分”/usr/usr1/zaiko”が設定されており、X-AllowDomainフィールドにはアクセス許可ホスト名”saasapps.com”が設定されている。さらに、ＨＴＴＰレスポンスには、Dateフィールドが存在していたので、X-OrigHeader-が前置されているが、Dateフィールドのデータも設定されている。さらに、ＨＴＴＰレスポンスのボディのデータも、ＨＴＴＰリクエストのボディに設定されている。
【００８６】
このようにして社内ＷｅｂサービスのレスポンスであるＨＴＴＰリクエストが内部中継サーバ１３から外部中継サーバ３へ送信される。
【００８７】
外部中継サーバ３のリクエスト受信部３２は、ＨＴＴＰリクエストを内部中継サーバ１３から受信して、図２０及び図２３の処理を実施する。図２０及び図２３の一部については最初のＨＴＴＰリクエスト受信時と同じ処理であるが、再度図４０のＨＴＴＰリクエストを受信したものとして説明する。
【００８８】
外部中継サーバ３のリクエスト受信部３２は、内部中継サーバ１３からＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストのソケットから送信元のＩＰアドレス及びソケットＩＤを取得する（ステップＳ４１）。さらに、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダからユーザＩＤ及びパスワードを抽出する（ステップＳ４３）。そして、リクエスト受信部３２は、送信元ＩＰアドレス、ユーザＩＤ及びパスワードのセットがアクセス許可情報格納部３１に格納されているアクセス許可情報に含まれるか確認する（ステップＳ４５）。
【００８９】
そして、リクエスト受信部３２は、アクセス許可情報にステップＳ４１及びＳ４３で取得されたデータが含まれる、すなわちアクセス許可ありであるか判断する（ステップＳ４７）。許可がない場合には端子Ａを介してステップＳ６７に移行する。一方、アクセス許可ありと判断された場合、リクエスト受信部３２は、ＨＴＴＰリクエストのヘッダのX-RelayURIフィールド及びHostフィールドから中継ＵＲＩを抽出する（ステップＳ４９）。そして、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、抽出された中継ＵＲＩに該当するエントリを受信待機パス一覧から取得するように依頼し、Ｗｅｂサービス制御部３３から結果を取得する（ステップＳ５１）。
【００９０】
リクエスト受信部３２は、Ｗｅｂサービス制御部３３からの処理結果に基づき、該当エントリが中継待機中パス一覧に存在するか判断する（ステップＳ５３）。２度目のＨＴＴＰリクエストであるから、今回は通常であれば該当エントリが存在する。該当エントリが存在する場合には、２回目以降のＨＴＴＰリクエストであり、端子Ｃを介してステップＳ５５に移行する。
【００９１】
図２３の処理の説明に移行して、端子Ｃの後に、リクエスト受信部３２は、抽出されたエントリのユーザＩＤとＨＴＴＰリクエストのヘッダから抽出されたユーザＩＤが一致するか判断する（ステップＳ５５）。一致しない場合には、何らかの問題が発生したということで、ステップＳ６７に移行する。
【００９２】
一方、抽出されたエントリのユーザＩＤとＨＴＴＰリクエストのヘッダから抽出されたユーザＩＤが一致する場合には、リクエスト受信部３２は、さらに抽出されたエントリにＷｅｂサービスのためのソケットＩＤが設定されているか判断する（ステップＳ５７）。このソケットＩＤが設定されていないと、ＳａａＳサーバ５にレスポンスを返すことができないので、このソケットＩＤが設定されていない場合には、ステップＳ６７に移行する。
【００９３】
このソケットＩＤがエントリに設定されている場合には、リクエスト受信部３２は、ＨＴＴＰリクエストのデータを含むリクエスト応答指示をアクセス要求処理部３６に出力する（ステップＳ５９）。これによって、ＳａａＳサーバ５への応答を送信する準備に入る。
【００９４】
さらに、リクエスト受信部３２は、受信したＨＴＴＰリクエストのヘッダにおけるX-AllowDomainフィールドから、アクセス許可ホスト名を抽出する（ステップＳ６１）。また、リクエスト受信部３２は、Ｗｅｂサービス制御部３３に、待機指示を出力する（ステップＳ６３）。Ｗｅｂサービス制御部３３は、ＳａａＳサーバ５から中継ＵＲＩについてのリクエストを待機する状態になる。なお、アクセス要求処理部３６も、ＳａａＳサーバ５からのこの中継ＵＲＩについてのリクエストを待機する。
【００９５】
さらに、リクエスト受信部３２は、中継ＵＲＩとアクセス許可ホスト名とユーザＩＤと内部中継サーバ１３に対する返信用ソケットＩＤとを含む中継ＵＲＩデータを出力して、Ｗｅｂサービス制御部３３に受信待機パス一覧格納部３８へ登録させる（ステップＳ６５）。この段階で、Ｗｅｂサービスに対する返信用ソケットＩＤが登録されていないエントリと登録されているエントリのほぼ同一の２つのエントリが登録されることになる。
【００９６】
このようにして、アクセス要求処理部３６に処理を要求した上で、ＳａａＳサーバ５のＳａａＳアプリケーション５０１からの次のＨＴＴＰリクエストを待機する状態になる。
【００９７】
なお、ステップＳ５５及びＳ５７でエラーを検出した場合及び端子Ａの後に、リクエスト受信部３２は、リプライ送信部３７にエラー情報を内部中継サーバ１３へ送信させる（ステップＳ６７）。
【００９８】
次に、図４１及び図４２を用いて、外部中継サーバ３からＳａａＳサーバ５へＨＴＴＰレスポンスを送信するための処理について説明する。アクセス要求処理部３６は、リクエスト受信部３２からＨＴＴＰリクエストデータを受信し、メインメモリ等の記憶装置に格納する（ステップＳ１８１）。そして、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダにおけるX-RelayURIフィールドから中継ＵＲＩのパスを抽出すると共に、ホスト名をも抽出する（ステップＳ１８３）。また、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信待機中パス一覧において、抽出された中継ＵＲＩのパス＋ホスト名を中継ＵＲＩとして含み且つＷｅｂサービスのためのソケットＩＤが登録済みのエントリが存在するか判断させる（ステップＳ１８５）。Ｗｅｂサービス制御部３３は、指示に従って受信待機パス一覧格納部３８を検索して、該当エントリがあればアクセス要求処理部３６に出力し、該当エントリがなければ該当エントリがない旨をアクセス要求処理部３６に出力する。
【００９９】
アクセス要求処理部３６は、Ｗｅｂサービス制御部３３からの結果を受信して、該当エントリが存在するか判断する（ステップＳ１８７）。該当エントリが存在しない場合には、何らかのエラーが発生しているので、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのデータを破棄する（ステップＳ１８９）。そして、端子Ｉを介して本処理を終了する。
【０１００】
一方、該当するエントリが存在する場合には、アクセス要求処理部３６は、受信待機パス一覧内の該当エントリからＷｅｂサービスのためのソケットＩＤを抽出する（ステップＳ１９１）。また、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダ中のX-OrigHeader-が前置されているフィールドの名前及びその値を抽出し、送信すべきＨＴＴＰレスポンスのヘッダのフィールドとして設定する（ステップＳ１９３）。処理は、端子Ｈを介して図４２の処理に移行する。
【０１０１】
図４２の処理の説明に移行して、端子Ｈの後に、アクセス要求処理部３６は、受信したＨＴＴＰリクエストのヘッダ以降のデータを、送信すべきＨＴＴＰレスポンスのデータ（メッセージボディのデータ）として設定する（ステップＳ１９５）。そして、アクセス要求処理部３６は、Ｗｅｂサービスリプライ送信部３４に、ＷｅｂサービスのためのソケットＩＤを用いて、生成されたＨＴＴＰレスポンスをＳａａＳサーバ５へ送信するように指示する（ステップＳ１９７）。Ｗｅｂサービスリプライ送信部３４は、生成されたＨＴＴＰレスポンスのデータを受信して、同じく受信したＷｅｂサービスのためのソケットＩＤを用いて、ＳａａＳサーバ５へＨＴＴＰレスポンスを返信する。なお、ここで送信されるＨＴＴＰレスポンスは、図３６に示したＨＴＴＰレスポンスと同じである。図３６は、在庫管理システム１５から受信したＨＴＴＰレスポンスであり、これによって外部中継サーバ３においてＨＴＴＰレスポンスが復元されて、ＳａａＳサーバ５へ送信されたことになる。ＳａａＳサーバ５では、あたかも直接社内Ｗｅｂサービスからのレスポンスを受信したように見えるため、そのまま処理を行うことができる。
【０１０２】
なお、アクセス要求処理部３６は、Ｗｅｂサービス制御部３３に、受信待機パス一覧から、今回用いたエントリを削除するように指示する（ステップＳ１９９）。Ｗｅｂサービス制御部３３は、アクセス要求処理部３６からの指示に応じて、該当エントリを受信待機パス一覧格納部３８から削除する。
【０１０３】
以上のような処理を実施することによって、ファイアウォール外部からファイアウォール内部のＷｅｂサービスを利用することができるようになる。よって、ＳａａＳサーバ５の利用拡大が期待される。
【０１０４】
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、外部中継サーバ３及び内部中継サーバ１３の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。また、ＳａａＳサーバ５で提供されるＷｅｂサービスと社内Ｗｅｂサービスとの組み合わせは、任意であって上で述べたものは一例に過ぎない。さらに、処理フローについても、処理結果が変わらない限りステップの順番を入れ替えたり、並列に実行するようにすることもできる。例えばヘッダの設定順番はＨＴＴＰの定義に従っている限りにおいては特に問題はない。
【０１０５】
なお、上で述べた外部中継サーバ３及び内部中継サーバ１３並びに他のサーバなどは、コンピュータ装置であって、図４３に示すように、メモリ２５０１とプロセッサ（ＣＰＵ２５０３）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【０１０６】
以上述べた本実施の形態をまとめると、以下のようになる。
【０１０７】
本実施の形態における第１の態様に係る中継処理方法は、ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１のサービス提供サーバに対して処理を要求する端末から第１のサービス提供サーバを第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、（Ｂ）リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して第１中継サーバに送信するステップと、（Ｃ）第１中継サーバから、第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして第１のサービス提供サーバからの処理リクエストを受信するステップと、（Ｄ）処理リクエストを第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、（Ｅ）第２のサービス提供サーバから、第２のリクエストに対する応答データを受信するステップと、（Ｆ）応答データを、第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、第１中継サーバに送信するステップとを含む。
【０１０８】
このようにすればファイアウォールによって通常であれば利用することができないファイアウォール内部の第２のサービス提供サーバを、ファイアウォール外部の第１のサービス提供サーバから利用できるようになる。
【０１０９】
なお、上で述べた第２ＨＴＴＰリクエストが、所定の中継ＵＲＩについてのＨＴＴＰリクエストである場合もある。このようにすれば、さらに連続して第１のサービス提供サーバからファイアウォール内部の第２のサービス提供サーバにリクエストを送信する場合にも対処できるようになる。
【０１１０】
本実施の形態における第２の態様に係る中継処理方法は、ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働してファイアウォール外部の第１のサービス提供サーバとファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法である。この中継処理方法は、（Ａ）第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストをファイアウォールを介して受信するステップと、（Ｂ）第１ＨＴＴＰリクエストの受信に応答して、所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するのを待機するステップと、（Ｃ）所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを第１のサービス提供サーバから受信するステップと、（Ｄ）第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、第１中継サーバに送信するステップと、（Ｅ）第１中継サーバから、第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、（Ｆ）第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれるレスポンスのためのデータを用いて、第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、第１中継サーバに送信するステップとを含む。
【０１１１】
このようにすればファイアウォールの設定を変更することなく、ファイルウォール外部の第１のサービス提供サーバからファイアウォール内部の第２のサービス提供サーバを利用することができるようになる。
【０１１２】
なお、上で述べた第３ＨＴＴＰリクエストが、所定の中継ＵＲＩについてのＨＴＴＰリクエストである場合もある。その場合、第３ＨＴＴＰリクエストの受信に応答して、所定の中継ＵＲＩについての第４ＨＴＴＰリクエストを第１のサービス提供サーバから受信するのを待機するステップをさらに含むようにしてもよい。１回だけではなく複数回ファイアウォール外部の第１のサービス提供サーバからファイアウォール内部の第２のサービス提供サーバへアクセスする場合に有用である。
【０１１３】
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。
【０１１４】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１１５】
（付記１）
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するステップと、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するステップと、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【０１１６】
（付記２）
前記第２ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストである
付記１記載の中継処理方法。
【０１１７】
（付記３）
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するステップと、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップと、
前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するステップと、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【０１１８】
（付記４）
前記第３ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストであり、
前記第３ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第４ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップ
をさらに含む付記３記載の中継処理方法。
【０１１９】
（付記５）
付記１乃至４のいずれか１つ記載の中継処理方法をコンピュータに実行させるためのプログラム。
【０１２０】
（付記６）
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる内部中継サーバであって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するリクエスト受信部と、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するリクエスト送信部と、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するリプライ受信部と、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するサービスリクエスト送信部と、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するサービスリプライ受信部と、
を有し、
前記リクエスト送信部が、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信する
内部中継サーバ。
【０１２１】
（付記７）
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる外部中継サーバであって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するリクエスト受信部と、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機した後、前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するサービスリクエスト受信部と、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するリプライ送信部と、
を有し、
前記リクエスト受信部が、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信し、
前記外部中継サーバが、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するサービスリプライ送信部、
をさらに有する外部中継サーバ。
【符号の説明】
【０１２２】
１ インターネット ３ 外部中継サーバ
５ ＳａａＳサーバ ７ ファイアウォール
９ 内部ネットワーク １１ 部門Ａユーザ端末
１３ 内部中継サーバ １５ 在庫管理システム
３１ アクセス許可情報格納部 ３２ リクエスト受信部
３３ Ｗｅｂサービス制御部
３４ Ｗｅｂサービスリプライ送信部
３５ Ｗｅｂサービスリクエスト受信部
３６ アクセス要求処理部
３７ リプライ送信部
３８ 受信待機中パス一覧格納部
１３１ リクエスト受信部 １３２ リプライ送信部
１３３ ユーザ情報格納部 １３４ 接続情報管理部
１３５ セッション一覧情報格納部 １３６ セッション管理部
１３７ 外部インタフェース部 １３８ アクセス要求処理部
１３９ 接続認証情報格納部
１４０ 社内Ｗｅｂサービスインタフェース部
１４１１ Ｗｅｂサービスリクエスト送信部
１４１２ Ｗｅｂサービスリプライ受信部
１３７１ リクエスト送信部 １３７２ リプライ受信部
【特許請求の範囲】
【請求項１】
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するステップと、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するステップと、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【請求項２】
前記第２ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストである
請求項１記載の中継処理方法。
【請求項３】
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するステップと、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップと、
前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するステップと、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【請求項４】
前記第３ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストであり、
前記第３ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第４ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップ
をさらに含む請求項３記載の中継処理方法。
【請求項５】
請求項１乃至４のいずれか１つ記載の中継処理方法をコンピュータに実行させるためのプログラム。
【請求項６】
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる内部中継サーバであって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するリクエスト受信部と、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するリクエスト送信部と、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するリプライ受信部と、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するサービスリクエスト送信部と、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するサービスリプライ受信部と、
を有し、
前記リクエスト送信部が、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信する
内部中継サーバ。
【請求項７】
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる外部中継サーバであって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するリクエスト受信部と、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機した後、前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するサービスリクエスト受信部と、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するリプライ送信部と、
を有し、
前記リクエスト受信部が、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信し、
前記外部中継サーバが、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するサービスリプライ送信部、
をさらに有する外部中継サーバ。
【請求項１】
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するステップと、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するステップと、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するステップと、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するステップと、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【請求項２】
前記第２ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストである
請求項１記載の中継処理方法。
【請求項３】
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる第２中継サーバにより実行される中継処理方法であって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するステップと、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップと、
前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するステップと、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するステップと、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信するステップと、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するステップと、
を含む中継処理方法。
【請求項４】
前記第３ＨＴＴＰリクエストが、前記所定の中継ＵＲＩについてのＨＴＴＰリクエストであり、
前記第３ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第４ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機するステップ
をさらに含む請求項３記載の中継処理方法。
【請求項５】
請求項１乃至４のいずれか１つ記載の中継処理方法をコンピュータに実行させるためのプログラム。
【請求項６】
ファイアウォール内部に設置され且つファイアウォール外部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる内部中継サーバであって、
前記第１のサービス提供サーバに対して処理を要求する端末から前記第１のサービス提供サーバを前記第２のサービス提供サーバと連携させるためのリクエストを受信するリクエスト受信部と、
前記リクエストに応答して、所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して前記第１中継サーバに送信するリクエスト送信部と、
前記第１中継サーバから、前記第１ＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして前記第１のサービス提供サーバからの処理リクエストを受信するリプライ受信部と、
前記処理リクエストを前記第２のサービス提供サーバに対する第２のリクエストに変換して、当該第２のサービス提供サーバに送信するサービスリクエスト送信部と、
前記第２のサービス提供サーバから、前記第２のリクエストに対する応答データを受信するサービスリプライ受信部と、
を有し、
前記リクエスト送信部が、
前記応答データを、前記第１のサービス提供サーバへのレスポンスのための第２ＨＴＴＰリクエストに変換し、前記第１中継サーバに送信する
内部中継サーバ。
【請求項７】
ファイアウォール外部に設置され且つファイアウォール内部の第１中継サーバと協働して前記ファイアウォール外部の第１のサービス提供サーバと前記ファイアウォール内部の第２のサービス提供サーバとを連携させる外部中継サーバであって、
前記第１中継サーバから所定の中継ＵＲＩ（Uniform Resource Identifier）についての第１ＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを前記ファイアウォールを介して受信するリクエスト受信部と、
前記第１ＨＴＴＰリクエストの受信に応答して、前記所定の中継ＵＲＩについての第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するのを待機した後、前記所定の中継ＵＲＩについての前記第２ＨＴＴＰリクエストを前記第１のサービス提供サーバから受信するサービスリクエスト受信部と、
前記第２ＨＴＴＰリクエストの受信に応答して、当該第２ＨＴＴＰリクエストを前記第１ＨＴＴＰリクエストに対する第１のＨＴＴＰレスポンスに変換して、前記第１中継サーバに送信するリプライ送信部と、
を有し、
前記リクエスト受信部が、
前記第１中継サーバから、前記第２ＨＴＴＰリクエストへのレスポンスのためのデータを含む第３ＨＴＴＰリクエストを受信し、
前記外部中継サーバが、
前記第３ＨＴＴＰリクエストの受信に応答して、当該第３ＨＴＴＰリクエストに含まれる前記レスポンスのためのデータを用いて、前記第２ＨＴＴＰリクエストへのレスポンスである第２のＨＴＴＰレスポンスを生成し、前記第１中継サーバに送信するサービスリプライ送信部、
をさらに有する外部中継サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３Ａ】
【図１３Ｂ】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３Ａ】
【図１３Ｂ】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【公開番号】特開２０１１−１８６９１２（Ｐ２０１１−１８６９１２Ａ）
【公開日】平成２３年９月２２日（２０１１．９．２２）
【国際特許分類】
【出願番号】特願２０１０−５３２４５（Ｐ２０１０−５３２４５）
【出願日】平成２２年３月１０日（２０１０．３．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年９月２２日（２０１１．９．２２）
【国際特許分類】
【出願日】平成２２年３月１０日（２０１０．３．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]