JP2018512084A - 高度にスケーラブルでフォールトトレラントなリモートアクセスアーキテクチャと、当該リモートアクセスアーキテクチャに接続する方法 - Google Patents

Abstract

クライアント／サーバ間リモートアクセスシステムのサービスにリモートアクセスを提供するシステム及び方法。方法は、スケジューラがサービスをホストするアプリケーションサーバを選択することを含み、選択は、クライアント／サーバ間リモートアクセスシステムのリソースの利用状態に従って行われる。サービスを一意に識別し、サービスへのクライアントのリモートアクセス確立に使用されるＵＲＬ（ユニフォームリソースロケータ）ペイロードを含むセッションＵＲＬを作成する。システムは、リソースＵＲＬにアクセス可能なプロキシサーバを含んでよい。プロキシサーバは、サービスへの接続要求をクライアントから受信する。認証コンポーネントは、リソースＵＲＬのペイロードに従って、要求を認証する。サービスマネージャは、セッションＵＲＬに接続されたクライアントとサービス間にセッションを確立する。

Description

発明の詳細な説明

［関連出願の相互参照］
本出願は、２０１５年１月３０日出願のＵＳ仮特許出願第６２／１０９，９１４号「高度にスケーラブルでフォールトトレラントなリモートアクセスアーキテクチャと、当該リモートアーキテクチャに接続する方法」の優先権を主張し、その開示の全体を参照により本明細書に組み込む。

［背景］
ブロードバンド無線ネットワークアクセスの成長及び可用性の結果として、サービスへのユビキタスリモートアクセスが、ごく普通のものになった。このため、ユーザは、種類が増え続けるクライアント装置（例えば、モバイル装置、タブレットコンピューティング装置、ラップトップ／ノートブック／デスクトップコンピュータ等）を用いて広範なリモートサービスに接続することによって、サービスにアクセスしている。リモートサーバは、３Ｇ、４Ｇ、及び、ＬＴＥモバイルデータネットワーク、ＷｉＦｉ及びＷｉＭＡＸ等の無線ネットワーク、有線ネットワーク等を含む、多様なネットワークを介してリモートサービスとクライアント装置の間で、データまたは他の情報を含むメッセージを通信してよい。

このような成長を前提として、クライアント装置の多数の同時ユーザにサービスを供給するには十分なスケーラビリティをリモートアクセスサーバが提供できない状況がある。さらに、リモートアクセスサーバがクラッシュして、リモートアクセスサーバに接続されたユーザ全ての接続を切る高需要及びコンポーネント故障等の状況がある。

［概要］
クライアント／サーバ間リモートアクセスシステムのサービスにリモートアクセスを提供するシステム及び方法を本明細書に開示する。開示の態様によると、クライアント／サーバ間リモートアクセスシステムのサービスにリモートアクセスを提供する方法を開示する。方法は、クライアント／サーバ間リモートアクセスシステムのリソースの利用状態に従って、スケジューラが、サービスをホストするアプリケーションサーバを選択することと、サービスを一意に識別し、クライアントによるサービスへのリモートアクセスの確立に使用されるＵＲＬペイロードを含むセッションＵＲＬを作成することを含む。

開示の他の態様によると、サービスへのアクセスを提供するクライアント／サーバ間リモートアクセスシステムを開示する。システムは、リソースＵＲＬ（ユニフォームリソースロケータ）でアクセス可能なプロキシサーバを含む。プロキシサーバは、サービスに接続する要求をクライアントから受信する。認証コンポーネントは、リソースＵＲＬのペイロードに従って、要求を認証する。スケジューラは、クライアント／サーバ間リモートアクセスシステムのリソースの利用状態に従って、サービスをホストするアプリケーションサーバを選択する。スケジューラは、クライアントとサービス間のセッションの確立に使用するペイロードを含むセッションＵＲＬを作成する。サービスマネージャが、認証された要求に従ってセッションＵＲＬに接続されたクライアントとサービス間のセッションを確立して、クライアントとサービス間でアプリケーションデータと状態情報を通信する。

さらに他の態様に従って、クライアント／サーバ間リモートアクセスシステムのサービスへのリモートアクセスを可能にする方法を開示する。方法は、クライアント／サーバ間リモートアクセスシステムのリソースの利用状態に従って、スケジューラが、サービスをホストするアプリケーションサーバを選択することと、アプリケーションＩＤをサービスに関連付けることと、ペイロードとしてアプリケーションＩＤを含むセッションＵＲＬ（ユニフォームリソースロケータ）であって、アプリケーションサーバがホストするサービスを識別するセッションＵＲＬをスケジューラが作成することと、セッションＵＲＬでサービスをクライアントに利用可能にすることを含む。

以下の図面及び詳細な記載を検討すると、他のシステム、方法、特徴、及び／または、利点は、当業者には明らかであろう。このような追加のシステム、方法、特徴、及び／または、利点は全て、本記載内に含まれ、請求項によって保護されるものとする。

図面内のコンポーネントは、互いに必ずしも縮尺通りではない。類似の参照番号は、幾つかの図面を通して対応する部分を指す。

サービスへのリモートアクセスを提供する環境の例を示す図である。 図１の例示の環境内で、クライアント装置が、リソースＵＲＬを用いて要求を行い、セッションＵＲＬを用いて、アプリケーションに接続し、アプリケーションとの接続を絶つことを示す動作フローの図である。 図２の動作フローを行う時、コンポーネント間で通信される一連のメッセージを示すコールフロー図である。 コラボレーションＵＲＬを作成して、コラボレータ及び／またはクライアント間のコラボレーションセッションを確立する動作フローを示す図である。 ダッシュボードによって提示されたユーザインタフェースの例を示す図である。 ダッシュボードによって提示されたユーザインタフェースの例を示す図である。 ダッシュボードによって提示されたユーザインタフェースの例を示す図である。 コンピューティング装置の例を示す図である。

