特許 6722184 サーバ要求にカプセル化されたコードを用いるマルチテナント機能

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6722184

(24)【登録日】2020年6月23日

(45)【発行日】2020年7月15日

(54)【発明の名称】サーバ要求にカプセル化されたコードを用いるマルチテナント機能

(51)【国際特許分類】

   G06F 9/455 20060101AFI20200706BHJP

   G06F 9/48 20060101ALI20200706BHJP

   G06F 21/53 20130101ALI20200706BHJP

【ＦＩ】

   G06F9/455 150

   G06F9/48 370

   G06F21/53

【請求項の数】22

【全頁数】19

(21)【出願番号】特願2017-527724(P2017-527724)

(86)(22)【出願日】2015年11月25日

(65)【公表番号】特表2017-539015(P2017-539015A)

(43)【公表日】2017年12月28日

(86)【国際出願番号】US2015062635

(87)【国際公開番号】WO2016086111

(87)【国際公開日】20160602

【審査請求日】2018年9月7日

(31)【優先権主張番号】62/084,511

(32)【優先日】2014年11月25日

(33)【優先権主張国】US

(31)【優先権主張番号】14/951,223

(32)【優先日】2015年11月24日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】517174913

【氏名又は名称】オース０，インコーポレイテッド

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】ヤンズク，トマシュ

(72)【発明者】

【氏名】ウロスキー，マティアス

【審査官】 杉浦 孝光

(56)【参考文献】

【文献】 特表２０１３−５４３１７１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１２／０１５９５２３（ＵＳ，Ａ１）

【文献】 特開２０１１−２３３１４６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４５５−９／５４

Ｇ０６Ｆ ２１／５３

(57)【特許請求の範囲】

【請求項1】

任意のアプリケーションのコンピュータ・ルーチンを実行するための環境を提供するように構成されたマルチテナント・インフラストラクチャ・サーバ（ＭＴＩＳ）であって、
プロセッサと、
通信ネットワークを介した通信を可能にするように構成された、前記プロセッサに結合されたネットワーク・インターフェースと、
コンテンツおよびプログラミング用の記憶装置と、
前記記憶装置に記憶されたプログラムであって、前記プログラムを実行することで前記マルチテナント・サーバが、
ウェブタスク・コンテナ内で前記コンピュータ・ルーチンを実行するための要求をウェブタスク・サーバから受信することであって、前記要求がクライアント・データを含むこと、
前記ＭＴＩＳにおいて、前記ウェブタスク・コンテナ内で前記コンピュータ・ルーチンを実行すること、
前記コンピュータ・ルーチンの実行に成功すると、結果のセットを前記ウェブタスク・サーバに戻すこと、
前記コンピュータ・ルーチンの実行に失敗すると、エラー通知を前記ウェブタスク・サーバに戻すこと、
前記コンピュータ・ルーチンの前記実行中に消費されたリソースを決定すること、および
前記ウェブタスク・コンテナを破棄して、前記ＭＴＩＳでの前記コンピュータ・ルーチンの永続的な記憶を防止することを含む動作を実行するように構成するプログラムと、を含み、
前記ウェブタスク・コンテナの前記破棄は、前記結果のセットまたは前記エラー通知が前記ウェブタスク・サーバによって受信されたという確認を、前記ウェブタスク・サーバから受信することに応答する、マルチテナント・インフラストラクチャ・サーバ（ＭＴＩＳ）。

【請求項2】

前記要求がウェブタスク・トークンを含む、請求項１に記載のＭＴＩＳ。

【請求項3】

前記要求が、前記コンピュータ・ルーチンを含まず、前記コンピュータ・ルーチンへのユニフォーム・リソース・アイデンティファイア（ＵＲＬ）リンクおよびクライアントの秘密を含む、請求項１に記載のＭＴＩＳ。

【請求項4】

前記要求は、ウェブタスク・トークンを含み、
前記プログラムを実行することでさらに、前記ＭＴＩＳが、前記ウェブタスク・トークン内に提示された前記ＵＲＬからコンピュータ・ルーチンを取り出すことを含む動作を実行するように構成する、請求項３に記載のＭＴＩＳ。

【請求項5】

前記ウェブタスク・トークンが、実行すべき前記コンピュータ・ルーチンおよびクライアントの秘密を含む、請求項２に記載のＭＴＩＳ。

【請求項6】

前記要求は、ウェブタスク・トークンを含み、
前記ウェブタスク・トークンが、暗号によってタンパリングおよび暴露から保護されている、請求項１に記載のＭＴＩＳ。

【請求項7】

前記ウェブタスク・コンテナが、前記ＭＴＩＳ内の分離された環境において実行される、前記コンピュータ・ルーチンの全ての依存関係を含む、請求項１に記載のＭＴＩＳ。

【請求項8】

前記分離された環境が、前記ＭＴＩＳ内のサンドボックスである、請求項７に記載のＭＴＩＳ。

【請求項9】

前記消費されたリソースが、前記コンピュータ・ルーチンの前記実行中に使用された処理能力およびメモリを含む、請求項１に記載のＭＴＩＳ。

【請求項10】

前記コンピュータ・ルーチンが、前記ＭＴＩＳのオペレーティング・システムから独立している、請求項１に記載のＭＴＩＳ。

【請求項11】

前記コンピュータ・ルーチンを実行する時間が、ＨＴＴＰ要求／応答サイクルに要する期間に制限される、請求項１に記載のＭＴＩＳ。

【請求項12】

前記ウェブタスク・サーバがＨＴＴＰサーバであり、前記要求がＨＴＴＰ要求である、請求項１１に記載のＭＴＩＳ。

【請求項13】

前記戻された結果が、Java（登録商標）Script Object Notation（ＪＳＯＮ）である、請求項１に記載のＭＴＩＳ。

【請求項14】

あるテナントのコンピュータ・ルーチンが、別のテナントのコンピュータ・ルーチンまたはデータにアクセスしないように、前記ＭＴＩＳが、各テナントについてデータ分離を提供する、請求項１に記載のＭＴＩＳ。

【請求項15】

任意のアプリケーションのコンピュータ・ルーチンを実行する方法であって、
マルチテナント・インフラストラクチャ・サーバ（ＭＴＩＳ）のウェブタスク・コンテナ内で前記コンピュータ・ルーチンを実行するための要求をウェブタスク・サーバから受信することであって、前記要求が、ウェブタスク・トークンおよびクライアント・データを含むことと、
前記ＭＴＩＳにおいて、前記ウェブタスク・コンテナ内で前記コンピュータ・ルーチンを実行することと、
前記コンピュータ・ルーチンの実行に成功すると、結果のセットを前記ウェブタスク・サーバに戻すことと、
前記コンピュータ・ルーチンの実行に失敗すると、エラー通知を前記ウェブタスク・サーバに戻すことと、
前記コンピュータ・ルーチンの前記実行中に消費されたリソースを決定することと、
前記ウェブタスク・コンテナを破棄して、前記ＭＴＩＳへの前記コンピュータ・ルーチンの永続的な記憶を防止することと、
を含み、
前記ウェブタスク・コンテナの前記破棄は、前記結果のセットまたは前記エラー通知が前記ウェブタスク・サーバによって受信されたという確認を、前記ウェブタスク・サーバから受信することに応答する、方法。

【請求項16】

前記ウェブタスク・トークンが、前記コンピュータ・ルーチンを含まず、前記コンピュータ・ルーチンへのユニフォーム・リソース・アイデンティファイア（ＵＲＬ）リンクおよびクライアントの秘密を含む、請求項１５に記載の方法。

