JP2009290861A - プロキシ・ベースの双方向ウェブサービス・ルータ・ゲートウェイ - Google Patents

Abstract

【課題】 ファイアウオールを大幅に変更することなく、異なる企業ドメインに属するクライアントとサーバとが双方向ウエブサービスを提供／授受するシステムを提供する。
【解決手段】 トンネル・ハブは、パブリック・ドメインに配置され、トンネル・ゲートウェイは、ファイアウォールの背後に配置される。この構成で、クライアントは双方向のサービスをリクエストでき、サーバが双方向サービスを提供できる。（ファイアウォールの背後にある）各トンネル・ゲートウェイは、ターゲット・ハブへファイアウォールを通して出る安全なトンネルを構築する。トンネルの創設（構築）後、第１ドメインのサービスのリクエストは、トンネル・ゲートウェイに入り、パブリック・ドメインにあるトンネル・ハブに移行し、さらに第２のドメインにあるトンネル・ゲートウェイに入る。第２ドメインのサーバがサービスを提供すると、そのサービスは、リクエストの通過したルートとは逆順に、通過する。
【選択図】 図１

Description

本発明は、通信に関し、特に双方向ウェブサービスを提供するシステムと方法に関する。

リモート・サービス・アクセスと分散型のサービスを構築することは、通信で可能となるビジネス・プロセス（ＣＥＢＰ：Communications-Enabled Business Processes）と、サービスとしてのソフトウェア（ＳａａＳ：Software as a Service）と、分散型のサービス指向アーキテクチャ（ＳＯＡ：Service-Oriented Architectures）のソルーションにとって重要なことである。これ無しでは、ウェブサービスのアプリケーションとＳＯＡのソリューションは、ネットワーク−アドレス−変換／ファイアウォールの企業ドメインに限られてしまう。

これらの問題を解決するために最も広く使用されるアプローチは、企業が、彼らのネットワーク−アドレス−変換／ファイアウォールを変更／開放して、彼らのウェブサービス・エンド・ポイントを公衆ネットワークから、一方向のウェブサービスと同様に、アクセスできるようにすることである。しかし、双方向のウェブサービスを提供するためには、サービス・プロバイダとサービス・コンシューマの両方を、外部の公衆ネットワークに曝す必要がある。これは、サービス・プロバイダとサービス・コンシューマの両方にとって、多大なリスクを伴う。企業のセキュリティ・アーキテクチャは、非常に精巧なものであり、なお非常な努力で実行可能となるため、企業のネットワーク−アドレス−変換／ファイアウォールを開放することは、好ましくない。企業のセキュリティ・アーキテクチャは、多くのサービスがオンデマンド方式で付加又は削除されるようなＣＥＢＰのダイナミックな特質をサポートすることはできない。

さらに、サービスを公衆ネットワークに曝す時間は、長く潜在的なリスクがあるが故に、多くのレベルでの承認を得なければならない。一定のネットワーク−アドレス−変換／ファイアウォールの再構築により、ダイナミックＣＥＢＰをサポートする企業のＩＴにかかる作業負荷とコストは、サービスとアプリケーションの数が増加するにつれて、膨大なものとなる。

他方で、中小企業は、彼らのウェブサービスを公衆化するようなインフラも専門知識も無い。これらの中小企業が自分のアプリケーションを公衆ネットワークからアクセスできるようにするためには、大きなコストがかかり、最終的にそれら企業は、これらのサービスを利用させないか、またはＣＥＢＰのソリューションの一部となるのを避けることになる。多くの場合、クライアントのアプリケーションは、特定の情報ソースからの関心のある事象を受領することを望むだけでよく、事象要求を外部のネットワークに曝すことは、不必要なだけでなく、セキュリティの問題を引き起こしてしまう。結論として、現在のアプローチは、双方向のウェブサービス（ＣＥＢＰと分散型のＳＯＡにとって必須なことである）用のホストとして管理されるサービスあるいはオンデマンドのサービスにとって、充分ではない。

これらの問題を解決する別の従来技術では、企業は仮想プライベート・ネットワーク（ＶＰＮ：Virtual Private Network）を展開して、分散したネットワークを接続することが必要である。しかし、ＶＰＮは、非常に高価かつ複雑である。さらに、多くの場合ＶＰＮは適切ではない。例えば、企業は、彼らのパートナー、第三者、サプライヤーが、彼らの内部企業ネットワークに、ＶＰＮを介して直接アクセスすることを許さないからである。