別段の規定の無い限り、本明細書で使用する全ての技術的用語及び科学的用語は、当業者が通常、理解するのと同じ意味を有する。本明細書に記載の方法及び材料と類似または同等の方法及び材料は、本開示の実践またはテストに使用できる。リモートアクセスアーキテクチャによって提供されたリモートアクセスアプリケーション及びサービスにクライアントを接続する高度にスケーラブルなフォールトトレラントなリモートアクセスアーキテクチャ及び方法を提供する実施態様を記載するが、実施態様が、それに限らないことは、当業者には明らかであろう。

上記を導入部として、図１を参照する。図１は、サービスへのリモートアクセスを提供するアーキテクチャ１００の例を示す。図１に示すように、クライアント装置１０２ａ／１０２ｂ／１０２ｃは、各クライアントソフトウェア開発キット（ＳＤＫ）１０４ａ／１０４ｂ／１０４ｃ及び各クライアントリモートアクセスアプリケーション１０５ａ／１０５ｂ／１０５ｃを実行してよい。クライアント装置１０２ａ／１０２ｂ／１０２ｃは、例えば、ＩＰｈｏｎｅ、ＡＮＤＲＯＩＤベースの装置、タブレット装置等の無線ハンドヘルド装置、または、デスクトップ／ノートブックパーソナルコンピュータであってよく、それらは、通信ネットワーク１２５によって１つまたは複数のプロキシサーバ１１３ａ／１１３ｂ／１１３ｃに接続される。

クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、各クライアントリモートアクセスアプリケーション１０５ａ／１０５ｂ／１０５ｃに関連付けられ、各クライアントリモートアクセスアプリケーション１０５ａ／１０５ｂ／１０５ｃが接続されたリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂから表示情報を受信するように適合される。クライアントリモートアクセスアプリケーション１０５ａ／１０５ｂ／１０５ｃは、アプリケーション１１５ａ／１１５ｂ／１１５ｃの１つまたは複数等、接続されたサービス（複数可）からの情報をクライアント装置１０２ａ／１０２ｂ／１０２ｃに表示するユーザインタフェースを提供するウェブブラウザ、専用アプリケーション等であってよい。「アプリケーション」及び「サービス」という用語は、本明細書では交換可能に用いられ、ネットワークを介してクライアント装置に配布されるプログラムまたはプログラムグループを指す。アプリケーションの例は、医用画像アプリケーション、ＣＡＤアプリケーション、地震計アプリケーション、コラボレーションホワイトボードアプリケーション等を含むが、これらに限らない。

通信ネットワーク１２５は、３Ｇ、４Ｇ、及び／または、ＬＴＥモバイルデータネットワーク、ＷｉＦｉ及びＷｉＭＡＸ等の無線ネットワーク、または、有線ネットワーク等であってよい。通信ネットワーク１２５を介した接続は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ＷｅｂＳｏｃｋｅｔプロトコル（ＷＳＳ）、または、ＴＣＰ／ＩＰネットワーク内でサポートされた任意の他のプロトコルであってよい。

プロキシサーバ１１３ａ／１１３ｂ／１１３ｃは、比較的多数の同時要求（例えば、何千から何百万の同時要求）を扱うことができるＨＴＴＰサーバ及びリバースプロキシサーバであってよい。ある実施態様において、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃは、リモートアクセス及びアプリケーションサーバ（複数可）１０３ａ／１０３ｂとは別個のノード（例えば、サーバコンピューティング装置）で実行し、通信接続１２６によって、リモートアクセス及びアプリケーションサーバ（複数可）１０３ａ／１０３ｂに通信可能に接続される。通信接続１２６は、通信接続１２５より容量の大きい接続であってよい。プロキシサーバ１１３ａ／１１３ｂ／１１３ｃは、リモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂの負荷、計算コスト、地理的な位置（複数可）、または、他の要因に従って、アーキテクチャ１００内のスケーリングも提供してよい。プロキシサーバ１１３ａ／１１３ｂ／１１３ｃの例は、カリフォルニア州サンフランシスコＮｇｉｎｘ社製のｎｇｉｎｘである。

リモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂは、サービスマネージャ１１１ａ／１１１ｂ、アプリケーションサーバ１１４ａ／１１４ｂ、及び、１つまたは複数のアプリケーション（サービス）１１５ａ／１１５ｂ／１１５ｃを含んでよい。アーキテクチャ１００において、サービスマネージャ１１１ａ／１１１ｂは、個々のリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂ上でアプリケーション１１５ａ／１１５ｂ／１１５ｃの停止及び開始を行う。アプリケーションサーバ１１４ａ／１１４ｂは、接続マーシャリングを提供する。アプリケーションサーバ１１４ａ／１１４ｂは、クライアント装置１０２ａ／１０２ｂ／１０２ｃからアプリケーション１１５ａ／１１５ｂ／１１５ｃに、及び、アプリケーション１１５ａ／１１５ｂ／１１５ｃからクライアント装置１１５ａ／１１５ｂ／１１５ｃに表示情報を提供するサーバＳＤＫ１１６ａ／１１６ｂを含んでよい。リモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂの例は、カナダアルバータ州カルガリーのＣａｌｇａｒｙ Ｓｃｉｅｎｔｉｆｉｃ社製のＰＵＲＥＷＥＢである。

アーキテクチャ１００内にユーザ及びアプリケーション１１５ａ／１１５ｂ／１１５ｃを認証する認証コンポーネント１２４が備えられてよい。アーキテクチャ１００によって提供されたセキュリティモデルによると、認証コンポーネント１２４によって認証され、アクセスが許可されるまで、どのアプリケーション１１５ａ／１１５ｂ／１１５ｃも互いを信用しない。認証コンポーネント１２４は、トークンベースの認証スキームを使用して、認証サービスを提供してよい。例えば、認証されると、制限付きユニフォームリソースロケータ（ＵＲＬ）がユーザにマップされてよい。