【請求項17】

前記ウェブタスク・トークンにおいて提示される前記ＵＲＬから、コンピュータ・ルーチンと取り出すことをさらに含む、請求項１６に記載の方法。

【請求項18】

前記ウェブタスク・トークンが、実行すべき前記コンピュータ・ルーチンおよびクライアントの秘密を含む、請求項１５に記載の方法。

【請求項19】

前記ウェブタスク・コンテナが、前記ＭＴＩＳ内の分離された環境において実行される、前記コンピュータ・ルーチンの全ての依存関係を含む、請求項１５に記載の方法。

【請求項20】

前記コンピュータ・ルーチンを実行する時間が、ＨＴＴＰ要求／応答サイクルに要する期間に制限され、
前記ウェブタスク・サーバがＨＴＴＰサーバであり、
前記要求がＨＴＴＰ要求である、請求項１５に記載の方法。

【請求項21】

前記戻された結果が、JavaScript Object Notation（ＪＳＯＮ）である、請求項１５に記載の方法。

【請求項22】

あるテナントのコンピュータ・ルーチンが、別のテナントのコンピュータ・ルーチンまたはデータにアクセスしないように、各テナントについてデータ分離を提供することをさらに含む、請求項１５に記載の方法。

【発明の詳細な説明】

【背景技術】

【0001】

コンピュータ・アプリケーション・アーキテクチャは、複数のコンピュータにまたがって様々なコンピューティング機能を分散する傾向で推移してきた。実際には、現代のモバイル・アプリケーションおよびウェブ・アプリケーションの大部分が、分散アーキテクチャに基づいている。たとえば、クライアント／サーバ・アーキテクチャでは、フロントエンドとバックエンドの間でアプリケーション機能を分割することで、バックエンドのコンピューティング・リソースをいくつかのクライアント間で再使用するのに役立つ。このことはまた、クライアントとサーバの間に信頼境界線を生成し、これによって、サーバはデータまたは機能を保護するためのアクセス権を許可できるようになる。典型的なクライアント／サーバ・アプリケーションでは、クライアントは、それ自体を認証した後に処理するためのデータをバックエンドに提出し、このバックエンドは、保護されたリソースを使用してクライアントの要求を処理した後に応答する。

【0002】

アプリケーションの典型的なクラウド・バックエンド（たとえば、モバイルまたはウェブ）は、未使用の（raw）コンピューティング・リソース（たとえば、ＣＰＵ、メモリ、ディスク、ネットワークなど）、ならびに、クライアントのものとは異なるオペレーティング・システムおよびアプリケーション・フレームワークの機能を実現する。バックエンドは、アプリケーション・ロジックの一部分を実装するサーバ・コード、ならびにデータベースの接続ストリング、アプリケーション・プログラム・インターフェース（ＡＰＩ）、セキュリティキーなどの保護されたデータまたは機能にアクセスするのに、このコードが必要とする秘密をカプセル化する。

【0003】

バックエンド・コードをホスティングするインフラストラクチャを管理するには、様々なサーバのサイジング、プロビジョニング、およびスケーリング、オペレーティング・システム更新の管理、セキュリティ問題への対処、必要に応じたハードウェアの更新、次いで、起こり得る機能不良についてこれらの要素全てを監視することが必要になる場合がある。したがって、通常、バックエンドを管理するという後方支援業務に多くの努力が費やされる。この努力は、コンピュータ・アプリケーションを開発、最適化、および／または利用する際に費やすほうがよい。

【0004】

ここ何年か、クラウド・コンピューティングの人気が高まってきているが、それというのも、クラウド・コンピューティングによって、情報技術（ＩＴ）のコストが削減され、サーバ・コンピューティング機能がコモディティ／ユーティリティとして利用可能になるからである。これまで、コストを削減するための主な取組みは、サーバ・コンピューティング機能をクラウド・コンピューティング・ベンダに外部委託することによってＩＴスタッフを削減することであった。しかし現在では、競合するいくつかのクラウド・コンピューティング・ベンダが存在し、したがって、ここでコスト削減は本質的には主に技術的なものである。

【0005】

コストを削減するための１つの技術的な取組みは、アプリケーション密度を増大させることである。具体的には、アプリケーションをホスティングするには、メモリやＣＰＵなどのリソース・コストがかかる。これらのリソース・コストをアプリケーション間で共有するやり方がある場合、こうしたリソース・コストをこれらアプリケーション全体に分散することができる。したがって、仮想マシンのリソースを共有するためにマルチテナント機能の技術が現れてきて、それによってアプリケーション密度が増大する。

【0006】

物理マシンをプロビジョニングし、割り当てるためのコストは、仮想マシンをプロビジョニングし、割り当てるためのコストよりも高い。さらに、仮想マシンをプロビジョニングし、割り当てるためのコストは、マルチテナント・コンテナをプロビジョニングし、割り当てるためのコストよりも高い。最後に、コンテナ内のプロセスを実行するためのコストはさらに、スレッドを実行するためのコストよりも高い。理想的には、軽量なウェブ・アプリケーションのクラスの場合、各アプリケーションをスレッドごとに実行することで、アプリケーション密度を最大化することができる。しかし、オペレーティング・システムによって各プロセスはリソースを管理できるようになるが、オペレーティング・システムは、スレッド・レベルでリソースを管理するのに適切な機能を提供するわけではない。具体的には、マルチテナント・コンテナなどでは、様々なテナントの情報資産を互いに分離しなければならず、また資源使用を管理し測定して、サービス品質を維持し、クラウド・コンピューティング・ベンダによる課金処理を可能にしなければならない。

【0007】

アプリケーションの開発および市場投入に通常関連するインフラストラクチャの構築および維持を複雑にすることなく、顧客がウェブ・アプリケーションを開発、実行、および管理できるようにするサービスとしてのプラットフォーム（ＰａａＳ）ソリューションが存在するが、これには様々な問題がつきまとう。たとえば、既知のＰａａＳプラットフォームは、魅力的なコスト構造を実現できない場合があり、非同期プログラミング・モデル上で実行される場合もあり、計算の結果をポーリングすることが必要となり、これによって待ち時間に悪影響を及ぼす。さらに、既知のＰａａＳアーキテクチャは、コードをアップロードするだけでなく、永続的に記憶することも必要とする場合がある。次いでコードは、各事象を待って、そのタスクを完了する。しかし、コードがどこか他の場所で管理されることで、コピーまたはハッキングに対して脆弱になるという点で、このような手法にはセキュリティ上のリスクを伴う。本開示が記述されているのは、これらの考察などに関するものである。

【図面の簡単な説明】

【0008】

各図面は、ほんの一例として、本教示による１つまたは複数の実装形態を示すが、それらに限定されるものではない。各図において、同じ参照番号は、同じまたは類似の要素を指す。

【0009】

【図1】安全なマルチテナント環境において任意のアプリケーションのコードを実行するための、例示的なアーキテクチャを示す。

【図2】マルチテナント・コンテナにおいてコードを実行するためのデータ・フレームワークのブロック図を示す。

【図3】図１のマルチテナント・インフラストラクチャ・サーバとして使用してもよい、例示的なウェブタスク仮想マシンを示す。

【図4】マルチテナント・インフラストラクチャ環境においてコードを実行するための、高水準の例示的なコール・フロー・プロセスを示す。

【図5】クラウド上に存在してもよい、ネットワーク・コンピュータまたはホスト・コンピュータを示す。

【図6】ユーザ・インターフェース要素を備えるコンピュータを示す。

【発明を実施するための形態】