マイクロソフト社は、近年BizTalk Connectivity Servicesをリリースした。これによりソフトウエア開発業者は、緩く結合した複数のアプリケーションを作り出すことができ、ファイアウォールの背後またはネットワーク−アドレス−変換の背後から、サービスをインターネットに露出できるようになった（http://connect.biztalk.net）。しかし、これは、プラットホームであり、アプリケーション依存のソリューションである。従って、Net frameworkの特殊バージョンを具備したウインドウズ・プラットホームを必要とする。この市販されたサービスは、マイクロソフト社が管理している。その為、アプリケーションに対しては透明性が無く、BizTalk's SDKを用いたアプリケーションのみが、外部ネットワークからアクセスが可能である。

課題を解決しようする手段

本発明により、従来技術のコストと不利益な点の少なくとも一部を改善した双方向ウェブサービスを提供できる。例えば、本発明の一実施例により、異なる企業ドメインあるいはファイアウォールの背後にあるクライアントとサーバは、ファイアウォールへの変更を行わずに又は僅かな変更だけで、双方向ウェブサービスをリクエストし受領できる。これは特に、上記したＣＥＢＰと、ＳａａＳと、ＳＯＡにとって、利点がある。

本発明の一実施例によれば、「トンネル・ハブ（tunnel hub）」は、パブリック・ドメインに配置され、「トンネル・ゲートウェイ（tunnel gateway）」は、ファイアウォールの背後に配置される。この構成で、クライアントは双方向サービスをリクエストでき、サーバが双方向サービスを提供できる。各トンネル・ゲートウェイは、ターゲット・ハブへファイアウォールを通して出る安全なトンネルを、創設／構築する。トンネルの創設（構築）後、サービスを要求するリクエストは、トンネル・ゲートウェイに入り、トンネル・ハブに移行し、さらにトンネル・ゲートウェイ（サーバがそのサービスを提供する）に移行する。サーバがサービスを提供すると、そのサービスは、トンネル・ハブに移行して、トンネル・ゲートウェイ（そのクライアントがそのサービスを要求したクライアントである）に入る。全てのトンネルは、企業のファイアウォールの背後から構築されているために、双方向のウェブサービスは、企業のネットワーク−アドレス−変換／ファイアウォールの構築をほとんど変更せずに、ファイアウォールを乗り越えることができる。

本発明の一実施例の構成要素を表すブロック図。 トンネル・ゲートウェイ１２３−ｉの構成要素を表すブロック図：ｉ∈｛１、２、３｝ トンネル・ハブ１１２の構成要素を表すブロック図。 本発明の一実施例の動作の各タスクのフローチャートを表す図。 タスク４０３の実行の（即ちトンネルのネットワークの確立する）の際に、本発明の一実施例により行われる各タスクのフローチャートを表す図。 タスク４０４の実行の（即ち双方向サービスをリクエストし受信する）際に、本発明の一実施例により行われる各タスクのフローチャートを表す図。

図１において、通信システム１００は、インターネット１０１と、企業のコンピュータ・ドメイン１１０−１〜１１０−３と、ファイアウォール１１１−１〜１１１−３と、トンネル１３１−１〜１３１−３と、トンネル・ハブ１１２とを有し、それらは図に示したよう接続されている。図１に示した実施例は、３つの企業ドメインを有するが、これ以外の数の企業ドメインを有するシステムも、本明細書を参照することにより、当業者は容易に想到できる。

インターネット１０１は、ユビキタス公衆データ・網（ＰＤＮ：Public Data Network）であり、当業者には公知である。本明細書を参照することにより、異なるネットワーク（例、公衆交換電話網（ＰＳＴＮ：Public Switched Telephone Network）等）で、ドメインの一部あるいは全てを接続する実施例も、当業者は容易に想到できる。