ダッシュボード１２７は、アプリケーションサーバのインスタンスを開始し、アーキテクチャ１００のコンポーネントを構成する能力を、システムアドミニストレータに提供する。ダッシュボードが提示するユーザインタフェースの例が、図５Ａ、５Ｂ、５Ｃに示され、アーキテクチャ１００内でコンポーネント（図５Ａ）、サービス情報（図５Ｂ）、アプリケーションサーバ及びサービスマネージャ情報（図５Ｃ）を開始するユーザインタフェースを示す。図には示さないが、ダッシュボード１２７は、クラスタ１２０の性能に関するメトリクスも報告してよい。

例えば、クラスタ１２０のアプリケーションサーバ１０３ａ／１０３ｂまたは他のノード等のリソースの利用を管理するスケジューラ１３０が、備えられてよい。スケジューラ１３０は、１つまたは複数の選択ヒューリスティクスを実施して、どのアプリケーションサーバ１０３ａ／１０３ｂがリモートアクセス接続要求にサービスを供給するかを決定してよい。ヒューリスティクスの一例は、最も少ない数のサービスを実行しているアプリケーションサーバを選択すること（すなわち、最小負荷ヒューリスティクス）である。ヒューリスティクスの別の例は、利用可能な容量を有する最も長く実行しているアプリケーションサーバを選択すること（すなわち、容量のある最も古いヒューリスティクス)である。この例のヒューリスティクスでは、最近作成されたアプリケーションサーバがアイドルになり、停止できるように、より少なく、より古いアプリケーションサーバにより多くのサービスをロードするように試みる。ヒューリスティクスのさらに別の例は、アプリケーション１１５ａ／１１５ｂ／１１５ｃのステートフルを考慮し、既存の実行中のアプリケーション（例えば、アプリケーション１１５ａ／１１５ｂ／１１５ｃの１つ）の状態に従って、アプリケーションサーバを選択する。例えば、アプリケーション１１５ａ／１１５ｂ／１１５ｃは、特定のクライアント１０２ａ／１０２ｂ／１０２ｃからの接続の受信に利用可能なように、アプリケーションサーバの待ち行列に入れられている場合がある。接続されると、特定のクライアント１０２ａ／１０２ｂ／１０２ｃは、接続されたままである、または、同じアプリケーション１１５ａ／１１５ｂ／１１５ｃに再接続する。このヒューリスティクスは、アプリケーション１１５ａ／１１５ｂ／１１５ｃの性質がグラフィカルである環境で使用されてよい。上記に従って、スケジューラ１３０は、セッションＵＲＬと、関連するペイロード（例えば、アプリケーション／サービスを一意に識別するアプリケーションＩＤ）をリアルタイムで作成してクライアント装置１０２ａ／１０２ｂ／１０２ｃのユーザを特定のアプリケーションサーバ（例えば、１１４ａ）にホストされたサービス（例えば、１１５ａ）に導いてよい。この特徴の詳細を、図３を参照して以下に記載する。

オーケストレータ１３１は、負荷、ハードウェア容量（例えば、ＣＰＵ、ＧＰＵ、メモリ）、ネットワーキング要求、費用、地理的な位置、または、他のメトリクスに従って、リモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂを開始、停止してよい。スケジューラ１３０は、企業、クラウドサービスプロバイダ、例えば、アマゾンウェブサービス、または、他の実体と関連付けられたファイアウォール１３４の背後にアプリケーションサーバ１０３ａ／１０３ｂをクラスタ１２０としてデプロイしてよい。クラスタリングによって、複数のリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂは、高い利用可能性、負荷バランシング、及び／または、並行処理を提供できる。ある実施態様においては、アプリケーションサーバ１０３ａ／１０３ｂは、オーケストレータ１３１から受信した開始コマンドに応答して画像から作成されたクラウドベースのインスタンスであってよい。例えば、各アプリケーション１１５（または、アプリケーション）に関連付けられた予め構築された画像があってよく、その画像は、例えば、クラウド環境のインスタンスとして、インスタンス化されて、アプリケーションサーバにロードできる。

オーケストレータ１３１は、手動または自動で動作してよい。手動で動作する時、ユーザは、（例えば、開発者に関連付けられたクライアントコンピューティング装置上で）コマンドラインインタフェースを用いて、オーケストレータ１３１にリモートで接続し、使用しているアプリケーションサーバをオンまたはオフにする。自動で動作するとき、オーケストレータ１３１は、クラスタ１２０内の現在のリソース配分に関してスケジューラ１３０から情報を受信してよい。クラスタ１２０内、または、個々のアプリケーションサーバ１０３ａ若しくは１０３ｂ上でのリソース利用が多い場合、オーケストレータ１３１は、新しいアプリケーションサーバインスタンス（複数可）を自動的に開始して、需要を満たしてよい。同様に、クラスタ１２０内、または、個々のアプリケーションサーバ１０３a若しくは１０３ｂ上での利用が少ない場合、オーケストレータ１３１は、既存のアプリケーションサーバインスタンスを自動的に停止してよい。

さらに、オーケストレータ１３１は、（リソースが許せば、追加のノードまたは同じノード上に）追加のプロキシサーバ１１３ａ／１１３ｂ／１１３ｃをデプロイして、クラスタ１２０のリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂへの接続を扱ってよい。あるいは、追加のリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂは、他のリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂの追加または同じノードにデプロイされてよい。

サービス発見及び構成コンポーネント１３２は、クラスタ１２０内で発見サービスを提供してよい。サービス発見及び構成コンポーネント１３２は、アプリケーション１１５ａ／１１５ｂ／１１５ｃがどのリソースを必要とし得るかを決定し、アプリケーション１１５ａ／１１５ｂ／１１５ｃをリモートクライアント１０２ａ／１０２ｂ／１０２ｃにアクセス可能にするように適合される。例えば、サービス発見及び構成コンポーネント１３２は、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃからの要求をアプリケーション１１５ａ／１１５ｂ／１１５ｃにルーティングするドメインネームサービス（ＤＮＳ）を提供してよい。サービス発見及び構成コンポーネント１３２の例は、ＨａｓｈｉＣｏｒｐ社製のＣｏｎｓｕｌである。