【0010】

本開示は一般に、仮想環境においてコンピュータ・ルーチンを実行する方法およびシステムに関する。本明細書において述べるコンピューティング環境は、コンピュータ・コードの形式でコンピュータ・ルーチンをコンピュータ開発者から受け取る。（１つまたは複数の）どのコンピューティング言語が、このルーチンで使用されているのか判定される。このルーチン専用のコンテナが作成され、その結果、ルーチン内の各言語と、このルーチンによって利用され、または呼び出される他の任意のインフラストラクチャとをサポートするようにプロビジョニングされる。したがって、このコンテナにより、ルーチンを、コードまたはそれへのリンク、システム・ツール、システム・ライブラリなど、実行すべき各要素を含む完全な環境に包含し、それによって、このルーチンは、その仮想宛先環境で確実に実行されることになる。この仮想宛先環境は、メモリ、処理能力、ネットワーキングなどを含め、ルーチンを実行するのに必要となる未使用のリソースを提供する。既知の手法とは異なり、ルーチンは、停止時に記憶装置にはアップロードされず、各イベントにはマッピングされず、宛先コンピューティング環境（すなわち仮想マシン）においては停止時に記憶されない。むしろ、ルーチンは、コードが再び実行されることを予測せずに、実行のために、対応する環境を有する仮想マシンにルーティングされる。したがって、コードは停止時には記憶されず、コードの実行が完了すると破棄される。

【0011】

このルーチンを実行する要求は、それが仮想宛先環境のゲスト・オペレーティング・システムに無関係であるという点で、任意のアプリケーション向けでもよい。コンピュータ・ルーチン実行要求は、マルチテナント機能インフラストラクチャで処理してもよく、それによって分離機能および測定機能を実現する。マルチテナント機能インフラストラクチャに結びついた言語が利用可能な場合、各要求は任意のプログラミング言語で表してもよい。

【0012】

有利には、それにより、コンピュータ・ルーチン（たとえばアプリケーション）をインストールし、それを実行する必要性がなくなり、これによってメンテナンス、スケーラビリティ、セキュリティ、およびサポートが簡単になる。さらに、一実施形態では、クラウド・コンピューティングを使用することによって、事前のインフラストラクチャ・コストを回避するのに役立ち、企業がそのコードをさらに素早く実行できるようになり、扱いやすさが改善し、メンテナンスが少なくて済む。実行すべきコードは、そのコンテナ内で分離されており、このコンテナは実行が完了すると破棄されるので、追加のセキュリティが設けられる。

【0013】

（例示的なシステム・アーキテクチャ）
図１には、安全なマルチテナント環境において任意のアプリケーションのルーチンを実行するための、例示的なアーキテクチャが示してある。システム１００は、クライアント１０２、ウェブタスク・サーバ１０７、複数のコンテナを含んでもよいマルチテナント・インフラストラクチャ・サーバ（ＭＴＩＳ）１４０、およびオンライン・ファイル記憶サーバ１３２を含む。システム１００の様々な構成要素間の通信を容易にする、ネットワーク１３０が存在する。ネットワーク１２０は、それだけには限らないが、ローカル・エリア・ネットワーク（「ＬＡＮ」）、仮想プライベート・ネットワーク（「ＶＰＮ」）、セルラー・ネットワーク、またはインターネットでもよい。したがって、クライアントは、ネットワーク１３０を介してウェブタスク・サーバ１０７と通信して、処理すべき任意のアプリケーションのコンピュータ・ルーチンを送信し、対応する処理結果をそこから受信することができる。一実施形態では、ウェブタスク・サーバ１０７にルーチンを送信する代わりに、オンライン・ファイル記憶サーバ１３２など、ルーチンのコードが記憶されるリポジトリにリンクが送信される。

【0014】

ウェブタスク・サーバ１０７は、クライアント１０２から情報を受信し、ＭＴＩＳ１４０で分離して実行されるインフラストラクチャを含む完全なパッケージ内にルーチンを包含するように構成される。次いで、ウェブタスク・サーバ１０７は、この「パッケージ」をＭＴＩＳ１４０に送信する。ウェブタスク・サーバ１０７は、コンピュータ・ルーチンが使用する全ての情報を有するコンテナを、ＭＴＩＳ１４０に要求する。次いで、ウェブタスク・サーバ１０７は、ＭＴＩＳ１４０によって指定されたコンテナに、パッケージの形式でメタデータとともにコンピュータ・ルーチンを送出する。次いで、コンテナは、メタデータに従ってパッケージ内のルーチンを実行する。コンテナは、ルーチンを実行した結果をウェブタスク・サーバ１０７に戻す。次いで、ウェブタスク・サーバ１０７は、この結果をクライアント１０２に（たとえば、そのブラウザ上に）戻す。

【0015】

ＭＴＩＳ１４０は、クラウド上で動作してもよく、ウェブタスク・サーバ１０７から受信されたコンピュータ・ルーチンを実行するのに使用される未使用のコンピューティング・リソースを含んでもよい。実行すべきこのルーチンは、ＭＴＩＳ１４０に記憶されないという点で非永続性である。そうではなく、コンピュータ・ルーチンの実行が完了すると、このルーチンは破棄される。

【0016】

（例示的な機能ブロック）
次に図２を参照すると、図２には、マルチテナント・コンテナ内のコード（たとえばコンピュータ・ルーチン）を実行するためのデータ・フレームワークのブロック図が示してある。システム１００には、クライアント１０２が、ネットワーク１３０を介してサーバ１０４と通信している様子が示してある。

【0017】

サーバ１４０は、クラウド上で動作してもよく、ＣＰＵ、メモリ、ディスクなど未使用のコンピューティング・リソース１４２、ならびにオペレーティング・システム１４４を含んでもよい。したがって、サーバ１４０は、未使用のコンピューティング・リソース１４２およびオペレーティング・システムを提供し、これらをクラウド・コモディティとして見ることができる。サーバ１４０は、実行すべきコンピュータ・ルーチンの形式のアプリケーション用のバックエンドを提供する。サーバ１４０から明らかに欠けているものは、アプリケーション・ロジックの一部分を実装するサーバ・コード、ならびにデータベースの接続ストリング、ＡＰＩキーなどの保護されたデータまたは機能にアクセスするのに、このコードが必要とする秘密である。サーバ・コードと秘密の両方とも、１つのバンドル１０８にともにシリアル化されたデータであり、クライアント１０２で見つけることができる。さらに、一実施形態では、サーバ・コードの全てをクライアント１０２のバンドル１０８に記憶する代わりに、このコードは、GitHub（登録商標）またはAmazon（登録商標） Simple Storage Service(S3)など、ユニフォーム・リソース・アイデンティファイア（ＵＲＬ）１１０で参照することのできる位置へと外部に置かれる。したがって、このコードは、オンライン・ファイル記憶サーバ１３２にリンクすることができる。

【0018】

任意のアプリケーション（または、それへのＵＲＬリンク）１１０用のコード（たとえばコンピュータ・ルーチン）、およびクライアントの秘密１１２を含むバンドル１０８は、本明細書においてはウェブタスク・トークン１１０と呼ばれ、これは、実行するために秘密とともにバックエンド・アプリケーション・ロジックを定義する。一実施形態では、これは、暗号によってタンパリングおよび暴露から保護される（１１４）。これは、安全に記憶することができ、またはネットワーク１３０のような信頼できないチャネルを通過することができる。

【0019】