企業ドメイン１１０−ｉは、クライアント１２１−ｉと、サーバ１２２−ｉと、トンネル・ゲートウェイ１２３−ｉとを有する。クライアント１２１−ｉは、ハードウェアとソフトウェアを有し、トンネル・ゲートウェイ１２３−ｉをプロキシとして用いて双方向サービスを要求（リクエスト）し、受領できる。当業者には、本明細書を参照することにより、トンネル・ゲートウェイ１２３−ｉの製造／使用方法は明らかである。サーバ１２２−ｉは、ハードウェアとソフトウェアを有し、次のことができる。
（１）双方向サービスに対するリクエストを、トンネル・ゲートウェイ１２３−ｉをプロキシとして介して受領すること。
（２）リクエストされた双方向サービスを、トンネル・ゲートウェイ１２３−ｉをプロキシとして介して提供すること。
当業者には、本明細書を参照することにより、サーバ１２２−ｉの製造／使用方法は、明らかである。トンネル・ゲートウェイ１２３−ｉは、ハードウェアとソフトウェアを用いて以下を実行する。
（１）ファイアウォール１１１−ｉとインターネット１０１を介して、トンネル・ハブ１１２へのトンネル１３１−ｉを創設（構築）すること。
（２）クライアント１２１−ｉとサーバ１２２−ｉに対するプロキシとして機能すること。
トンネル・ゲートウェイ１２３−ｉのアーキテクチャを、図面を参照して以下に説明する。クライアント１２１−ｉと、サーバ１２２−ｉと、トンネル・ゲートウェイ１２３−ｉと、トンネル・ハブ１１２とで行われるタスクを、図面を参照して詳述する。

ファイアウォール１１１−１〜１１１−３は、ハードウェアとソフトウェアを有し、インターネット１０１からハッカーが、企業ドメイン内のリソースにアクセスするのを阻止する。ファイアウォール１１１−１〜１１１−３の製造／使用方法は、本明細書を参照することにより、当業者に明らかである。

トンネル・ハブ１１２は、ハードウェアとソフトウェアを有し、以下を実行する。 （１）トンネル・ゲートウェイ１２３−１〜１２３−３と間の安全確保したトンネルを確立すること。
（２）サービスに対するリクエストを、クライアント１２１−ｉからサーバ１２２−ｋにルーティングすること：ｋ∈｛１、２、３｝とｉ≠ｋ。
（３）サービスをサーバ１２２−ｋからクライアント１２１−ｉに戻すようルーティングすること。
トンネル・ハブ１１２のアーキテクチャとそのタスクの実行を、図面を参照して詳述する。

本発明の一実施例では、各企業ドメインは、１つのクライアント・コンピュータと、１つのサーバ・コンピュータと、１つのトンネル・ゲートウェイとを有するが、本明細書を参照することにより、如何なる数のクライアント・コンピュータ、サーバ・コンピュータ、トンネル・ゲートウェイを有する企業ドメインを構築することは、当業者は、想到できる。

本発明の一実施例によれば、クライアント１２１−ｉは、サーバ１２２−ｊ（ｊ∈｛１、２、３｝）からサービスをリクエストできる。本発明の一実施例によれば、このサービスは、「双方向サービス」である。この双方向サービスとは、本明細書においては、クライアントにより開始された少なくとも１つの通信と、サーバ・コンピュータにより開始された少なくとも１つの通信があるサービスと定義する。本明細書を参照することにより、当業者は、クライアント・コンピュータが、サーバ・コンピュータから「一方向」サービスをリクエストできる実施例を、容易に想到できる。

本発明の一実施例によれば、トンネル・ゲートウェイ１２３−ｉがトンネル・ハブ１１２との間のトンネルを確立した後、クライアント１２１−ｉからの全てのサービス・リクエストは、トンネル・ゲートウェイ１２３−ｉを通り、（１）サーバ１２２−ｉ（同一企業ドメイン１１０−ｉ内の）に、または（２）サーバ１２２−ｋ（別企業ドメイン１１０−ｋ内の）に転送されるべく、トンネル・ハブ１１２にルーティングされる。かくして、クライアント１２１−ｉは、トンネル・ゲートウェイ１２３−ｉをサービス・プロキシとして用いる。

図２は、トンネル・ゲートウェイ１２３−ｉ（ｉ∈｛１、２、３｝）の構成要素を表すブロック図である。図２において、トンネル・ゲートウェイ１２３−ｉは、プロキシ２０１−ｉと、ルータ２０２−ｉと、トンネル１３１−ｉとを有し、それらは図に示したよう接続されている。当業者には、本明細書を参照することにより、トンネル・ゲートウェイ１２３−ｉの製造／使用方法は明らかである。

トンネル・ゲートウェイ１２３−ｉは、トンネル・ハブ１１２との間のトンネル１３１−ｉを確立する。クライアント１２１−ｉ上のアプリケーションからの双方向ウェブサービスの全リクエストは、トンネル・ゲートウェイ１２３−ｉを通り、トンネル・ハブ１１２（サーバが別企業ドメインにサービスを提供する場合）またはサーバ１２２−ｉ（サーバが同一の企業ドメインにサービスを提供する場合）のいずれかに、ルーティングされる。これにより、クライアント１２１−ｉ上のアプリケーションは、トンネル・ゲートウェイ１２３−ｉをサービス・プロキシとして、構築し使用できる。これは公知である。