スケジューラ１３０、サービス発見及び構成コンポーネント１３２等のクラスタ１２０のコンポーネントから情報を取得、または、当該コンポーネントに情報を提供するために、ダッシュボード１２７及び他の外部のコンポーネントとインタフェースを取るＡＰＩ Ｅｄｇｅ１２８を備えてよい。

ある実施態様においては、クラスタ１２０の１つまたは複数のコンポーネント、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃ、認証コンポーネント１２４、または、ダッシュボード１２７は、アマゾンウェブサービス（ＡＷＳ）を含むが、これに限らないクラウドインフラストラクチャ内にデプロイされてよい。クライアント装置１０２ａ／１０２ｂ／１０２ｃとリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂの例を図６に示す。さらに、アーキテクチャ１００内のコンポーネントの１つまたは複数が、アーキテクチャ１００のスケーラビリティとフォールトトレランスを向上させるマイクロサービスとしてデプロイされてよい。従って、アーキテクチャ１００は、多数のクライアントがネットワークを介してアプリケーションにリモートでアクセスし得る高度にスケーラブルな、フォールトトレラントなアーキテクチャを提供する。

図２及び図３を参照すると、フローの例とアーキテクチャ１００のコンポーネント間で送信される一連のメッセージとを示す動作フローチャートとコールフロー図が示されている。

図２を参照すると、２０２において、ハンドシェイク動作が、クライアントとプロキシサーバ間で行われる。ハンドシェイク動作は、クライアントリモートアクセスアプリケーション１０５ａとしてクライアント１０２ａのブラウザを用いて実行されるＪａｖａＳｃｒｉｐｔファイルを、例えば、プロキシサーバ１１３ａからクライアント１０２ａにダウンロードすることを伴ってよい。図３のように、２０２で行われた動作に関連付けられたコールフローは、フロー１及び２によって一般的に示される。クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃに接続し、例えば、ＨＴＴＰ ＧＥＴ方法を用いて、アプリケーション１１５ａ／１１５ｂ／１１５ｃと関連付けられたリソースＵＲＬとパラメータを受信する。パラメータは、アプリケーション名及びクライアント識別子を含んでよい（フロー１）。プロキシサーバ１１３ａ／１１３ｂ／１１３ｃは、クライアントリモートアクセスアプリケーション１０５ａ／１０５ｂ／１０５ｃとして実行する、例えば、ＪａｖａＳｃｒｉｐｔをクライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃに返信する（フロー２）。

２０４において、サービスがスケジュールされる。例えば、フロー１で渡されたアプリケーション名を用いて、スケジューラ１３０は、サービスマネージャ１１１ａがリソースＵＲＬに関連付けられたクライアント要求を満たすアプリケーション１１５ａを開始するように要求してよい。２０４で行われた動作に関連付けられたコールフローは、図３のフロー３及び４によって一般的に示される。クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、使用するアプリケーション１１５ａ／１１５ｂ／１１５ｃに関連付けられたアプリケーションサーバ１１４ａ／１１４ｂのスケジューラ１３０からクラスタアドレスを取得する（フロー３）。スケジューラ１３０は、クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃにクラスタアドレスを返信する（フロー４）。

２０６において、リソースＵＲＬの対象であるアプリケーションを開始する。スケジューラ１３０は、アプリケーションサーバ１１４ａのリソース利用をチェックし、負荷等に応じて、アプリケーション１１５ａを開始するようサービスマネージャ１１１ａに連絡する。２０６で行われる動作に関連付けられたコールフローは、図３のフロー５〜１４によって一般的に示される。クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、リソースＵＲＬ（例えば、フロー５の／ｒｅｍｏｔｅ／ａｐｐ）に配置されたプロキシサーバ１１３ａ／１１３ｂ／１１３ｃに接続する。例えば、クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃに接続し、例えば、ユーザまたはクライアント装置１０２ａ／１０２ｂ／１０２ｃに関する認証情報を含むペイロードと共にＨＴＴＰ ＰＯＳＴ方法を用いて要求を送ってよい。

認証情報は、認証コンポーネント１２４に提供され、ユーザまたはクライアント装置１０２ａ／１０２ｂ／１０２ｃがアプリケーション１１５ａ／１１５ｂ／１１５ｃへのアクセスを許可されるか（または、許可されたままにするか）否かを決定する（フロー６）。認証を通過すると、認証コンポーネント１２４は、スケジューラ１３０に要求を行い（フロー７）、スケジューラ１３０は、次に、アプリケーション１１５ａ／１１５ｂ／１１５ｃを実行するリモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂの負荷を決定するようにアプリケーションサーバ１１４ａ／１１４ｂに連絡する（フロー８）。リモートアクセス及びアプリケーションサーバ１０３ａ／１０３ｂのサービスマネージャ１１１ａ／１１１ｂは、決定を行い（フロー９）、負荷が閾値量を超える場合、または、アプリケーション１１５ａ／１１５ｂ／１１５ｃが実行中でない場合、スケジューラ１３０は、サービスマネージャ１１１ａ／１１１ｂにＳｔａｒｔメッセージを送って（フロー１０）、アプリケーション１１５ａ／１１５ｂ／１１５ｃを開始する（フロー１１）。例えば、サービスマネージャ１１１ａは、アプリケーションＩＤを用いて、アプリケーション１１５ａに接続し、開始する。サービスマネージャ１１１ａは、アプリケーション１１５ａに関連付けられた「セッション」を確立し、そうすると、セッションは、クライアント装置がリモートに接続されてよい「待ち行列に入れられたサービス」とみなされる。待ち行列に入れられたサービスは、（リモートにアクセス可能な一種類のアプリケーションに対して）一意のアプリケーション名、及び／または、待ち行列に入れられたサービスの接続に対して一意のアプリケーションＩＤによって知られてよい。