ウェブタスク・トークン１１０を暗号解読し、暗号解読済みの内容をサーバ１４０（たとえばＭＴＩＳ）に提供するのは、ウェブタスク・サーバ（たとえば、図１の１０７）である。たとえば、ウェブタスク・サーバ１０７によって暗号解読が実行されるが、それというのも、サーバ１４０（たとえばＭＴＩＳ）内のウェブタスク・コンテナは、信頼できないコード実行し、したがってウェブタスク・トークン１１０を暗号解読するための暗号鍵が付与されないからである。

【0020】

ウェブタスク・トークン１０８は、コード（たとえばコンピュータ・ルーチン）自体ではなくサーバ・コードへのＵＲＬリンク１１０を含んでもよいので、今日の帯域幅の標準を考慮すれば、トークンのシリアル化されたサイズは比較的小さい。したがって、ウェブタスク・トークン１０８は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を含め、様々なプロトコルでのペイロードの一部として巡回できる柔軟性を提供する。図１の例では、ウェブタスク・トークンは、クライアント１０２のアプリケーション自体に記憶される。したがって、ウェブタスク・トークン１０８に含まれるバックエンドの秘密１１２をクライアント１０２の末端部に保持することによって、この秘密は、暗号化１１４によって暴露から安全な状態が保たれる。したがって、ウェブタスク・トークンは、タンパリングおよびスプーフィングに耐性がある。

【0021】

要求１２４が、クライアント１０２から発生し、ネットワーク１３０を介してサーバ１４０に送信されて、任意のアプリケーション用のコンピュータ・ルーチンが実行されるとき、この要求１２４は、クライアント特定データ１０６ならびにウェブタスク・トークン１０８を含んでもよく、ウェブタスク要求を生成する。したがって、ウェブタスク要求は、クライアント１０２からの要求１２４であり、これは、通常のクライアント要求データ１０６に加えてウェブタスク・トークン１１０を含む。

【0022】

一実施形態では、サーバ１４０は、ウェブタスク要求１２４（すなわち、ウェブタスク・トークン１０８およびクライアント・データ１０６を含む）を受信し、ウェブタスク・トークン１０８で提示されたＵＲＬ１１０に基づいてオンライン・ファイル記憶装置１３２からコンピュータ・ルーチンを取り出し、適切なコンピューティング・リソース１４２を適用して、ウェブタスク要求を実行する。したがって、サーバ１４０は、特定のアプリケーション・ロジックに焦点を当てる代わりに、任意のウェブタスク要求を実行するための汎用の実行環境を提供する。ウェブタスク用の汎用な統一実行環境を実現するサーバ１４０などのサーバは、本明細書においてＭＴＩＳと称される場合がある。

【0023】

一実施形態では、汎用のままにするため、ＭＴＩＳ１４０は、全てのウェブタスク用に統一実行環境を提供する。したがって、ＭＴＩＳ１４０上で実行される様々なアプリケーションのバックエンド・ロジックは、オペレーティング・システム（ＯＳ）１４４およびプリインストールされたソフトウェア・パッケージによって提供される同じ機能にアクセスする。

【0024】

ウェブタスク・モデルによって課せられるアプリケーション特有の状態の欠如とともに、ＭＴＩＳ１４０の統一性により、従来のバックエンドを上回るいくつかの利点を有する。たとえば、様々な異種のアプリケーションによって、ウェブタスク・ランタイムを容易にスケーリングすることができる（１０４）。したがって、これにより、アプリケーション・ロジック層は、大規模なデータ・センターがハードウェア・レベルで利用するのと同じ規模の経済をいくぶん活用できるようになる。したがって、ＭＴＩＳ１４０は、既知のＰａａＳよりも高い抽象レベルで、アプリケーション・ロジック処理のコモディティ化を可能にする。

【0025】

（信頼できないコンピュータ・ルーチンをサンドボックスするための例示的なマルチテナント・モデル）
一実施形態では、ＭＴＩＳ１４０のアーキテクチャはマルチテナントである。マルチテナント機能とは、コンピュータ・ルーチン（たとえばソフトウェア）の単一のインスタンスが、複数のテナントにサービス提供しながらサーバ上で実行されるアーキテクチャを指す。テナントは、ソフトウェアへの特定の権限を有する共通のアクセス権を共有する一群のユーザを含む。このようなマルチテナント・アーキテクチャを用いる場合、ソフトウェア・アプリケーションは、データ、構成、ユーザ管理、テナント個々の機能、ならびに非機能特性の共有分を、あらゆるテナントに提供する。先に述べたように、本明細書において述べるＭＴＩＳ１４０のマルチテナント機能アーキテクチャは、アプリケーション密度を増大させる。

【0026】

ＭＴＩＳ１４０のマルチテナント・アーキテクチャにおいて考えるべき１つの問題は、あるテナントの悪質な（または、単に書き方の悪い）コンピュータ・ルーチンが、別のテナントのデータにアクセスするのをどのように防止するかである。この点に関しては、本明細書において述べるウェブタスク要求は、ＭＴＩＳ１４０においてサンドボックスを呼び出してもよい。サンドボックスは、実行中のプログラムを分離するためのセキュリティ・メカニズムである。これは、メモリ上の専用空間など、ゲスト・プログラムが実行される厳重に制御されたリソースのセットを提供する。そのために、Docker（登録商標）を使用して、ウェブタスク要求周りに安全な（コンテナ）サンドボックスを生成してもよい。たとえば、Dockerは、コンテナ技術を使用してインフラストラクチャからアプリケーションを分離し、これは、仮想マシンがオペレーティング・システムをベア・メタルから分離する方法に似ている。ウェブタスク要求は、コンピュータ・ルーチンへのリンクを提供し、ランタイム、システム・ツール、システム・ライブラリなど、実行すべき構成要素を本質的に含む完全なファイル・システムにコンピュータ・ルーチンを包含するDockerコンテナとして実装してもよく、それにより、確実にその宛先環境（すなわちＭＴＩＳ１４０）で実行されることになる。

【0027】

一実施形態では、ウェブタスク要求１２４を使用して実行されるカスタム・コンピュータ・ルーチンは、ＨＴＴＰ要求のコンテキスト内にある。実行時間は、ＨＴＴＰ要求の通常の存続期間に制限してもよい。言い換えれば、ウェブタスク要求１２４の持続時間は、ＨＴＴＰ要求／応答サイクルまたは同様のサイクルが満たすのに十分なだけ短い。

【0028】

たとえば、ウェブタスク要求１２４は、ウェブタスク要求１２４の本体内のサーバ・コード（または、それへのリンク）を含む、クライアント１０２からのＨＴＴＰ ＰＯＳＴ要求を受け取る。一実施形態では、ウェブタスク要求１２４はまた、ウェブタスク・コンテナ名を指定し、これは、ＭＴＩＳ１４０でコンピュータ・ルーチンが実行されることになる分離境界線を表す。顧客とウェブタスク・コンテナの１対１のマップが存在する場合があり、これは、ある加入者に関連するコンピュータ・ルーチンが、別の加入者のコンピュータ・ルーチンから常に分離されていることを意味する。ＭＴＩＳ１４０は、本明細書ではウェブタスク・コンテナと呼ばれることもある、分離された環境でカスタム・コンピュータ・ルーチンを実行し、その結果とともに応答を送信して戻す。一実施形態では、この応答は、JavaScript（登録商標） Object Notation(ＪＳＯＮ)である。したがって、ウェブタスク要求１２４を介して提供されるカスタム・コンピュータ・ルーチンは、全てのテナントにわたる統一環境において実行される。

【0029】