クライアント１２１−ｉから見ると、トンネル・ゲートウェイ１２３−ｉは、クライアント１２１−ｉ上のアプリケーションにとって、特殊なウェブ・プロキシであり、プロキシとして、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Simple Object Access Protocol）のリクエストあるいはハイパーテキスト転送プロトコル（ＨＴＴＰ：Hypertext Transfer Protocol）のリクエストを、トンネル・ハブ１１２に転送する。サーバ１２２−ｉから見ると、トンネル・ゲートウェイ１２３−ｉは、特殊なリバース・プロキシであり、トンネル・ハブ１１２から来た全リクエストを、対応するウェブサービス・エンドポイントに転送する。本発明のトンネル・ゲートウェイ１２３−ｉと従来技術のウェブ・プロキシとの間の違いの１つは、データ交換を行う前に、トンネル・ゲートウェイは、トンネル（例えば、永続的なTＣＰ接続、保護されたＴＣＰ接続等）を、企業ドメイン１１０−ｉの内側からトンネル・ハブ１１２まで確立する点である。トンネルの確立が成功すると、クライアント１２１−ｉ上のアプリケーションは、トンネル・ゲートウェイ１２３−ｉをプロキシとして用いて、企業ドメインを超えて、ウェブサービスにアクセスできる。更に、サーバ１２２−ｊは、クライアント１２１−ｉ上のアプリケーションと、トンネル・ゲートウェイ１２３−ｊとトンネル・ゲートウェイ１２３−ｉを介して、通信を確立できる。かくして双方向ウェブサービス通信は、クライアントとサーバが異なる企業ドメインに属する場合でも、達成できる。

図３において、トンネル・ハブ１１２は、プロキシ３０１と、ルータ３０２と、トンネル１３１−１〜１３１−３とを有し、それらは図に示すよう接続される。本明細書を参照することにより、トンネル・ハブ１１２の製造／使用方法は、当業者に明らかである。

本発明の一実施例によれば、トンネル・ハブ１１２は、パブリック・ドメインに配置される。その結果、トンネル・ゲートウェイ１２３−ｉは、ファイアウォールを貫通することなく、トンネル・ハブ１１２にアクセスできる。トンネル・ゲートウェイ１２３−ｉからのリクエストを受領すると、トンネル・ハブ１１２内のトンネル３０３−ｉは、それをルータ３０２に転送する。このルータ３０２は、このリクエストを適宜のトンネル・ゲートウェイに転送する。

図４は、本発明の一実施例の動作の各タスクのフローチャートを示す。

タスク４０１において、トンネル・ハブ１１２は、パブリック・ドメイン内に配置される。本明細書を参照することにより、当業者は、タスク４０１の実行方法を、想到できる。

タスク４０２において、トンネル・ゲートウェイ１２３−１〜１２３−３は、適宜の企業ドメイン内に配置される。本明細書を参照することにより、当業者は、タスク４０２の実行方法を、想到できる。

タスク４０３において、トンネル・ゲートウェイ１２３−１〜１２３−３は、トンネル・ハブ１１２とのトンネルのネットワークの確立を開始する。タスク４０３は、図面を参照して以下説明する。

タスク４０４において、クライアント１２１−１〜１２１−３は、サーバ１２２−１〜１２２−３からの双方向サービスをリクエストし受領する。タスク４０４は、図面を参照して以下説明する。

図５は、タスク４０３の実行の際即ちトンネル・ネットワークの確立する際に、本発明の一実施例により行われる各タスクのフローチャートを示す。

タスク５０１において、トンネル・ゲートウェイ１２３−ｉは、トンネル・リクエストを、トンネル１３１−ｉを通して、トンネル・ハブ１１２に送信する。本明細書を参照することにより、当業者は、タスク５０１の実行方法を想到できる。

タスク５０２において、トンネル・ハブ１１２は、トンネル・ゲートウェイ１２３−ｉからのトンネル・リクエストを受領する。本明細書を参照することにより、当業者は、タスク５０２の実行方法を想到できる。

タスク５０３、５０４において、トンネル・ハブ１１２は、トンネル・ゲートウェイ１２３−ｉを認証して、トンネル・ゲートウェイ１２３−ｉが、実際にサーバ１２２−ｊが提供したサービスにアクセスできる権限を有することを確認する。トンネル・ゲートウェイ１２３−ｉが認証されない場合には、このプロセスを中止する。トンネル・ゲートウェイ１２３−ｉが認証された場合は、このプロセスはタスク５０５に進む。本明細書を参照することにより、当業者は、タスク５０３、５０４の実行方法を想到できる。