次に、アプリケーション１１５ａ／１１５ｂ／１１５ｃは、上記のように、スタートアッププロセスを開始し、例えば、ＴＣＰ接続メッセージを用いて、アプリケーションサーバ１１４ａ／１１４ｂに接続する（フロー１２）。アプリケーション１１５ａ／１１５ｂ／１１５ｃは、識別情報（例えば、アプリケーションＩＤ、アプリケーション名、及び、サーバインスタンス識別子、サービスマネージャ識別子）を提供し、識別情報は、スケジューラ１３０に渡される（フロー１３）。スケジューラ１３０は、次に、識別情報をクライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃに伝える（フロー１４）。

図２に戻ると、２０８において、アプリケーションサーバでサービスを利用可能にするセッションＵＲＬを作成する。認証コンポーネント１２４は、セッションを作成し、アプリケーションサーバ１１４ａは、セッションＵＲＬをクライアントＳＤＫ１０４に返信する。２０８で行われる動作に関連付けられたコールフローは、図３のフロー１５〜１８によって一般的に示される。上記パラメータを用いて、クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、パラメータと共に、例えば、ＨＴＴＰ ＰＯＳＴ方法を使用して、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃに要求を行ってよく（フロー１５）、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃは、クライアント装置１０２ａ／１０２ｂ／１０２ｃがパラメータによって識別されたアプリケーション１１５ａ／１１５ｂ／１１５ｃにアクセスを許可されるか否かを再び決定するように認証コンポーネント１２４に要求を渡す（フロー１６）。認証されると、認証コンポーネント１２４は、ＣｒｅａｔｅＳｅｓｓｉｏｎメッセージをアプリケーションサーバ１１４ａ／１１４ｂに送る（フロー１７）。アプリケーションサーバ１１４ａ／１１４ｂは、アプリケーション１１５ａ／１１５ｂ／１１５ｃの位置をセッションクッキーと共にクライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃに返信する（フロー１８）。このように、セッションが作成され、クライアントＳＤＫは、サービスに結びつく準備が整う。

２１０において、クライアントは、アプリケーションと対話する。２１０で行われる動作に関連付けられたコールフローは、図３のフロー１９〜２２によって一般的に示される。クライアント装置１０２ａは、アプリケーションＩＤを用いて、待ち行列に入れられたサービス（すなわち、アプリケーション１１５ａ）の特定のインスタンスに接続してよい。クライアントＳＤＫ１０４ａは、クライアント１０２ａの認証に使用されるペイロードを含むセッションＵＲＬを用いて、アプリケーション１１５ａに接続する。クライアント１０２ａが接続されると、アプリケーション１１５ａは、「アクティブサービス」にアップグレードされる。追加のクライアントが、一意のアプリケーションＩＤを用いてアクティブサービスに接続してよく、それによって、接続されたクライアントは、アクティブサービスとコラボレートしてよい。その詳細を以下に記載する。詳細には、クライアント装置（例えば、１０２ａ）は、コラボレーションセッションにおいて、他のクライアント装置（例えば、１０２ｂ及び／または１０２c）とコラボレートしてよい。例えば、コラボレータ１２２ａ／１２２ｂ／１２２ｃは、コラボレーションセッションにおいて、クライアント装置１０２ａ／１０２ｂ／１０２ｃと共に働いて、例えば、アプリケーション１１５ａ／１１５ｂ／１１５ｃを共有してよい。コラボレータ１２２ａ／１２２ｂ／１２２ｃとクライアント装置１０２ａ／１０２ｂ／１０２ｃは、例えば、共有アプリケーション状態及びメッセージの受け渡しを介して、アプリケーション１１５ａ等のリソース、または、データを共有してよい。図４を参照してコラボレーションの追加の詳細を記載する。

２１０で行われる動作に関連付けられたコールフローは、図３のフロー１９〜２２によって一般的に示される。セッションＵＲＬの位置情報とパラメータを用いて、クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃは、例えば、ＨＴＴＰ ＰＯＳＴ方法として、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃに要求を送り（フロー１９）、要求は、認証コンポーネント１２４に渡される（フロー２０）。認証されると、認証コンポーネント１２４は、リモートアクセスセッションにおいて、アプリケーション１１５ａ／１１５ｂ／１１５ｃをクライアント装置１０２ａ／１０２ｂ／１０２ｃに通信可能に接続するＡｔｔａｃｈＣｌｉｅｎｔメッセージをアプリケーションサーバ１１４ａ／１１４ｂに伝える（フロー２１）。アプリケーション１１５ａ／１１５ｂ／１１５ｃは、ここで、図１に示すように、例えば、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃを介して、アプリケーションサーバ１１４ａ／１１４ｂとクライアント装置１０２ａ／１０２ｂ／１０２ｃの間に形成されたＷｅｂ Ｓｏｃｋｅｔ接続（フロー２２）によって、クライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃに通信可能に接続される。従って、画像データ、アプリケーション状態情報、または、リモートセッションに関連付けられた他のデータは、アプリケーション１１５ａ／１１５ｂ／１１５ｃとクライアント装置１０２ａ／１０２ｂ／１０２ｃ間で送信されてよい。