ウェブタスク要求１２４は、コンピュータ・ルーチン（または、それへのリンク）、ならびにその実行中に必要となるコンテキスト・データを含む。たとえば、クライアント１０２は、JavaScript関数閉包を実行依頼する。ＭＴＩＳ１４０は、その関数を呼び出し、単一のコールバック・パラメータを提供する。ウェブタスク要求でのカスタム・コンピュータ・ルーチンは、ウェブタスク・コンテナでの実行を終了すると、コールバックを呼び出し、エラーまたは単一の結果値を表示する。一実施形態では、その結果値は、次いでＪＳＯＮとしてシリアル化され、ＨＴＴＰ応答においてクライアント１０２に戻される。

【0030】

一実施形態では、ＭＴＩＳ１４０は、Node.Jsに基づいており、これによって、カスタム・コンピュータ・ルーチンが、ウェブタスク環境で事前に与えられるNode.Jsモジュールの固定セットを利用できるようになる。サポートされるモジュールのセットは、様々な拡張性シナリオの特定の要求条件によって提供されることがある。ＭＴＩＳ１４０内の全てのテナントにわたるコンピューティング環境の統一性により、要求１２４が到着したときに、あらかじめ準備された様々なウェブタスク・コンテナのプールを各テナントに割り当てる準備ができているようにすることが可能になる。これによって、コールド・スタートアップの待ち時間が短くなる。

【0031】

ＭＴＩＳ１４０は、ウェブタスク要求１２４を処理するためのリソースを割り当てる際に、オーバヘッドの量を低減するように構成される。リソース割当てオーバヘッドは、仮想マシンの生成、プロセスの生成、スレッドの生成、およびメモリの割当ての形で生じる場合がある。したがって、ＭＴＩＳ１４０は、リソース・プールを使用してもよい。

【0032】

一実施形態では、Docker（オープン・ソース）が提供するコンパートメントなど、サード・パーティのインフラストラクチャ・コンパートメントを使用して、コンピュータ・ルーチン環境を分離することができる。Dockerは単に、環境を取り除くが、マルチテナント機能を提供しない。ベンダのクラウド・インフラストラクチャ、および／またはＭＴＩＳ１４０による要求によって、仮想マシンをプールしてもよい。

【0033】

ＭＴＩＳ１４０は、プロセス・プールを生成することができ、プロセスを割当て解除する代わりに、このプロセスをプールに戻すことができる。しかし実際には、クラウド・オーバヘッドを低減するために、割り当てられたプロセスの数は１桁でもよいが、それというのも要求は単一スレッドであると考えられるからである。Java（登録商標）仮想マシンまたはNode.Jsランタイムなどの実行環境によって、プロセス管理を管理することもできる。

【0034】

ＭＴＩＳ１４０はまた、v8::isolateおよびv8::contextなど、分離およびコンテキストのプリミティブを使用して、分離した方式でコンピュータ・ルーチンを確実に実行してもよい。一実施形態では、ＭＴＩＳ１４０は、それ自体のメモリを管理してもよい。あるいは、Java仮想マシンまたはNode.Jsなどの実行環境が、それ自体のメモリを管理してもよい。実行環境は、それ自体のメモリ・アロケータ、およびそれ自体のガーベッジコレクションを有してもよいことに留意されたい。

【0035】

一実施形態では、分離プリミティブを使用することによってセキュリティを実装してもよい。具体的には、実行環境は、それぞれのサンドボックスにおいてコンピュータ・ルーチンを実行してもよい。追加のセキュリティおよび認証は、ＭＴＩＳ１４０によって実行してもよい。より典型的には、初期認証は、クラウド・インフラストラクチャへのパブリック・アカウント向けでもよい。したがって、認証は、要求ごとにおこなう必要はなく、それによって性能が改善される。

【0036】

一実施形態では、実行環境（すなわち、ＭＴＩＳ１４０）によって言語結合が管理される。結合は、実行環境に固有のものでもよく、または代替的に、通常はダイナミック・リンク・ライブラリの形式のアドオンを介してもよい。（様々な言語での）実行環境を動的に見い出だすこともできる。なぜなら、様々な実行環境で事前構成し得るサンドボックスにより、プログラムに従ってこうした実行環境を列挙することができるからである。したがって、ＭＴＩＳ１４０は、サンドボックスの生成／呼出しを実行しなくてはならないのではなく、何がサポートされているのか決定し、エラー・メッセージで迅速に応答することができる。

【0037】

事前コンパイルは、ＭＴＩＳ１４０を介して実装される最適化となる場合がある。たとえば、ウェブタスク要求１２４内に埋め込まれたコンピュータ・ルーチンは、ソース・コードではなくバイトコードでもよい。ストアドプロシージャが呼び出される場合、サーバ側のデータベースが、ストアドプロシージャを事前コンパイルしている場合もある（このストアドプロシージャは、ＭＴＩＳ１４０に常駐していてもよいことに留意されたい）。このようにして、もっぱら、送信されたコンピュータ・ルーチンのパラメータに応じて、ウェブタスク要求１２４を生成することができる。

【0038】

様々な実施形態では、本明細書に記載のマルチテナント・システムは、安全なコンピュータ・ルーチン実行のための様々な保証を提供する。第１に、あるテナントのコンピュータ・ルーチンが、別のテナントのコンピュータ・ルーチンまたはデータにアクセスできないデータ分離が存在する。たとえば、あるテナントが、埋込み式パスワードを有する接続ストリングまたはＵＲＬを使用して、カスタム・データベースにアクセスするコンピュータ・ルーチンまたはデータを実行する場合、同じシステム内で実行される別のテナントのコンピュータ・ルーチンは、そのパスワードを見つけることができない。

【0039】

第２に、ＤＯＳ（Denial of Service）攻撃を軽減するための、制御されたリソース消費が実現する。そのために、一実施形態では、ウェブタスク要求１２４のサンドボックスにより、ある任意のテナントが使用できるメモリ、ＣＰＵ、および他のシステム・リソースの量を制限する。

【0040】

次に図３を参照する。図３には、図１のＭＴＩＳ１４０として使用してもよい、例示的なウェブタスク仮想マシン（ＶＭ）が示してある。あるテナントのコンピュータ・ルーチンおよびデータを別のテナントから分離するために、あらゆるテナントのコンピュータ・ルーチンが、サンドボックス３１０内のそれ自体のウェブタスク・コンテナ（たとえばDocker）において実行される。ＨＴＴＰ要求は、ＭＴＩＳ１４０などのウェブタスクＶＭに到達すると、まずプロキシ３０６によって処理される。プロキシ３０６は、テナントとコンテナの間の関連付けを表す状態を維持する。一実施形態では、プロキシ３０６は、ｅｔｃｄ構成を見て、ウェブタスク・コンテナが特定のテナントについて既に割り当てられているかどうか判定する。割り当てられている場合、プロキシ３０６は、そのウェブタスク・コンテナ３１０に要求を転送する。割り当てられていない場合、プロキシは、ウェブタスク・クラスタで利用可能な、あらかじめ準備されたウェブタスク・コンテナのプールから、そのテナント用の新規のウェブタスク・コンテナを割り当てる。次いで、プロキシは、後続の要求のために、ｅｔｃｄ（すなわち、クラスタ内の全てのコンピュータにわたって実行され、動的構成レジストリを提供して、様々なコンフィギュレーション・データがクラスタ・メンバー間で共有できるようにするデーモン）に、その関連付けを記録する。

【0041】

