ウェブソケット通信の分散エミュレーションを通してウェブアプリケーションサポートを提供する企業クライアント／サーバーシステム及び方法
ｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントにおけるクロス起点セキュリティ制約のためにアクセスできないサーバー間で分散ウェブアプリケーションのサービス通信を可能にするシステム。ウェブブラウザクライアントは、定義されたソース起点を有するソース起点サーバーから受け取られたクライアント側ウェブアプリケーションを実行し、そしてその定義されたウェブアプリケーションサービスへの接続を要求する。エミュレーションクライアントライブラリーを実行すると、ウェブブラウザクライアントと、ソース起点の範囲外のターゲット起点を有するゲートウェイサーバーとの間に、両方向ＨＴＴＰベースの通信接続を確立し、要求識別ウェブアプリケーションサービスへのアクセスを与える。両方向ＨＴＴＰベースの通信接続は、ソースとターゲット起点との間にセキュアな通信経路を与えるクロス起点通信ブリッジを含む。ゲートウェイサーバーは、要求識別ウェブアプリケーションサービスに対して規定の関係を有するターゲットサーバーによって提供されるターゲット定義サービスへのＨＴＭＬ５適合接続を確立することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ネットワーク通信システムに係り、より詳細には、ＨＴＴＰベースのネットワークを経てリアルタイム両方向性通信をサポートすることのできる企業クラスのクライアント／サーバーシステムに係る。
【０００２】
本発明は、２００９年５月１日に出願された米国仮特許出願第６１／１７４，９２３号の利益を請求する。
【背景技術】
【０００３】
ウェブアプリケーションの開発及び使用は、成長を続けているが、広く使用されているＨＴＴＰプロトコルが半二重通信しかサポートしないという点で著しい制約が存在する。従来のクライアント／サーバーアプリケーション使用モデルの場合のように、クライアントが種々のバックエンドシステムと対話できることが要求されない場合には、連続的なティア・ツー・ティア両方向又は全二重通信接続が強く望まれる。リアルタイム株フィードを表示し、アドホック情報更新を許し、特に、入札、チャット、ゲーム、及び他のアプリケーションで遭遇するリアルタイムオペレーションにおいて複数のユーザ間に能動的に参加できるようにする、等のウェブ上でのリアルタイムサービスの需要が重要になり増加している。
【０００４】
所有権クライアント及びサーバーアプリケーションによってサポートされる他のプロトコルを利用することはできるは、ウェブブラウザクライアントが偏在するという事実は、実際上、基本的ＨＴＴＰプロトコルの使用を要求する。本来的に、従来のウェブブラウザベースのクライアントアプリケーションは、データ要求及び応答が一度に一方向にしか流れない通信に基本的に制約されている。両方向通信をエミュレートする従来の試みは、典型的に、コメット・アンド・リバース・アジャック(Comet and Reverse Ajax)において具現化されるようなポーリング技術の使用を含む。本質的に、サーバーは、選択環境のもとで、クライアントへ情報をプッシュすることができる。しかしながら、これらの技術は、標準化の欠如、不充分な性能、及び限定された拡張性のような多数の制限で悩まされている。
【０００５】
例えば、直接的なポーリング技術は、ＨＴＴＰ要求を規則的なインターバルでターゲットウェブサーバーへ繰り返し送信するためにウェブブラウザに関連して典型的に具現化されるクライアントアプリケーションを要求する。各要求は、サーバーが更新情報を有するかどうかに基づいて更新されたリアルタイム情報を潜在的に返送するサーバー発生応答を即座に受け取る。ポーリングインターバルに基づいて、受け取られる情報は、実際には、リアルタイムで受け取られず、逆に、応答情報がない場合にサーバー要求の高いオーバーヘッドを頻繁に受けて、得ることしかできない。このオーバーヘッドは、クライアント及びサーバーの両性能に影響を及ぼし、ネットワーク帯域巾を消費する。
【０００６】
直接的ポーリングのオーバーヘッドを回避するために、ロングポーリングとして知られたバリアントが開発された。非同期ポーリングとしても知られているロングポーリングでは、この場合も典型的にウェブブラウザであるクライアントアプリケーションは、ターゲットウェブサーバーシステムに要求を発行する。即座の応答を与えるのではなく、ターゲットサーバーは、ある定義されたインターバルまで遅延し、ある新たな情報が応答として与えられるのを待機する。ある新たな、即ちリアルタイムのデータが遅延インターバル中にサーバーにより得られる場合には、リアルタイム情報を含むサーバー応答がクライアントへ送られる。新たな情報が受け取られない場合には、空き応答がクライアントアプリケーションに返送され、未決要求を終了させる。従って、ロングポーリングは、リアルタイムデータの配布の待ち時間を短縮する潜在性があり、要求／応答サイクルの数をある程度減少することができる。しかしながら、ロングポーリングは、依然として著しい数の要求／応答サイクルが必要とされ、且つ同様の数のＨＴＴＰヘッダがロングポーリング及びポーリングの両方に存在してクライアントとサーバーとの間で交換しなければならないために、慣習的なポーリングに勝る実質的な性能改善を与えない。
【０００７】
ストリーミングは、別の従来の変形例である。ストリーミングが使用される場合には、クライアントウェブブラウザが完全な要求を送信するが、ターゲットサーバーは、少なくともある定義されたインターバル中に接続をオープンに維持できるように応答する。実際に、ターゲットサーバーは、応答が完了したという確認を延期する。これは、ターゲットサーバーが、そのターゲットサーバーによって受け取られる付加的なリアルタイム情報で応答を続けられるようにする。ストリーミング接続を確立する利益は、クライアント及びサーバーシステムの一部分においてオーバーヘッドを減少することである。ネットワークトラフィックも減少される。というのは、クライアント及びサーバーシステムは、ストリーミング接続を確立するのにＨＴＴＰヘッダパケットを一度しか送信しないからである。応答継続ネットワークパケットは、必要に応じて送信されるだけであり、従って、データしか含まず、ひいては、最小のオーバーヘッドしか課さない。不都合にも、ストリーミングは、ＨＴＴＰでカプセル化され、従って、低レベルＨＴＴＰ転送がネットワーク全般を通してどのようにルーティングされるかに完全に依存する。それ故、ストリーミングは、所与の接続がルーティングされる無数のシステムによって全体的に決定される予想不能な接続／切断及び実質的なバッファリング待ち時間を受ける。それ故、従来のストリーミングは、信頼できない。
【０００８】
或いは又、提案されているＨＴＭＬ５ドラフト仕様は、ウェブソケット、サーバー送信イベント(Server-Sent Event)、及びそれに関連したアクセスセキュリティ要求を含む新たなプロトコル特徴を、ＨＴＴＰプロトコルを使用して信頼性ある両方向性通信を可能にする手段として定義している。ＨＴＭＬ５仕様は、他の中でも全二重直接ＴＣＰ通信を標準化するよう意図されているが、最終的な仕様は、公式に採用されるのに、数年でなくても、おそらく、１年はかかる。次世代のウェブブラウザへの機能的合体及び動作的に均一の採用は、おそらく、数年は行われないであろう。更に、実用性、ビジネス及び他の制約のために既存のインプレースウェブブラウザの更新に対する抵抗もあり、おそらく、大規模な採用が数年以上阻止されるであろう。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
その結果、ビジネス及び他の商業的サービス、リクリエーション及び情報を含む全ての特性のウェブサービスにアクセスするのに使用できるクライアントウェブブラウザとは実質的に独立してリアルタイム全二重通信能力を提供する手段が要望されている。
【課題を解決するための手段】
【００１０】
従って、本発明の一般的な目的は、リアルタイム両方向ブラウザ通信を、該当する場合に、現在提案されているＨＴＭＬ５仕様と一貫したものにできる効率的なゲートウェイサーバーシステムを提供することである。
【００１１】
これは、本発明において、ｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントにおけるクロス起点(cross-origin)セキュリティ制約のためにアクセスできないサーバー間で分散ウェブアプリケーションにおいてサービス通信を行うことのできるシステムを提供することにより達成される。ウェブブラウザクライアントは、定義されたソース起点を有するソース起点サーバーから受け取られたクライアント側ウェブアプリケーションを実行し、そしてその定義されたウェブアプリケーションサービスを要求するための接続を要求する。エミュレーションクライアントライブラリーを実行すると、ウェブブラウザクライアントと、ソース起点の範囲外のターゲット起点を有するゲートウェイサーバーとの間に、両方向可能ＨＴＴＰベースの通信接続を確立し、要求識別ウェブアプリケーションサービスへのアクセスを与える。両方向可能ＨＴＴＰベースの通信接続は、ソースとターゲット起点との間にセキュアな通信経路を与えるクロス起点通信ブリッジを含む。ゲートウェイサーバーは、要求識別ウェブアプリケーションサービスに対して規定の関係を有するターゲットサーバーによって提供されるターゲット定義サービスへのＨＴＭＬ５適合接続を確立することができる。
【００１２】
本発明の効果は、参加するウェブブラウザクライアントが完全なＨＴＭＬ５適合であるかどうかに関わらず、分散ウェブアプリケーションを一般的に具現化できることである。本発明の一実施形態を使用して分散ウェブアプリケーションを具現化することにより、バックエンドシステムとサービスとの間でウェブブラウザクライアントまでずっとＨＴＭＬ５仕様に機能的に適合するように適当なメッセージ取り扱い配信が確保される。更に、好ましい実施形態は、ＨＴＭＬ５規格に機能的に適合する。本来的に適合するＨＴＭＬ５ウェブブラウザクライアントは、サーバー又はクライアントアプリケーションコードを変更する必要なく、本発明によりサポートされる分散ウェブアプリケーションに及びその中に透過的に参加することができる。
【００１３】
本発明の別の効果は、クライアントエミュレーションライブラリーがバイナリー及びテキストベースの両プロトコルサポートを与えることである。バイナリープロトコルサポートは、テキストのみのウェブソケットプロトコルの特徴改善を許すと共に、クライアントとサーバーとの間の生のＴＣＰ通信を一般的に可能にする非常に望ましい仕様拡張である。バイナリープロトコルサポートを設けることは、ＨＴＭＬ５適合に影響することなく、ウェブソケットプロトコルサポートへ効率的にインターフェイスされる。本来的に適合するＨＴＭＬ５ウェブブラウザクライアントは、バイナリープロトコルから等しく利益を得、そしてそれを使用することができる。
【００１４】
本発明の更に別の効果は、ウェブブラウザクライアントのエミュレーションスタック、及びゲートウェイサーバーとの相互動作が、高性能であることである。メッセージの配信は、弾力的である。下流のサーバー送信イベント要求に対する接続を含む全ての接続は、クライアントが開始するので、クライアントとゲートウェイサーバーとの間の通信は、ＨＴＴＰプロトコルの具現化によりファイアウオール及びプロキシーサーバーをシームレスに横断することができる。切れた接続又は失われた要求の場合には、クライアント側ウェブアプリケーションは、自動的に再接続してメッセージの配信を保証するよう選択することができる。再接続オペレーションは、クライアントプロトコルライブラリ８４として具現化されるのが好ましい。更に、エミュレーション層は、ローカルウェブブラウザクライアントのプロキシー設定を自動的に認識しそして讃えることができ、ウェブプロキシーサーバーを通過しなければならない接続に伴う潜在的な問題を排除することができる。更に、クライアントライブラリは、異なるクライアント技術で具現化することもでき、そして全てのケースで、サービスに対するプロトコルトランザクションを許すために適当なＡＰＩを与えることができる。アプリケーションサーバーロジックを具現化するのに、複数のクライアント／サーバー通信トランザクションを潜在的に伴う複合サーブレットベース及び他のカスタムサーバー側サポートロジックは、要求されない。むしろ、ウェブブラウザクライアントアプリケーションは、テキスト、及び適宜に、バイナリーデータパッケージと通信することができ、これにより、通信オーバーヘッド、複雑さ、及び実行待ち時間を減少することができる。本発明により表される分散ウェブアプリケーションアーキテクチャーは、ワールドワイドの商業的アプリケーションの環境でも、非常に大きなユーザコミュニティをサポートするように容易に拡張することができる。
【００１５】
本発明の更に別の効果は、分散ウェブアプリケーションの環境においてアクセスできるサービス及び起点サーバーのセットにわたり、ひいては、ウェブブラウザクライアントの特定のセットにより、容易に管理された制御をゲートウェイサーバーが与えることである。
【００１６】
本発明の更に別の効果は、１つ以上のバックエンドサービスから、参加する全ての接続されたウェブブラウザクライアントへ送られ又は得られるデータのブロードキャスト及びマルチキャスト通知のための効率的な基礎を、ゲートウェイサーバーの使用により与えることである。バックエンドデータソースは、１つ又は幾つかの当該ゲートウェイサーバーへデータを送信することができ、これにより、単一の接触点から新たなサーバー送信イベント通知としてゲートウェイサーバーサポートウェブブラウザクライアントへ効率的に配布できるようにする。
【００１７】
本発明の更に別の効果は、エミュレーションクライアントライブラリを使用して、多数の異なる特殊なクライアントプロトコルをサポートできることである。特定の又は所有権クライアントのプロトコルを要求する分散ウェブアプリケーションは、ゲートウェイサーバーを経てダウンロードするのに使用できるクライアントライブラリリソースを調整することによりサポートすることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の好ましい実施形態のための好ましい動作環境を一般的に示す。
【図２】分散クライアント／サーバーウェブアプリケーションの具現化において本発明の好ましい実施形態を具現化するのに適したクライアント／サーバーシステムを示すブロック図である。
【図３】分散クライアント／サーバーウェブアプリケーションの具現化において本発明の好ましい実施形態を具現化するのに適した好ましいクライアント／サーバーシステムを示すブロック図である。
【図４】本発明の好ましい実施形態と一貫する分散クライアント／サーバーウェブアプリケーションに関連してクライアント側アプリケーションを具現化するように構成されたウェブブラウザクライアントを示す詳細なブロック図である。
【図５】本発明の好ましい実施形態と一貫する積層ライブラリスタックとして具現化されるクライアントライブラリのブロック図である。
【図６】本発明の好ましい実施形態によるウェブブラウザクライアントアプリケーションの好ましいｉｆｒａｍｅベース具現化を示す詳細ブロック図である。
【図７】本発明の好ましい実施形態によるエミュレートウェブソケットネットワーク接続を確立する際のウェブブラウザクライアントアプリケーションの初期化及び実行を示すシーケンス図である。
【図８Ａ】本発明の好ましい実施形態により構成されたウェブブラウザクライアントアプリケーションの好ましいカプセル化実施を示すブロック図である。
【図８Ｂ】本発明の好ましい実施形態により構成されたウェブブラウザクライアントアプリケーションの好ましいカプセル化実施を示すブロック図である。
【図９】本発明の好ましい実施形態によるエミュレートウェブソケットネットワーク接続を確立する際のウェブブラウザクライアントカプセル化アプリケーションの実行を示すシーケンス図である。
【図１０】本発明の好ましい実施形態において具現化されるゲートウェイサーバーの好ましい具現化のブロック図である。
【図１１】本発明の好ましい実施形態に関連して使用される好ましいサービスリダイレクション技術を示すフローチャートである。
【図１２】本発明の好ましい実施形態によりウェブブラウザクライアントとゲートウェイサーバーとの間にエミュレートウェブソケット接続を確立する好ましいプロセスを示すシーケンス図である。
【図１３】本発明の好ましい実施形態によりウェブブラウザクライアントとゲートウェイサーバーとの間にエミュレートウェブソケット接続を確立し維持するのに含まれるプロキシーサーバーの取り扱いを示すシーケンス図である。
【発明を実施するための形態】
【００１９】
本発明は、ウェブサービスにアクセスするのに使用されるクライアントウェブブラウザの現在のネーティブな能力とは実質的に独立してリアルタイム全二重通信能力の必要性を満足する。本発明の以下の詳細な説明において、１つ以上の図面に示された同じ部分を指すのに同じ参照番号が使用される。
【００２０】
サポート仕様を含むドラフトＨＴＭＬ５は、ウェブブラウザ及び同様のＨＴＴＰベースのクライアントアプリケーションにおいて具現化するために推奨されるウェブソケット(WebSocket)及びサーバー送信イベント(Server-Sent Event)（ＳＳＥ）のネーティブなアーキテクチャー及び動作特徴を定義する。ウェブソケット及びサーバー送信イベントは、全二重直接ＴＣＰ通信チャンネルを使用できるクライアントアプリケーションを前提としている。本発明に関連したアプリケーション１０において、図１に一般的に示すように、従来のクライアントシステム１２、１４は、パブリックインターネット、プライベートイントラネット又は他の通信ネットワーク１６を通して、１つ以上のリモートサーバーシステム１８、２０、２２にアクセスして、リアルタイム情報を両方向に要求し且つ受け取るために、ウェブブラウザアプリケーションを実行する。典型的な例において、クライアントシステム１２により実行されるウェブブラウザクライアントを通してなされる情報要求は、最初に、一次又はソースサーバー１８に向けられ、そして他の二次サーバー２０、２２で必要とされるリアルタイム両方向情報フィード接続が確立される。例えば、ソースサーバー１８からウェブページが要求され、これは、配信されたページのユーザインターフェイス表現内の適当な指定のウインドウエリア内で、ニュースソースサーバー２０からのリアルタイムニュースストーリー及び株情報サーバー２２からの株価情報を提示する。
【００２１】
従来、ソースサーバー１８との整合においてサーバー２０、２２とのリアルタイム両方向二次接続の透過的な確立は、クライアントシステム１２、１４により実行されるウェブブラウザクライアントにおけるウェブソケットのネーティブサポート及びサーバー送信イベントのサポートに依存する。広く普及したネーティブなウェブソケット及びサーバー送信イベントのサポートがないと、更に、全ての主要な独立したウェブブラウザクライアント具現化にわたって適合する仕方で、商業的又はその他のウェブソケットベースシステムを確立することは、実際的でない。
【００２２】
本発明によれば、特定のウェブブラウザ具現化がＨＴＭＬ５規格をもたないか又はその部分的なネーティブ具現化しかもたない場合でも、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントを具現化して、完全に適合するウェブソケット及びサーバー送信イベントを即座にサポートできるようにするゲートウェイサービスが提供される。このゲートウェイサービスは、既存のサーバー１８、２０、２２において具現化されるか、或いは好ましい実施形態のように、個別の専用のゲートウェイサーバーシステムにおいて具現化される。通常部分的にネーティブな特徴の具現化を確認することが、適宜に利用される。その他、本発明は、ＨＴＭＬ５仕様に適合するネーティブな具現化と一貫した機能的適合システムを達成するエミュレーションシステムを具現化する。
【００２３】
図２を参照すれば、ウェブソケット及びサーバー送信イベントの種々の観点の有効なエミュレーションは、従来は、既存の従来の規格適合ウェブブラウザ、特に、ドラフトＨＴＭＬ５仕様に完全に適合しないもの、に組み込まれる確立されたセキュリティ並びに機能的制限によって除外される。ウェブソケット及びサーバー送信イベントエミュレーションの重要な要件は、クロス起点通信を透過的に具現化できることである。このような通信は、従来、既存の規格指定同一起点セキュリティポリシー要件により除外される。即ち、ソース起点サーバー３４からクライアントシステム３２へ配信されるウェブページを特に含むドキュメントは、同じ起点範囲内のみのあるリソースを参照し、要求するように制約される。一般的に定義されるように、起点とは、トランスポートプロトコル、ドメイン及びポートナンバーにより定義される。起点アクセス制約は、クロスサイトスクリプティングアタックを除外し、そして異なる起点をソースとするドキュメント間の偶発的な相互作用をより一般的に防止する。不都合なことに、従来の起点セキュリティ特徴は、異なるソース起点範囲を有するページ間の、悪意のない通信も阻止する。従来、例えば、ソース起点サーバー３４から送られるドキュメントは、異なる起点にあるターゲットサーバー３６、３８から送られるドキュメント又はサービスにアクセスすること又はそれとデータを交換することが防止される。
【００２４】
本発明によれば、図３に一般的に示すように、本発明の好ましい実施形態により構成されたクロスドキュメントメッセージングシステム４０は、クライアントシステム３２によりロードされたドキュメントを異なる起点にわたって選択的にセキュアに相互作用できるようにする。ターゲット起点要求は、説明上、ソース起点サーバー３４の範囲外にある起点により定義されたサーバーにより提供されるドキュメント又はサービスに対して、ソース起点サーバー３４から受け取られるソース起点ドキュメントから生じるリソース要求として定義される。指定のドメイン、ポート及びトランスポートプロトコルのいずれかがソース及びターゲット起点間で異なる場合には、起点の範囲が異なり、それら起点間の要求がクロス起点要求となる。本発明によれば、クライアントシステム３２からのターゲット起点要求は、特に、ゲートウェイサーバー４２へ向けられ、これは、次いで、ターゲットサーバー３６、３８と通信できるようにする適当なサービスを具現化する。ゲートウェイサーバー４２は、典型的に、ソース起点サーバー３４及びクライアントシステム３２の範囲外の起点である。
【００２５】
図４に５０で詳細に示されたように、クライアントシステム３２で実行されるウェブブラウザクライアントアプリケーション５２は、ユーザ選択ソース起点ウェブサーバー３４へ要求を発行する。評価の際に、ソース起点ウェブサーバー３４は、要求対応ウェブページドキュメント５４を返送する。好ましくは、ウェブページドキュメント５４は、検索されるべき初期構成リソースの識別を含むように予めコード化される。ウェブブラウザクライアントアプリケーション５２がオブジェクト基準に遭遇するときに、初期構成リソース要求がソース起点ウェブサーバー３４へ発行され、それに対応するクライアントライブラリ５６を返送する。オブジェクト基準リソースの性質に基づいて、１つ以上のファイルがクライアントライブラリ５６の一部分として返送される。又、ウェブページドキュメント５４は、ソース起点ウェブサーバー３４に代わって動作する指定のゲートウェイサーバー４２を識別するように働く初期ターゲット基準でも予めコード化されるのが好ましい。
【００２６】
クライアントライブラリ５６の好ましい実施形態が、図５に、積層ライブラリスタック７０として一般的に示されている。全体的に、クライアントライブラリ５６は、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザアプリケーション５２において実行されたときに機能的ＨＴＭＬ５適合ウェブソケットエミュレーションを与える。低レベルの、より基本的な層が積層ライブラリスタック７０の底に配置され、より上位の層において、より高いレベルの機能が次第に与えられる。図５に示すもの以外の付加的な層が、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザに存在する。アドベフラッシュ(Adobe Flash)、マイクロソフトシルバーライト(Microsoft Silverlight)、及びオラクルジャバ(Oracle Java（登録商標）)を含むウェブブラウザアプリケーション層プラグインも、もしあれば、ウェブブラウザ実行環境内で利用することができる。
【００２７】
クライアントライブラリ５６のベースは、必要なエミュレーションをｐｒｅ−ＨＴＭＬ５適合ウェブブラウザにもたずに名目上存在する従来のＸｍｌＨｔｔｐＲｅｑｕｅｓｔ（ＸＨＲ）層７２である。ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層７２は、ＨＴＴＰ及びＨＴＴＰＳ要求を指定のターゲットウェブサーバーシステムへ直接送信することのできるアプリケーションプログラミングインターフェイス（ＡＰＩ）を与える。サーバー応答は、データとして直接受け取られ、これは、次いで、要求を開始したウェブアプリケーションにより使用するためにＡＰＩを通して得ることができる。名目上、ＸｍｌＨｔｔｐＲｅｑｕｅｓｔの実行及び完了は、単一の起点に限定される。即ち、要求ソース及びターゲットウェブサーバーシステムは、共通起点の範囲内に存在しなければならない。
【００２８】
ポストメッセージ(PostMessage)層７４は、クライアントブラウザ５２の環境内で実行されるウェブアプリケーションにアクセスできる付加的なＡＰＩコールを与えることにより、エミュレートされたクロス起点メッセージをサポートするために設けられる。本発明の好ましい実施形態で具現化されるように、ポストメッセージ層７４は、従来のウェブブラウザの厳密なセキュリティポリシー具現化を管理し、ウインドウ内に埋め込まれたドキュメントが異なる起点からロードされる場合でも、単一のベースウェブページドキュメントにより定義される複数のフレームをセキュアに通信できるようにする。ベースドキュメントと、ページ内に埋め込まれたドキュメントとの間の通信は、ターゲットが、命名されたソース起点からのメッセージを明確に予想しそして受け容れるとすれば、ポストメッセージ層７４を通して許される。ソースが、命名されたターゲット起点からのメッセージを明確に聴取し受け容れる場合には、両方向通信がサポートされる。ある現在の、従来ウェブブラウザは、ポストメッセージＡＰＩの初期ネーティブ具現化をサポートする。ポストメッセージ層７４は、既存のポストメッセージＡＰＩの存在及び適合性を検出するのが好ましい。ネーティブポストメッセージＡＰＩが存在しないか、ネーティブポストメッセージＡＰＩが不適合である場合には、ポストメッセージ層７４がエミュレーションを通して全てのポストメッセージＡＰＩコールを取り扱うことができる。
【００２９】
好ましい実施形態において、ポストメッセージ層７４は、典型的にジャバスクリプト(JavaScript（登録商標）)、フラッシュ(Flash)及びシルバーライト(Silverlight)である埋め込みウインドウ技術の性質に基づく具現化を使用してポストメッセージＡＰＩをエミュレートする。各々について、埋め込みドキュメント又はその等効物が埋め込みウインドウ起点の範囲内で検索される。この埋め込みドキュメントは、機能的に、ポストメッセージＡＰＩと両立性のあるブリッジ整流処理を与える。現在の好ましい実施形態と一貫したジャバスクリプトの場合には、クライアントｉｆｒａｍｅを、ゲートウェイサーバー４２により取り扱われる対応起点へのブリッジとして使用する構造化された仕方でエミュレーションが具現化され、それにより、ソース対ターゲット通信経路を機能的に確立する。ポストメッセージのメッセージは、ＵＲＬ ｉｄ断片として転送される短いデータセグメント、典型的に、ｉｆｒａｍｅ ＵＲＬのポスト“＃”部分として、ｉｆｒａｍｅを通して通信される。ジャバ、フラッシュ及びシルバーライトの場合には、ウインドウ対応埋め込みドキュメントと組み合わされて動作されるインストールランタイムは、本発明により構成された技術対応ブリッジメカニズムを使用して通信を確立するための基礎をなす。
【００３０】
クロス起点リクエスト(Cross-Origin Request)層７６は、ＨＴＭＬ５適合クロス起点リソースシェアリングＡＰＩを通してアクセス可能なＷ３Ｃクロス起点リソースシェアリング(Cross-Origin Resource Sharing)（ＣＯＲＳ）仕様のエミュレーションを与える。クロス起点リクエスト層７６は、ウェブブラウザクライアントがネーティブクロス起点リソースシェアリングをサポートしないか又はネーティブ具現化が適合しない場合にイネーブルされる。本発明の好ましい実施形態で具現化されるように、クロス起点リソースシェアリングは、ポストメッセージ層７４及びＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層７２のレバレッジ使用を通してウェブブラウザクライアント５２においてエミュレートされる。クロス起点リソース要求は、ポストメッセージ及びＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層７４、７２を通して処理され、そしてゲートウェイサーバー４２を通して、対応ターゲットサーバー３６、３８によりサービスされる指定のターゲット起点に接続される。本発明の好ましい実施形態では、ゲートウェイサーバー４２は、ターゲットサーバー３６、３８への特定の適合接続を確立できるＨＴＭＬ５適合クロス起点リソースシェアリングコンポーネントを具現化する。
【００３１】
サーバー送信イベント層７８は、ウェブクライアントが、ＨＴＭＬ５適合サーバー送信イベントストリームに接続できるようにする。サーバー送信イベント層７８は、データのストリームをリモートターゲットサーバーからウェブブラウザ５２へ送信されるものとしてローカルに管理する。データのサーバー送信ストリームは、従来、ウェブブラウザクライアント５２へと下流へ送信されるネットワークメッセージの一方向性非同期シリーズとして具現化される。ある従来のウェブブラウザは、ＳＳＥプロトコルの初期のネーティブ具現化であるが、本発明の好ましい実施形態は、エージェント特有のネーティブ具現化を拡張することによりサーバー送信イベント層７８の完全な具現化を与える。即ち、サーバー送信イベント層７８は、現在エージェントを検出し、そしてＳＳＥプロトコルに対するサポートを完了するために必要に応じて機能を補足する。部分的なネーティブサポートが得られないか又は使用できない場合には、サーバー送信イベント層７８は、ＳＳＥプロトコルをサポートするのに適したものとして全エミュレーションを遂行する。本発明の好ましい実施形態では、ゲートウェイサーバー４２は、ウェブブラウザクライアント５２とのクロス起点ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ応答ストリーミング接続を管理するためのプログラムを具現化し、サーバー送信イベントストリームのソースで動作している上流ターゲットサーバーから供給される付加的なメッセージを聴取しながら、ＨＴＴＰ応答をオープンに保つ。
【００３２】
ウェブソケットエミュレーション層８０は、両方向接続をサポートする。接続が確立されると、ウェブブラウザクライアント５２は、典型的にターゲットサーバー３６、３８をホストとするバックエンドサービスに直接リンクされる。又、接続は、それが確立されると、オープンのままとなり、クライアント及びサーバーの両方は、非同期で前後に情報を送信することができる。ウェブソケットエミュレーション層８０は、ジャバー(Jabber)、ＩＭＡＰ、等のテキストベースのプロトコルをサポートする。好ましい実施形態では、ウェブソケットエミュレーション層８０は、ＨＴＭＬ５適合ウェブソケットＡＰＩの完全な具現化を与える。
【００３３】
バイトソケット(ByteSocket)層８２は、好ましくは、ウェブソケットエミュレーション層８０を通るバイナリーデータ送信をサポートするために設けられる。それに対応するバイナリートランスポートプロトコル仕様は、Ｗ３Ｃ又はＩＥＴＦにより与えられていない。本発明によれば、バイトソケット層８２は、ウェブソケットＡＰＩと一般的にパラレルのＡＰＩを具現化する。バイトソケットＡＰＩは、主としてバイト値を含むバイナリープリミティブの読み取り及び書き込みを許す付加的な方法を与える。バイトソケット層８２は、バイナリープロトコルの全範囲の具現化を可能にし、更に、テキストベースのプロトコルに対しネットワークにわたってバイナリー圧縮及び暗号化を適用する。
【００３４】
典型的に特殊な付加的なクライアントプロトコルライブラリが、クライアントプロトコルライブラリ層８４の一部分として、クライアントライブラリ５６に含まれてもよい。これらのクライアントプロトコルライブラリは、典型的に、アプリケーション又はサーバー特有のプロトコルを具現化する。本発明の好ましい実施形態では、クライアントプロトコルライブラリ層８４は、例えば、グーグルトーク(Google Talk)により使用される従来のＸＭＰＰプロトコルを具現化するＸｍｐｐＣｌｉｅｎｔを含むことができる。好ましくは、ＸｍｐｐＣｌｉｅｎｔクライアントライブラリは、ウェブソケットエミュレーション層８０を利用して、ＸＭＰＰテキスト指向のメッセージを交換する。
【００３５】
又、クライアントプロトコルライブラリ層８４は、ストリーミングテキスト配向メッセージングプロトコル(Streaming Text Orientated Messaging Protocol)（Ｓｔｏｍｐ）を具現化するＳｔｏｍｐＣｌｉｅｎｔクライアントライブラリを含むことができる。好ましくは、ＳｔｏｍｐＣｌｉｅｎｔクライアントライブラリは、バイトソケットクライアントライブラリを使用して、ＡｐａｃｈｅＡｃｔｉｖｅＭＱのようなＳｔｏｍｐ適合アプリケーションを実行するリモートサーバーとでＳｔｏｍｐメッセージを交換する。同様に、リモートインターネットリレーチャット(Internet Relay Chat)（ＩＲＣ）サーバーとのメッセージ交換をサポートするためにＩｒｃＣｌｉｅｎｔクライアントライブラリを設けることができる。更に特殊なクライアントライブラリ、例えば、リモートフレームバッファクライアントライブラリは、特殊な両方向プロトコルをサポートするために具現化することができる。ネットワークを経てキーボード及びマウスイベントを送信すると共にグラフィックスクリーン更新を受信するためにバーチャルネットワーククライアント（ＶＮＣ）具現化によりリモートフレームバッファプロトコルが使用される。
【００３６】
本発明の別の実施形態では、エミュレーション層７０の初期化中に、ウェブブラウザクライアント５２の実行環境内でフラッシュプラグインの潜在的な存在を検出するためのテストが実施される。検出されて、エミュレーションに対する付属物として使用できるように適当に構成された場合には、エミュレーション層７０は、指定のゲートウェイサーバー４２との単一のＴＣＰソケット接続を確立するに充分な幾つかのネットワーク及びソケット通信動作をプラグインへ選択的に委任することができる。即ち、ＵＩ動作をサポートするためにフラッシュプラグインが一般的に使用されるが、そのプラグインに組み込まれた限定されたネットワーク層及び限定されたソケット能力の選択的利点を取り入れることができる。ネットワーク及びソケット層の観点しか使用しないと、目に見える表示アーティファクトは生成されない。しかしながら、フラッシュプラグインは、常に利用できるものではなく、ファイアウオール、ＨＴＴＰプロキシー及び他の通信バリアの存在により使用可能な仕方で又は使用できるように構成される。フラッシュプラグインにより与えられるネットワーク層の使用は、依然、限定された環境のもとで行われる。
【００３７】
典型的な使用において、ウェブアプリケーションは、ウェブブラウザクライアント５２により実行されるクライアント側アプリケーションと、ソース起点サーバー３４及び１つ以上のターゲットサーバー３６、３８によりある組み合わせで機能的に具現化される分散型サーバー側アプリケーションと、の組み合わせとして具現化される。ウェブページ５４におけるオブジェクト基準は、ウェブブラウザクライアント５２がクライアント側アプリケーションを１つ以上のドキュメントとして最初にロードできるようにする。クライアント側アプリケーションは、典型的に、サーバー送信イベント層７８、ウェブソケット層８０及びバイトソケット層８２に関連したＡＰＩと対話しそしてそれを使用するように設計される。ウェブソケット層８０は、使用される主たるＡＰＩであると予想されるが、全ての層をクライアント側アプリケーションにより使用することができる。
【００３８】
図６を参照すれば、ウェブブラウザクライアント５２の環境内の実行可能なドキュメント９２としてクライアント側アプリケーションが示されている。本発明の好ましい実施形態において具現化されるように、ドキュメント９２の実行によるクライアントライブラリ５６へのＡＰＩコールは、最終的にポストメッセージ要求９４として実現される。各ポストメッセージ要求９４は、少なくとも、当該ソース及びターゲット起点と、要求により表される動作とによって定義される。ソース起点は、ドキュメント９２の起点である。具現化されるエミュレーションの性質により、メッセージのターゲット起点は、実際には、ゲートウェイサーバー４２の起点である。負荷バランス及び相対的な地理的な理由で複数のゲートウェイサーバー４２を同時に具現化することができる。実際上、ポストメッセージ要求９４は、ターゲットゲートウェイサーバー４２も識別する。
【００３９】
クライアント側アプリケーションを具現化する技術がＪａｖａＳｃｒｉｐｔ（登録商標）である場合には、１つ以上のｉｆｒａｍｅ９２が通信ブリッジとして確立される。クロス起点要求層７４として処理された各クロス起点ＸｍｌＨｔｔｐＲｅｑｕｅｓｔは、それに対応するポストメッセージ要求９４として実現され、これは、次いで、ドキュメントイベントとしてｉｆｒａｍｅ９６インスタンスへ通されるのが好ましい。ｉｆｒａｍｅ９６インスタンスは、要求に関連したソース及びターゲット起点の独特の組み合わせに基づいて選択され、ターゲット起点は、この場合も、サービスゲートウェイサーバー４２の起点に対応する。本発明の好ましい実施形態では、ｉｆｒａｍｅ９６インスタンスは、必要に応じて生成され、そしてウェブページ５４又はウェブブラウザクライアント５２が閉じるまで持続するのが好ましい。ソース及びターゲット起点の組み合わせに対するｉｆｒａｍｅがまだ生成されない場合には、ポストメッセージ層７４がそれに対応するｉｆｒａｍｅ９６を生成し、そしてゲートウェイサーバー４２とのプリフライト要求／応答トランザクションを通して、ｉｆｒａｍｅ９６インスタンスにより信頼関係が確立される。
【００４０】
ゲートウェイサーバー４２の観点から、プリフライト要求の発生は、標準的なＣＯＲＳプリフライト要求と一貫したものであり、従って、ＣＯＲＳ適合ウェブブラウザをゲートウェイサーバー４２と相互動作させることができる。信頼関係を確立する一部分として、通信ブリッジルーチンがゲートウェイサーバー４２からｉｆｒａｍｅ９６インスタンスへダウンロードされ、ｉｆｒａｍｅ９６インスタンス内でポストメッセージＡＰＩのターゲット側を具現化する。信頼関係により、開始するポストメッセージ要求に対応するＸｍｌＨｔｔｐＲｅｑｕｅｓｔは、次いで、ゲートウェイサーバー４２へ送信され、そしてターゲットサーバー３６のようなサービスサーバーへ適宜に転送される。本発明の好ましい実施形態では、ゲートウェイサーバー４２を通してアクセスできる他のターゲットサーバー３６、３８によって提供されるサービスを定義するために、ゲートウェイサーバー４２にマッピングが管理上確立される。従って、ポストメッセージ要求がウェブソケット要求を表す場合には、典型的な結果として、ドキュメント９２から、それに対応するｉｆｒａｍｅ９６インスタンス、ゲートウェイサーバー４２を経て、ドキュメント９２へのリアルタイム非同期データソースとして働くターゲットサーバー３６により典型的に提供されるリモートサービスへ、両方向可能な接続が確立される。
【００４１】
ソース起点の検証は、ゲートウェイサーバー４２によって行われるのが好ましい。ＪａｖａＳｃｒｉｐｔ（登録商標）エミュレーション環境では、ゲートウェイサーバー４２は、受け取られた各要求が、ゲートウェイサーバー４２のターゲット起点に一致する値を有するＸＭＬＨｔｔｐＲｅｑｕｅｓｔ“リファラ”ヘッダと、許されたソース起点の値を有するＸＭＬＨｔｔｐＲｅｑｕｅｓｔ“Ｘ−起点”ヘッダとを含むことを検証する。好ましくは、“Ｘ−起点”ヘッダの値は、ゲートウェイサーバー４２からｉｆｒａｍｅ９６インスタンスへダウンロードされる通信ブリッジルーチンにより決定される。ゲートウェイサーバー４２は、通信ブリッジルーチンを発生し、そして通信ブリッジルーチンは、ウェブブラウザクライアント５２からのｉｆｒａｍｅ９６インスタンスを含むドキュメント９２のソース起点を決定するので、“Ｘ−起点”ヘッダの値は、ゲートウェイサーバー４２により、要求のソース起点を正確に識別すると信用される。
【００４２】
フラッシュ及びシルバーライトのような他のクライアント側アプリケーション具現化技術については、同様のエミュレーションアーキテクチャーが使用される。一般的に、ポストメッセージ９４は、識別された技術に基づき、ベースドキュメント９２内に、ｉｆｒａｍｅ９６と同様の対応サブウインドウを生成する。ウインドウを初期化すると、ドキュメント又は等効物が、プリフライト要求／応答トランザクションの一部分又は等効物としてゲートウェイサーバー４２から参照され及び検索される。その検索されたドキュメントは、本発明の好ましい実施形態では、ポストメッセージＡＰＩのターゲット側を具現化する通信ブリッジルーチンを機能的に含み、これにより、必要に応じて、ベースドキュメント９２とサブウインドウドキュメントとの間にセキュアな通信経路を許す。
【００４３】
ゲートウェイサーバー４２との信頼関係を確立する好ましいプロセス１１０が図７に一般的に示されている。ウェブブラウザクライアント５２のユーザによって典型的に開始される従来のページ要求１１２に応答して、要求１１２で示すように、ロードページ要求が起点サーバー３４へ発行される。それに対応するページがロードされ（１１４）、そして最初に評価され（１１６）、ページにより要求される付加的なオブジェクトを探索しロードする。本発明の好ましい実施形態では、クライアントライブラリ５６へのページ埋め込み参照により、埋め込み参照識別ゲートウェイサーバー４２から本質的にスタティックなリソースロード１１８が生じる。ウェブブラウザクライアント５２は、ロードされたページに関連した初期化１２０を完了し、これは、クライアントライブラリ層７０のウェブブラウザクライアントへのエミュレーションインターセプトを検出し及び確立するためのクライアントライブラリの必須の初期化を含む。
【００４４】
典型的に、あるユーザ対話１２２、又はドキュメント９２の自律的動作から生じる開始イベントに応答して、ウェブソケット、バイトソケット、クロス起点要求、又は他の要求がクライアントライブラリ層７０に対してなされる。例示上、この要求は、ドキュメント９２により表されるＪａｖａＳｃｒｉｐｔ（登録商標）クライアントアプリケーションから発生するウェブソケット要求である。この要求は、更に、ゲートウェイサーバー４２により提供される特定のサービスへの接続を要求するものとして特定される。この要求は、ポストメッセージ層７４へと処理される（１２４）。本発明の好ましい実施形態によれば、適当なｉｆｒａｍｅ９６インスタンスがまだ存在しない場合に、ウェブページベースドキュメント５４のソース起点を識別する機能的ソース起点、及びサービスの有効な位置を識別する機能的ターゲット起点を伴うｉｆｒａｍｅが生成される。ＪａｖａＳｃｒｉｐｔ（登録商標）におけるｉｆｒａｍｅの生成は、例えば、次のコードで具現化することができる。
【００４５】
ｉｆｒａｍｅの機能的ソース起点は、明確にセットされず、通信ブリッジルーチンにより、ウェブブラウザクライアント５２へのコールによって自動的に決定される。このコールは、ｉｆｒａｍｅ９６インスタンスの生成に続く通信ブリッジルーチンの初期化中及びｉｆｒａｍｅ９６インスタンスへの通信ブリッジルーチンのダウンロード中に行われるのが好ましい。従って、ｉｆｒａｍｅ９６インスタンスの機能的ソース起点は、ｉｆｒａｍｅ９６インスタンスの生成の役割を果たすドキュメント９２のソース起点、例えば、“ｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍ：８０”として決定される。機能的ターゲット起点は、“ｓｒｃ”属性を、例えば、“ｈｔｔｐ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０”として明確に使用して特定される。
【００４６】
好ましくは、開始ポストメッセージ要求の当該ソース及びターゲット起点、並びに要求されたサービス、を識別するプリフライトＸｍｌＨｔｔｐＲｅｑｕｅｓｔメッセージは、指定されたゲートウェイサーバー４２へ送信される（１２６）。ゲートウェイサーバー４２における管理上確立されるサービスアクセスポリシーが要求に対して評価される。本発明の好ましい実施形態では、ポリシーが一般的に次の形態をとる。
【００４７】
従って、サービス“／ｇｗＳｔｏｃｋＳｅｒｖｉｃｅ”のための“ｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍ：８０”から“ｗｓ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０”への特定のクロス起点リソース要求は、受け容れできると決定される。この要求は、更に、例えば、リモートターゲットサーバー３６により提供される実際のサービスソース“ｔｃｐ：／／ｔａｒｇｅｔ．ｃｏｍ：１３３０／ｓｔｏｃｋＳｅｒｖｉｃｅ”へのＴＣＰベースのウェブソケット接続を確立して、ゲートウェイサーバー４２によるオンデマンド生成によってサポートされる。本発明の好ましい実施形態では、ウェブブラウザクライアントアプリケーション９２により要求できる種々のサービスがゲートウェイサーバー４２において直接ホストされる。サービスアクセスポリシーにより特定される接続は、このようなケースでは、ローカルホストへの接続参照である。
【００４８】
サービスアクセスポリシーの評価に基づき、確認メッセージが返送される（１２８）。何らかの理由でサービス接続が許されない場合には、発生する要求１２４が本質的に失敗となる。ウェブソケット接続に必要なエミュレートサポートは、それが許される場合に、初期化される（１３０）。本発明の好ましい実施形態では、これは、次のＪａｖａＳｃｒｉｐｔ（登録商標）に一般的に例示するように、到来する要求イベントを取り扱うためのポストメッセージリスナーをｉｆｒａｍｅ９６インスタンス内にインストールすることを含む。
【００４９】
ウェブソケット要求１２４に対応するポストメッセージ要求は、次いで、ＸｍｌＨｔｔｐＲｅｑｕｅｓｔへ機能的に変換される。より詳細には、ＨＴＭＬ５適合ポストメッセージ要求は、ベースウェブページ５４ドキュメント内で、ターゲットドキュメントを表すウインドウにおいてコールされる。この要求は、ポストメッセージデータとして表されるメッセージ、及び要求のソース起点を通す。ｉｆｒａｍｅ９６インスタンスがそれ以前に確立される場合には、ポストメッセージ要求がポストメッセージ７４ ＡＰＩに通される。
【００５０】
この要求は、次いで、ゲートウェイサーバー４２へ送信され、そしてサービスアクセスポリシーに基づいて資格付けがなされる。ゲートウェイサーバー４２は、次いで、識別されたターゲットサーバー３６との対応接続１３４を確立する。接続１３４の性質は、要求されたサービスの性質に依存し、例えば、ＴＣＰ又はウェブソケット接続でよい。ＸｍｌＨｔｔｐＲｅｑｕｅｓｔに対する応答が受け取られて、ｉｆｒａｍｅチェーンを通して戻され、応答データペイロードをベースウェブページ５４ドキュメントへ返送する。その後のウェブソケット要求１２４は、ｉｆｒａｍｅ９６インスタンスを再使用し、それにより、ソース及びターゲット起点間に確立される信頼関係のレバレッジ使用をなす。
【００５１】
他のウェブブラウザクライアントアプリケーション９２技術に関しては、ベースページ５４との対話が制限される。図８Ａに一般的に示されるように、ウェブブラウザベースページ５４は、そのベースページ５４に埋め込まれた別のウェブブラウザクライアントアプリケーション９２との必須の対話がもしあっても制限した状態で、カプセル化フラッシュ、シルバーライト、又は他のアプリケーション１５２を埋め込むことができる。本発明の好ましい実施形態では、このようなカプセル化アプリケーション１５２は、ゲートウェイサーバー４２からのリソース１１８としてロードされる。
【００５２】
フラッシュカプセル化アプリケーション１５２のケースでは、フラッシュプラグインの一部分として与えられるフラッシュランタイムライブラリは、一般的な所有権ネットワーク及びソケット状通信能力を含む。クライアントライブラリ５６は、カプセル化アプリケーション１５２の一部分として含まれ、カプセル化アプリケーション１５２がゲートウェイサーバー４２の外部サービスと直接通信できるようにするのが好ましい。
【００５３】
本発明の好ましいフラッシュ実施形態は、クロス起点リソースシェアリングでのフラッシュアプリケーション実行をサポートする。図８Ｂを参照すれば、ソース起点サーバー３４からロードされたドキュメント９２は、これもソース起点サーバー３４からロードされたフラッシュクライアントアプリケーション１５６に対する参照を含む。それ故、ウェブブラウザクライアント５２により実行されるフラッシュクライアントアプリケーション１５６は、ドキュメント９２のソース起点及びソース起点サーバー３４内で実行される。従って、フラッシュクライアントアプリケーション１５６は、ゲートウェイサーバー４２からロードされることが更に特定されるフラッシュブリッジアプリケーション１５８に対する参照を含む。それ故、フラッシュブリッジアプリケーション１５８は、ゲートウェイサーバー４２のターゲット起点内で実行される。
【００５４】
フラッシュクライアント及びブリッジアプリケーション１５６、１５８は、ＳＷＦファイルフォーマットドキュメントとしてロードされたフラッシュ移動ファイルとして具現化されるのが好ましい。フラッシュクライアントアプリケーション１５６は、クライアントライブラリ５６を含むのが好ましい。本発明により、ｉｆｒａｍｅを通してのポストメッセージ通信と同様に、フラッシュクライアントとブリッジアプリケーション１５６、１５８との間にセキュアな通信能力が確立される。このチャンネルは、フラッシュランタイムライブラリを通してサポートされる共有イベントを使用して確立され、従って、データを両方向にディスパッチできるのが好ましい。この通信チャンネルは、フラッシュブリッジアプリケーション１５８が、実行を通して、ゲートウェイサーバー４２により資格付けされたソース起点で識別されたフラッシュクライアントアプリケーション１５６を検証しそしてそれのみと通信することを要求することにより、ソース及びターゲット起点の独特の組み合わせに固定される。この通信チャンネルの初期化において、フラッシュクライアントアプリケーション１５６のソース起点は、フラッシュブリッジアプリケーション１５８によりフラッシュクライアントアプリケーション１５６のＬｏａｄｅｒＩｎｆｏメタデータから検索される。このソース起点は、ゲートウェイサーバー４２へ返送される。ゲートウェイサーバー４２に対してローカルの管理上確立されたセキュリティポリシーの評価において起点が許可されたとすれば、フラッシュブリッジアプリケーション１５８は、返送メッセージにより、フラッシュクライアントアプリケーション１５６との共有イベント通信に対してイネーブルされる。フラッシュクライアントアプリケーション１５６により具現化されたクライアント側ウェブアプリケーションは、例えば、ターゲットサーバー３６により提供されるリモートサーバーにアクセスするため、必要に応じて、ゲートウェイサーバー４２のクロス起点にアクセスすることができる。
【００５５】
或いは又、フラッシュクライアントアプリケーション１５６は、ウェブソケット接続を使用してゲートウェイサーバー４２と直接通信することができる。ネーティブウェブソケット接続が望まれる場合には、フラッシュブリッジアプリケーションは、ターゲットゲートウェイサーバー４２へウェブソケット要求を発行するように試みる。フラッシュブリッジアプリケーション１５８を通して通信するのではなく、フラッシュクライアントアプリケーション１５６の初期実行は、フラッシュクライアントアプリケーション１５６の一部分として与えられるクライアントライブラリ５６を通してウェブソケット接続要求を発行する。この接続要求は、ゲートウェイサーバー４２とのソケットベース接続を要求するためにフラッシュランタイムを使用してエミュレートされる。次いで、フラッシュクロスドメインポリシーファイルが、意図されるウェブソケット接続のターゲット起点から検索される。ゲートウェイサーバー４２は、特に、そのような要求を聴取し、そして有効フラッシュクロスドメインポリシーファイルを返送するように構成されるのが好ましい。フラッシュクライアントアプリケーション１５６の基礎となるフラッシュランタイムは、ポリシーを評価し、そしてターゲット起点とのクロス起点ウェブストック接続が許されるかどうか決定する。
【００５６】
規範的なクロスドメインポリシーファイルは、次の通りである。
【００５７】
フラッシュランタイムが適合ポリシーファイルを受け取りそしてフロムドメイン(from-domain)がフラッシュクライアントアプリケーション１５６のソース起点に一致するとすれば、ランタイムは、クライアントライブラリがソケットを指定のポートにおいてターゲット起点へとオープンしそしてネーティブウェブソケットプロトコルを経て通信するのを許す。ウェブソケットプロトコルハンドシェークの一部分として、ターゲット起点のクッキーを送信することも要求される。しかしながら、ネーティブソケット接続は、デフォールトによりクッキーを送信せず、従って、ターゲットドメインに取り付けられたクッキーを発見するために最小のＨＴＴＰ要求もターゲットゲートウェイに送信される。クッキーは、ＨＴＴＰ応答からパースされ、ウェブソケットハンドシェーク通信に含まれる。
【００５８】
デスクトップ及びアプレットＪａｖａ（登録商標）クライアントにおけるクロス起点通信の具現化は、同様のクライアントアプリケーション１５６及びブリッジアプリケーション１５８アーキテクチャーを使用するのが好ましい。Ｊａｖａ（登録商標）クライアントアプリケーション１５６については、アプリケーションコードが、ソース起点サーバー３４から、好ましくはクライアントライブラリ５６のＪａｖａ（登録商標）具現化を含む.ｊａｒファイルにおいてロードされる。従って、Ｊａｖａ（登録商標）クライアントアプリケーション１５６は、ドキュメント９２のソース起点にある。初期実行において、Ｊａｖａ（登録商標）クライアントアプリケーション１５６は、.ｊａｒファイルとしても与えられるブリッジアプリケーション１５８をゲートウェイサーバー４２からロードするための要求をなす。ブリッジアプリケーション１５８のロードは、許される。その実行は、ターゲット領域で行われる。
【００５９】
Ｊａｖａ（登録商標）クライアントランタイムは、ソケット及びＨＴＴＰ要求ライブラリ具現化を含む。ネーティブなウェブソケットプロトコル接続が望まれる場合には、ブリッジアプリケーション１５８は、ゲートウェイサーバー４２へのソケット接続をなすことができる。そうではなくて、例えば、介在するプロキシーサーバーを横断するために要求されるように、エミュレートされたウェブソケットプロトコルが必要となる場合には、ランタイムＨＴＴＰ要求ライブラリが使用される。
【００６０】
異なる起点からのコードを、非セキュアな仕方で相互作用しないよう分離するために、Ｊａｖａ（登録商標）ランタイムは、異なる起点からのクラスを異なる「クラスローダ」にロードする。デフォールトにより、１つのクラスローダにロードされたコードは、別のクラスローダにロードされたコードにアクセスしたり又はそれを実行したりすることができない。しかしながら、ランタイムシステムのコアであるコードは、特殊な「ランタイムクラスローダ」にロードされ、これは、他のコードにより安全にアクセスすることができる。Ｊａｖａ（登録商標）クライアントとブリッジアプリケーションとの間の通信チャンネルをポストメッセージアナログコードとしてクライアントライブラリ５６に生成するために、クライアント及びブリッジの両.ｊａｒは、コアＪａｖａ（登録商標）ランタイムの一部分として存在するインターフェイス又は拡張可能なクラスをインスタンス生成する。ランタイムクラスローダにロードされるこのクラスは、Ｊａｖａ（登録商標）クライアントアプリケーション１５６及びＪａｖａ（登録商標）ブリッジアプリケーション１５８の両方にアクセスすることができる。この目的に使用できる規範的なクラスは、標準的Ｊａｖａ（登録商標）クラス“ｊａｖａ（登録商標）．ｂｅａｎｓ．ＰｒｏｐｅｒｔｙＣｈａｎｇｅＳｕｐｐｏｒｔ”である。このクラスは、全ての実行環境においてＪａｖａ（登録商標）ランタイムに得ることができ、従って、セキュリティの例外を招くことなくＪａｖａ（登録商標）クライアントアプリケーション１５６及びＪａｖａ（登録商標）ブリッジアプリケーション１５８によってコールすることができる。ＰｒｏｐｅｒｔｙＣｈａｎｇｅＳｕｐｐｏｒｔクラス、及び他のそのようなクラスは、任意のデータを両方向に通過できる拡張又は具現化を許すに充分なほど一般的である。
【００６１】
他のクライアントランタイム環境でも要求されるように、ターゲット通信の報告されるソース起点は、正確であり、且つ改竄から保護されねばならない。正確さを確保するために、Ｊａｖａ（登録商標）ブリッジアプリケーション１５８は、Ｊａｖａ（登録商標）ランタイム環境へのコールを具現化し、Ｊａｖａ（登録商標）クライアントアプリケーション１５６のソース起点を決定する。特に、Ｊａｖａ（登録商標）ブリッジアプリケーション１５８は、Ｊａｖａ（登録商標）クライアントアプリケーション１５６の.ｊａｒファイル内に存在することが分かっている.ｃｌａｓｓファイルをロードするためのコールをなす。例えば、この.ｃｌａｓｓファイルが“ＳｏｕｒｃｅＯｒｉｇｉｎＬｏｃａｔｉｏｎ．ｃｌａｓｓ”と命名された場合には、Ｊａｖａ（登録商標）ブリッジアプリケーション１５８は、クラスをロードするために次のコールを行う。
【００６２】
返送されるＵＲＬ値は、ロードされた.ｃｌａｓｓファイルの起点、ひいては、ソース起点の識別を含む。例えば、Ｊａｖａ（登録商標）クライアントアプリケーション１５６の.ｊａｒファイルの名前が“ｃｌｉｅｎｔ．ｊａｒ”である場合には、返送されるＵＲＬが次の形態となる。
【００６３】
それ故、“ｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍ：８０”は、Ｊａｖａ（登録商標）クライアントアプリケーション１５６のソース起点である。このソース起点は、次いで、任意の接続中にゲートウェイサーバー４２へ送られ、ゲートウェイサーバー４２がこのソース起点からのクロス起点接続を確認し、選択的に許すことができるようにする。Ｊａｖａ（登録商標）クライアントランタイムは、それ自身、クラスロード中に正しいリソースストリングを返送することに信頼があるので、ソース起点値も信頼がある。
【００６４】
本発明の好ましい実施形態において対処されるシルバーライトカプセル化アプリケーション１５２のケースには、制限が存在する。要するに、シルバーライトランタイムによりサポートされる起点セキュリティ範囲は、広く配布されるウェブアプリケーションに関連した実際の使用に対して充分な仕様を与えない。この制限は、本発明の好ましい実施形態では、カプセル化アプリケーション１５２の設定中のクロス起点通信ポリシーを資格付けすることで管理される。図９を参照すれば、典型的にあるユーザ対話１６２に応答して、カプセル化シルバーライトアプリケーション１５２は、ウェブソケット要求１６４として表されたシルバーライトサービス要求を、クライアントライブラリ５６を通して処理する。本発明の好ましい実施形態において具現化されるように、２つのヘッダがウェブソケット要求１６４に自動的に追加される。又、本発明の好ましい実施形態では、ヘッダは、次のように特定される。
【００６５】
ここで、第１のヘッダは、有効なソース起点を識別し、そして第２のヘッダは、ソース起点をエンコードする動的に発生されるヘッダである。ゲートウェイサーバー４２に向けられたウェブソケット要求１６４を処理する際に、シルバーライトランタイムは、クロス起点通信の試みを認識する。次いで、シルバーライトランタイムは、プリフライト要求１６６を開始して、クライアントアクセスポリシーを検索する。プリフライト要求は、慣習によれば、特に命名された“ｃｌｉｅｎｔａｃｃｅｓｓｐｏｌｉｃｙ．ｘｍｌ”ドキュメントを検索するために起点ルートに向けられる。従って、定義されたターゲット起点がｈｔｔｐ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０である場合には、ドキュメント要求は、ｈｔｔｐ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０／ｃｌｉｅｎｔａｃｃｅｓｓｐｏｌｉｃｙ．ｘｍｌに向けられる。ゲートウェイサーバー４２は、シルバーライトアクセスの予想において、そのような要求を聴取し、そしてカスタマイズされたクライアントアクセスポリシー１６８で応答し、ゲートウェイサーバー４２に、クロス起点アクセスを許すサービスアクセスポリシーをもたせる。即ち、要求のソース起点が、サービスアクセスポリシーの＜ｃｒｏｓｓ−ｓｉｔｅ−ｃｏｎｓｔｒａｉｎｔ＞エントリーに対してチェックされる。この制約を満足すると、ｃｌｉｅｎｔａｃｃｅｓｓｐｏｌｉｃｙ．ｘｍｌドキュメントが動的に発生されそして返送される（１６８）。クライアントアクセスポリシーは、一般的に、次の形態となる。
【００６６】
ドメインｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍから、サブ経路を含む経路／ｍｙＳｅｒｖｉｃｅへの有効な要求は、２つのヘッダ値Ｘ−Ｏｒｉｇｉｎ及びＸ−Ｏｒｉｇｉｎ−ｈｔｔｐ％３Ａ％２Ｆ％２Ｆｒｅｔａｉｌｅｒ．ｃｏｍ％３Ａ８０を含むことが許されることが明記される。このクライアントアクセスポリシーは、シルバーライトカプセル化アプリケーション１５２への参照と共にシルバーライトランタイムに登録される。その結果、本発明によれば、シルバーライトカプセル化アプリケーション１５２は、ヘッダを全シルバーライト要求の一部分として与え、そしてゲートウェイサーバー４２は、両ヘッダを有するシルバーライト要求だけを受け容れる。プリフライトトランザクション１６６、１６８の一部分としてのクライアントアクセスポリシーの動的な発生及びアプリケーションは、そのような要求を許し通過させるためにシルバーライトランタイムの動作を資格付けする。シルバーライトランタイムは、非適合ヘッダを有する要求を阻止し続ける。ゲートウェイサーバー４２は、適合ヘッダをもたないシルバーライト要求は許さない。
【００６７】
図１０を参照すれば、ゲートウェイサーバー４２の好ましい具現化１９０が示されている。好ましい実施形態において、ゲートウェイサーバー４２は、ウェブブラウザクライアント３２及び種々の起点サーバー３４、３６、３８へのネットワーク接続をサポートするように構成された従来のウェブサーバーシステムにおいて具現化される。機能的に、クライアントネットワークインターフェイス１９２は、ウェブブラウザクライアント３２とのネットワーク接続１９４をサポートする。クライアントライブラリ５６から発信する要求は、ゲートウェイサーバー４２により実行されるアプリケーションサーバー内にホストされるイベント駆動モジュールとして具現化されるのが好ましいエミュレーションサポートプロセッサ１９６に向けられる。最初に処理される要求は、次いで、ネーティブウェブソケットライブラリ１９８を通して具現化され、このライブラリは、サービスネットワークインターフェイス２００を通して、要求されたウェブソケット両立性サービスを提供するリモート起点サーバー３６、２８へ至るＴＣＰ及び他のネットワーク接続２０２を確立することができる。
【００６８】
又、ゲートウェイサーバー４２によりホストされるアプリケーションサーバー内のイベント駆動モジュールとして実行されるサービスアクセスプロセッサ２０４は、エミュレーションサポートプロセッサ１９６により受け取られる要求を評価し、資格付けする。フラッシュ及びシルバーライトプリフライト動作中に発行されるクライアントアクセス要求は、ソケットポリシープロセッサ２０６により受け取られて取り扱われる。サービスアクセスプロセッサ２０４は、フラッシュ及びシルバーライトプリフライト要求において識別される起点を資格付けするために、必要に応じて、ソケットポリシープロセッサ２０６によりアクセスされる。
【００６９】
ゲートウェイサーバー４２、特に、エミュレーションサポートプロセッサ１９６は、サービス要求のリダイレクションをサポートするのが好ましい。サービスアクセスプロセッサ２０４は、サービス要求を資格付けするのに加えて、サービスターゲットのリダイレクションを指定する。名目上、このようなリダイレクションは、サービス要求に応答して従来のＨＴＴＰ３０Ｘを返送することにより具現化される。しかしながら、ゲートウェイサーバー４２とのウェブソケット通信に対してｉｆｒａｍｅ９６インスタンスを使用する本発明の実施形態は、そのようなリダイレクション要求を取り扱う上で制限がある。より詳細には、ｉｆｒａｍｅ９６インスタンスは、ｉｆｒａｍｅ９６インスタンスの生成中に確立されたターゲット起点の範囲外の起点へのリダイレクションを取り扱うことができない。カプセル化プログラム１５２を具現化するのに使用される他の技術は、リダイレクション要求を自動的に取り扱う上で同様に制限がある。
【００７０】
その影響を受ける好ましい実施形態では、図１１に示す別のリダイレクション処理フロー２１０を使用するのが好ましい。明瞭化のために、リダイレクション処理フロー２１０は、Ｊａｖａｓｃｒｉｐｔ（登録商標）具現化に特定して説明する。上述したように、ウェブソケット要求２１２は、クライアントライブラリ５６のポストメッセージ層７４を通るポストメッセージ要求２１４及びそれに対応するｉｆｒａｍｅ９６インスタンス２１６として処理される。対応サービスに対する要求２１８は、ゲートウェイサーバー４２へとなされる。名目上、その要求は、リモートターゲットサーバー３６、３８上の要求されたサービスへの接続２２０により取り扱われる。
【００７１】
そうではなくて、ゲートウェイサーバー４２のインスタンス２１８は、異なるゲートウェイサーバー４２のインスタンス２２２へのリダイレクションが適当であることを決定することがある。この決定は、ローカルの管理上確立されるサービスアクセスポリシーの評価に基づいて行われ、そしてリダイレクションターゲットゲートウェイサーバー４２のインスタンス２２２を識別するのが好ましい。リダイレクションは、ｉｆｒａｍｅ２１６へ返送されるサービスリダイレクト２２４メッセージの生成により具現化されるのが好ましい。サービスリダイレクト２２４メッセージは、ＨＴＴＰ ３０Ｘリダイレクションメッセージを包むＨＴＴＰ ２０Ｘメッセージとして特に与えられる。ｉｆｒａｍｅ２１６は、明確なＨＴＴＰ ３０Ｘメッセージの取り扱いに失敗することがあるが、リダイレクションがクロス起点である場合には、ｉｆｒａｍｅ２１６は、ＨＴＴＰ ２０Ｘメッセージを受け取り、そしてそこに含まれたペイロードデータを適合応答として発信ポストメッセージ要求２１４へ返送することができる。ポストメッセージ層７４は、更に、メッセージペイロードを評価のためにウェブソケットエミュレーション層８０へ返送する。返送されるメッセージペイロードがＨＴＴＰ ３０Ｘリダイレクションに対応する特定のケースでは、ウェブソケットエミュレーション層８０は、ＨＴＴＰ ３０Ｘリダイレクションメッセージにより指定されるリダイレクションターゲットゲートウェイサーバー４２のインスタンス２２２へポストメッセージ要求２１４を再発行することにより、リダイレクションディレクティブをエミュレートする。ゲートウェイサーバー４２のインスタンス２２２のターゲット起点に対応するｉｆｒａｍｅ９６インスタンス２２６が使用される。ゲートウェイサーバー４２のインスタンス２２２が更なるリダイレクションを遂行しなければ、リモートターゲットサーバー３６、３８上の要求識別サービスへの接続２２８がなされる。
【００７２】
一般的に同等のリダイレクション処理フロー２１０は、Ｊａｖａ（登録商標）、フラッシュ及びシルバーライトのような他の具現化技術に対して具現化される。これらのケースにおいて該当する場合には、ブリッジアプリケーション１５８インスタンスは、定義されたターゲット起点に制限され、従って、リダイレクション要求の即座の取り扱いを除外する。包まれたＨＴＴＰ ３０Ｘリダイレクションメッセージは、この場合も、ブリッジアプリケーション１５８インスタンスに与えられ（２２４）、コンテンツをクライアントアプリケーション１５６へ返送してクライアントアプリケーション１５６内でウェブソケットエミュレーション層８０により取り扱いできるようにするのが好ましい。
【００７３】
ｉｆｒａｍｅ９６又はブリッジアプリケーション１５８インスタンスにおいて即座に取り扱う上で問題となる他の応答メッセージは、リダイレクション処理フロー２１０と同様に取り扱いできることが明らかである。即ち、このような問題応答は、ＨＴＴＰ ２００応答メッセージで包まれ、その包囲された応答メッセージをドキュメント９２又はクライアントアプリケーション１５６により取扱できるようにする。
【００７４】
ウェブブラウザクライアント５２とゲートウェイサーバー４２との間にエミュレートされたウェブソケット接続を確立する好ましいプロセス２４０が図１２に示されている。クライアント側ウェブソケットエミュレーション、又はクライアントライブラリ５６に対する同様の要求２４２に応答して、最初にゲートウェイサーバー４２に対してＨＴＴＰ接続２４４がなされる。しかしながら、この接続２４４は、ゲートウェイサーバー４２によって閉じられず、オープンに維持され（２４６）、そして両方向ウェブソケット通信セッションの半分の有効なエミュレーションにおいてゲートウェイサーバー４２からウェブクライアントブラウザ５２へ下流にデータを送信するのに使用される。接続２４４を経て与えられるサービス要求は、要求されたサービスを有効にホスティングするものとして識別された適当なリモートターゲットサーバー３６との従来の両方向性ＴＣＰベースウェブソケット接続２４８を確立するために、ゲートウェイサーバー４２により使用されるのが好ましい。接続２４８が確立されると、それに対応するサービス２５０は、オープン接続２４６を経て中継されるサーバー送信イベントの非同期シリーズとしてデータを選択して送信することができる。
【００７５】
好ましくは、あるユーザイベント２５２に応答して生じるか又はクライアント側ウェブアプリケーション２５４の自律的実行に基づいて生じる上流通信は、個別のＨＴＴＰ接続２５６を経て、ゲートウェイサーバー４２へＸｍｌＨｔｔｐＲｅｑｕｅｓｔとして送られるクロス起点リソース要求として送信される。この要求は、サーバー送信イベントメッセージシンタックスを使用してエミュレーションにおいて送信されるのが好ましい。この好みは、主として、両方向通信を取り扱う上での一貫性のためであり、そして更に、サーバー送信イベント層７８の信頼性ある配信メッセージメカニズムに基づいてウェブソケットを通して信頼性あるメッセージ配信を行えるようにする。即ち、好ましい実施形態では、エミュレートされたサーバー送信メッセージシンタックスは、受信確認のために追跡されるイベントＩＤを含む。サーバー送信イベントメッセージは、それに対応する確認メッセージが受信されるまでバッファされ、メッセージ配信失敗の環境又は見掛け上の環境において再送信を行えるようにするのが好ましい。接続２５６を通して受け取られた上流メッセージは、サービス２５０による考慮及び適当な応答のためにゲートウェイサーバー４２により両方向ウェブソケット接続２４８を通してルーティングされる。
【００７６】
上流通信は、典型的に、その数が制限され、短いメッセージになる傾向がある。これは、従来のウェブブラウザクライアントにおいて具現化される同時接続制限と組み合わされて、ウェブブラウザクライアントからゲートウェイサーバー４２への過渡的な上流接続を使用する好みを生じる。エミュレーションのもとでは、下流接続２４６のみが持続的通信接続として維持されるのが好ましい。
【００７７】
従来のネーティブウェブソケット接続の性質により、プロキシー及び他の中継サーバーの存在は、ウェブソケット接続の経路において許容される。本発明の好ましい実施形態では、ウェブソケットエミュレーション層８０は、ゲートウェイサーバー４２との組み合わせにおいて、下流接続２４６の状態の機能的監視を具現化して、下流接続２４６の経路におけるプロキシー又は他のサーバーの存在又は問題の振舞いを検出するのが好ましい。図１３を参照すれば、プロキシーサーバーの潜在的な存在を許容する本発明のオペレーション２７０が示されている。ウェブソケット接続を開始する要求２４２は、プロキシーサーバー２７４へのルーティングを引き起こす上流へのＨＴＴＰ接続を生じさせる。次いで、それに対応するＨＴＴＰ接続２７６が生成されて、ゲートウェイサーバー４２へルーティングされる。上述したように、この接続は、終了せず、接続２７８としてオープンに維持される。介在するプロキシーサーバー２７４は、典型的に、それに対応する接続２７８’をオープンに維持するが、プロキシーサーバー２７４の厳密な振舞いは、プロキシーサーバー２７４のローカル構成により決定される。ゲートウェイサーバー４２は、接続２７８をオープンに維持するが、プロキシーサーバー２７４は、下流送信データをバッファするか、又は構成ポリシーの問題として、接続２７８”を完全に終了させる。いずれにせよ、ウェブブラウザクライアントは、プロキシーサーバー２７４により決定される任意の待ち時間又は全データ配信の終了を受ける限定されたデータを受け取る。
【００７８】
本発明によれば、ゲートウェイサーバー４２は、オープンの下流接続２７８がスレッシュホールド期間より長くアイドル状態になったときにその接続を通して心鼓動パケットを自律的に送信する。ここに示す好ましい実施形態では、心鼓動スレッシュホールドは、５秒である。ウェブソケットエミュレーション層８０が心鼓動周期を越えて接続２７８”を通してデータを受信し損なうと、プロキシーサーバーの存在が仮定され、そして接続２７８”がプロキシーサーバー２７４により終了されないとすれば、接続２７８”を経て上流へ切断が送られる。この切断は、プロキシーサーバー２７４により保持されたバッファデータのフラッシュを生じさせる。好ましくは、ＨＴＴＰＳプロトコルを使用してゲートウェイサーバー４２への新たな接続２８０が確立される。接続２８０は、この場合も、持続的な下流接続２８２としてオープンに保たれる。ＨＴＴＰＳプロトコルを使用する接続は、デフォールトでは、好ましいものではない。というのは、接続を確立しそれを通してデータを処理ためにウェブブラウザクライアント５２及びゲートウェイサーバー４２の両方に大きなオーバーヘッドがかかるためである。しかしながら、ＨＴＴＰＳ接続は、介在するプロキシーサーバー２７４が検出される場合には、好ましいものである。というのは、プロトコルが、バッファも中断もせずに、ほぼ常時にプロキシーサーバー２７４を通過するからである。ＨＴＴＰＳ接続を確立できない場合には、長いポーリングへの後退が具現化されるのが好ましい。それ故、下流接続２８２は、プロキシーサーバー２７４が存在するときでも有効に持続維持することができる。接続失敗２７８”の場合に未確認のままであるサーバー送信イベントは、自動的に再送信される。ゲートウェイサーバーが上流接続制限を検出できるようにするため、好ましくはウェブソケットエミュレーション層８０において、ウェブブラウザクライアント５２で同様の心鼓動メカニズムが具現化されるのが好ましい。
【００７９】
従って、リアルタイムウェブアプリケーションにとって重要な両方向ウェブブラウザクライアント通信を達成するためのシステム及び方法が説明された。エミュレートされたウェブソケットサーバーシステムは、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザが、両方向全二重バイナリー及びテキスト通信を即座にサポートできるようにする。それ故、複雑な従来の分散型ウェブアプリケーションアーキテクチャーを回避することができる。むしろ、本発明を使用することにより、ウェブアプリケーションは、ＨＴＴＰ上のエミュレートされたウェブソケットを通して搬送されるネーティブプロトコルを使用してバックエンドサービスと直接通信することができる。
【００８０】
本発明の好ましい実施形態の以上の説明から、当業者であれば、ここに開示した実施形態の多数の変更や修正が容易に明らかとなろう。それ故、特許請求の範囲内で、本発明は、上述したものとは異なる仕方で実施されてもよいことが理解されよう。
【符号の説明】
【００８１】
１０：アプリケーション
１２、１４：従来のクライアントシステム
１６：通信ネットワーク
１８、２０、２２：リモートサーバーシステム
３２：クライアントシステム
３４：ソース起点サーバー
３６、３８：ターゲットサーバー
４０：クロスドキュメントメッセージングシステム
４２：ゲートウェイサーバー
５２：ウェブブラウザクライアントアプリケーション
５４：ウェブページドキュメント
５６：クライアントライブラリ
７０：ライブラリスタック
７２：ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層
７４：ポストメッセージ層
７６：クロス起点リクエスト層
７８：サーバー送信イベント層
８０：ウェブソケットエミュレーション層
８２：バイトソケット層
８４：クライアントプロトコルライブラリ層
９２：実行可能なドキュメント
９４：ポストメッセージ要求
９６：ｉｆｒａｍｅ
【技術分野】
【０００１】
本発明は、一般に、ネットワーク通信システムに係り、より詳細には、ＨＴＴＰベースのネットワークを経てリアルタイム両方向性通信をサポートすることのできる企業クラスのクライアント／サーバーシステムに係る。
【０００２】
本発明は、２００９年５月１日に出願された米国仮特許出願第６１／１７４，９２３号の利益を請求する。
【背景技術】
【０００３】
ウェブアプリケーションの開発及び使用は、成長を続けているが、広く使用されているＨＴＴＰプロトコルが半二重通信しかサポートしないという点で著しい制約が存在する。従来のクライアント／サーバーアプリケーション使用モデルの場合のように、クライアントが種々のバックエンドシステムと対話できることが要求されない場合には、連続的なティア・ツー・ティア両方向又は全二重通信接続が強く望まれる。リアルタイム株フィードを表示し、アドホック情報更新を許し、特に、入札、チャット、ゲーム、及び他のアプリケーションで遭遇するリアルタイムオペレーションにおいて複数のユーザ間に能動的に参加できるようにする、等のウェブ上でのリアルタイムサービスの需要が重要になり増加している。
【０００４】
所有権クライアント及びサーバーアプリケーションによってサポートされる他のプロトコルを利用することはできるは、ウェブブラウザクライアントが偏在するという事実は、実際上、基本的ＨＴＴＰプロトコルの使用を要求する。本来的に、従来のウェブブラウザベースのクライアントアプリケーションは、データ要求及び応答が一度に一方向にしか流れない通信に基本的に制約されている。両方向通信をエミュレートする従来の試みは、典型的に、コメット・アンド・リバース・アジャック(Comet and Reverse Ajax)において具現化されるようなポーリング技術の使用を含む。本質的に、サーバーは、選択環境のもとで、クライアントへ情報をプッシュすることができる。しかしながら、これらの技術は、標準化の欠如、不充分な性能、及び限定された拡張性のような多数の制限で悩まされている。
【０００５】
例えば、直接的なポーリング技術は、ＨＴＴＰ要求を規則的なインターバルでターゲットウェブサーバーへ繰り返し送信するためにウェブブラウザに関連して典型的に具現化されるクライアントアプリケーションを要求する。各要求は、サーバーが更新情報を有するかどうかに基づいて更新されたリアルタイム情報を潜在的に返送するサーバー発生応答を即座に受け取る。ポーリングインターバルに基づいて、受け取られる情報は、実際には、リアルタイムで受け取られず、逆に、応答情報がない場合にサーバー要求の高いオーバーヘッドを頻繁に受けて、得ることしかできない。このオーバーヘッドは、クライアント及びサーバーの両性能に影響を及ぼし、ネットワーク帯域巾を消費する。
【０００６】
直接的ポーリングのオーバーヘッドを回避するために、ロングポーリングとして知られたバリアントが開発された。非同期ポーリングとしても知られているロングポーリングでは、この場合も典型的にウェブブラウザであるクライアントアプリケーションは、ターゲットウェブサーバーシステムに要求を発行する。即座の応答を与えるのではなく、ターゲットサーバーは、ある定義されたインターバルまで遅延し、ある新たな情報が応答として与えられるのを待機する。ある新たな、即ちリアルタイムのデータが遅延インターバル中にサーバーにより得られる場合には、リアルタイム情報を含むサーバー応答がクライアントへ送られる。新たな情報が受け取られない場合には、空き応答がクライアントアプリケーションに返送され、未決要求を終了させる。従って、ロングポーリングは、リアルタイムデータの配布の待ち時間を短縮する潜在性があり、要求／応答サイクルの数をある程度減少することができる。しかしながら、ロングポーリングは、依然として著しい数の要求／応答サイクルが必要とされ、且つ同様の数のＨＴＴＰヘッダがロングポーリング及びポーリングの両方に存在してクライアントとサーバーとの間で交換しなければならないために、慣習的なポーリングに勝る実質的な性能改善を与えない。
【０００７】
ストリーミングは、別の従来の変形例である。ストリーミングが使用される場合には、クライアントウェブブラウザが完全な要求を送信するが、ターゲットサーバーは、少なくともある定義されたインターバル中に接続をオープンに維持できるように応答する。実際に、ターゲットサーバーは、応答が完了したという確認を延期する。これは、ターゲットサーバーが、そのターゲットサーバーによって受け取られる付加的なリアルタイム情報で応答を続けられるようにする。ストリーミング接続を確立する利益は、クライアント及びサーバーシステムの一部分においてオーバーヘッドを減少することである。ネットワークトラフィックも減少される。というのは、クライアント及びサーバーシステムは、ストリーミング接続を確立するのにＨＴＴＰヘッダパケットを一度しか送信しないからである。応答継続ネットワークパケットは、必要に応じて送信されるだけであり、従って、データしか含まず、ひいては、最小のオーバーヘッドしか課さない。不都合にも、ストリーミングは、ＨＴＴＰでカプセル化され、従って、低レベルＨＴＴＰ転送がネットワーク全般を通してどのようにルーティングされるかに完全に依存する。それ故、ストリーミングは、所与の接続がルーティングされる無数のシステムによって全体的に決定される予想不能な接続／切断及び実質的なバッファリング待ち時間を受ける。それ故、従来のストリーミングは、信頼できない。
【０００８】
或いは又、提案されているＨＴＭＬ５ドラフト仕様は、ウェブソケット、サーバー送信イベント(Server-Sent Event)、及びそれに関連したアクセスセキュリティ要求を含む新たなプロトコル特徴を、ＨＴＴＰプロトコルを使用して信頼性ある両方向性通信を可能にする手段として定義している。ＨＴＭＬ５仕様は、他の中でも全二重直接ＴＣＰ通信を標準化するよう意図されているが、最終的な仕様は、公式に採用されるのに、数年でなくても、おそらく、１年はかかる。次世代のウェブブラウザへの機能的合体及び動作的に均一の採用は、おそらく、数年は行われないであろう。更に、実用性、ビジネス及び他の制約のために既存のインプレースウェブブラウザの更新に対する抵抗もあり、おそらく、大規模な採用が数年以上阻止されるであろう。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
その結果、ビジネス及び他の商業的サービス、リクリエーション及び情報を含む全ての特性のウェブサービスにアクセスするのに使用できるクライアントウェブブラウザとは実質的に独立してリアルタイム全二重通信能力を提供する手段が要望されている。
【課題を解決するための手段】
【００１０】
従って、本発明の一般的な目的は、リアルタイム両方向ブラウザ通信を、該当する場合に、現在提案されているＨＴＭＬ５仕様と一貫したものにできる効率的なゲートウェイサーバーシステムを提供することである。
【００１１】
これは、本発明において、ｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントにおけるクロス起点(cross-origin)セキュリティ制約のためにアクセスできないサーバー間で分散ウェブアプリケーションにおいてサービス通信を行うことのできるシステムを提供することにより達成される。ウェブブラウザクライアントは、定義されたソース起点を有するソース起点サーバーから受け取られたクライアント側ウェブアプリケーションを実行し、そしてその定義されたウェブアプリケーションサービスを要求するための接続を要求する。エミュレーションクライアントライブラリーを実行すると、ウェブブラウザクライアントと、ソース起点の範囲外のターゲット起点を有するゲートウェイサーバーとの間に、両方向可能ＨＴＴＰベースの通信接続を確立し、要求識別ウェブアプリケーションサービスへのアクセスを与える。両方向可能ＨＴＴＰベースの通信接続は、ソースとターゲット起点との間にセキュアな通信経路を与えるクロス起点通信ブリッジを含む。ゲートウェイサーバーは、要求識別ウェブアプリケーションサービスに対して規定の関係を有するターゲットサーバーによって提供されるターゲット定義サービスへのＨＴＭＬ５適合接続を確立することができる。
【００１２】
本発明の効果は、参加するウェブブラウザクライアントが完全なＨＴＭＬ５適合であるかどうかに関わらず、分散ウェブアプリケーションを一般的に具現化できることである。本発明の一実施形態を使用して分散ウェブアプリケーションを具現化することにより、バックエンドシステムとサービスとの間でウェブブラウザクライアントまでずっとＨＴＭＬ５仕様に機能的に適合するように適当なメッセージ取り扱い配信が確保される。更に、好ましい実施形態は、ＨＴＭＬ５規格に機能的に適合する。本来的に適合するＨＴＭＬ５ウェブブラウザクライアントは、サーバー又はクライアントアプリケーションコードを変更する必要なく、本発明によりサポートされる分散ウェブアプリケーションに及びその中に透過的に参加することができる。
【００１３】
本発明の別の効果は、クライアントエミュレーションライブラリーがバイナリー及びテキストベースの両プロトコルサポートを与えることである。バイナリープロトコルサポートは、テキストのみのウェブソケットプロトコルの特徴改善を許すと共に、クライアントとサーバーとの間の生のＴＣＰ通信を一般的に可能にする非常に望ましい仕様拡張である。バイナリープロトコルサポートを設けることは、ＨＴＭＬ５適合に影響することなく、ウェブソケットプロトコルサポートへ効率的にインターフェイスされる。本来的に適合するＨＴＭＬ５ウェブブラウザクライアントは、バイナリープロトコルから等しく利益を得、そしてそれを使用することができる。
【００１４】
本発明の更に別の効果は、ウェブブラウザクライアントのエミュレーションスタック、及びゲートウェイサーバーとの相互動作が、高性能であることである。メッセージの配信は、弾力的である。下流のサーバー送信イベント要求に対する接続を含む全ての接続は、クライアントが開始するので、クライアントとゲートウェイサーバーとの間の通信は、ＨＴＴＰプロトコルの具現化によりファイアウオール及びプロキシーサーバーをシームレスに横断することができる。切れた接続又は失われた要求の場合には、クライアント側ウェブアプリケーションは、自動的に再接続してメッセージの配信を保証するよう選択することができる。再接続オペレーションは、クライアントプロトコルライブラリ８４として具現化されるのが好ましい。更に、エミュレーション層は、ローカルウェブブラウザクライアントのプロキシー設定を自動的に認識しそして讃えることができ、ウェブプロキシーサーバーを通過しなければならない接続に伴う潜在的な問題を排除することができる。更に、クライアントライブラリは、異なるクライアント技術で具現化することもでき、そして全てのケースで、サービスに対するプロトコルトランザクションを許すために適当なＡＰＩを与えることができる。アプリケーションサーバーロジックを具現化するのに、複数のクライアント／サーバー通信トランザクションを潜在的に伴う複合サーブレットベース及び他のカスタムサーバー側サポートロジックは、要求されない。むしろ、ウェブブラウザクライアントアプリケーションは、テキスト、及び適宜に、バイナリーデータパッケージと通信することができ、これにより、通信オーバーヘッド、複雑さ、及び実行待ち時間を減少することができる。本発明により表される分散ウェブアプリケーションアーキテクチャーは、ワールドワイドの商業的アプリケーションの環境でも、非常に大きなユーザコミュニティをサポートするように容易に拡張することができる。
【００１５】
本発明の更に別の効果は、分散ウェブアプリケーションの環境においてアクセスできるサービス及び起点サーバーのセットにわたり、ひいては、ウェブブラウザクライアントの特定のセットにより、容易に管理された制御をゲートウェイサーバーが与えることである。
【００１６】
本発明の更に別の効果は、１つ以上のバックエンドサービスから、参加する全ての接続されたウェブブラウザクライアントへ送られ又は得られるデータのブロードキャスト及びマルチキャスト通知のための効率的な基礎を、ゲートウェイサーバーの使用により与えることである。バックエンドデータソースは、１つ又は幾つかの当該ゲートウェイサーバーへデータを送信することができ、これにより、単一の接触点から新たなサーバー送信イベント通知としてゲートウェイサーバーサポートウェブブラウザクライアントへ効率的に配布できるようにする。
【００１７】
本発明の更に別の効果は、エミュレーションクライアントライブラリを使用して、多数の異なる特殊なクライアントプロトコルをサポートできることである。特定の又は所有権クライアントのプロトコルを要求する分散ウェブアプリケーションは、ゲートウェイサーバーを経てダウンロードするのに使用できるクライアントライブラリリソースを調整することによりサポートすることができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の好ましい実施形態のための好ましい動作環境を一般的に示す。
【図２】分散クライアント／サーバーウェブアプリケーションの具現化において本発明の好ましい実施形態を具現化するのに適したクライアント／サーバーシステムを示すブロック図である。
【図３】分散クライアント／サーバーウェブアプリケーションの具現化において本発明の好ましい実施形態を具現化するのに適した好ましいクライアント／サーバーシステムを示すブロック図である。
【図４】本発明の好ましい実施形態と一貫する分散クライアント／サーバーウェブアプリケーションに関連してクライアント側アプリケーションを具現化するように構成されたウェブブラウザクライアントを示す詳細なブロック図である。
【図５】本発明の好ましい実施形態と一貫する積層ライブラリスタックとして具現化されるクライアントライブラリのブロック図である。
【図６】本発明の好ましい実施形態によるウェブブラウザクライアントアプリケーションの好ましいｉｆｒａｍｅベース具現化を示す詳細ブロック図である。
【図７】本発明の好ましい実施形態によるエミュレートウェブソケットネットワーク接続を確立する際のウェブブラウザクライアントアプリケーションの初期化及び実行を示すシーケンス図である。
【図８Ａ】本発明の好ましい実施形態により構成されたウェブブラウザクライアントアプリケーションの好ましいカプセル化実施を示すブロック図である。
【図８Ｂ】本発明の好ましい実施形態により構成されたウェブブラウザクライアントアプリケーションの好ましいカプセル化実施を示すブロック図である。
【図９】本発明の好ましい実施形態によるエミュレートウェブソケットネットワーク接続を確立する際のウェブブラウザクライアントカプセル化アプリケーションの実行を示すシーケンス図である。
【図１０】本発明の好ましい実施形態において具現化されるゲートウェイサーバーの好ましい具現化のブロック図である。
【図１１】本発明の好ましい実施形態に関連して使用される好ましいサービスリダイレクション技術を示すフローチャートである。
【図１２】本発明の好ましい実施形態によりウェブブラウザクライアントとゲートウェイサーバーとの間にエミュレートウェブソケット接続を確立する好ましいプロセスを示すシーケンス図である。
【図１３】本発明の好ましい実施形態によりウェブブラウザクライアントとゲートウェイサーバーとの間にエミュレートウェブソケット接続を確立し維持するのに含まれるプロキシーサーバーの取り扱いを示すシーケンス図である。
【発明を実施するための形態】
【００１９】
本発明は、ウェブサービスにアクセスするのに使用されるクライアントウェブブラウザの現在のネーティブな能力とは実質的に独立してリアルタイム全二重通信能力の必要性を満足する。本発明の以下の詳細な説明において、１つ以上の図面に示された同じ部分を指すのに同じ参照番号が使用される。
【００２０】
サポート仕様を含むドラフトＨＴＭＬ５は、ウェブブラウザ及び同様のＨＴＴＰベースのクライアントアプリケーションにおいて具現化するために推奨されるウェブソケット(WebSocket)及びサーバー送信イベント(Server-Sent Event)（ＳＳＥ）のネーティブなアーキテクチャー及び動作特徴を定義する。ウェブソケット及びサーバー送信イベントは、全二重直接ＴＣＰ通信チャンネルを使用できるクライアントアプリケーションを前提としている。本発明に関連したアプリケーション１０において、図１に一般的に示すように、従来のクライアントシステム１２、１４は、パブリックインターネット、プライベートイントラネット又は他の通信ネットワーク１６を通して、１つ以上のリモートサーバーシステム１８、２０、２２にアクセスして、リアルタイム情報を両方向に要求し且つ受け取るために、ウェブブラウザアプリケーションを実行する。典型的な例において、クライアントシステム１２により実行されるウェブブラウザクライアントを通してなされる情報要求は、最初に、一次又はソースサーバー１８に向けられ、そして他の二次サーバー２０、２２で必要とされるリアルタイム両方向情報フィード接続が確立される。例えば、ソースサーバー１８からウェブページが要求され、これは、配信されたページのユーザインターフェイス表現内の適当な指定のウインドウエリア内で、ニュースソースサーバー２０からのリアルタイムニュースストーリー及び株情報サーバー２２からの株価情報を提示する。
【００２１】
従来、ソースサーバー１８との整合においてサーバー２０、２２とのリアルタイム両方向二次接続の透過的な確立は、クライアントシステム１２、１４により実行されるウェブブラウザクライアントにおけるウェブソケットのネーティブサポート及びサーバー送信イベントのサポートに依存する。広く普及したネーティブなウェブソケット及びサーバー送信イベントのサポートがないと、更に、全ての主要な独立したウェブブラウザクライアント具現化にわたって適合する仕方で、商業的又はその他のウェブソケットベースシステムを確立することは、実際的でない。
【００２２】
本発明によれば、特定のウェブブラウザ具現化がＨＴＭＬ５規格をもたないか又はその部分的なネーティブ具現化しかもたない場合でも、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントを具現化して、完全に適合するウェブソケット及びサーバー送信イベントを即座にサポートできるようにするゲートウェイサービスが提供される。このゲートウェイサービスは、既存のサーバー１８、２０、２２において具現化されるか、或いは好ましい実施形態のように、個別の専用のゲートウェイサーバーシステムにおいて具現化される。通常部分的にネーティブな特徴の具現化を確認することが、適宜に利用される。その他、本発明は、ＨＴＭＬ５仕様に適合するネーティブな具現化と一貫した機能的適合システムを達成するエミュレーションシステムを具現化する。
【００２３】
図２を参照すれば、ウェブソケット及びサーバー送信イベントの種々の観点の有効なエミュレーションは、従来は、既存の従来の規格適合ウェブブラウザ、特に、ドラフトＨＴＭＬ５仕様に完全に適合しないもの、に組み込まれる確立されたセキュリティ並びに機能的制限によって除外される。ウェブソケット及びサーバー送信イベントエミュレーションの重要な要件は、クロス起点通信を透過的に具現化できることである。このような通信は、従来、既存の規格指定同一起点セキュリティポリシー要件により除外される。即ち、ソース起点サーバー３４からクライアントシステム３２へ配信されるウェブページを特に含むドキュメントは、同じ起点範囲内のみのあるリソースを参照し、要求するように制約される。一般的に定義されるように、起点とは、トランスポートプロトコル、ドメイン及びポートナンバーにより定義される。起点アクセス制約は、クロスサイトスクリプティングアタックを除外し、そして異なる起点をソースとするドキュメント間の偶発的な相互作用をより一般的に防止する。不都合なことに、従来の起点セキュリティ特徴は、異なるソース起点範囲を有するページ間の、悪意のない通信も阻止する。従来、例えば、ソース起点サーバー３４から送られるドキュメントは、異なる起点にあるターゲットサーバー３６、３８から送られるドキュメント又はサービスにアクセスすること又はそれとデータを交換することが防止される。
【００２４】
本発明によれば、図３に一般的に示すように、本発明の好ましい実施形態により構成されたクロスドキュメントメッセージングシステム４０は、クライアントシステム３２によりロードされたドキュメントを異なる起点にわたって選択的にセキュアに相互作用できるようにする。ターゲット起点要求は、説明上、ソース起点サーバー３４の範囲外にある起点により定義されたサーバーにより提供されるドキュメント又はサービスに対して、ソース起点サーバー３４から受け取られるソース起点ドキュメントから生じるリソース要求として定義される。指定のドメイン、ポート及びトランスポートプロトコルのいずれかがソース及びターゲット起点間で異なる場合には、起点の範囲が異なり、それら起点間の要求がクロス起点要求となる。本発明によれば、クライアントシステム３２からのターゲット起点要求は、特に、ゲートウェイサーバー４２へ向けられ、これは、次いで、ターゲットサーバー３６、３８と通信できるようにする適当なサービスを具現化する。ゲートウェイサーバー４２は、典型的に、ソース起点サーバー３４及びクライアントシステム３２の範囲外の起点である。
【００２５】
図４に５０で詳細に示されたように、クライアントシステム３２で実行されるウェブブラウザクライアントアプリケーション５２は、ユーザ選択ソース起点ウェブサーバー３４へ要求を発行する。評価の際に、ソース起点ウェブサーバー３４は、要求対応ウェブページドキュメント５４を返送する。好ましくは、ウェブページドキュメント５４は、検索されるべき初期構成リソースの識別を含むように予めコード化される。ウェブブラウザクライアントアプリケーション５２がオブジェクト基準に遭遇するときに、初期構成リソース要求がソース起点ウェブサーバー３４へ発行され、それに対応するクライアントライブラリ５６を返送する。オブジェクト基準リソースの性質に基づいて、１つ以上のファイルがクライアントライブラリ５６の一部分として返送される。又、ウェブページドキュメント５４は、ソース起点ウェブサーバー３４に代わって動作する指定のゲートウェイサーバー４２を識別するように働く初期ターゲット基準でも予めコード化されるのが好ましい。
【００２６】
クライアントライブラリ５６の好ましい実施形態が、図５に、積層ライブラリスタック７０として一般的に示されている。全体的に、クライアントライブラリ５６は、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザアプリケーション５２において実行されたときに機能的ＨＴＭＬ５適合ウェブソケットエミュレーションを与える。低レベルの、より基本的な層が積層ライブラリスタック７０の底に配置され、より上位の層において、より高いレベルの機能が次第に与えられる。図５に示すもの以外の付加的な層が、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザに存在する。アドベフラッシュ(Adobe Flash)、マイクロソフトシルバーライト(Microsoft Silverlight)、及びオラクルジャバ(Oracle Java（登録商標）)を含むウェブブラウザアプリケーション層プラグインも、もしあれば、ウェブブラウザ実行環境内で利用することができる。
【００２７】
クライアントライブラリ５６のベースは、必要なエミュレーションをｐｒｅ−ＨＴＭＬ５適合ウェブブラウザにもたずに名目上存在する従来のＸｍｌＨｔｔｐＲｅｑｕｅｓｔ（ＸＨＲ）層７２である。ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層７２は、ＨＴＴＰ及びＨＴＴＰＳ要求を指定のターゲットウェブサーバーシステムへ直接送信することのできるアプリケーションプログラミングインターフェイス（ＡＰＩ）を与える。サーバー応答は、データとして直接受け取られ、これは、次いで、要求を開始したウェブアプリケーションにより使用するためにＡＰＩを通して得ることができる。名目上、ＸｍｌＨｔｔｐＲｅｑｕｅｓｔの実行及び完了は、単一の起点に限定される。即ち、要求ソース及びターゲットウェブサーバーシステムは、共通起点の範囲内に存在しなければならない。
【００２８】
ポストメッセージ(PostMessage)層７４は、クライアントブラウザ５２の環境内で実行されるウェブアプリケーションにアクセスできる付加的なＡＰＩコールを与えることにより、エミュレートされたクロス起点メッセージをサポートするために設けられる。本発明の好ましい実施形態で具現化されるように、ポストメッセージ層７４は、従来のウェブブラウザの厳密なセキュリティポリシー具現化を管理し、ウインドウ内に埋め込まれたドキュメントが異なる起点からロードされる場合でも、単一のベースウェブページドキュメントにより定義される複数のフレームをセキュアに通信できるようにする。ベースドキュメントと、ページ内に埋め込まれたドキュメントとの間の通信は、ターゲットが、命名されたソース起点からのメッセージを明確に予想しそして受け容れるとすれば、ポストメッセージ層７４を通して許される。ソースが、命名されたターゲット起点からのメッセージを明確に聴取し受け容れる場合には、両方向通信がサポートされる。ある現在の、従来ウェブブラウザは、ポストメッセージＡＰＩの初期ネーティブ具現化をサポートする。ポストメッセージ層７４は、既存のポストメッセージＡＰＩの存在及び適合性を検出するのが好ましい。ネーティブポストメッセージＡＰＩが存在しないか、ネーティブポストメッセージＡＰＩが不適合である場合には、ポストメッセージ層７４がエミュレーションを通して全てのポストメッセージＡＰＩコールを取り扱うことができる。
【００２９】
好ましい実施形態において、ポストメッセージ層７４は、典型的にジャバスクリプト(JavaScript（登録商標）)、フラッシュ(Flash)及びシルバーライト(Silverlight)である埋め込みウインドウ技術の性質に基づく具現化を使用してポストメッセージＡＰＩをエミュレートする。各々について、埋め込みドキュメント又はその等効物が埋め込みウインドウ起点の範囲内で検索される。この埋め込みドキュメントは、機能的に、ポストメッセージＡＰＩと両立性のあるブリッジ整流処理を与える。現在の好ましい実施形態と一貫したジャバスクリプトの場合には、クライアントｉｆｒａｍｅを、ゲートウェイサーバー４２により取り扱われる対応起点へのブリッジとして使用する構造化された仕方でエミュレーションが具現化され、それにより、ソース対ターゲット通信経路を機能的に確立する。ポストメッセージのメッセージは、ＵＲＬ ｉｄ断片として転送される短いデータセグメント、典型的に、ｉｆｒａｍｅ ＵＲＬのポスト“＃”部分として、ｉｆｒａｍｅを通して通信される。ジャバ、フラッシュ及びシルバーライトの場合には、ウインドウ対応埋め込みドキュメントと組み合わされて動作されるインストールランタイムは、本発明により構成された技術対応ブリッジメカニズムを使用して通信を確立するための基礎をなす。
【００３０】
クロス起点リクエスト(Cross-Origin Request)層７６は、ＨＴＭＬ５適合クロス起点リソースシェアリングＡＰＩを通してアクセス可能なＷ３Ｃクロス起点リソースシェアリング(Cross-Origin Resource Sharing)（ＣＯＲＳ）仕様のエミュレーションを与える。クロス起点リクエスト層７６は、ウェブブラウザクライアントがネーティブクロス起点リソースシェアリングをサポートしないか又はネーティブ具現化が適合しない場合にイネーブルされる。本発明の好ましい実施形態で具現化されるように、クロス起点リソースシェアリングは、ポストメッセージ層７４及びＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層７２のレバレッジ使用を通してウェブブラウザクライアント５２においてエミュレートされる。クロス起点リソース要求は、ポストメッセージ及びＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層７４、７２を通して処理され、そしてゲートウェイサーバー４２を通して、対応ターゲットサーバー３６、３８によりサービスされる指定のターゲット起点に接続される。本発明の好ましい実施形態では、ゲートウェイサーバー４２は、ターゲットサーバー３６、３８への特定の適合接続を確立できるＨＴＭＬ５適合クロス起点リソースシェアリングコンポーネントを具現化する。
【００３１】
サーバー送信イベント層７８は、ウェブクライアントが、ＨＴＭＬ５適合サーバー送信イベントストリームに接続できるようにする。サーバー送信イベント層７８は、データのストリームをリモートターゲットサーバーからウェブブラウザ５２へ送信されるものとしてローカルに管理する。データのサーバー送信ストリームは、従来、ウェブブラウザクライアント５２へと下流へ送信されるネットワークメッセージの一方向性非同期シリーズとして具現化される。ある従来のウェブブラウザは、ＳＳＥプロトコルの初期のネーティブ具現化であるが、本発明の好ましい実施形態は、エージェント特有のネーティブ具現化を拡張することによりサーバー送信イベント層７８の完全な具現化を与える。即ち、サーバー送信イベント層７８は、現在エージェントを検出し、そしてＳＳＥプロトコルに対するサポートを完了するために必要に応じて機能を補足する。部分的なネーティブサポートが得られないか又は使用できない場合には、サーバー送信イベント層７８は、ＳＳＥプロトコルをサポートするのに適したものとして全エミュレーションを遂行する。本発明の好ましい実施形態では、ゲートウェイサーバー４２は、ウェブブラウザクライアント５２とのクロス起点ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ応答ストリーミング接続を管理するためのプログラムを具現化し、サーバー送信イベントストリームのソースで動作している上流ターゲットサーバーから供給される付加的なメッセージを聴取しながら、ＨＴＴＰ応答をオープンに保つ。
【００３２】
ウェブソケットエミュレーション層８０は、両方向接続をサポートする。接続が確立されると、ウェブブラウザクライアント５２は、典型的にターゲットサーバー３６、３８をホストとするバックエンドサービスに直接リンクされる。又、接続は、それが確立されると、オープンのままとなり、クライアント及びサーバーの両方は、非同期で前後に情報を送信することができる。ウェブソケットエミュレーション層８０は、ジャバー(Jabber)、ＩＭＡＰ、等のテキストベースのプロトコルをサポートする。好ましい実施形態では、ウェブソケットエミュレーション層８０は、ＨＴＭＬ５適合ウェブソケットＡＰＩの完全な具現化を与える。
【００３３】
バイトソケット(ByteSocket)層８２は、好ましくは、ウェブソケットエミュレーション層８０を通るバイナリーデータ送信をサポートするために設けられる。それに対応するバイナリートランスポートプロトコル仕様は、Ｗ３Ｃ又はＩＥＴＦにより与えられていない。本発明によれば、バイトソケット層８２は、ウェブソケットＡＰＩと一般的にパラレルのＡＰＩを具現化する。バイトソケットＡＰＩは、主としてバイト値を含むバイナリープリミティブの読み取り及び書き込みを許す付加的な方法を与える。バイトソケット層８２は、バイナリープロトコルの全範囲の具現化を可能にし、更に、テキストベースのプロトコルに対しネットワークにわたってバイナリー圧縮及び暗号化を適用する。
【００３４】
典型的に特殊な付加的なクライアントプロトコルライブラリが、クライアントプロトコルライブラリ層８４の一部分として、クライアントライブラリ５６に含まれてもよい。これらのクライアントプロトコルライブラリは、典型的に、アプリケーション又はサーバー特有のプロトコルを具現化する。本発明の好ましい実施形態では、クライアントプロトコルライブラリ層８４は、例えば、グーグルトーク(Google Talk)により使用される従来のＸＭＰＰプロトコルを具現化するＸｍｐｐＣｌｉｅｎｔを含むことができる。好ましくは、ＸｍｐｐＣｌｉｅｎｔクライアントライブラリは、ウェブソケットエミュレーション層８０を利用して、ＸＭＰＰテキスト指向のメッセージを交換する。
【００３５】
又、クライアントプロトコルライブラリ層８４は、ストリーミングテキスト配向メッセージングプロトコル(Streaming Text Orientated Messaging Protocol)（Ｓｔｏｍｐ）を具現化するＳｔｏｍｐＣｌｉｅｎｔクライアントライブラリを含むことができる。好ましくは、ＳｔｏｍｐＣｌｉｅｎｔクライアントライブラリは、バイトソケットクライアントライブラリを使用して、ＡｐａｃｈｅＡｃｔｉｖｅＭＱのようなＳｔｏｍｐ適合アプリケーションを実行するリモートサーバーとでＳｔｏｍｐメッセージを交換する。同様に、リモートインターネットリレーチャット(Internet Relay Chat)（ＩＲＣ）サーバーとのメッセージ交換をサポートするためにＩｒｃＣｌｉｅｎｔクライアントライブラリを設けることができる。更に特殊なクライアントライブラリ、例えば、リモートフレームバッファクライアントライブラリは、特殊な両方向プロトコルをサポートするために具現化することができる。ネットワークを経てキーボード及びマウスイベントを送信すると共にグラフィックスクリーン更新を受信するためにバーチャルネットワーククライアント（ＶＮＣ）具現化によりリモートフレームバッファプロトコルが使用される。
【００３６】
本発明の別の実施形態では、エミュレーション層７０の初期化中に、ウェブブラウザクライアント５２の実行環境内でフラッシュプラグインの潜在的な存在を検出するためのテストが実施される。検出されて、エミュレーションに対する付属物として使用できるように適当に構成された場合には、エミュレーション層７０は、指定のゲートウェイサーバー４２との単一のＴＣＰソケット接続を確立するに充分な幾つかのネットワーク及びソケット通信動作をプラグインへ選択的に委任することができる。即ち、ＵＩ動作をサポートするためにフラッシュプラグインが一般的に使用されるが、そのプラグインに組み込まれた限定されたネットワーク層及び限定されたソケット能力の選択的利点を取り入れることができる。ネットワーク及びソケット層の観点しか使用しないと、目に見える表示アーティファクトは生成されない。しかしながら、フラッシュプラグインは、常に利用できるものではなく、ファイアウオール、ＨＴＴＰプロキシー及び他の通信バリアの存在により使用可能な仕方で又は使用できるように構成される。フラッシュプラグインにより与えられるネットワーク層の使用は、依然、限定された環境のもとで行われる。
【００３７】
典型的な使用において、ウェブアプリケーションは、ウェブブラウザクライアント５２により実行されるクライアント側アプリケーションと、ソース起点サーバー３４及び１つ以上のターゲットサーバー３６、３８によりある組み合わせで機能的に具現化される分散型サーバー側アプリケーションと、の組み合わせとして具現化される。ウェブページ５４におけるオブジェクト基準は、ウェブブラウザクライアント５２がクライアント側アプリケーションを１つ以上のドキュメントとして最初にロードできるようにする。クライアント側アプリケーションは、典型的に、サーバー送信イベント層７８、ウェブソケット層８０及びバイトソケット層８２に関連したＡＰＩと対話しそしてそれを使用するように設計される。ウェブソケット層８０は、使用される主たるＡＰＩであると予想されるが、全ての層をクライアント側アプリケーションにより使用することができる。
【００３８】
図６を参照すれば、ウェブブラウザクライアント５２の環境内の実行可能なドキュメント９２としてクライアント側アプリケーションが示されている。本発明の好ましい実施形態において具現化されるように、ドキュメント９２の実行によるクライアントライブラリ５６へのＡＰＩコールは、最終的にポストメッセージ要求９４として実現される。各ポストメッセージ要求９４は、少なくとも、当該ソース及びターゲット起点と、要求により表される動作とによって定義される。ソース起点は、ドキュメント９２の起点である。具現化されるエミュレーションの性質により、メッセージのターゲット起点は、実際には、ゲートウェイサーバー４２の起点である。負荷バランス及び相対的な地理的な理由で複数のゲートウェイサーバー４２を同時に具現化することができる。実際上、ポストメッセージ要求９４は、ターゲットゲートウェイサーバー４２も識別する。
【００３９】
クライアント側アプリケーションを具現化する技術がＪａｖａＳｃｒｉｐｔ（登録商標）である場合には、１つ以上のｉｆｒａｍｅ９２が通信ブリッジとして確立される。クロス起点要求層７４として処理された各クロス起点ＸｍｌＨｔｔｐＲｅｑｕｅｓｔは、それに対応するポストメッセージ要求９４として実現され、これは、次いで、ドキュメントイベントとしてｉｆｒａｍｅ９６インスタンスへ通されるのが好ましい。ｉｆｒａｍｅ９６インスタンスは、要求に関連したソース及びターゲット起点の独特の組み合わせに基づいて選択され、ターゲット起点は、この場合も、サービスゲートウェイサーバー４２の起点に対応する。本発明の好ましい実施形態では、ｉｆｒａｍｅ９６インスタンスは、必要に応じて生成され、そしてウェブページ５４又はウェブブラウザクライアント５２が閉じるまで持続するのが好ましい。ソース及びターゲット起点の組み合わせに対するｉｆｒａｍｅがまだ生成されない場合には、ポストメッセージ層７４がそれに対応するｉｆｒａｍｅ９６を生成し、そしてゲートウェイサーバー４２とのプリフライト要求／応答トランザクションを通して、ｉｆｒａｍｅ９６インスタンスにより信頼関係が確立される。
【００４０】
ゲートウェイサーバー４２の観点から、プリフライト要求の発生は、標準的なＣＯＲＳプリフライト要求と一貫したものであり、従って、ＣＯＲＳ適合ウェブブラウザをゲートウェイサーバー４２と相互動作させることができる。信頼関係を確立する一部分として、通信ブリッジルーチンがゲートウェイサーバー４２からｉｆｒａｍｅ９６インスタンスへダウンロードされ、ｉｆｒａｍｅ９６インスタンス内でポストメッセージＡＰＩのターゲット側を具現化する。信頼関係により、開始するポストメッセージ要求に対応するＸｍｌＨｔｔｐＲｅｑｕｅｓｔは、次いで、ゲートウェイサーバー４２へ送信され、そしてターゲットサーバー３６のようなサービスサーバーへ適宜に転送される。本発明の好ましい実施形態では、ゲートウェイサーバー４２を通してアクセスできる他のターゲットサーバー３６、３８によって提供されるサービスを定義するために、ゲートウェイサーバー４２にマッピングが管理上確立される。従って、ポストメッセージ要求がウェブソケット要求を表す場合には、典型的な結果として、ドキュメント９２から、それに対応するｉｆｒａｍｅ９６インスタンス、ゲートウェイサーバー４２を経て、ドキュメント９２へのリアルタイム非同期データソースとして働くターゲットサーバー３６により典型的に提供されるリモートサービスへ、両方向可能な接続が確立される。
【００４１】
ソース起点の検証は、ゲートウェイサーバー４２によって行われるのが好ましい。ＪａｖａＳｃｒｉｐｔ（登録商標）エミュレーション環境では、ゲートウェイサーバー４２は、受け取られた各要求が、ゲートウェイサーバー４２のターゲット起点に一致する値を有するＸＭＬＨｔｔｐＲｅｑｕｅｓｔ“リファラ”ヘッダと、許されたソース起点の値を有するＸＭＬＨｔｔｐＲｅｑｕｅｓｔ“Ｘ−起点”ヘッダとを含むことを検証する。好ましくは、“Ｘ−起点”ヘッダの値は、ゲートウェイサーバー４２からｉｆｒａｍｅ９６インスタンスへダウンロードされる通信ブリッジルーチンにより決定される。ゲートウェイサーバー４２は、通信ブリッジルーチンを発生し、そして通信ブリッジルーチンは、ウェブブラウザクライアント５２からのｉｆｒａｍｅ９６インスタンスを含むドキュメント９２のソース起点を決定するので、“Ｘ−起点”ヘッダの値は、ゲートウェイサーバー４２により、要求のソース起点を正確に識別すると信用される。
【００４２】
フラッシュ及びシルバーライトのような他のクライアント側アプリケーション具現化技術については、同様のエミュレーションアーキテクチャーが使用される。一般的に、ポストメッセージ９４は、識別された技術に基づき、ベースドキュメント９２内に、ｉｆｒａｍｅ９６と同様の対応サブウインドウを生成する。ウインドウを初期化すると、ドキュメント又は等効物が、プリフライト要求／応答トランザクションの一部分又は等効物としてゲートウェイサーバー４２から参照され及び検索される。その検索されたドキュメントは、本発明の好ましい実施形態では、ポストメッセージＡＰＩのターゲット側を具現化する通信ブリッジルーチンを機能的に含み、これにより、必要に応じて、ベースドキュメント９２とサブウインドウドキュメントとの間にセキュアな通信経路を許す。
【００４３】
ゲートウェイサーバー４２との信頼関係を確立する好ましいプロセス１１０が図７に一般的に示されている。ウェブブラウザクライアント５２のユーザによって典型的に開始される従来のページ要求１１２に応答して、要求１１２で示すように、ロードページ要求が起点サーバー３４へ発行される。それに対応するページがロードされ（１１４）、そして最初に評価され（１１６）、ページにより要求される付加的なオブジェクトを探索しロードする。本発明の好ましい実施形態では、クライアントライブラリ５６へのページ埋め込み参照により、埋め込み参照識別ゲートウェイサーバー４２から本質的にスタティックなリソースロード１１８が生じる。ウェブブラウザクライアント５２は、ロードされたページに関連した初期化１２０を完了し、これは、クライアントライブラリ層７０のウェブブラウザクライアントへのエミュレーションインターセプトを検出し及び確立するためのクライアントライブラリの必須の初期化を含む。
【００４４】
典型的に、あるユーザ対話１２２、又はドキュメント９２の自律的動作から生じる開始イベントに応答して、ウェブソケット、バイトソケット、クロス起点要求、又は他の要求がクライアントライブラリ層７０に対してなされる。例示上、この要求は、ドキュメント９２により表されるＪａｖａＳｃｒｉｐｔ（登録商標）クライアントアプリケーションから発生するウェブソケット要求である。この要求は、更に、ゲートウェイサーバー４２により提供される特定のサービスへの接続を要求するものとして特定される。この要求は、ポストメッセージ層７４へと処理される（１２４）。本発明の好ましい実施形態によれば、適当なｉｆｒａｍｅ９６インスタンスがまだ存在しない場合に、ウェブページベースドキュメント５４のソース起点を識別する機能的ソース起点、及びサービスの有効な位置を識別する機能的ターゲット起点を伴うｉｆｒａｍｅが生成される。ＪａｖａＳｃｒｉｐｔ（登録商標）におけるｉｆｒａｍｅの生成は、例えば、次のコードで具現化することができる。
【００４５】
ｉｆｒａｍｅの機能的ソース起点は、明確にセットされず、通信ブリッジルーチンにより、ウェブブラウザクライアント５２へのコールによって自動的に決定される。このコールは、ｉｆｒａｍｅ９６インスタンスの生成に続く通信ブリッジルーチンの初期化中及びｉｆｒａｍｅ９６インスタンスへの通信ブリッジルーチンのダウンロード中に行われるのが好ましい。従って、ｉｆｒａｍｅ９６インスタンスの機能的ソース起点は、ｉｆｒａｍｅ９６インスタンスの生成の役割を果たすドキュメント９２のソース起点、例えば、“ｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍ：８０”として決定される。機能的ターゲット起点は、“ｓｒｃ”属性を、例えば、“ｈｔｔｐ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０”として明確に使用して特定される。
【００４６】
好ましくは、開始ポストメッセージ要求の当該ソース及びターゲット起点、並びに要求されたサービス、を識別するプリフライトＸｍｌＨｔｔｐＲｅｑｕｅｓｔメッセージは、指定されたゲートウェイサーバー４２へ送信される（１２６）。ゲートウェイサーバー４２における管理上確立されるサービスアクセスポリシーが要求に対して評価される。本発明の好ましい実施形態では、ポリシーが一般的に次の形態をとる。
【００４７】
従って、サービス“／ｇｗＳｔｏｃｋＳｅｒｖｉｃｅ”のための“ｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍ：８０”から“ｗｓ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０”への特定のクロス起点リソース要求は、受け容れできると決定される。この要求は、更に、例えば、リモートターゲットサーバー３６により提供される実際のサービスソース“ｔｃｐ：／／ｔａｒｇｅｔ．ｃｏｍ：１３３０／ｓｔｏｃｋＳｅｒｖｉｃｅ”へのＴＣＰベースのウェブソケット接続を確立して、ゲートウェイサーバー４２によるオンデマンド生成によってサポートされる。本発明の好ましい実施形態では、ウェブブラウザクライアントアプリケーション９２により要求できる種々のサービスがゲートウェイサーバー４２において直接ホストされる。サービスアクセスポリシーにより特定される接続は、このようなケースでは、ローカルホストへの接続参照である。
【００４８】
サービスアクセスポリシーの評価に基づき、確認メッセージが返送される（１２８）。何らかの理由でサービス接続が許されない場合には、発生する要求１２４が本質的に失敗となる。ウェブソケット接続に必要なエミュレートサポートは、それが許される場合に、初期化される（１３０）。本発明の好ましい実施形態では、これは、次のＪａｖａＳｃｒｉｐｔ（登録商標）に一般的に例示するように、到来する要求イベントを取り扱うためのポストメッセージリスナーをｉｆｒａｍｅ９６インスタンス内にインストールすることを含む。
【００４９】
ウェブソケット要求１２４に対応するポストメッセージ要求は、次いで、ＸｍｌＨｔｔｐＲｅｑｕｅｓｔへ機能的に変換される。より詳細には、ＨＴＭＬ５適合ポストメッセージ要求は、ベースウェブページ５４ドキュメント内で、ターゲットドキュメントを表すウインドウにおいてコールされる。この要求は、ポストメッセージデータとして表されるメッセージ、及び要求のソース起点を通す。ｉｆｒａｍｅ９６インスタンスがそれ以前に確立される場合には、ポストメッセージ要求がポストメッセージ７４ ＡＰＩに通される。
【００５０】
この要求は、次いで、ゲートウェイサーバー４２へ送信され、そしてサービスアクセスポリシーに基づいて資格付けがなされる。ゲートウェイサーバー４２は、次いで、識別されたターゲットサーバー３６との対応接続１３４を確立する。接続１３４の性質は、要求されたサービスの性質に依存し、例えば、ＴＣＰ又はウェブソケット接続でよい。ＸｍｌＨｔｔｐＲｅｑｕｅｓｔに対する応答が受け取られて、ｉｆｒａｍｅチェーンを通して戻され、応答データペイロードをベースウェブページ５４ドキュメントへ返送する。その後のウェブソケット要求１２４は、ｉｆｒａｍｅ９６インスタンスを再使用し、それにより、ソース及びターゲット起点間に確立される信頼関係のレバレッジ使用をなす。
【００５１】
他のウェブブラウザクライアントアプリケーション９２技術に関しては、ベースページ５４との対話が制限される。図８Ａに一般的に示されるように、ウェブブラウザベースページ５４は、そのベースページ５４に埋め込まれた別のウェブブラウザクライアントアプリケーション９２との必須の対話がもしあっても制限した状態で、カプセル化フラッシュ、シルバーライト、又は他のアプリケーション１５２を埋め込むことができる。本発明の好ましい実施形態では、このようなカプセル化アプリケーション１５２は、ゲートウェイサーバー４２からのリソース１１８としてロードされる。
【００５２】
フラッシュカプセル化アプリケーション１５２のケースでは、フラッシュプラグインの一部分として与えられるフラッシュランタイムライブラリは、一般的な所有権ネットワーク及びソケット状通信能力を含む。クライアントライブラリ５６は、カプセル化アプリケーション１５２の一部分として含まれ、カプセル化アプリケーション１５２がゲートウェイサーバー４２の外部サービスと直接通信できるようにするのが好ましい。
【００５３】
本発明の好ましいフラッシュ実施形態は、クロス起点リソースシェアリングでのフラッシュアプリケーション実行をサポートする。図８Ｂを参照すれば、ソース起点サーバー３４からロードされたドキュメント９２は、これもソース起点サーバー３４からロードされたフラッシュクライアントアプリケーション１５６に対する参照を含む。それ故、ウェブブラウザクライアント５２により実行されるフラッシュクライアントアプリケーション１５６は、ドキュメント９２のソース起点及びソース起点サーバー３４内で実行される。従って、フラッシュクライアントアプリケーション１５６は、ゲートウェイサーバー４２からロードされることが更に特定されるフラッシュブリッジアプリケーション１５８に対する参照を含む。それ故、フラッシュブリッジアプリケーション１５８は、ゲートウェイサーバー４２のターゲット起点内で実行される。
【００５４】
フラッシュクライアント及びブリッジアプリケーション１５６、１５８は、ＳＷＦファイルフォーマットドキュメントとしてロードされたフラッシュ移動ファイルとして具現化されるのが好ましい。フラッシュクライアントアプリケーション１５６は、クライアントライブラリ５６を含むのが好ましい。本発明により、ｉｆｒａｍｅを通してのポストメッセージ通信と同様に、フラッシュクライアントとブリッジアプリケーション１５６、１５８との間にセキュアな通信能力が確立される。このチャンネルは、フラッシュランタイムライブラリを通してサポートされる共有イベントを使用して確立され、従って、データを両方向にディスパッチできるのが好ましい。この通信チャンネルは、フラッシュブリッジアプリケーション１５８が、実行を通して、ゲートウェイサーバー４２により資格付けされたソース起点で識別されたフラッシュクライアントアプリケーション１５６を検証しそしてそれのみと通信することを要求することにより、ソース及びターゲット起点の独特の組み合わせに固定される。この通信チャンネルの初期化において、フラッシュクライアントアプリケーション１５６のソース起点は、フラッシュブリッジアプリケーション１５８によりフラッシュクライアントアプリケーション１５６のＬｏａｄｅｒＩｎｆｏメタデータから検索される。このソース起点は、ゲートウェイサーバー４２へ返送される。ゲートウェイサーバー４２に対してローカルの管理上確立されたセキュリティポリシーの評価において起点が許可されたとすれば、フラッシュブリッジアプリケーション１５８は、返送メッセージにより、フラッシュクライアントアプリケーション１５６との共有イベント通信に対してイネーブルされる。フラッシュクライアントアプリケーション１５６により具現化されたクライアント側ウェブアプリケーションは、例えば、ターゲットサーバー３６により提供されるリモートサーバーにアクセスするため、必要に応じて、ゲートウェイサーバー４２のクロス起点にアクセスすることができる。
【００５５】
或いは又、フラッシュクライアントアプリケーション１５６は、ウェブソケット接続を使用してゲートウェイサーバー４２と直接通信することができる。ネーティブウェブソケット接続が望まれる場合には、フラッシュブリッジアプリケーションは、ターゲットゲートウェイサーバー４２へウェブソケット要求を発行するように試みる。フラッシュブリッジアプリケーション１５８を通して通信するのではなく、フラッシュクライアントアプリケーション１５６の初期実行は、フラッシュクライアントアプリケーション１５６の一部分として与えられるクライアントライブラリ５６を通してウェブソケット接続要求を発行する。この接続要求は、ゲートウェイサーバー４２とのソケットベース接続を要求するためにフラッシュランタイムを使用してエミュレートされる。次いで、フラッシュクロスドメインポリシーファイルが、意図されるウェブソケット接続のターゲット起点から検索される。ゲートウェイサーバー４２は、特に、そのような要求を聴取し、そして有効フラッシュクロスドメインポリシーファイルを返送するように構成されるのが好ましい。フラッシュクライアントアプリケーション１５６の基礎となるフラッシュランタイムは、ポリシーを評価し、そしてターゲット起点とのクロス起点ウェブストック接続が許されるかどうか決定する。
【００５６】
規範的なクロスドメインポリシーファイルは、次の通りである。
【００５７】
フラッシュランタイムが適合ポリシーファイルを受け取りそしてフロムドメイン(from-domain)がフラッシュクライアントアプリケーション１５６のソース起点に一致するとすれば、ランタイムは、クライアントライブラリがソケットを指定のポートにおいてターゲット起点へとオープンしそしてネーティブウェブソケットプロトコルを経て通信するのを許す。ウェブソケットプロトコルハンドシェークの一部分として、ターゲット起点のクッキーを送信することも要求される。しかしながら、ネーティブソケット接続は、デフォールトによりクッキーを送信せず、従って、ターゲットドメインに取り付けられたクッキーを発見するために最小のＨＴＴＰ要求もターゲットゲートウェイに送信される。クッキーは、ＨＴＴＰ応答からパースされ、ウェブソケットハンドシェーク通信に含まれる。
【００５８】
デスクトップ及びアプレットＪａｖａ（登録商標）クライアントにおけるクロス起点通信の具現化は、同様のクライアントアプリケーション１５６及びブリッジアプリケーション１５８アーキテクチャーを使用するのが好ましい。Ｊａｖａ（登録商標）クライアントアプリケーション１５６については、アプリケーションコードが、ソース起点サーバー３４から、好ましくはクライアントライブラリ５６のＪａｖａ（登録商標）具現化を含む.ｊａｒファイルにおいてロードされる。従って、Ｊａｖａ（登録商標）クライアントアプリケーション１５６は、ドキュメント９２のソース起点にある。初期実行において、Ｊａｖａ（登録商標）クライアントアプリケーション１５６は、.ｊａｒファイルとしても与えられるブリッジアプリケーション１５８をゲートウェイサーバー４２からロードするための要求をなす。ブリッジアプリケーション１５８のロードは、許される。その実行は、ターゲット領域で行われる。
【００５９】
Ｊａｖａ（登録商標）クライアントランタイムは、ソケット及びＨＴＴＰ要求ライブラリ具現化を含む。ネーティブなウェブソケットプロトコル接続が望まれる場合には、ブリッジアプリケーション１５８は、ゲートウェイサーバー４２へのソケット接続をなすことができる。そうではなくて、例えば、介在するプロキシーサーバーを横断するために要求されるように、エミュレートされたウェブソケットプロトコルが必要となる場合には、ランタイムＨＴＴＰ要求ライブラリが使用される。
【００６０】
異なる起点からのコードを、非セキュアな仕方で相互作用しないよう分離するために、Ｊａｖａ（登録商標）ランタイムは、異なる起点からのクラスを異なる「クラスローダ」にロードする。デフォールトにより、１つのクラスローダにロードされたコードは、別のクラスローダにロードされたコードにアクセスしたり又はそれを実行したりすることができない。しかしながら、ランタイムシステムのコアであるコードは、特殊な「ランタイムクラスローダ」にロードされ、これは、他のコードにより安全にアクセスすることができる。Ｊａｖａ（登録商標）クライアントとブリッジアプリケーションとの間の通信チャンネルをポストメッセージアナログコードとしてクライアントライブラリ５６に生成するために、クライアント及びブリッジの両.ｊａｒは、コアＪａｖａ（登録商標）ランタイムの一部分として存在するインターフェイス又は拡張可能なクラスをインスタンス生成する。ランタイムクラスローダにロードされるこのクラスは、Ｊａｖａ（登録商標）クライアントアプリケーション１５６及びＪａｖａ（登録商標）ブリッジアプリケーション１５８の両方にアクセスすることができる。この目的に使用できる規範的なクラスは、標準的Ｊａｖａ（登録商標）クラス“ｊａｖａ（登録商標）．ｂｅａｎｓ．ＰｒｏｐｅｒｔｙＣｈａｎｇｅＳｕｐｐｏｒｔ”である。このクラスは、全ての実行環境においてＪａｖａ（登録商標）ランタイムに得ることができ、従って、セキュリティの例外を招くことなくＪａｖａ（登録商標）クライアントアプリケーション１５６及びＪａｖａ（登録商標）ブリッジアプリケーション１５８によってコールすることができる。ＰｒｏｐｅｒｔｙＣｈａｎｇｅＳｕｐｐｏｒｔクラス、及び他のそのようなクラスは、任意のデータを両方向に通過できる拡張又は具現化を許すに充分なほど一般的である。
【００６１】
他のクライアントランタイム環境でも要求されるように、ターゲット通信の報告されるソース起点は、正確であり、且つ改竄から保護されねばならない。正確さを確保するために、Ｊａｖａ（登録商標）ブリッジアプリケーション１５８は、Ｊａｖａ（登録商標）ランタイム環境へのコールを具現化し、Ｊａｖａ（登録商標）クライアントアプリケーション１５６のソース起点を決定する。特に、Ｊａｖａ（登録商標）ブリッジアプリケーション１５８は、Ｊａｖａ（登録商標）クライアントアプリケーション１５６の.ｊａｒファイル内に存在することが分かっている.ｃｌａｓｓファイルをロードするためのコールをなす。例えば、この.ｃｌａｓｓファイルが“ＳｏｕｒｃｅＯｒｉｇｉｎＬｏｃａｔｉｏｎ．ｃｌａｓｓ”と命名された場合には、Ｊａｖａ（登録商標）ブリッジアプリケーション１５８は、クラスをロードするために次のコールを行う。
【００６２】
返送されるＵＲＬ値は、ロードされた.ｃｌａｓｓファイルの起点、ひいては、ソース起点の識別を含む。例えば、Ｊａｖａ（登録商標）クライアントアプリケーション１５６の.ｊａｒファイルの名前が“ｃｌｉｅｎｔ．ｊａｒ”である場合には、返送されるＵＲＬが次の形態となる。
【００６３】
それ故、“ｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍ：８０”は、Ｊａｖａ（登録商標）クライアントアプリケーション１５６のソース起点である。このソース起点は、次いで、任意の接続中にゲートウェイサーバー４２へ送られ、ゲートウェイサーバー４２がこのソース起点からのクロス起点接続を確認し、選択的に許すことができるようにする。Ｊａｖａ（登録商標）クライアントランタイムは、それ自身、クラスロード中に正しいリソースストリングを返送することに信頼があるので、ソース起点値も信頼がある。
【００６４】
本発明の好ましい実施形態において対処されるシルバーライトカプセル化アプリケーション１５２のケースには、制限が存在する。要するに、シルバーライトランタイムによりサポートされる起点セキュリティ範囲は、広く配布されるウェブアプリケーションに関連した実際の使用に対して充分な仕様を与えない。この制限は、本発明の好ましい実施形態では、カプセル化アプリケーション１５２の設定中のクロス起点通信ポリシーを資格付けすることで管理される。図９を参照すれば、典型的にあるユーザ対話１６２に応答して、カプセル化シルバーライトアプリケーション１５２は、ウェブソケット要求１６４として表されたシルバーライトサービス要求を、クライアントライブラリ５６を通して処理する。本発明の好ましい実施形態において具現化されるように、２つのヘッダがウェブソケット要求１６４に自動的に追加される。又、本発明の好ましい実施形態では、ヘッダは、次のように特定される。
【００６５】
ここで、第１のヘッダは、有効なソース起点を識別し、そして第２のヘッダは、ソース起点をエンコードする動的に発生されるヘッダである。ゲートウェイサーバー４２に向けられたウェブソケット要求１６４を処理する際に、シルバーライトランタイムは、クロス起点通信の試みを認識する。次いで、シルバーライトランタイムは、プリフライト要求１６６を開始して、クライアントアクセスポリシーを検索する。プリフライト要求は、慣習によれば、特に命名された“ｃｌｉｅｎｔａｃｃｅｓｓｐｏｌｉｃｙ．ｘｍｌ”ドキュメントを検索するために起点ルートに向けられる。従って、定義されたターゲット起点がｈｔｔｐ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０である場合には、ドキュメント要求は、ｈｔｔｐ：／／ｇａｔｅｗａｙ．ｃｏｍ：２７５０／ｃｌｉｅｎｔａｃｃｅｓｓｐｏｌｉｃｙ．ｘｍｌに向けられる。ゲートウェイサーバー４２は、シルバーライトアクセスの予想において、そのような要求を聴取し、そしてカスタマイズされたクライアントアクセスポリシー１６８で応答し、ゲートウェイサーバー４２に、クロス起点アクセスを許すサービスアクセスポリシーをもたせる。即ち、要求のソース起点が、サービスアクセスポリシーの＜ｃｒｏｓｓ−ｓｉｔｅ−ｃｏｎｓｔｒａｉｎｔ＞エントリーに対してチェックされる。この制約を満足すると、ｃｌｉｅｎｔａｃｃｅｓｓｐｏｌｉｃｙ．ｘｍｌドキュメントが動的に発生されそして返送される（１６８）。クライアントアクセスポリシーは、一般的に、次の形態となる。
【００６６】
ドメインｈｔｔｐ：／／ｒｅｔａｉｌｅｒ．ｃｏｍから、サブ経路を含む経路／ｍｙＳｅｒｖｉｃｅへの有効な要求は、２つのヘッダ値Ｘ−Ｏｒｉｇｉｎ及びＸ−Ｏｒｉｇｉｎ−ｈｔｔｐ％３Ａ％２Ｆ％２Ｆｒｅｔａｉｌｅｒ．ｃｏｍ％３Ａ８０を含むことが許されることが明記される。このクライアントアクセスポリシーは、シルバーライトカプセル化アプリケーション１５２への参照と共にシルバーライトランタイムに登録される。その結果、本発明によれば、シルバーライトカプセル化アプリケーション１５２は、ヘッダを全シルバーライト要求の一部分として与え、そしてゲートウェイサーバー４２は、両ヘッダを有するシルバーライト要求だけを受け容れる。プリフライトトランザクション１６６、１６８の一部分としてのクライアントアクセスポリシーの動的な発生及びアプリケーションは、そのような要求を許し通過させるためにシルバーライトランタイムの動作を資格付けする。シルバーライトランタイムは、非適合ヘッダを有する要求を阻止し続ける。ゲートウェイサーバー４２は、適合ヘッダをもたないシルバーライト要求は許さない。
【００６７】
図１０を参照すれば、ゲートウェイサーバー４２の好ましい具現化１９０が示されている。好ましい実施形態において、ゲートウェイサーバー４２は、ウェブブラウザクライアント３２及び種々の起点サーバー３４、３６、３８へのネットワーク接続をサポートするように構成された従来のウェブサーバーシステムにおいて具現化される。機能的に、クライアントネットワークインターフェイス１９２は、ウェブブラウザクライアント３２とのネットワーク接続１９４をサポートする。クライアントライブラリ５６から発信する要求は、ゲートウェイサーバー４２により実行されるアプリケーションサーバー内にホストされるイベント駆動モジュールとして具現化されるのが好ましいエミュレーションサポートプロセッサ１９６に向けられる。最初に処理される要求は、次いで、ネーティブウェブソケットライブラリ１９８を通して具現化され、このライブラリは、サービスネットワークインターフェイス２００を通して、要求されたウェブソケット両立性サービスを提供するリモート起点サーバー３６、２８へ至るＴＣＰ及び他のネットワーク接続２０２を確立することができる。
【００６８】
又、ゲートウェイサーバー４２によりホストされるアプリケーションサーバー内のイベント駆動モジュールとして実行されるサービスアクセスプロセッサ２０４は、エミュレーションサポートプロセッサ１９６により受け取られる要求を評価し、資格付けする。フラッシュ及びシルバーライトプリフライト動作中に発行されるクライアントアクセス要求は、ソケットポリシープロセッサ２０６により受け取られて取り扱われる。サービスアクセスプロセッサ２０４は、フラッシュ及びシルバーライトプリフライト要求において識別される起点を資格付けするために、必要に応じて、ソケットポリシープロセッサ２０６によりアクセスされる。
【００６９】
ゲートウェイサーバー４２、特に、エミュレーションサポートプロセッサ１９６は、サービス要求のリダイレクションをサポートするのが好ましい。サービスアクセスプロセッサ２０４は、サービス要求を資格付けするのに加えて、サービスターゲットのリダイレクションを指定する。名目上、このようなリダイレクションは、サービス要求に応答して従来のＨＴＴＰ３０Ｘを返送することにより具現化される。しかしながら、ゲートウェイサーバー４２とのウェブソケット通信に対してｉｆｒａｍｅ９６インスタンスを使用する本発明の実施形態は、そのようなリダイレクション要求を取り扱う上で制限がある。より詳細には、ｉｆｒａｍｅ９６インスタンスは、ｉｆｒａｍｅ９６インスタンスの生成中に確立されたターゲット起点の範囲外の起点へのリダイレクションを取り扱うことができない。カプセル化プログラム１５２を具現化するのに使用される他の技術は、リダイレクション要求を自動的に取り扱う上で同様に制限がある。
【００７０】
その影響を受ける好ましい実施形態では、図１１に示す別のリダイレクション処理フロー２１０を使用するのが好ましい。明瞭化のために、リダイレクション処理フロー２１０は、Ｊａｖａｓｃｒｉｐｔ（登録商標）具現化に特定して説明する。上述したように、ウェブソケット要求２１２は、クライアントライブラリ５６のポストメッセージ層７４を通るポストメッセージ要求２１４及びそれに対応するｉｆｒａｍｅ９６インスタンス２１６として処理される。対応サービスに対する要求２１８は、ゲートウェイサーバー４２へとなされる。名目上、その要求は、リモートターゲットサーバー３６、３８上の要求されたサービスへの接続２２０により取り扱われる。
【００７１】
そうではなくて、ゲートウェイサーバー４２のインスタンス２１８は、異なるゲートウェイサーバー４２のインスタンス２２２へのリダイレクションが適当であることを決定することがある。この決定は、ローカルの管理上確立されるサービスアクセスポリシーの評価に基づいて行われ、そしてリダイレクションターゲットゲートウェイサーバー４２のインスタンス２２２を識別するのが好ましい。リダイレクションは、ｉｆｒａｍｅ２１６へ返送されるサービスリダイレクト２２４メッセージの生成により具現化されるのが好ましい。サービスリダイレクト２２４メッセージは、ＨＴＴＰ ３０Ｘリダイレクションメッセージを包むＨＴＴＰ ２０Ｘメッセージとして特に与えられる。ｉｆｒａｍｅ２１６は、明確なＨＴＴＰ ３０Ｘメッセージの取り扱いに失敗することがあるが、リダイレクションがクロス起点である場合には、ｉｆｒａｍｅ２１６は、ＨＴＴＰ ２０Ｘメッセージを受け取り、そしてそこに含まれたペイロードデータを適合応答として発信ポストメッセージ要求２１４へ返送することができる。ポストメッセージ層７４は、更に、メッセージペイロードを評価のためにウェブソケットエミュレーション層８０へ返送する。返送されるメッセージペイロードがＨＴＴＰ ３０Ｘリダイレクションに対応する特定のケースでは、ウェブソケットエミュレーション層８０は、ＨＴＴＰ ３０Ｘリダイレクションメッセージにより指定されるリダイレクションターゲットゲートウェイサーバー４２のインスタンス２２２へポストメッセージ要求２１４を再発行することにより、リダイレクションディレクティブをエミュレートする。ゲートウェイサーバー４２のインスタンス２２２のターゲット起点に対応するｉｆｒａｍｅ９６インスタンス２２６が使用される。ゲートウェイサーバー４２のインスタンス２２２が更なるリダイレクションを遂行しなければ、リモートターゲットサーバー３６、３８上の要求識別サービスへの接続２２８がなされる。
【００７２】
一般的に同等のリダイレクション処理フロー２１０は、Ｊａｖａ（登録商標）、フラッシュ及びシルバーライトのような他の具現化技術に対して具現化される。これらのケースにおいて該当する場合には、ブリッジアプリケーション１５８インスタンスは、定義されたターゲット起点に制限され、従って、リダイレクション要求の即座の取り扱いを除外する。包まれたＨＴＴＰ ３０Ｘリダイレクションメッセージは、この場合も、ブリッジアプリケーション１５８インスタンスに与えられ（２２４）、コンテンツをクライアントアプリケーション１５６へ返送してクライアントアプリケーション１５６内でウェブソケットエミュレーション層８０により取り扱いできるようにするのが好ましい。
【００７３】
ｉｆｒａｍｅ９６又はブリッジアプリケーション１５８インスタンスにおいて即座に取り扱う上で問題となる他の応答メッセージは、リダイレクション処理フロー２１０と同様に取り扱いできることが明らかである。即ち、このような問題応答は、ＨＴＴＰ ２００応答メッセージで包まれ、その包囲された応答メッセージをドキュメント９２又はクライアントアプリケーション１５６により取扱できるようにする。
【００７４】
ウェブブラウザクライアント５２とゲートウェイサーバー４２との間にエミュレートされたウェブソケット接続を確立する好ましいプロセス２４０が図１２に示されている。クライアント側ウェブソケットエミュレーション、又はクライアントライブラリ５６に対する同様の要求２４２に応答して、最初にゲートウェイサーバー４２に対してＨＴＴＰ接続２４４がなされる。しかしながら、この接続２４４は、ゲートウェイサーバー４２によって閉じられず、オープンに維持され（２４６）、そして両方向ウェブソケット通信セッションの半分の有効なエミュレーションにおいてゲートウェイサーバー４２からウェブクライアントブラウザ５２へ下流にデータを送信するのに使用される。接続２４４を経て与えられるサービス要求は、要求されたサービスを有効にホスティングするものとして識別された適当なリモートターゲットサーバー３６との従来の両方向性ＴＣＰベースウェブソケット接続２４８を確立するために、ゲートウェイサーバー４２により使用されるのが好ましい。接続２４８が確立されると、それに対応するサービス２５０は、オープン接続２４６を経て中継されるサーバー送信イベントの非同期シリーズとしてデータを選択して送信することができる。
【００７５】
好ましくは、あるユーザイベント２５２に応答して生じるか又はクライアント側ウェブアプリケーション２５４の自律的実行に基づいて生じる上流通信は、個別のＨＴＴＰ接続２５６を経て、ゲートウェイサーバー４２へＸｍｌＨｔｔｐＲｅｑｕｅｓｔとして送られるクロス起点リソース要求として送信される。この要求は、サーバー送信イベントメッセージシンタックスを使用してエミュレーションにおいて送信されるのが好ましい。この好みは、主として、両方向通信を取り扱う上での一貫性のためであり、そして更に、サーバー送信イベント層７８の信頼性ある配信メッセージメカニズムに基づいてウェブソケットを通して信頼性あるメッセージ配信を行えるようにする。即ち、好ましい実施形態では、エミュレートされたサーバー送信メッセージシンタックスは、受信確認のために追跡されるイベントＩＤを含む。サーバー送信イベントメッセージは、それに対応する確認メッセージが受信されるまでバッファされ、メッセージ配信失敗の環境又は見掛け上の環境において再送信を行えるようにするのが好ましい。接続２５６を通して受け取られた上流メッセージは、サービス２５０による考慮及び適当な応答のためにゲートウェイサーバー４２により両方向ウェブソケット接続２４８を通してルーティングされる。
【００７６】
上流通信は、典型的に、その数が制限され、短いメッセージになる傾向がある。これは、従来のウェブブラウザクライアントにおいて具現化される同時接続制限と組み合わされて、ウェブブラウザクライアントからゲートウェイサーバー４２への過渡的な上流接続を使用する好みを生じる。エミュレーションのもとでは、下流接続２４６のみが持続的通信接続として維持されるのが好ましい。
【００７７】
従来のネーティブウェブソケット接続の性質により、プロキシー及び他の中継サーバーの存在は、ウェブソケット接続の経路において許容される。本発明の好ましい実施形態では、ウェブソケットエミュレーション層８０は、ゲートウェイサーバー４２との組み合わせにおいて、下流接続２４６の状態の機能的監視を具現化して、下流接続２４６の経路におけるプロキシー又は他のサーバーの存在又は問題の振舞いを検出するのが好ましい。図１３を参照すれば、プロキシーサーバーの潜在的な存在を許容する本発明のオペレーション２７０が示されている。ウェブソケット接続を開始する要求２４２は、プロキシーサーバー２７４へのルーティングを引き起こす上流へのＨＴＴＰ接続を生じさせる。次いで、それに対応するＨＴＴＰ接続２７６が生成されて、ゲートウェイサーバー４２へルーティングされる。上述したように、この接続は、終了せず、接続２７８としてオープンに維持される。介在するプロキシーサーバー２７４は、典型的に、それに対応する接続２７８’をオープンに維持するが、プロキシーサーバー２７４の厳密な振舞いは、プロキシーサーバー２７４のローカル構成により決定される。ゲートウェイサーバー４２は、接続２７８をオープンに維持するが、プロキシーサーバー２７４は、下流送信データをバッファするか、又は構成ポリシーの問題として、接続２７８”を完全に終了させる。いずれにせよ、ウェブブラウザクライアントは、プロキシーサーバー２７４により決定される任意の待ち時間又は全データ配信の終了を受ける限定されたデータを受け取る。
【００７８】
本発明によれば、ゲートウェイサーバー４２は、オープンの下流接続２７８がスレッシュホールド期間より長くアイドル状態になったときにその接続を通して心鼓動パケットを自律的に送信する。ここに示す好ましい実施形態では、心鼓動スレッシュホールドは、５秒である。ウェブソケットエミュレーション層８０が心鼓動周期を越えて接続２７８”を通してデータを受信し損なうと、プロキシーサーバーの存在が仮定され、そして接続２７８”がプロキシーサーバー２７４により終了されないとすれば、接続２７８”を経て上流へ切断が送られる。この切断は、プロキシーサーバー２７４により保持されたバッファデータのフラッシュを生じさせる。好ましくは、ＨＴＴＰＳプロトコルを使用してゲートウェイサーバー４２への新たな接続２８０が確立される。接続２８０は、この場合も、持続的な下流接続２８２としてオープンに保たれる。ＨＴＴＰＳプロトコルを使用する接続は、デフォールトでは、好ましいものではない。というのは、接続を確立しそれを通してデータを処理ためにウェブブラウザクライアント５２及びゲートウェイサーバー４２の両方に大きなオーバーヘッドがかかるためである。しかしながら、ＨＴＴＰＳ接続は、介在するプロキシーサーバー２７４が検出される場合には、好ましいものである。というのは、プロトコルが、バッファも中断もせずに、ほぼ常時にプロキシーサーバー２７４を通過するからである。ＨＴＴＰＳ接続を確立できない場合には、長いポーリングへの後退が具現化されるのが好ましい。それ故、下流接続２８２は、プロキシーサーバー２７４が存在するときでも有効に持続維持することができる。接続失敗２７８”の場合に未確認のままであるサーバー送信イベントは、自動的に再送信される。ゲートウェイサーバーが上流接続制限を検出できるようにするため、好ましくはウェブソケットエミュレーション層８０において、ウェブブラウザクライアント５２で同様の心鼓動メカニズムが具現化されるのが好ましい。
【００７９】
従って、リアルタイムウェブアプリケーションにとって重要な両方向ウェブブラウザクライアント通信を達成するためのシステム及び方法が説明された。エミュレートされたウェブソケットサーバーシステムは、従来のｐｒｅ−ＨＴＭＬ５適合ウェブブラウザが、両方向全二重バイナリー及びテキスト通信を即座にサポートできるようにする。それ故、複雑な従来の分散型ウェブアプリケーションアーキテクチャーを回避することができる。むしろ、本発明を使用することにより、ウェブアプリケーションは、ＨＴＴＰ上のエミュレートされたウェブソケットを通して搬送されるネーティブプロトコルを使用してバックエンドサービスと直接通信することができる。
【００８０】
本発明の好ましい実施形態の以上の説明から、当業者であれば、ここに開示した実施形態の多数の変更や修正が容易に明らかとなろう。それ故、特許請求の範囲内で、本発明は、上述したものとは異なる仕方で実施されてもよいことが理解されよう。
【符号の説明】
【００８１】
１０：アプリケーション
１２、１４：従来のクライアントシステム
１６：通信ネットワーク
１８、２０、２２：リモートサーバーシステム
３２：クライアントシステム
３４：ソース起点サーバー
３６、３８：ターゲットサーバー
４０：クロスドキュメントメッセージングシステム
４２：ゲートウェイサーバー
５２：ウェブブラウザクライアントアプリケーション
５４：ウェブページドキュメント
５６：クライアントライブラリ
７０：ライブラリスタック
７２：ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ層
７４：ポストメッセージ層
７６：クロス起点リクエスト層
７８：サーバー送信イベント層
８０：ウェブソケットエミュレーション層
８２：バイトソケット層
８４：クライアントプロトコルライブラリ層
９２：実行可能なドキュメント
９４：ポストメッセージ要求
９６：ｉｆｒａｍｅ
【特許請求の範囲】
【請求項１】
ｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントにウェブアプリケーションサポートを与えて、ソースサーバーにより提供されるアプリケーションがターゲットサーバーにより提供されるサービスを利用できるようにする方法であって、前記ターゲットサーバーのサービスは、前記ソースサーバーのソース起点との通信に対してセキュアなターゲット起点から提供されるものであり、
ａ）定義されたソース起点を有するソース起点サーバーから受け取られるクライアント側ウェブアプリケーションをウェブブラウザクライアントにより実行する段階であって、要求識別ウェブアプリケーションサービスへの接続を要求する段階を含む当該実行段階と、
ｂ）前記ウェブブラウザクライアントによるエミュレーションクライアントライブラリの実行を通して、前記ウェブブラウザクライアントと、前記要求識別ウェブアプリケーションサービスにアクセスするためのゲートウェイサーバーとの間の両方向可能なＨＴＴＰベースの通信接続を第１に確立する段階であって、前記ゲートウェイサーバーは、前記定義されたソース起点の範囲外の定義されたターゲット起点に関連され、そして前記両方向可能なＨＴＴＰベースの通信接続は、前記定義されたソース起点と前記ターゲット起点との間にセキュアな通信経路を与えるクロス起点通信ブリッジを含むものである当該段階と、
ｃ）前記ゲートウェイサーバーを通して、前記要求識別ウェブアプリケーションサービスに対して規定の関係を有するターゲットサーバーにより提供されるターゲット定義サービスへのＨＴＭＬ５適合接続を第２の確立する段階と、
を含む方法。
【請求項２】
前記実行段階は、前記ウェブブラウザクライアントにより通信ブリッジプログラムを実行することを含み、前記通信ブリッジプログラムは、前記要求段階に応答して前記ゲートウェイサーバーから受け取られ、前記クライアント側ウェブアプリケーションは、前記定義されたソース起点内で実行され、前記通信ブリッジプログラムは、前記定義されたターゲット起点内で実行され、そして前記クロス起点通信ブリッジは、前記通信ブリッジプログラムと前記ウェブブラウザクライアントとの間に確立される、請求項１に記載の方法。
【請求項３】
前記ゲートウェイサーバーにより前記両方向可能なＨＴＴＰベースの通信接続を資格付けする段階を更に含み、前記要求は、前記定義されたソース起点及び前記要求識別ウェブアプリケーションサービスの識別を与え、そして前記ゲートウェイサーバーは、前記要求を受け入れるべきかどうか決定する、請求項２に記載の方法。
【請求項４】
前記資格付け段階は、サービスアクセスポリシーを評価して、前記定義されたソース起点と、前記要求識別ウェブアプリケーションサービスとの間の許された関係を決定する段階を含む、請求項３に記載の方法。
【請求項５】
前記資格付け段階は、前記要求識別ウェブアプリケーションサービスに対する前記既定の関係を決定する段階を含む、請求項４に記載の方法。
【請求項６】
前記ゲートウェイサーバーは、更に、前記要求をリダイレクトすべきかどうか決定し、前記資格付け段階は、ＨＴＴＰ応答メッセージに包まれたＨＴＴＰリダイレクションメッセージを返送し、前記ＨＴＴＰリダイレクションメッセージを前記クライアント側ウェブアプリケーションへ配信する、請求項３に記載の方法。
【請求項７】
前記エミュレーションクライアントライブラリは、ウェブソケットエミュレーション層を含み、前記第１に確立する段階は、前記ＨＴＴＰリダイレクションメッセージに応答して、前記要求識別ウェブアプリケーションサービスにアクセスするために前記ウェブブラウザクライアントとリダイレクションゲートウェイサーバーとの間に前記両方向可能なＨＴＴＰベースの通信接続を確立し、前記リダイレクションゲートウェイサーバーは、前記定義されたソース起点の範囲外の定義されたリダイレクションターゲット起点に関連される、請求項６に記載の方法。
【請求項８】
分散ウェブアプリケーションの実行をサポートするサーバーシステムであって、
ａ）ネットワークに結合されたソース起点サーバーシステムであって、これは、クライアント側ウェブアプリケーションを含み、そしてソース起点の範囲内で前記ネットワークを通してアクセスできるソース起点サーバーシステムと、
ｂ）前記ネットワークに結合されたゲートウェイサーバーシステムであって、これは、通信ブリッジプログラムを含み、ターゲット起点の範囲内で前記ネットワークを通してアクセスでき、そしてウェブアプリケーションサービスへネットワーク接続を与えるように動作するゲートウェイサーバーシステムと、
ｃ）前記ネットワークに結合されたクライアントシステムであって、これは、ウェブブラウザクライアントを実行するように動作でき、前記ウェブブラウザクライアントは、クロス起点メッセージを除外するｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントであり、前記ウェブブラウザクライアントは、前記クライアント側ウェブアプリケーションを前記ソース起点サーバーシステムダウンロードするように働き、更に、前記ウェブブラウザクライアントは、前記ソース起点の範囲内で前記クライアントシステム上の前記クライアント側ウェブアプリケーションを実行するように動作し、前記ウェブブラウザクライアントは、前記通信ブリッジプログラムを前記ゲートウェイサーバーシステムダウンロードするように動作し、前記ウェブブラウザクライアントは、更に、前記ターゲット起点の範囲内で前記クライアントシステム上の前記通信ブリッジプログラムを実行するように動作し、前記クライアント側ウェブアプリケーション及び前記通信ブリッジプログラムは、クロス起点通信チャンネルを具現化し、前記クライアント側ウェブアプリケーションは、更に、前記通信ブリッジプログラム及び前記ゲートウェイサーバーシステムを通して前記ウェブアプリケーションサービスクロス起点の要求を発行するように動作するようなクライアントシステムと、
を備えたサーバーシステム。
【請求項９】
前記クロス起点通信チャンネルは、フラッシュランタイムライブラリベースのネーティブ共有イベントを使用してデータを転送し、そして前記通信ブリッジプログラムは、フラッシュランタイムライブラリに関連したＬｏａｄｅｒＩｎｆｏメタデータを使用して、前記ソース起点を決定する、請求項８に記載のサーバーシステム。
【請求項１０】
前記通信ブリッジプログラムの実行は、更に、前記ゲートウェイサーバーシステムに維持されたクライアントアクセスポリシーに基づいて前記ゲートウェイサーバーシステムにより条件付きで受け容れられるソース起点クライアントアクセス要求を前記ゲートウェイサーバーシステムに与えることにより前記ソース起点を検証するように動作する、請求項９に記載のサーバーシステム。
【請求項１１】
前記クロス起点通信チャンネルは、シルバーライトランタイムライブラリを使用し、前記通信ブリッジプログラムは、前記ゲートウェイサーバーシステムによるクロス起点通信チャンネルの確認を可能にするソース起点を識別するエンコードされたヘッダデータでウェブソケット要求をエンコードするよう動作する、請求項８に記載のサーバーシステム。
【請求項１２】
前記通信ブリッジプログラムの実行は、更に、許されたヘッダデータの識別を含む動的に発生されるアクセスポリシーを条件付きで検索する前記ゲートウェイサーバーシステムに向けられるクロスサイトアクセスポリシー要求を発生するよう動作し、前記エンコードされたヘッダデータは、前記ウェブアプリケーションサービスの前記要求に前記許されたヘッダデータとして合体され、そして前記ウェブアプリケーションサービスへの前記要求の送信を資格付けするために前記ゲートウェイサーバーシステムにより使用される、請求項１１に記載のサーバーシステム。
【請求項１３】
前記クロス起点通信チャンネルは、ランタイムクラスロードのクラスを通してデータの転送を許すＪａｖａランタイムライブラリを使用し、そしてＪａｖａランタイムライブラリに関連したクラスローダーメタデータは、前記ソース起点を決定するために前記通信ブリッジプログラムにより使用される、請求項８に記載のサーバーシステム。
【請求項１４】
前記ゲートウェイサーバーシステムは、前記要求に応答して前記クライアントシステムへ送信する前にＨＴＴＰリダイレクション及びエラーメッセージをＨＴＴＰ ２０Ｘメッセージ内に包むように動作する、請求項８に記載のサーバーシステム。
【請求項１５】
前記クライアント側ウェブアプリケーションと前記ウェブアプリケーションサービスとの間のエミュレートされたウェブソケット通信接続は、前記クライアントシステム上で実行される前記通信ブリッジプログラムを通して前記クライアントシステムと前記ゲートウェイサーバーシステムとの間のオープンＨＴＴＰ接続を経て確立され、前記クロス起点通信チャンネルは、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔメッセージのクロス起点転送を与え、そして一連のＸＭＬＨｔｔｐＲｅｑｕｅｓｔメッセージが、前記エミュレートされたウェブソケット通信接続を通して転送されるデータを搬送する、請求項８に記載のサーバーシステム。
【請求項１６】
前記ゲートウェイサーバーシステムは、前記エミュレートされたウェブソケット通信接続を通して転送されるデータを搬送するため、前記クライアントシステムへサーバー送信イベントを送信するように動作する、請求項１５に記載のサーバーシステム。
【請求項１７】
前記エミュレートされたウェブソケット通信接続は、前記ゲートウェイサーバーシステムと前記ウェブアプリケーションサービスとの間でネーティブなウェブソケット通信接続として具現化される、請求項１６に記載のサーバーシステム。
【請求項１８】
前記オープンのＨＴＴＰ接続は、セキュアなＨＴＴＰ接続である、請求項１７に記載のサーバーシステム。
【請求項１９】
前記通信ブリッジプログラムは、サーバー送信イベントの識別子を追跡して、前記クライアントシステムと前記ゲートウェイサーバーシステムとの間のサーバー送信イベントメッセージデータの配信を保証する、請求項１８に記載のサーバーシステム。
【請求項２０】
前記ゲートウェイサーバーシステムは、前記クライアントシステムへキープアライブデータを送信して、前記オープンのＨＴＴＰ接続を維持するように動作する、請求項１９に記載のサーバーシステム。
【請求項１】
ｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントにウェブアプリケーションサポートを与えて、ソースサーバーにより提供されるアプリケーションがターゲットサーバーにより提供されるサービスを利用できるようにする方法であって、前記ターゲットサーバーのサービスは、前記ソースサーバーのソース起点との通信に対してセキュアなターゲット起点から提供されるものであり、
ａ）定義されたソース起点を有するソース起点サーバーから受け取られるクライアント側ウェブアプリケーションをウェブブラウザクライアントにより実行する段階であって、要求識別ウェブアプリケーションサービスへの接続を要求する段階を含む当該実行段階と、
ｂ）前記ウェブブラウザクライアントによるエミュレーションクライアントライブラリの実行を通して、前記ウェブブラウザクライアントと、前記要求識別ウェブアプリケーションサービスにアクセスするためのゲートウェイサーバーとの間の両方向可能なＨＴＴＰベースの通信接続を第１に確立する段階であって、前記ゲートウェイサーバーは、前記定義されたソース起点の範囲外の定義されたターゲット起点に関連され、そして前記両方向可能なＨＴＴＰベースの通信接続は、前記定義されたソース起点と前記ターゲット起点との間にセキュアな通信経路を与えるクロス起点通信ブリッジを含むものである当該段階と、
ｃ）前記ゲートウェイサーバーを通して、前記要求識別ウェブアプリケーションサービスに対して規定の関係を有するターゲットサーバーにより提供されるターゲット定義サービスへのＨＴＭＬ５適合接続を第２の確立する段階と、
を含む方法。
【請求項２】
前記実行段階は、前記ウェブブラウザクライアントにより通信ブリッジプログラムを実行することを含み、前記通信ブリッジプログラムは、前記要求段階に応答して前記ゲートウェイサーバーから受け取られ、前記クライアント側ウェブアプリケーションは、前記定義されたソース起点内で実行され、前記通信ブリッジプログラムは、前記定義されたターゲット起点内で実行され、そして前記クロス起点通信ブリッジは、前記通信ブリッジプログラムと前記ウェブブラウザクライアントとの間に確立される、請求項１に記載の方法。
【請求項３】
前記ゲートウェイサーバーにより前記両方向可能なＨＴＴＰベースの通信接続を資格付けする段階を更に含み、前記要求は、前記定義されたソース起点及び前記要求識別ウェブアプリケーションサービスの識別を与え、そして前記ゲートウェイサーバーは、前記要求を受け入れるべきかどうか決定する、請求項２に記載の方法。
【請求項４】
前記資格付け段階は、サービスアクセスポリシーを評価して、前記定義されたソース起点と、前記要求識別ウェブアプリケーションサービスとの間の許された関係を決定する段階を含む、請求項３に記載の方法。
【請求項５】
前記資格付け段階は、前記要求識別ウェブアプリケーションサービスに対する前記既定の関係を決定する段階を含む、請求項４に記載の方法。
【請求項６】
前記ゲートウェイサーバーは、更に、前記要求をリダイレクトすべきかどうか決定し、前記資格付け段階は、ＨＴＴＰ応答メッセージに包まれたＨＴＴＰリダイレクションメッセージを返送し、前記ＨＴＴＰリダイレクションメッセージを前記クライアント側ウェブアプリケーションへ配信する、請求項３に記載の方法。
【請求項７】
前記エミュレーションクライアントライブラリは、ウェブソケットエミュレーション層を含み、前記第１に確立する段階は、前記ＨＴＴＰリダイレクションメッセージに応答して、前記要求識別ウェブアプリケーションサービスにアクセスするために前記ウェブブラウザクライアントとリダイレクションゲートウェイサーバーとの間に前記両方向可能なＨＴＴＰベースの通信接続を確立し、前記リダイレクションゲートウェイサーバーは、前記定義されたソース起点の範囲外の定義されたリダイレクションターゲット起点に関連される、請求項６に記載の方法。
【請求項８】
分散ウェブアプリケーションの実行をサポートするサーバーシステムであって、
ａ）ネットワークに結合されたソース起点サーバーシステムであって、これは、クライアント側ウェブアプリケーションを含み、そしてソース起点の範囲内で前記ネットワークを通してアクセスできるソース起点サーバーシステムと、
ｂ）前記ネットワークに結合されたゲートウェイサーバーシステムであって、これは、通信ブリッジプログラムを含み、ターゲット起点の範囲内で前記ネットワークを通してアクセスでき、そしてウェブアプリケーションサービスへネットワーク接続を与えるように動作するゲートウェイサーバーシステムと、
ｃ）前記ネットワークに結合されたクライアントシステムであって、これは、ウェブブラウザクライアントを実行するように動作でき、前記ウェブブラウザクライアントは、クロス起点メッセージを除外するｐｒｅ−ＨＴＭＬ５適合ウェブブラウザクライアントであり、前記ウェブブラウザクライアントは、前記クライアント側ウェブアプリケーションを前記ソース起点サーバーシステムダウンロードするように働き、更に、前記ウェブブラウザクライアントは、前記ソース起点の範囲内で前記クライアントシステム上の前記クライアント側ウェブアプリケーションを実行するように動作し、前記ウェブブラウザクライアントは、前記通信ブリッジプログラムを前記ゲートウェイサーバーシステムダウンロードするように動作し、前記ウェブブラウザクライアントは、更に、前記ターゲット起点の範囲内で前記クライアントシステム上の前記通信ブリッジプログラムを実行するように動作し、前記クライアント側ウェブアプリケーション及び前記通信ブリッジプログラムは、クロス起点通信チャンネルを具現化し、前記クライアント側ウェブアプリケーションは、更に、前記通信ブリッジプログラム及び前記ゲートウェイサーバーシステムを通して前記ウェブアプリケーションサービスクロス起点の要求を発行するように動作するようなクライアントシステムと、
を備えたサーバーシステム。
【請求項９】
前記クロス起点通信チャンネルは、フラッシュランタイムライブラリベースのネーティブ共有イベントを使用してデータを転送し、そして前記通信ブリッジプログラムは、フラッシュランタイムライブラリに関連したＬｏａｄｅｒＩｎｆｏメタデータを使用して、前記ソース起点を決定する、請求項８に記載のサーバーシステム。
【請求項１０】
前記通信ブリッジプログラムの実行は、更に、前記ゲートウェイサーバーシステムに維持されたクライアントアクセスポリシーに基づいて前記ゲートウェイサーバーシステムにより条件付きで受け容れられるソース起点クライアントアクセス要求を前記ゲートウェイサーバーシステムに与えることにより前記ソース起点を検証するように動作する、請求項９に記載のサーバーシステム。
【請求項１１】
前記クロス起点通信チャンネルは、シルバーライトランタイムライブラリを使用し、前記通信ブリッジプログラムは、前記ゲートウェイサーバーシステムによるクロス起点通信チャンネルの確認を可能にするソース起点を識別するエンコードされたヘッダデータでウェブソケット要求をエンコードするよう動作する、請求項８に記載のサーバーシステム。
【請求項１２】
前記通信ブリッジプログラムの実行は、更に、許されたヘッダデータの識別を含む動的に発生されるアクセスポリシーを条件付きで検索する前記ゲートウェイサーバーシステムに向けられるクロスサイトアクセスポリシー要求を発生するよう動作し、前記エンコードされたヘッダデータは、前記ウェブアプリケーションサービスの前記要求に前記許されたヘッダデータとして合体され、そして前記ウェブアプリケーションサービスへの前記要求の送信を資格付けするために前記ゲートウェイサーバーシステムにより使用される、請求項１１に記載のサーバーシステム。
【請求項１３】
前記クロス起点通信チャンネルは、ランタイムクラスロードのクラスを通してデータの転送を許すＪａｖａランタイムライブラリを使用し、そしてＪａｖａランタイムライブラリに関連したクラスローダーメタデータは、前記ソース起点を決定するために前記通信ブリッジプログラムにより使用される、請求項８に記載のサーバーシステム。
【請求項１４】
前記ゲートウェイサーバーシステムは、前記要求に応答して前記クライアントシステムへ送信する前にＨＴＴＰリダイレクション及びエラーメッセージをＨＴＴＰ ２０Ｘメッセージ内に包むように動作する、請求項８に記載のサーバーシステム。
【請求項１５】
前記クライアント側ウェブアプリケーションと前記ウェブアプリケーションサービスとの間のエミュレートされたウェブソケット通信接続は、前記クライアントシステム上で実行される前記通信ブリッジプログラムを通して前記クライアントシステムと前記ゲートウェイサーバーシステムとの間のオープンＨＴＴＰ接続を経て確立され、前記クロス起点通信チャンネルは、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔメッセージのクロス起点転送を与え、そして一連のＸＭＬＨｔｔｐＲｅｑｕｅｓｔメッセージが、前記エミュレートされたウェブソケット通信接続を通して転送されるデータを搬送する、請求項８に記載のサーバーシステム。
【請求項１６】
前記ゲートウェイサーバーシステムは、前記エミュレートされたウェブソケット通信接続を通して転送されるデータを搬送するため、前記クライアントシステムへサーバー送信イベントを送信するように動作する、請求項１５に記載のサーバーシステム。
【請求項１７】
前記エミュレートされたウェブソケット通信接続は、前記ゲートウェイサーバーシステムと前記ウェブアプリケーションサービスとの間でネーティブなウェブソケット通信接続として具現化される、請求項１６に記載のサーバーシステム。
【請求項１８】
前記オープンのＨＴＴＰ接続は、セキュアなＨＴＴＰ接続である、請求項１７に記載のサーバーシステム。
【請求項１９】
前記通信ブリッジプログラムは、サーバー送信イベントの識別子を追跡して、前記クライアントシステムと前記ゲートウェイサーバーシステムとの間のサーバー送信イベントメッセージデータの配信を保証する、請求項１８に記載のサーバーシステム。
【請求項２０】
前記ゲートウェイサーバーシステムは、前記クライアントシステムへキープアライブデータを送信して、前記オープンのＨＴＴＰ接続を維持するように動作する、請求項１９に記載のサーバーシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２０１２−５２５６５９（Ｐ２０１２−５２５６５９Ａ）
【公表日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願番号】特願２０１２−５０８８０６（Ｐ２０１２−５０８８０６）
【出願日】平成２２年５月１日（２０１０．５．１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３３３１４
【国際公開番号】ＷＯ２０１０／１２７３２７
【国際公開日】平成２２年１１月４日（２０１０．１１．４）
【出願人】（５１１２６５８４４）カージング コーポレーション (2)
【Ｆターム（参考）】
【公表日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願日】平成２２年５月１日（２０１０．５．１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３３３１４
【国際公開番号】ＷＯ２０１０／１２７３２７
【国際公開日】平成２２年１１月４日（２０１０．１１．４）
【出願人】（５１１２６５８４４）カージング コーポレーション (2)
【Ｆターム（参考）】
[ Back to top ]