アプリケーション状態情報は、状態モデルにおいてリモートセッション中に通信されてよく、アプリケーション状態情報は、リモートにアクセスされたアプリケーション１１５ａ／１１５ｂ／１１５ｃに関する情報、及び／または、クライアント装置１０２ａ／１０２ｂ／１０２ｃ若しくはコラボレーションセッションに参加している可能性のあるクライアント装置１０２ａ／１０２ｂ／１０２ｃに関するセッション情報である。詳細には、状態モデルは、アプリケーション状態に対する変更を含んでよく、アプリケーションサーバ１１４ａ／１１４ｂとクライアント装置１０２ａ／１０２ｂ／１０２ｃの間、または、複数のクライアント装置１０２ａ／１０２ｂ／１０２ｃがコラボレーションセッションに参加している場合、クライアント装置１０２ａ／１０２ｂ／１０２ｃ間で通信されてよい。状態モデルは、例えば、拡張マークアップ言語（ＸＭＬ）ドキュメントによって表すことができる。状態モデルの他の表現も使用できることを理解されたい。

図２の２１２おいて、クライアントは、アプリケーションとの接続を絶つ。クライアントＳＤＫ１０４ａは、アプリケーションサーバ１１４ａに停止メッセージを送り、アプリケーションサーバ１１４ａは、サービスマネージャ１１１ａとの接続を絶ち、クライアント１０２ａとアプリケーション１１５ａの間の接続を閉じる。２１２で行われる動作に関連付けられたコールフローは、図３のフロー２３〜２８によって一般的に示される。クライアント装置１０２ａ／１０２ｂ／１０２ｃのユーザが、リモートセッションを終了し、アプリケーション１１５ａ／１１５ｂ／１１５ｃとの接続を絶ちたい場合、例えば、ウエブソケットクローズまたはＨＴＴＰ ＤＥＬＥＴＥ方法を用いて、要求を行ってよく、要求は、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃに伝えられ（フロー２３）、プロキシサーバ１１３ａ／１１３ｂ／１１３ｃは、その要求を認証要求として、認証コンポーネント１２４に渡す（フロー２４）。認証されると、Ｓｔｏｐメッセージが、アプリケーションサーバ１１４ａ／１１４ｂに伝えられ（フロー２５）、アプリケーションサーバ１１４ａ／１１４ｂは、次に、ＴＣＰ Ｄｉｓｃｏｎｎｅｃｔ（フロー２６）とＴＣＰ Ｃｌｏｓｅ（フロー２７）メッセージをアプリケーション１１５ａ／１１５ｂ／１１５ｃに伝える。アプリケーションサーバ１１４ａ／１１４ｂは、次に、切断メッセージをクライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃに送り、アプリケーション１１５ａ／１１５ｂ／１１５ｃとのセッションを終了する。アプリケーションサーバ１１４ａ／１１４ｂは、次に、切断メッセージをクライアントＳＤＫ１０４ａ／１０４ｂ／１０４ｃに送り、アプリケーション１１５ａ／１１５ｂ／１１５ｃとのセッションを終了する（フロー２８）。

上記動作及びコールフロー図は、アーキテクチャ１００内でクライアント装置１０２ａ／１０２ｂ／１０２ｃをリモートアプリケーション１１５ａ／１１５ｂ／１１５ｃに接続し、また、リモートアプリケーション１１５ａ／１１５ｂ／１１５ｃとの接続を絶つフロー例を提供するが、他の変更形態及びコールフローは当業者には明らかであろう。

図４は、本開示のアーキテクチャ１００でコラボレーションセッションを開始する動作フロー４００の例を示す。４０２において、クライアントは、クライアントＳＤＫからコラボレーションＵＲＬを要求する。例えば、クライアント１０２ａのユーザは、クライアントＳＤＫ１０４ａから、他のコラボレータ１２２ａ／１２２ｂ／１２２ｃまたはクライアント１０２ｂ／１０２ｃがコラボレーションセッションに接続するのを可能にして、各々が、例えば、アプリケーション１１５ａと対話できるようにするコラボレーションＵＲＬを要求してよい。４０４において、共有されるアプリケーションを実行しているアプリケーションサーバを識別するコラボレーションＵＲＬを構築する。例えば、コラボレーションＵＲＬは、プロキシサーバ１１３ａの背後のアプリケーションサーバ１１４ａを一意に識別するように、認証サービス１２４によって構築されてよい。

４０６において、コラボレーションＵＲＬは、要求を行っているクライアントに返信される。４０８において、要求を行っているクライアントのユーザ（例えば、１０２ａ）は、コラボレータ１２２ａ／１２２ｂ／１２２ｃまたはクライアント１０２ｂ／１０２ｃの１つまたは複数にコラボレーションＵＲＬを転送してよい。４１０において、コラボレータまたは他のクライアントは、コラボレーションＵＲＬを用いてコラボレーションセッションに接続する。４１２において、サービス発見及び構成コンポーネントは、アプリケーションサーバ１１４ａへのコラボレーションＵＲＬを解明する。サービス発見及び構成コンポーネント１３２は、ＤＮＳを用いて位置サービスを行ってよい。４１４において、コラボレータは、それぞれ、コラボレーションセッションに参加して、アプリケーション１１５ａと対話する。

従って、動作フロー４００は、複数のユーザがアーキテクチャ１００内で実行しているアプリケーションとコラボレートして対話することを可能にする方法を提供する。

図６は、実施形態及び態様の例を実施し得る例示のコンピューティング環境を示す。このコンピューティングシステム環境は、適切なコンピューティング環境の一例でしかなく、使用や機能の範囲に関するいかなる制限も示唆していない。

多くの他の汎用または専用コンピューティングシステム環境または構成を使用してよい。使用に適し得る周知のコンピューティングシステム、環境、及び／または、構成の例は、パーソナルコンピュータ、サーバ、ハンドヘルド若しくはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ネットワークパーソナルコンピュータ（ＰＣ）、ミニコンピュータ、メインフレームコンピュータ、埋め込みシステム、上記システムまたは装置のいずれかを含む分散コンピューティング環境等を含むが、これらに限らない。