全てのテナント向けの統一実行環境によって、ウェブタスク・コンテナのあらかじめ準備されたプールが可能になる。Dockerコンテナの起動待ち時間が元々短いことを考慮に入れたとしても、あらかじめ準備されたコンテナをプールから取り出すことができることにより、実行中のコンテナのプロビジョニングと比較して、コールド・スタートアップの待ち時間が短縮される。

【0042】

一実施形態では、任意の単一のウェブタスク・コンテナは、単一のテナントのために複数の並行要求を処理できるようにする、簡略なＨＴＴＰサーバに過ぎない。特定のウェブタスク・コンテナ内で実行される要求は、互いに分離されることがない。ウェブタスク・コンテナの存続期間は、制御装置デーモンによって管理され、このデーモンは、信頼できるDockerコンテナにおいて実行され、したがって、事前構成された存続期間管理ポリシーに従って、クラスタ内で任意のウェブタスク・コンテナを終了することができる。

【0043】

一実施形態では、あらゆるテナントのコンピュータ・ルーチンを、それ自体のDockerコンテナ３１０において実行するのに加えて、イグレス・ファイアウォール・ルールがウェブタスク・クラスタ内に構成される。これらのルールにより、あるウェブタスク・コンテナ内の信頼できないコンピュータ・ルーチンが、他のウェブタスク・コンテナまたはウェブタスクインフラストラクチャと通信しないようになる。ウェブタスク・コンテナのＨＴＴＰサーバは、（たとえば、Dockerによって生成された）ブリッジ３０８によってホストのネットワークから分離されたローカル・ネットワーク上で実行されているので、ファイアウォール・ルールを設定することが可能である。一実施形態では、ウェブタスク・コンテナ内で実行されるコンピュータ・ルーチンは、公衆インターネットに向かうアウトバウンド・コールを開始することができる。これにより、カスタム・コンピュータ・ルーチンから外部データ・ソースまでのアウトバウンド通信、および顧客のデータベースまたは企業のエッジ・サービスなどのサービスが可能になる。

【0044】

メモリおよびＣＰＵの消費を制限するため、（たとえば、Docker（登録商標）が提供する）制御グループ（cgroups）メカニズムを使用してもよい。cgroupsは、Linux（登録商標）によってサポートされているメカニズムであり、Docker（登録商標）は、cgroups上に構築された技術であることに留意されたい。さらに、あらゆるウェブタスク・コンテナは、一時的なLinuxユーザを生成してもよく、起動時のこのユーザ向けのプラグ可能な認証モジュール（ＰＡＭ）制限を構成する。これら２つのメカニズムはともに、Fork爆弾など、メモリおよびＣＰＵへの一連の攻撃を防止するのに役立つ。

【0045】

（例示的なコール・フロー・プロセス）
サーバ要求システムにおいてカプセル化されたコードを用いたマルチテナント機能の前述の概要によれば、次に、例示的なコール・フロー・プロセスのハイレベルの考察を加えることが役立つ場合がある。そのために、図４には、マルチテナント・インフラストラクチャ環境においてコード（たとえばコンピュータ・ルーチン）を実行するための、例示的なハイレベルのコール・フロー・プロセスが示してあり、ここで、実行されたコンピュータ・ルーチンは非永続的なものである。コール・フロー・プロセス４００は、論理的なコール・フローでの一群のステップとして示してあり、これは、ハードウェア、ソフトウェア、またはその組合せで実装することのできる一連の動作を表す。ソフトウェアにおいて、各ステップは、１つまたは複数のプロセッサが実行するときに前述の動作を実行する、コンピュータ実行可能命令を表す。一般に、コンピュータ実行可能命令には、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれており、これらは、特定の機能を実行し、または特定の抽象データ型を実装する。各動作を説明する順序は、限定的に解釈すべきものではなく、説明された任意の数のブロックを任意の順序で、かつ／またはこのプロセスを実施するのと並行して組み合わせることができる。議論を進めるため、図１のシステム１００を参照してプロセス４００を説明する。例示的なコール・フロー４００では、クライアント１０２、ウェブタスク・サーバ１０７、およびマルチテナント・インフラストラクチャ・サーバ（ＭＴＩＳ）１４０がクラウド内に存在する。

【0046】

ステップ４０８では、開発者が、自身のコンピューティング装置上で実行されるコード（たとえばコンピュータ・ルーチン）を作成し、これがクライアント１０２でのフロー４００で表してある。一実施形態では、コンピュータ・ルーチンは、オンライン・ファイル記憶サーバ１３２に記憶される。

【0047】

ステップ４１０では、ウェブタスク・サーバ１０７との接続が確立され、明確に定義されたエンドポイントに要求が送信され、ここで、実行される任意のアプリケーション用のコンピュータ・ルーチンは、この要求のパラメータである。ウェブタスク要求１２４は、ウェブタスク・トークン１０８ならびにクライアント・データ１０６を含む。様々な実施形態では、ウェブタスク・トークン１０８は、コンピュータ・ルーチン（または、コンピュータ・ルーチン１３０を記憶するオンライン・ファイル記憶装置へのＵＲＬリンク）、およびこのコンピュータ・ルーチンに関連するクライアントの秘密１１２を含んでもよい。一実施形態では、ウェブタスク・サーバ１０７がクライアント１０２から到達できない場合、接続失敗のエラーがクライアント１０２に戻される。そのために、コンピュータ・ルーチンは、このエラーに対処するためのハンドラを備えてもよい。

【0048】

ステップ４１２では、ウェブタスク・サーバ１０７が、クライアント・データ１０６とともにウェブタスク・トークンを受信し、使用されるコンピュータ・ルーチンのタイプを決定する。このコンピュータ・ルーチンに基づいて、ウェブタスク・サーバ１０７は、ウェブタスク・トークン１０８およびクライアント・データを含むウェブタスク要求１２４を作成する。様々な実施形態では、ウェブタスク・トークンは、ＭＴＩＳ１４０内で分離して実行される構成要素を含む完全な環境にコンピュータ・ルーチンを包含する、マルチテナント・コンテナ（たとえばDockerなど）を呼び出してもよい。このコンテナは、本明細書においてウェブタスク・コンテナと呼ばれることがある。

【0049】

一実施形態では、ウェブタスク・サーバ１０７はＨＴＴＰサーバであり、クライアント１０２とウェブタスク・サーバ１０７の間での通信４１０中の接続はＨＴＴＰ接続であり、ウェブタスク・トークンおよびデータ１０６を含むウェブタスク要求１２４はＨＴＴＰ要求である。あるいは、単一の汎用型エンドポイントのみが開発者に公開されている場合、他のプロトコル、すなわち遠隔手続き呼出し（ＲＰＣ）を使用してもよい。

【0050】

ステップ４１４では、ウェブタスク・サーバ１０７が、ウェブタスク要求１２４をＭＴＩＳ１４０に送信する。この点に関しては、ウェブタスク・サーバ１０７は、ＭＴＩＳ１４０から、コンピュータ・ルーチンが使用する全ての情報を有するコンテナを要求する。一実施形態では、ＭＴＩＳ１４０は、サポートされている様々な言語についての言語結合を含んでもよい。たとえば、ＭＴＩＳ１４０は、JavaScript結合およびＣ＃結合を有してもよい。サポートされていない言語が要求に入ってくると、ＭＴＩＳ１４０は、適切なエラー・メッセージを提示してもよい。

【0051】