タスク５０５、５０６において、トンネル・ハブ１１２とトンネル・ゲートウェイ１２３−ｉは、トンネルを確立する。本明細書を参照することにより、当業者は、タスク５０５、５０６の実行方法を想到できる。

図６は、タスク４０４の実行の際即ち双方向サービスをリクエストし受信する際に、本発明の一実施例により行われる各タスクのフローチャートを示す。

タスク６０１において、クライアント１２１−ｉは、双方向サービスのリクエストをトンネル・ゲートウェイ１２３−ｉに送信する。本明細書を参照することにより、タスク６０１を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６０２におてい、トンネル・ゲートウェイ１２３−ｉは、双方向サービスのリクエストをクライアント１２１−ｉから受領する。本明細書を参照することにより、タスク６０２を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６０３において、トンネル・ゲートウェイ１２３−ｉは、サーバをサービスにマッピングするルックアップ・テーブルの助けを借りて、リクエストを適宜送信する。サービスがサーバ１２２−ｉにより提供されると、このサーバ１２２−ｉは、クライアント１２１−ｉと同一の企業ドメインに属する為、トンネル・ゲートウェイ１２３−ｉは、このリクエストをサーバ１２２−ｉに直接送る（タスク６０４）。これには、トンネル・ハブ１１２は関与しない。その後、サーバ１２２−ｉとクライアント１２１−ｉは、トンネル・ゲートウェイ１２３−ｉを介して相互に作用し合う（要求し受領する）。これに、トンネル・ハブ１１２は関与しない。これに対し、リクエストされたサービスをサーバ１２２−ｊが提供する時には、このサーバ１２２−ｊはクライアント１２１−ｉと同一の企業ドメインには属さない為、トンネル・ゲートウェイがこのリクエストをトンネル・ハブ１１２に送信する。本明細書を参照することにより、タスク６０３と６０４を実行する本発明の実施例の製造／使用方法は、当業者に明らかである。

タスク６０５において、トンネル・ハブ１１２は、リクエストをトンネル・ゲートウェイ１２３−ｉからトンネル１３１−ｉを介して受領する。本明細書を参照することにより、タスク６０５を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６０６において、トンネル・ハブ１１２は、サーバをサービスにマッピングする（サーバとサービスを対応付ける）ルックアップ・テーブルの助けを借りて、リクエストを、トンネル１３１−ｋを介してトンネル・ゲートウェイ１２３−ｋに送信する。本明細書を参照することにより、タスク６０６を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６０７において、トンネル・ゲートウェイ１２３−ｋは、リクエストをトンネル１３１−ｋを介して受領する。本明細書を参照することにより、タスク６０７を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６０８において、トンネル・ゲートウェイ１２３−ｋは、サーバをサービスにマッピングするルックアップ・テーブルの助けを借りて、リクエストをサーバ１２２−ｋに送信する。本明細書を参照することにより、タスク６０８を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６０９において、サーバ１２２−ｋは、サービスに対するリクエストを受領する。本明細書を参照することにより、タスク６０９を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１０において、サーバ１２２−ｋは、サービスを、トンネル・ゲートウェイ１２３−ｋに送信する。これは、サービスを要求したクライアントに戻す為である。本明細書を参照することにより、タスク６１０を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１１において、トンネル・ゲートウェイ１２３−ｋは、サービスを受領する。本明細書を参照することにより、タスク６１１を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１２において、トンネル・ゲートウェイ１２３−ｋは、サーバをサービスにマッピングするルックアップ・テーブルの助けを借りて、サービスを適宜送信する。サービスを要求したクライアントがクライアント１２１−ｋの場合は、サーバ１２２−ｋとトンネル・ゲートウエイ１２３−ｋと同一の企業ドメインに属するので、トンネル・ゲートウエイ１２３−ｋは、このサービスをクライアント１２１−ｋに直接送信する。これには、トンネル・ハブ１１２は関与しない。これに対し、サービスをクライアント１２１−ｉが要求した場合は、トンネル・ゲートウエイ１２３−ｉは、このサービスをトンネル・ハブ１１２に、トンネル１３１−ｋを介して送信する。本明細書を参照することにより、タスク６１２を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１３において、トンネル・ハブ１１２は、サービスをトンネル１３１−ｋを介して受信する。本明細書を参照することにより、タスク６１３を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１４において、トンネル・ハブ１１２は、サービスをトンネル・ゲートウェイ１２３−ｉにトンネル１３１−ｉを介して送信する。本明細書を参照することにより、タスク６１４を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１５において、トンネル・ゲートウェイ１２３−ｉは、サービスを受領する。本明細書を参照することにより、タスク６１５を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１６において、トンネル・ゲートウェイ１２３−ｉは、サービスをクライアント１２１−ｉに送信する。本明細書を参照することにより、タスク６１６を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