コンピュータによって実行されるプログラムモジュール等のコンピュータ実行可能命令を使用してよい。一般に、プログラムモジュールは、特定のタスクを実行または特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。通信ネットワークまたは他のデータ伝送媒体を介してリンクされるリモート処理装置によってタスクが行われる分散コンピューティング環境を使用してよい。分散コンピューティング環境においては、プログラムモジュールと他のデータは、メモリ記憶装置を含むローカル及びリモートの両方のコンピュータストレージに配置されてよい。

図６を参照すると、本明細書に記載の態様を実施する例示のシステムは、コンピューティング装置６００等のコンピューティング装置を含む。最も基本的な構成において、コンピューティング装置６００は、典型的に、少なくとも１つの処理ユニット６０２とメモリ６０４を含む。コンピューティング装置の正確な構成及び種類に応じて、メモリ６０４は、揮発性（ランダムアクセスメモリ(ＲＡＭ)等）、不揮発性（リードオンリメモリ（ＲＯＭ）、フラッシュメモリ等）、または、これら２つの何らかの組み合わせであってよい。この最も基本的な構成を点線６０６によって図６に示す。

コンピューティング装置６００は、追加の特徴／機能を有してよい。例えば、コンピューティング装置６００は、磁気若しくは光学ディスクまたはテープを含むが、これらに限らない、追加のストレージ（リムーバブル及び／または非リムーバブル）を含んでよい。このような追加のストレージは、リムーバブルストレージ６０８及び非リムーバブルストレージ６１０として図６に示される。

コンピューティング装置６００は、典型的に、様々な有形のコンピュータ可読媒体を含む。コンピュータ可読媒体は、装置６００によってアクセスでき、且つ、揮発性及び不揮発性の両方、リムーバブル及び非リムーバブルの両方の媒体を含む、任意の入手可能な有形媒体であってよい。

有形のコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または、他のデータ等の情報を記憶する任意の方法または技術で実施された揮発性及び不揮発性、リムーバブル及び非リムーバブルの媒体を含む。メモリ６０４、リムーバブルストレージ６０８、及び、非リムーバブルストレージ６１０は全て、コンピュータ記憶媒体の例である。有形のコンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、電気的消去可能プログラムリードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、若しくは、他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、若しくは、他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、若しくは、他の磁気記憶装置、または、所望の情報の記憶に使用でき、且つ、コンピューティング装置６００によってアクセスできる任意の他の媒体を含むが、これらに限らない。任意のこのようなコンピュータ記憶媒体は、コンピューティング装置６００の一部であってよい。

コンピューティング装置６００は、コンピューティング装置６００が他の装置と通信するのを可能にする通信接続（複数可）６１２を含んでよい。コンピューティング装置６００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置等の入力装置（複数可）６１４も有してよい。ディスプレイ、スピーカ、プリンタ等の出力装置（複数可）６１６も含まれてよい。これらの装置は全て、当分野で周知であり、ここで詳細に説明する必要は無い。

本明細書に記載の様々な技術は、ハードウェア若しくはソフトウェア、または、必要に応じて、それら両方の組み合わせと関連して実施されてよいことは理解されたい。従って、本開示の主題の方法及び装置、または、それらの一定の態様若しくはその一部は、有形媒体で具体化されるプログラムコード（すなわち、命令）の形を取ってよく、有形媒体は、フロッピーディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または、プログラムコードをコンピュータ等の機械にロードし、機械によって実行されると、機械が、本開示の主題を実践する装置になる任意の他の機械可読記憶媒体等であってよい。プログラム可能コンピュータにおいてプログラムコードを実行する場合、コンピューティング装置は、一般に、プロセッサと、（揮発性及び不揮発性メモリ、及び／または、記憶要素を含む）プロセッサによって読み取ることのできる記憶媒体と、少なくとも１つの入力装置と、少なくとも１つの出力装置とを含む。１つまたは複数のプログラムは、例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）、再利用可能な制御装置等を使用して、本開示の主題と関連して記載されたプロセスを実施または利用してよい。このようなプログラムは、高水準の手続き型またはオブジェクト指向のプログラミング言語で実施されて、コンピュータシステムと通信してよい。しかしながら、プログラム（複数可）は、必要に応じて、アセンブリまたは機械言語で実施できる。いずれの場合でも、言語は、コンパイラ型またはインタープリタ型言語であってよく、ハードウェアの実施態様と組み合わせられてよい。

主題を構造的特徴及び／または方法論的行為に特有の言語で記載したが、請求項に規定した主題は、上記特定の特徴や行為に必ずしも限定されないことを理解されたい。むしろ、上記特定の特徴及び行為は、請求項を実施する形態の例として開示している。

Claims (23)

1. クライアント／サーバ間リモートアクセスシステムのサービスにリモートアクセスを提供する方法であって、
   前記クライアント／サーバ間リモートアクセスシステムのリソースの利用状態に従って、スケジューラが、前記サービスをホストするアプリケーションサーバを選択することと、
   前記サービスを一意に識別し、且つ、クライアントによる前記サービスへの前記リモートアクセスの確立に使用されるＵＲＬ（ユニフォームリソースロケータ）ペイロードを含むセッションＵＲＬを作成することと、
   を含む、前記方法。
2. 前記アプリケーションサーバの前記選択に先立って、前記サービスへの接続を要求する前記クライアントに提供されるリソースＵＲＬを作成することをさらに含む、請求項１に記載の方法。
3. 前記リソースＵＲＬに関連付けられたプロキシサーバで要求を受信して、前記サービスにアクセスすることをさらに含む、請求項１〜２のいずれかに記載の方法。
4. 前記サービスを一意に識別する前記ＵＲＬペイロードは、アプリケーションＩＤである、請求項１〜３のいずれかに記載の方法。
5. 前記クライアント／サーバ間リモートアクセスシステムの前記クライアントと前記サービスの間、及び、サービス間の信頼を確立する認証コンポーネントを提供することをさらに含む、請求項１〜４のいずれかに記載の方法。
6. 前記認証コンポーネントがコラボレーションＵＲＬを前記クライアントに提供することと、
   前記コラボレーションＵＲＬを用いて、前記プロキシサーバで、第２のクライアントから第２の要求を受信することと、
   前記第２のクライアントを前記セッションに参加させることと、
   をさらに含む、請求項５に記載の方法。
