図面 (/)

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

出願人 オース0,インコーポレイテッド
発明者 ヤンズク,トマシュウロスキー,マティアス
出願日 2015年11月25日 (4年11ヶ月経過) 出願番号 2017-527724
公開日 2017年12月28日 (2年10ヶ月経過) 公開番号 2017-539015
状態 特許登録済
技術分野 ストアードプログラムにおける機密保護 マルチプログラミング
主要キーワード 分離境界線 専用空間 非永続性 コスト構造 後方支援 固定セット 関係語 埋込み式
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年12月28日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (7)

課題・解決手段

マルチテナントインフラストラクチャサーバMTIS)は、任意のアプリケーションコンピュータルーチンを実行するための環境を提供するように構成される。MTISは、ウェブタスク・サーバから要求を受信して、ウェブタスク・コンテナ内でコンピュータ・ルーチンを実行する。コンピュータ・ルーチンは、MTISにおいてウェブタスク・コンテナ内で実行される。コンピュータ・ルーチンの実行に成功すると、結果セットがウェブタスク・サーバに戻される。コンピュータ・ルーチンの実行に失敗すると、エラー通知がウェブタスク・サーバに戻される。コンピュータ・ルーチンの実行中に消費されたリソースが決定される。ウェブタスク・コンテナが破棄されて、MTISへのコンピュータ・ルーチンの永続的な記憶が防止する。

概要

背景

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

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

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

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

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

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

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

概要

マルチテナント・インフラストラクチャ・サーバ(MTIS)は、任意のアプリケーションのコンピュータ・ルーチンを実行するための環境を提供するように構成される。MTISは、ウェブタスク・サーバから要求を受信して、ウェブタスク・コンテナ内でコンピュータ・ルーチンを実行する。コンピュータ・ルーチンは、MTISにおいてウェブタスク・コンテナ内で実行される。コンピュータ・ルーチンの実行に成功すると、結果セットがウェブタスク・サーバに戻される。コンピュータ・ルーチンの実行に失敗すると、エラー通知がウェブタスク・サーバに戻される。コンピュータ・ルーチンの実行中に消費されたリソースが決定される。ウェブタスク・コンテナが破棄されて、MTISへのコンピュータ・ルーチンの永続的な記憶が防止する。

目的

しかし、オペレーティング・システムによって各プロセスはリソースを管理できるようになるが、オペレーティング・システムは、スレッド・レベルでリソースを管理するのに適切な機能を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記要求がウェブタスク・トークンを含む、請求項1に記載のMTIS。

請求項3

前記ウェブタスク要求が、前記コンピュータ・ルーチンを含まず、前記コンピュータ・ルーチンおよびクライアントの秘密への、ユニフォーム・リソース・アイデンティファイア(URL)リンクを含む、請求項1に記載のMTIS。

請求項4

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

請求項5

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

請求項6

前記ウェブタスク・トークンが、暗号によってタンパリングおよび暴露から保護されている、請求項1に記載のMTIS。

請求項7

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

請求項8

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

請求項9

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

請求項10

前記ウェブタスク・コンテナの前記破棄は、前記結果のセットまたは前記エラー・コンピュータ・ルーチンが前記ウェブタスク・コンテナによって受信されたという確認を、前記ウェブタスク・サーバから受信することに応答する、請求項1に記載のMTIS。

請求項11

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

請求項12

前記コンピュータ・ルーチンを実行する時間が、HTTP要求応答サイクルに要する期間に制限される、請求項1に記載のMTIS。

請求項13

前記ウェブタスク・サーバがHTTPサーバであり、前記ウェブタスク要求がHTTP要求である、請求項12に記載のMTIS。

請求項14

前記戻された結果が、JavaScript(登録商標) Object Notation(JSON)である、請求項1に記載のMTIS。

請求項15

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

請求項16

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

請求項17

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

請求項18

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

請求項19

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

請求項20

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

請求項21

前記ウェブタスク・コンテナの前記破棄は、前記結果のセットまたは前記エラー通知が前記ウェブタスク・コンテナによって受信されたという確認を、前記ウェブタスク・サーバから受信することに応答する、請求項16に記載の方法。

請求項22

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

請求項23

前記戻された結果が、JavaScript Object Notation(JSON)である、請求項16に記載の方法。

請求項24

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

背景技術

0001

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

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

図面の簡単な説明

0008

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

0009

安全なマルチテナント環境において任意のアプリケーションのコードを実行するための、例示的なアーキテクチャを示す。
マルチテナント・コンテナにおいてコードを実行するためのデータ・フレームワークのブロック図を示す。
図1のマルチテナント・インフラストラクチャ・サーバとして使用してもよい、例示的なウェブタスク仮想マシンを示す。
マルチテナント・インフラストラクチャ環境においてコードを実行するための、高水準の例示的なコールフロー・プロセスを示す。
クラウド上に存在してもよい、ネットワーク・コンピュータまたはホスト・コンピュータを示す。
ユーザ・インターフェース要素を備えるコンピュータを示す。

実施例

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

ウェブタスク・トークン110を暗号解読し、暗号解読済みの内容をサーバ140(たとえばMTIS)に提供するのは、ウェブタスク・サーバ(たとえば、図1の107)である。たとえば、ウェブタスク・サーバ107によって暗号解読が実行されるが、それというのも、サーバ140(たとえばMTIS)内のウェブタスク・コンテナは、信頼できないコード実行し、したがってウェブタスク・トークン110を暗号解読するための暗号鍵が付与されないからである。

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

一実施形態では、ウェブタスク・サーバ107はHTTPサーバであり、クライアント102とウェブタスク・サーバ107の間での通信410中の接続はHTTP接続であり、ウェブタスク・トークンおよびデータ106を含むウェブタスク要求124はHTTP要求である。あるいは、単一の汎用型エンドポイントのみが開発者に公開されている場合、他のプロトコル、すなわち遠隔手続き呼出し(RPC)を使用してもよい。

0050

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

0051

ステップ416では、MTIS140が、実行されるコンピュータ・ルーチン抽出し、MTIS140の分離された環境(たとえばウェブタスク・コンテナ)で、このコンピュータ・ルーチンを実行する。ウェブタスク・コンテナは、MTIS140のサンドボックス環境内で実行してもよい。MTIS140はまた、ウェブタスク・サーバ107が使用するプロトコルと互換性のある形式での応答を構成する。様々な実施形態では、この応答は、XML、JSONなどでもよい。したがって、MTISは、受信したウェブタスク要求について、汎用な統一実行環境を提供する。

0052

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

0053

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

0054

ステップ422では、この応答が、ウェブタスク・サーバ107からクライアント102に転送される。あるいは、またはさらに、この応答は、MTISからクライアント102に直接転送してもよい。

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