ステップ４１６では、ＭＴＩＳ１４０が、実行されるコンピュータ・ルーチン抽出し、ＭＴＩＳ１４０の分離された環境（たとえばウェブタスク・コンテナ）で、このコンピュータ・ルーチンを実行する。ウェブタスク・コンテナは、ＭＴＩＳ１４０のサンドボックス環境内で実行してもよい。ＭＴＩＳ１４０はまた、ウェブタスク・サーバ１０７が使用するプロトコルと互換性のある形式での応答を構成する。様々な実施形態では、この応答は、ＸＭＬ、ＪＳＯＮなどでもよい。したがって、ＭＴＩＳは、受信したウェブタスク要求について、汎用な統一実行環境を提供する。

【0052】

一実施形態では、課金目的のため、ＭＴＩＳは、要求識別（ＩＤ）に関連付けられた、ＭＴＩＳ１４０のウェブタスク・コンテナ内でのコンピュータ・ルーチンの実行中に消費されてきたリソース（たとえば、ＣＰＵ、メモリなど）を追跡する（すなわちステップ４１８）。ＭＴＩＳ１４０は、ウェブタスク・サーバ１０７が生成した要求ＩＤを使用し、要求ＩＤを、JavaScriptランタイム、オペレーティング・システムのいずれかからのスレッドＩＤ、またはＭＴＩＳ１４０によって内部で生成されたスレッドＩＤと関連付けてもよい。一実施形態では、使用されるスレッド・リソースを要求ＩＤに関連付けることによって、要求ごとに消費されるリソースに関する測定が実現する。リソース追跡は、ＣＰＵ、メモリ（たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、ハードディスク）に限定する必要はなく、コンピュータ・ルーチンの実行中に利用されるネットワーク・リソースなど、任意の測定可能なリソースを含むことができる。

【0053】

一実施形態では、ステップ４２０において、ＭＴＩＳが、ウェブタスク・サーバ１０７に応答を送信する。この応答は、ＭＴＩＳ１４０で実行されたコンピュータ・ルーチンに基づいて計算された結果でもよい。ＭＴＩＳが要求を満たせないか、または要求を時間内に満たせない場合、ＭＴＩＳは、適切な応答（すなわちエラー・メッセージ）でウェブタスク・サーバに応答を返してもよい。したがって、ＭＴＩＳからの応答は、実行されたコンピュータ・ルーチンまたは適切なエラー・メッセージに基づいて計算された結果でもよい。

【0054】

ステップ４２２では、この応答が、ウェブタスク・サーバ１０７からクライアント１０２に転送される。あるいは、またはさらに、この応答は、ＭＴＩＳからクライアント１０２に直接転送してもよい。

【0055】

場合によっては、ステップ４２４において、結果がウェブタスク・サーバによって受信されたという確認が、ウェブタスク・サーバからＭＴＩＳ１４０によって受信されてもよい。ステップ４２６では、ＭＴＩＳ１４０が、リソース割当て解除を適宜実行する。一実施形態では、使用されてきたコンテナはプールに戻されず、むしろ、廃棄されて置き換えられる。ＭＴＩＳ１４０は、ウェブタスク・コンテナを破棄し、それにより、コンピュータ・ルーチンは停止時に記憶されないことが確実になる。

【0056】

（例示的な使用事例）
コンピュータ・ルーチンをサーバ要求にカプセル化するシステムおよび方法の先に述べた説明では、いくつかの例示的な使用事例のハイレベルな考察が役立つこともある。本明細書において述べる概念およびシステムは、様々な使用事例に適用することができる。たとえば、これらは、分散アプリケーションに適用してもよく、ここで、アプリケーションを設計して別々の構成要素にしてもよく、それぞれは、他と独立して動作するように設計される。これら別々の構成要素により、ＭＴＩＳ１４０を介して実行されるコンピュータ・ルーチンを、様々なインスタンスに送信することができる。

【0057】

一例では、本明細書に記載のシステムを、オフロード用に使用することができる。そのために、アプリケーションは、ＭＴＩＳ１４０を使用して、ローカルまたは遠隔にルーチンを実行してもよい。ローカルなコンピューティング・リソースが利用可能でなく、または不十分な状況では、アプリケーションは、ＭＴＩＳ１４０を介して、コンピューティング要求をクラウドにオフロードしてもよい。

【0058】

一例では、本明細書において述べる概念は、ウェブ・サービスを作成するのに使用することができる。アプリケーションは、コンピュータ・ルーチンに埋め込まれた様々な機能に役立つスクリプトを、エンド・ユーザが作成するための機構を提供してもよい。スクリプトには、ＭＴＩＳ１４０を介してクラウド上で実行してもよいものがある。

【0059】

一例では、本明細書に記載のシステムを、非同期実行アプリケーションで使用することができる。このような状況では、ＭＴＩＳ１４０上で実行されるコンピュータ・ルーチンは、同期して実行する必要がない。この点に関しては、ウェブタスク・サーバ１０７は、長寿命／長期間プロセス用のディスパッチャの役割を果たしてもよい。

【0060】

一例では、本明細書において述べる概念は、垂直アプリケーション／セキュリティ用に使用してもよい。セキュリティＡＰＩを実装して、サンドボックスを維持するマルチテナント・インフラストラクチャ・サーバ・アプリケーションで実行してもよい。一実施形態では、ＭＴＩＳ１４０は、クライアントとマルチテナント・インフラストラクチャ・サーバ・アプリケーションとの間の接続をセキュリティ保護するための暗号化をサポートしてもよい。コンピュータ・ルーチンがＭＴＩＳ１４０に常駐しておらず、また全てのコンピュータ・ルーチンが安全なサンドボックス内で実行されるので、ＭＴＩＳ１４０は、セキュリティＡＰＩを介して公開されるように、認証機能にとって安全な実行環境を提供する。セキュリティに関しては、一実装形態では、ＭＴＩＳ１４０を使用して、多層アプリケーションでのプロキシ・レベルで、認証機能、許可機能、監査機能、および／または測定機能を実装することができる。

【0061】

（例示的なコンピュータ・プラットフォーム）
前述の通り、ウェブタスク・サーバへの接続の確立、コンピュータ・ルーチンを実行するための要求の送信、メッセージの送受信、ウェブタスク・トークンの送受信、ウェブタスク・コンテナの生成、分離された環境でのコンピュータ・ルーチンの実行のための機能、および他の機能を、図５に示すように、ネットワーク１３０を介してデータ通信用に接続され、クライアント・サーバ１０２、ウェブタスク・サーバ１０７、およびＭＴＩＳ１４０として動作するコンピュータ上に実装することができる。特殊目的の装置を使用してもよいが、このような装置はまた、データ通信用の適切なネットワーク接続にもかかわらず、本明細書において述べる機能などの機能を実装するように「サーバ」プログラミングを実行するのに一般に使用されるデータ処理装置の一般的なクラスを表すものである、１つまたは複数のハードウェア・プラットフォームを使用して実装してもよい。

【0062】

図５および図６には、クラウド・コンピューティング用に適用してもよい、汎用コンピュータのハードウェア・プラットフォームの機能ブロック図が示してある。図５には、ウェブタスク・サーバ１０７またはＭＴＩＳ１４０などのサーバを実装するのに通常使用してもよい、ネットワークまたはホスト・コンピュータ・プラットフォームが示してある。図６には、パーソナル・コンピュータ、またはクライアント１０２などのクライアント・コンピューティング装置を実装するのに使用してもよい、ユーザ・インターフェース要素を有する装置が示してある。図５および図６に示すような機器の一般的な構造および一般的な動作は、ハイレベルの図から自明でなければならないと考えられる。

【0063】