7. 前記コラボレーションＵＲＬは、前記選択されたアプリケーションサーバを識別し、前記第２のクライアントを認証する、請求項６に記載の方法。
8. 前記セッションＵＲＬは、前記クライアントに関連付けられたユーザにマップされる、請求項５〜７のいずれかに記載の方法。
9. 前記クライアント／サーバ間リモートアクセスシステム内のリソース利用を前記スケジューラを用いて管理することをさらに含む、請求項１〜８のいずれかに記載の方法。
10. 前記スケジューラは、前記アプリケーションサーバが最も少ない数のサービスを実行していることに基づいて、前記アプリケーションサーバを選択する、請求項９に記載の方法。
11. 前記スケジューラは、前記アプリケーションサーバが利用可能な容量を有する最も長く実行している前記アプリケーションサーバであることに基づいて、前記アプリケーションサーバを選択する、請求項９〜１０のいずれかに記載の方法。
12. 前記スケジューラは、前記アプリケーションサーバの既存の実行中のサービスの状態に基づいて、前記アプリケーションサーバを選択する、請求項９〜１１のいずれかに記載の方法。
13. 前記スケジューラは、リアルタイムで前記セッションＵＲＬを作成して、前記サービスをホストする前記アプリケーションサーバに前記クライアントを導く、請求項９〜１２のいずれかに記載の方法。
14. 負荷、ハードウェア容量（例えば、ＣＰＵ、ＧＰＵ、メモリ）、ネットワーク要件、費用、または、地理的な位置の１つに従って、前記クライアント／サーバ間リモートアクセスシステム内のアプリケーションサーバを開始及び停止させるオーケストレータをさらに含む、請求項９〜１３のいずれかに記載の方法。
15. 前記スケジューラから前記オーケストレータに情報を提供し、現在のリソース配分に関する情報を受信し、需要に基づいて、前記アプリケーションサーバを自動的に開始または停止することをさらに含む、請求項１４に記載の方法。
16. サービスへのアクセスを提供するクライアント／サーバ間リモートアクセスシステムであって、
    リソースＵＲＬ（ユニフォームリソースロケータ）で利用可能なプロキシサーバであって、クライアントからの前記サービスへの接続要求を受信する前記プロキシサーバと、
    前記リソースＵＲＬのペイロードに従って、前記要求を認証する認証コンポーネントと、
    前記クライアント／サーバ間リモートアクセスシステムのリソースの利用状態に従って、前記サービスをホストするアプリケーションサーバであって、前記クライアントと前記サービスの間のセッションの確立に使用される前記ペイロードを含むセッションＵＲＬを作成する前記アプリケーションサーバを選択するスケジューラと、
    前記認証された要求に従って前記セッションＵＲＬに接続された前記クライアントと前記サービスの間の前記セッションを確立して、前記クライアントと前記サービスの間のアプリケーションデータと状態情報を通信するサービスマネージャと、
    を含む、前記クライアント／サーバ間リモートアクセスシステム。
17. コラボレーションＵＲＬが、前記認証コンポーネントによって前記クライアントに提供され、第２のクライアントからの第２の要求が、前記コラボレーションＵＲＬを用いて、前記プロキシサーバで受信され、前記第２のクライアントを、前記セッションに参加させる、請求項１６に記載のクライアント／サーバ間リモートアクセスシステム。
18. 前記コラボレーションＵＲＬは、前記アプリケーションサーバを識別し、前記第２のクライアントを認証する、請求項１７に記載のクライアント／サーバ間リモートアクセスシステム。
19. 前記クライアント／サーバ間リモートアクセスシステム内のリソース利用は、前記スケジューラを用いて管理され、前記スケジューラは、前記アプリケーションサーバが最も少ない数のサービスを実行していることに基づいて前記アプリケーションサーバを選択する、または、前記アプリケーションサーバが利用可能な容量を有する最も長く実行している前記アプリケーションサーバであることに基づいて前記アプリケーションサーバを選択する、または、前記アプリケーションサーバの既存の実行しているサービスの状態に基づいて前記アプリケーションサーバを選択する、請求項１６〜１８のいずれかに記載のクライアント／サーバ間リモートアクセスシステム。
20. 前記アプリケーションサーバを識別するペイロードパラメータを含むコラボレーションＵＲＬを前記認証コンポーネントが前記クライアントに提供することと、
    前記コラボレーションＵＲＬを用いて、第２のクライアントからの第２の要求を前記プロキシサーバで受信することと、
    前記第２のクライアントを前記セッションに参加させることと、
    をさらに含む、請求項１６〜１９のいずれかに記載のクライアント／サーバ間リモートアクセスシステム。
21. 前記コラボレーションＵＲＬは、前記第２のクライアントを認証する、請求項２０に記載のクライアント／サーバ間リモートアクセスシステム。
22. 前記スケジューラは、最も少ない数のサービスを実行している前記アプリケーションサーバを選択すること、前記アプリケーションサーバが利用可能な容量を有する最も長く実行しているアプリケーションサーバであることに基づいて前記アプリケーションサーバを選択すること、または、前記アプリケーションサーバの既存の実行中のサービスの状態に基づいて前記アプリケーションサーバを選択すること、という基準の１つに基づいて、前記アプリケーションサーバを選択する、請求項１６〜２１のいずれかに記載のクライアント／サーバ間リモートアクセスシステム。
23. 前記アプリケーションサーバは、前記サービスを前記クライアントに利用可能にする時、リアルタイムで、前記セッションＵＲＬを作成する、請求項１６〜２３のいずれかに記載のクライアント／サーバ間リモートアクセスシステム。