タスク６１７において、クライアント１２１−ｉは、サービスを受領する。本明細書を参照することにより、タスク６１７を実行する本発明の実施例の製造／使用方法は当業者に明らかである。

以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。

１００ 通信システム
１０１ インターネット
１１０ 企業ドメイン
１１１ ファイアウォール
１１２ トンネル・ハブ
１２１ クライアント
１２２ サーバ
１２３ トンネル・ゲートウェイ
１３１ トンネル
２０１ プロキシ
２０２ ルータ
３０１ プロキシ
３０２ ルータ
４０１ トンネル・ハブをパブリック・ドメイン内に配置する
４０２ トンネル・ゲートウェイをファイアウォールの背後に配置する
４０３ トンネル・ハブとトンネル・ゲートウェイの間にトンネル・ネットワークを確立 する
４０４ 双方向サービスをトンネルのネットワークを介してリクエストし提供する
５０１ トンネル・リクエストを送信する
５０２ トンネル・リクエストを受信する
５０３ 認証された？
５０４ 認証する
５０５ トンネルを確立する
５０６ トンネルを確立する
６０１ サービスをリクエストする
６０２ サービス・リクエストを受領する
６０３，６０６，６０８ リクエストを送信する
６０４ リクエストを受領し処理する
６０５，６０７，６０９ リクエストを受領する
６１０ サービスを提供する
６１１，６１３，６１５，６１７ サービスを受領する
６１２，６１４，６１６ サービスを送信する

Claims (4)

1. （Ａ）第１トンネルを確立するステップと、
   前記第１トンネルは、第１企業ドメインにある第１トンネル・ゲートウェイから、第１ファイアウォールを介して、パブリック・ドメインにあるトンネル・ハブまでであり、
   （Ｂ）第２トンネルを確立するステップと、
   前記第２トンネルは、第２企業ドメインにある第２トンネル・ゲートウェイから、第２ファイアウォールを介して、前記トンネル・ハブまでであり
   を有する
   ことを特徴とするトンネルを確立する方法。
2. （Ｃ）双方向ウェブサービスのリクエストを送信するステップと、
   前記リクエストは、前記第１トンネル・ゲートウェイから、前記トンネル・ハブへ更に前記第２トンネル・ゲートウェイに、送信され、
   （Ｄ）前記リクエストに応じて、サービスを送信するステップと、
   前記サービスは、前記第２トンネル・ゲートウェイから、前記トンネル・ハブへ更に前記第１トンネル・ゲートウェイに、送信される
   ことを特徴とする請求項１記載の方法。
3. （Ｅ）第３トンネルを確立するステップ
   前記第３トンネルは、第３企業ドメインにある第３トンネル・ゲートウェイから、第３のファイアウォールを介して、前記トンネル・ハブにまでであり
   をさらに有する
   ことを特徴とする請求項１記載の方法。
4. （Ｆ）第１の双方向ウェブサービスの第１リクエストを送信するステップと、
   前記第１リクエストは、前記第１トンネル・ゲートウェイから、前記トンネル・ハブへ更に前記第２トンネル・ゲートウェイにまで、送信され、
   （Ｇ）前記第１リクエストに応答して、第１サービスを送信するステップと、
   前記第１サービスは、前記第２トンネル・ゲートウェイから、前記トンネル・ハブへ更に第１トンネル・ゲートウェイにまで、送信され、
   （Ｈ）第２の双方向ウェブサービスの第２リクエストを送信するステップと、
   前記第２リクエストは、前記第１トンネル・ゲートウェイから、前記トンネル・ハブへ更に前記第３トンネル・ゲートウェイにまで、送信され、
   （Ｉ）前記第２リクエストに応答して、第２サービスを送信するステップと、
   前記第２サービスは、前記第３トンネル・ゲートウェイから、前記トンネル・ハブへ更に第１トンネル・ゲートウェイにまで、送信される
   をさらに有する
   ことを特徴とする請求項３記載の方法。
   

Images