サーバとして構成された汎用コンピュータは、たとえば、ネットワーク１３０上でのパケット・データ通信用のデータ通信インターフェースを含む。サーバ・コンピュータはまた、プログラム命令を実行するための、１つまたは複数のプロセッサの形での中央処理装置（ＣＰＵ）を含む。サーバ・プラットフォームは通常、内部コミュニケーション・バス、プログラム記憶装置、ならびにサーバによって処理および／または通信される様々なデータ・ファイル用のデータ記憶装置を含むが、サーバは、ネットワーク通信を介してプログラミングおよびデータを受信することが多い。このようなサーバのハードウェア要素、オペレーティング・システム、およびプログラミング言語は、本質的に従来のものである。もちろん、複数の類似プラットフォーム上で分散した形でサーバ機能を実装して、処理負荷を分散してもよい。

【0064】

前述の通り、ＭＴＩＳへの要求は、クライアント・マシンから実行してもよい。図６の場合と同様に、クライアント・マシンは、プロセッサ、メモリ、および、直接またはインターネットを介してクラウド・サーバに接続するのに十分なネットワーク接続を有する任意の装置でもよい。通常、オペレーティング・システムが存在することになる。典型的な構成は、中央処理装置、ＲＡＭ、および、Wi-Fi接続またはイーサネット（登録商標）接続である。メモリは、コンピュータ読取り可能な媒体となり、かつ／または他のコンピュータ読取り可能な媒体にアクセスすることになり、メモリおよび／または他のコンピュータ読取り可能な媒体に常駐しているコンピュータ実行可能コードからなるクライアント・アプリケーションを実行することになる。

【0065】

同様に、図５に示したようなクラウド・サーバは、プロセッサ、メモリ、および、直接またはインターネットを介してクライアント・マシンに接続するのに十分なネットワーク接続を有する装置でもよい。クライアント・マシンと同様に、通常、オペレーティング・システムが存在することになる。典型的な構成は、中央処理装置、ＲＡＭ、および、Wi-Fi接続またはイーサネット接続である。メモリは、コンピュータ読取り可能な媒体となり、かつ／または他のコンピュータ読取り可能な媒体にアクセスすることになり、メモリおよび／または他のコンピュータ読取り可能な媒体に常駐しているコンピュータ実行可能コードからなるクライアント・アプリケーションを実行することになる。

【0066】

クラウド・サーバは一般に、仮想マシンを生成できる仮想化環境を実行することになる。それぞれの仮想マシンでは、オペレーティング・システム、またはシステム・レベルの環境が存在してもよい。それぞれの仮想マシンはプロセスを生成してもよく、プロセスのそれぞれはスレッドを生成してもよい。Java仮想マシン、または．ＮＥＴランタイムなどの実行環境は、仮想マシン内で実行され、プロセスおよびスレッドを管理してもよい。

【0067】

図５および図６に示すＲＡＭおよびＲＯＭなどのコンピュータ読取り可能な媒体には、少なくとも２つのタイプのコンピュータ読取り可能な媒体、すなわちコンピュータ記憶媒体および通信媒体が含まれる。コンピュータ記憶媒体には、コンピュータ読取り可能な命令、データ構造、プログラム・モジュール、または他のデータなど、情報を記憶するための任意の方法または技術で実装された、揮発性および不揮発性、取外し可能および取外し不可能な媒体が含まれる。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、もしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または、コンピューティング装置がアクセスする情報を記憶するのに使用できる他の任意の非伝送媒体が含まれる。対照的に、通信媒体は、搬送波などの変調されたデータ信号、または他の伝送メカニズムに、コンピュータ読取り可能な命令、データ構造、プログラム・モジュール、または他のデータを含んでもよい。本明細書において規定するように、コンピュータ記憶媒体には、通信媒体は含まれない。

【0068】

ソフトウェア機能は、実行可能コードならびに関連する記憶データ、たとえば、コンピュータ・ルーチンを実行するための要求の送信、メッセージの送受信、ウェブタスク・トークンの送受信、ウェブタスク・コンテナの生成、分離された環境におけるコンピュータ・ルーチンの実行、および他の機能のための、ウェブタスク・サーバ１０７およびＭＴＩＳ１４０上でアプリケーション用に使用されるファイルを含むプログラミングを必要とする。ソフトウェア・コードは、コンピューティング装置によって実行可能である。動作にあたって、コードは、コンピューティング装置内に記憶される。しかし、他の時点では、ソフトウェアは、他の場所に記憶してもよく、かつ／または適切なコンピューティング装置システムにロードするために移送してもよい。コンピューティング装置のプロセッサによって、このようなコードを実行することで、コンピューティング装置は、実質的に、本明細書において考察および例示した実装形態において実行されるように、様々な機能を実行できるようになる。

【0069】

したがって、上述したようにノード・データを受信および処理する方法の各態様は、プログラミングに組み入れてもよい。この技術のプログラム態様は、典型的には、あるタイプの持続的で機械読取り可能な媒体上で実行され、またはそれに組み入れられる、実行可能コードおよび／または関連するデータの形での「成果物」または「製品」と考えてもよい。

【0070】

（結論）
最良の形態と考えられるもの、および／または他の例についてこれまで述べてきたが、様々な修正をそれに加えてもよく、また本明細書において開示される主題を、様々な形態および例で実施してもよく、また数多くの用途に各教示を適用してもよく、そのほんの一部しか本明細書で説明してこなかったことが理解される。本教示の真の範囲に含まれるありとあらゆる適用例、修正形態、および変形形態の請求は、添付の特許請求の範囲によるものである。

【0071】

直前に述べたことを除いて、特許請求の範囲に記載されているかどうかに関わらず、これまで述べてきたこと、または例示してきたことは、任意の構成要素、ステップ、特徴、目的、利益、利点、または均等物を広く一般に供するものと解釈されるものではなく、またはそう解釈すべきではない。

【0072】

本明細書で使用される用語および表現は、特定の意味が本明細書において別の意味に説明されている場合を除いて、それらに対応する調査および研究の領域に対して、そうした用語および表現に与えられる通常の意味を有することが理解されよう。第１および第２などの関係語は、もっぱら、あるエンティティまたはアクションを、別のものと区別するために使用されることがあり、このようなエンティティまたはアクションの間の実際のこうしたいかなる関係または順序をも、必ずしも必要とするものではなく、また意味するものでもない。用語「comprises」、「comprising」またはそれらの他のいかなる変形も、非排他的な包含を含むものであり、したがって、要素のリストを含むプロセス、方法、物品、または装置は、それらの要素のみを含むのではなく、明示的にリストされていない、またはこうしたプロセス、方法、物品、もしくは装置に固有ではない他の要素を含んでもよい。「a」または「an」が前置される要素は、さらに制約を受けることなく、その要素を含むプロセス、方法、物品、または装置にさらなる同一要素が存在することを妨げるものではない。

【0073】

読者が技術開示の本質を素早く把握できるように、開示内容の要約を提示する。特許請求の範囲に記載の範囲または意味を曲げて解釈し、またはそれを限定するために使用されるものではないという了解の下に、要約書が提示されている。さらに、前述の発明の詳細な説明においては、本開示を簡潔に説明するために、様々な特徴が様々な実施形態にまとめられていることが分かる。この開示方法は、特許請求の範囲に記載されている実施形態が、それぞれの請求項に明白に述べられている以上の特徴を必要とするという意図を反映するものと解釈すべきではない。むしろ、添付の特許請求の範囲が示すように、発明性のある主題は、開示された単一の実施形態の全ての特徴よりも少ない。したがって、添付の特許請求の範囲は、ここに発明の詳細な説明に援用され、各請求項は別々に特許請求される主題として独立している。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】