(57)【特許請求の範囲】
【請求項１】
分散型ファイル・システムにおけるファイルにアクセスするためのコンピューターで実行する方法であって、
分散型ファイル・システムにおけるファイルに対する共有ファイル・アクセス（ＳＦＡ）ベース動作を共有ファイル・アクセス（ＳＦＡ）クライアントから受けるステップであって、前記共有ファイル・アクセス（ＳＦＡ）ベース動作が、共有ファイル・アクセス（ＳＦＡ）ベース動作の便宜的ロックを示す動作モディファイアを有し、前記共有ファイル・アクセス（ＳＦＡ）ベース動作が、共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースに基づいて定義される、ステップと、
前記共有ファイル・アクセス（ＳＦＡ）ベース動作の動作モディファイアを参照することに基づいて、前記ファイル上において前記共有ファイル・アクセス（ＳＦＡ）ベース動作を実行するステップであって、前記ファイルが前記ファイルに対応する動作を実行するためのファイル・サービスと関連付けられ、前記ファイル・サービスが複数のテーブルを含み、前記複数のテーブルが、前記分散型ファイル・システムにおけるファイルの状態を格納し、前記共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースが、前記分散型ファイル・システムにおけるファイルにアクセスするために、共有ファイル・アクセス（ＳＦＡ）プロトコルおよび表現状態転送（ＲＥＳＴ）プロトコルの統合機能を含む、ステップと、
前記分散型ファイル・システムにおける前記ファイルに対する表現状態転送（ＲＥＳＴ）ベース動作を表現状態転送（ＲＥＳＴ）クライアントから受けるステップであって、前記表現状態転送（ＲＥＳＴ）ベース動作が前記共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースに基づいて定義される、ステップと、
前記共有ファイル・アクセス（ＳＦＡ）ベース動作の前記動作モディファイアを参照することに基づいて、前記ファイル上において前記表現状態転送（ＲＥＳＴ）ベース動作を実行するステップであって、前記ファイル・サービスのファイル・サービス・スキーマに基づいて格納された前記ファイルに対するファイル状態を識別することに少なくとも部分的に基づいて、前記表現状態転送（ＲＥＳＴ）ベース動作を実行し、前記ファイル・サービス・スキーマはファイルおよびディレクトリーがそれらの名称に基づいて格納される階層的なテーブルを含む、ステップと、
を含む、コンピューターで実行する方法。
【請求項２】
請求項１に記載の方法において、前記動作モディファイアを参照することに基づいて前記ファイル上において前記表現状態転送（ＲＥＳＴ）ベース動作を実行するステップが、更に、
前記共有ファイル・アクセス（ＳＦＡ）ベース動作の動作モディファイアに関連付けられた便宜的ロックを識別するステップであって、前記便宜的ロックが、前記ファイルの最新状態が、前記共有ファイル・アクセス（ＳＦＡ）ベース動作に関連付けられた共有ファイル・アクセス（ＳＦＡ）クライアント上にキャッシュされていることを示す、ステップと、
前記動作モディファイアを参照することに基づいて、前記共有ファイル・アクセス（ＳＦＡ）ベース動作の前記便宜的ロックを中断することを決定するステップと、
前記表現状態転送（ＲＥＳＴ）ベース動作が実行されるように、便宜的ロック中断動作を実行するステップと、
を含む、方法。
【請求項３】
請求項１に記載の方法において、前記共有ファイル・アクセス（ＳＦＡ）クライアントが、
前記共有ファイル・アクセス（ＳＦＡ）クライアントがローカル・キャッシュから読み取る読み取り（Ｒ）便宜的ロック、
前記クライアントがローカルに書き込む書き込み（Ｗ）便宜的ロック、
ハンドルが閉じられたとき、前記共有ファイル・アクセス（ＳＦＡ）クライアントが直ちに通知を送らないハンドル（Ｈ）便宜的ロック、
の内１つ以上を含む前記便宜的ロックを取得し、
前記読み取り（Ｒ）便宜的ロックが、前記表現状態転送（ＲＥＳＴ）ベース動作が書き込み動作であるときに中断され、
前記書き込み（Ｗ）便宜的ロックが、前記表現状態転送（ＲＥＳＴ）ベース動作が読み取り動作であるときに中断され、
前記ハンドル（Ｈ）便宜的ロックが、前記表現状態転送（ＲＥＳＴ）ベース動作が削除動作であるときに中断される、方法。
【請求項４】
請求項３に記載の方法において、前記ハンドル（Ｈ）便宜的ロックが、前記表現状態転送（ＲＥＳＴ）ベース動作が前記共有ファイル・アクセス（ＳＦＡ）ベース動作の前記ハンドル（Ｈ）による共有違反を開始したときに中断され、前記共有ファイル・アクセス（ＳＦＡ）ベース動作の前記アクセス・モードおよび前記共有モードが、前記便宜的ロックとは異なる、方法。
【請求項５】
請求項３に記載の方法において、前記便宜的ロック中断動作が、キャッシュされているＳＭＢクライアントの変更を一掃する動作と、指定要求制限時間を超えて遅延したクライアント・キャッシュ一掃に対して、動作不実行通知を伝達する動作とを含む、方法。
【請求項６】
分散型ファイル・システムにおけるファイルにアクセスするためのコンピューターで実行する方法であって、
分散型ファイル・システムにおけるファイルに対する共有ファイル・アクセス（ＳＦＡ）ベース動作を共有ファイル・アクセス（ＳＦＡ）クライアントから受けるステップであって、前記共有ファイル・アクセス（ＳＦＡ）ベース動作が、共有ファイル・アクセス（ＳＦＡ）ベース動作のアクセス共有モード(access-shared mode)を示す動作モディファイアを有し、前記共有ファイル・アクセス（ＳＦＡ）ベース動作が、共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースに基づいて定義される、ステップと、
前記動作モディファイアに基づいて、前記共有ファイル・アクセス（ＳＦＡ）ベース動作を実行するステップと、
前記分散型ファイル・システムにおける前記ファイルに対する表現状態転送（ＲＥＳＴ）ベース動作を表現状態転送（ＲＥＳＴ）クライアントから受けるステップであって、前記ファイルが前記ファイルに対応する動作を実行するためのファイル・サービスと関連付けられ、前記ファイル・サービスが複数のテーブルを含み、前記複数のテーブルが、前記分散型ファイル・システムにおけるファイルの状態を格納し、前記共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースが、前記分散型ファイル・システムにおけるファイルにアクセスするために、共有ファイル・アクセス（ＳＦＡ）プロトコルおよび表現状態転送（ＲＥＳＴ）プロトコルの統合機能を含む、ステップと、
前記共有ファイル・アクセス（ＳＦＡ）ベース動作の前記動作モディファイアを参照することに基づいて、前記ファイル上において前記表現状態転送（ＲＥＳＴ）ベース動作を実行するステップであって、前記ファイル・サービスのファイル・サービス・スキーマに基づいて格納された前記ファイルに対するファイル状態を識別することに少なくとも部分的に基づいて、前記表現状態転送（ＲＥＳＴ）ベース動作を実行し、前記ファイル・サービス・スキーマはファイルおよびディレクトリーがそれらの名称に基づいて格納される階層的なテーブルを含む、ステップと、
を含む、コンピューターで実行する方法。
【請求項７】
請求項６に記載の方法において、前記表現状態転送（ＲＥＳＴ）ベース動作がファイル作成動作であり、前記アクセス−シェア・モード・モディファイアが、書き込み共有モード、または書き込み／削除共有モードの内１つを含むときにのみ、前記ファイル作成動作が実行される、方法。
【請求項８】
請求項６に記載の方法において、前記表現状態転送（ＲＥＳＴ）ベース動作がファイル取得動作または範囲リスト動作であり、前記シェア・モード・モディファイアが読み取り共有モードを含むときにのみ、前記ファイル取得動作または範囲リスト動作が実行される、方法。
【請求項９】
請求項６に記載の方法において、前記表現状態転送（ＲＥＳＴ）ベース動作が範囲設定動作、プロパティ設定動作、またはファイル・メタデーター設定動作であって、前記シェア・モード・モディファイアが書き込み共有モードを含むときにのみ、前記範囲設定動作、プロパティ設定動作、またはファイル・メタデーター設定動作が実行される、方法。
【請求項１０】
請求項６に記載の方法において、前記表現状態転送（ＲＥＳＴ）ベース動作が削除動作であり、前記シェア・モード・モディファイアが削除共有モードを含むときにのみ、前記削除動作が実行される、方法。
【請求項１１】
請求項６に記載の方法において、前記表現状態転送（ＲＥＳＴ）ベース動作がファイル・リスト動作、ファイル・プロパティ取得動作、またはファイル・メタデーター取得動作であり、前記ファイルが、シェア・モード・モディファイアを有する前記共有ファイル・アクセス（ＳＦＡ）ベース動作に基づく排他的読み取りアクセスによって開いている間に、前記ファイル・リスト動作、前記ファイル・プロパティ取得動作、または前記ファイル・メタデーター取得動作が実行される、方法。
【請求項１２】
請求項６に記載の方法であって、更に、前記シェア・モード・モディファイアが、前記受けた表現状態転送（ＲＥＳＴ）ベース動作に基づいて、前記ファイルへのアクセスを排除するとき、共有違反を伝達するステップを含む、方法。
【請求項１３】
分散型ファイル・システムにおけるファイルにアクセスするためのコンピューターで実行する方法であって、
共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースにおいてファイルに対する動作を受けるステップと、
前記ファイルに対応する動作を実行するためにファイル・サービスにアクセスするステップであって、前記ファイル・サービスが複数のテーブルを含み、前記複数のテーブルが、前記分散型ファイル・システムにおけるファイルの状態を格納し、前記共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースが、前記分散型ファイル・システムにおけるファイルにアクセスするために、共有ファイル・アクセス（ＳＦＡ）プロトコルおよび表現状態転送（ＲＥＳＴ）プロトコルの統合機能を含む、ステップと、
前記ファイル・サービスのファイル・サービス・スキーマに基づいて格納された前記ファイルに対するファイル状態を識別することに少なくとも部分的に基づいて、前記動作を実行するステップと、
を含み、
前記ファイル・サービス・スキーマが、ファイルおよびディレクトリーの対応する名称に基づいて前記ファイルおよびディレクトリーを格納するために階層状テーブルを含み、複数のファイル識別子を格納する名前空間テーブルへの参照を使用して、ファイルおよびディレクトリーを引き出す、
コンピューターで実行する方法。
【請求項１４】
請求項１３に記載の方法において、前記複数のテーブルが、前記共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースのセマンティクスに対応する前記ファイル・サービス・スキーマにおいて定義されたフィールドを含み、前記複数のテーブルが、共有ファイル・アクセス（ＳＦＡ）クライアントと表現状態転送（ＲＥＳＴ）クライアントとの間における動作相互作用を調整するために、前記共有ファイル・アクセス−表現状態転送（ＳＦＡ−ＲＥＳＴ）インターフェースにおいて定義された動作に基づいて関係付けられる、方法。
【請求項１５】
請求項１３に記載の方法において、複数の共有ファイル・アクセス（ＳＦＡ）クライアントおよび表現状態転送（ＲＥＳＴ）クライアントが前記ファイル・サービス・スキーマを使用して前記ファイル状態に同時にアクセスするように、前記ファイル・サービス・スキーマが、ファイル状態をメモリーに格納するのを回避して、ファイル状態を直接クラウド・コンピューティング・プラットフォームのストアに格納することをサポートする、方法。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  データー・アクセスは、様々な異なるタイプのデーター・アクセス・プロトコルによって行い易くなる。データー・アクセス・プロトコルは、コンピューター内部またはコンピューター間におけるデーター通信に対して規則を設ける。異なるタイプのデーター・アクセス・プロトコルはデーターにアクセスするときに確かな利点が得られる。具体的には、サーバ・メッセージ・ブロック（「ＳＭＢ」）プロトコルのような共有ファイル・アクセス（「ＳＦＡ」）プロトコルは、ファイル・システム・リソースにアクセスするために使用することができ、表現状態転送（「ＲＥＳＴ」：Representation State Transfer）プロトコルは、定められたアーキテクチャ上の制約によって限定されるクライアント・サーバ相互作用のために使用することもできる。各プロトコルは、データーにアクセスするためのメッセージを伝達するために明確に定義されたフォーマットである。つまり、プロトコルが、データー・アクセス・サービスにリンクするためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）として実装されるとき、１つのプロトコルのＡＰＩライブラリーは、他のプロトコルのＡＰＩの実行時に実行することが避けられない。これに関して、従来のデーター・アクセス・プロトコルおよびＡＰＩは、統合ファイル共有や制約に基づくクライアント・サーバ相互作用を促進することについては有効ではない。何故なら、従来のデーター・アクセス・プロトコルおよびＡＰＩは、統合ＳＭＢおよびＲＥＳＴ機能に対する総合的な支援を提供することができないからである。
【発明の概要】
【課題を解決するための手段】
【０００２】
[0002]  この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として別個に用いられることを意図するのでもない。
【０００３】
[0003]  種々の実施形態において、ファイル・システムへのアクセスを与える方法およびシステムを提供する。ファイル・システムにおけるファイルに対する動作モディファイア(operation modifier)を有するＳＦＡベース動作を受ける。ＳＦＡベース動作は、ファイル表現状態転送（ＲＥＳＴ）インターフェースに基づいて定義される。ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能を含む。分散型ファイル・ストレージにおけるファイルに対するＲＥＳＴベース動作を受ける。このＲＥＳＴベース動作は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて定義される。ＳＦＡベース動作は、動作モディファイアを使用して実行される。このＲＥＳＴベース動作を実行するために、動作モディファイアを参照する。ＳＦＡ−ＲＥＳＴインターフェースに基づいて、ＲＥＳＴベース動作を実行する。ファイル・システムにアクセスするためのファイルス・キーマ(file schema)を実装することができる。このスキーマは、ファイルを格納するためのテーブルを含み、これらのテーブルは、ＳＦＡ−ＲＥＳＴインターフェースのエレメントに対応するフィールドを含む。更に、ファイル・システムにおけるファイル・シェア(file share)をバックアップするために、スナップショット・コンポーネントを実装できることも考えられる。
【図面の簡単な説明】
【０００４】
[0004]  以下に、添付図面を参照しながら本発明について詳細に説明する。図面において、
【図１】図１は、本発明の実施形態を実現するときの使用に適した計算環境例のブロック図である。
【図２Ａ】図２Ａ〜２Ｄは、本発明の実施形態を採用することができるクラウド・コンピューティング・インフラストラクチャ例およびプラットフォーム例のブロック図である。
【図２Ｂ】図２Ａ〜２Ｄは、本発明の実施形態を採用することができるクラウド・コンピューティング・インフラストラクチャ例およびプラットフォーム例のブロック図である。
【図２Ｃ】図２Ａ〜２Ｄは、本発明の実施形態を採用することができるクラウド・コンピューティング・インフラストラクチャ例およびプラットフォーム例のブロック図である。
【図２Ｄ】図２Ａ〜２Ｄは、本発明の実施形態を採用することができるクラウド・コンピューティング・インフラストラクチャ例およびプラットフォーム例のブロック図である。
【図３】図３は、本発明の実施形態にしたがって、分散型ファイル・システムにおいてファイルにアクセスする方法を示す流れ図である。
【図４】図４は、本発明の実施形態にしたがってファイル・シェアのスナップショットを撮る方法を示す流れ図である。
【図５】図５は、本発明の実施形態にしたがって分散型ファイル・システムにおいてファイルにアクセスする方法を示す流れ図である。
【図６】図６は、本発明の実施形態にしたがって分散型ファイル・システムにおいてファイルにアクセスする方法を示す流れ図である。
【発明を実施するための形態】
【０００５】
[0005]  本発明の実施形態の主題について、本明細書では、法的要件を満たすために具体性を持って説明する。しかしながら、説明自体は、本特許の範囲を限定することは意図していない。むしろ、本発明者は、特許請求する主題は、本文書において記載するステップとは異なるステップまたは同様のステップの組み合わせを含むように、他の現在の技術または今後の技術と関連付けて、別の方法で具体化してもよいことを想定している。更に、「ステップ」および／または「ブロック」という用語は、本明細書においては、採用される方法の異なるエレメントを言外に意味するために用いることもできるが、個々のステップの順序が明示的に記載されているのではなければ、そしてされている場合を除いて(unless and except)、この用語は、本明細書において開示される種々のステップ間において、いかなる特定の順序をも暗示するように解釈してはならない。
【０００６】
[0006]  本開示に限って言うと、「含む」(including)という単語は、「含む」(comprising)という単語と同じ広い意味を有する。加えて、「ａ」および「ａｎ」のような単語は、別段逆のことが示されない限り、単数だけでなく複数も含むものとする。つまり、例えば、「特徴」(a feature)の要件は、１つ以上の特徴が存在する場合に満たされる。また、「また」(or)という用語は、接続詞、離接的接続詞、または双方を含むものとする（つまり、ａまたはｂは、ａまたはｂのいずれか、ならびにａおよびｂを含む）。
【０００７】
[0007]  以下の詳細な説明の目的上、本発明の実施形態について説明するにあたって、ＨＴＴＰによるＳＦＡおよびＲＥＳＴベース動作を使用してクラウド・コンピューティング・プラットフォーム上においてファイル・サービスをサポートするように相互作用するＳＦＡベース動作を参照する。しかしながら、クラウド・コンピューティング・プラットフォーム上におけるファイル・サービスのためにＳＦＡ−ＲＥＳＴインターフェースを介したコンテンツの共有は、単なる一例であり、説明する技法は、ＳＦＡベース動作およびＲＥＳＴベース動作が相互作用する他の実施態様のコンテキストにも拡大できることが考えられる。
【０００８】
[0008]  ネットワーク上におけるノード間で、ファイル、プリンター、シリアル・ポート、および通信への共有アクセスを与えるために、共有ファイル・アクセス・プロトコルが使用される。具体的には、共有ファイル・アクセス・プロトコルは、クライアントがファイルを、これらが正にローカル・コンピューター上にあるかのように、操作することを可能にする。読み取り、書き込み、作成、削除のような動作は全てサポートされ、唯一の違いは、ファイルが計算デバイスにローカルであるのではなく、実際にはリモート・サーバ上にあることである。
【０００９】
[0009]  共有ファイル・アクセス・プロトコルの実装は、クライアント−サーバー手法によって行われ、クライアントが具体的な要求を行い、サーバーはしかるべく応答する。具体的には、ＳＭＢプロトコルは、クライアントがファイル・サーバに対して要求を行えるように、ファイル・システムへのアクセスを与える。背景として、ファイル・システム・ストレージにおける１つの情報を他の情報と差別化できるようにするためにはデーターをどのように格納しそして引き出すとよいか制御するために、ファイル・システムが使用される。データーおよびその名称を管理するために使用される構造および論理規則をファイル・システムと呼ぶ。ＳＭＢサーバーは、それらのファイル・システムおよびその他のリソースを、ネットワーク上においてクライアントに利用可能にする。したがって、ＳＭＢプロトコルは好ましいファイル共有プロトコルである。
【００１０】
[0010]  表現状態転送（「ＲＥＳＴ」）とは、調整された１組のアーキテクチャ上の制約から成るソフトウェア・アーキテクチャ・スタイルのことであり、分散型ハイパーメディア・システム(distributed hypermedia system)によって、コンポーネント、コネクター、およびデーター・エレメントに適用される。これに関して、ＲＥＳＴプロトコルは、アーキテクチャ制約プロトコルと記述されてもよいであろう。正式なＲＥＳＴアーキテクチャ制約は、とりわけ、クライアント−サーバー、ステートレス、キャッシュ可能、自己記述メッセージ、および表現を通じたリソースの操作を含む。具体的には、ステートレス性(statelessness)とは、クライアント−サーバー通信が、要求間において、サーバー上に格納されているクライアント・コンテキストによって制約されない、または要求間において、状態が全くクライアント内に維持されなくてもよいという観念を指すことができる。任意のクライアントからの各要求は、その要求にサービスするために必要な全ての情報を含み、セッション状態はクライアント内に保持される。また、ＲＥＳＴは、ハイパーテキスト・トランスファ・プロトコル（「ＨＴＴＰ」）上で実行するように構成することもできる。例えば、拡張マークアップ言語（「ＸＭＬ」）ファイルを含む指定ウェブ・ページを読み取るのでもよく、ＸＭＬは所望のコンテンツを記述しこれを有する。ＡＰＩとして実装されたＲＥＳＴプロトコルは、移動体アプリケーション、ソーシャル・ネットワーキング・ウェブ・サイト、および自動ビジネス・プロセスにおいて使用することができる。ＲＥＳＴ様式(REST style)は、クライアントとサービスとの間における相互作用が、限定された数の動作を有することによって改良される(enhance)ことを強調する。リソースには、それら自体の一意のユニバーサル・リソース識別子（「ＵＲＩ」）を割り当てることができる。
【００１１】
[0011]  計算プラットフォームとは、一般に、そのプラットフォーム内部で実行し、制約にしたがい、そのプラットフォームの機能(facilities)を利用するように設計された複数のソフトウェアを有する既存の環境を指すことができる。プラットフォームは、ハードウェア・アーキテクチャおよびソフトウェア・フレームワークを含み、その組み合わせによって、クライアントおよびサーバーに、データー・アクセス・プロトコルを使用して通信させることができる。典型的なプラットフォームは、ハードウェア・アーキテクチャ、オペレーティング・システム、およびランタイム・ライブラリーを含む。ハードウェア・アーキテクチャは、物理コンポーネントの識別および相互関係に関係し(refer to)、ソフトウェア・フレームワークは、ソフトウェアが汎用的な機能性を設ける抽象化(abstraction)に関係する。具体的には、ソフトウェア・フレームワーク（例えば、ＲＥＳＴ  ＡＰＩ）は、ブロブ・ストレージにおけるブロブへのアクセスを可能にすることができる。これに関して、例えば、顧客は、専用プラットフォーム・インフラストラクチャ上での応用のために、データー（例えば、ブロブ・データー）ブロブ・ストレージにアクセスすることができる。プラットフォームは、分散型クラウド・コンピューティング・インフラストラクチャにおける計算プラットフォームとして実装することができる。
【００１２】
[0012]  通例、クラウド・コンピューティング・プラットフォームは、データーを格納する、またはサービス・アプリケーションを分散させて実行するように機能する(act)。計算プラットフォームは、国および大陸を含む広い地理的位置にわたって広がることができる。クラウド・コンピューティング・プラットフォームは、異なるタイプのサービスを提供するパブリック・クラウドとすることができる。異なるタイプのサービスには、計算サービス（例えば、仮想機械、ウェブ・サイト、クラウド・サービス、および移動体サービス）、データー・サービス（例えば、格納、ＳＱＬデーターベース、ＳＱＬ報告、テーブル、バックアップ、復元）、ネットワーキング・サービス（例えば、仮想ネットワーク、トラフィック・マネージャ、データー転送）、およびアプリケーション・サービス（例えば、メディア・サービス、サービス・バス、通知ハブ、および多要素認証）が含まれる。例えば、クラウド・コンピューティング・プラットフォームは、インターネット・アクセス可能なデーターセンターにおいて機械上でサービス・アプリケーションを実行し、データーを格納することに備える(provide for)。
【００１３】
[0013]  クラウド・コンピューティング・プラットフォームのコンポーネント（例えば、ファブリック・コントローラ）は、更に、コンピューター・リソース、ネットワーク・ギア、シリアル・デバイス、およびファブリックの基礎機能をサポートする電力ユニットの健全性(health)の監視、維持、および管理に関する(surrounding)種々の役割も担う。種々の異なるタイプのクラウド構成に本発明の実施形態を実現することができ、したがって、クラウド・コンピューティング・プラットフォームの適した構造が使用されればよいこと、そして本発明の実施形態は本明細書に記載されることには限定されないことは、当業者には理解され認められてしかるべきである。
【００１４】
[0014]  プラットフォームは、データーへのアクセスをサポートするサービスをサポートすることができる。データー・アクセスは、様々な異なるタイプのデーター・アクセス・プロトコルによって容易に行われる。データー・アクセス・プロトコルは、コンピューター内部またはコンピューター間におけるデーター通信についての規則を設ける。異なるタイプのデーター・アクセス・プロトコルは、データーをアクセスするときに確かな利点が得られる。具体的には、ＳＭＢプロトコルは好ましいファイル共有プロトコルであり、ＲＥＳＴプロトコルは制約に基づくクライアント・サーバ相互作用に頻繁に使用される。各プロトコルは、データーにアクセスするためのメッセージを通信するために明確に定義されたフォーマットである。つまり、プロトコルが、データー・アクセス・サービスにリンクするためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）として実装されるとき、１つのプロトコルのＡＰＩライブラリーは、他のプロトコルのＡＰＩの実行時に実行することが避けられない。これに関して、従来のデーター・アクセス・プロトコルおよびＡＰＩは、統合ファイル共有や制約に基づくクライアント・サーバ相互作用を促進することについては有効ではない。何故なら、従来のデーター・アクセス・プロトコルおよびＡＰＩは、統合ＳＭＢおよびＲＥＳＴ機能に対する総合的な支援を提供することができないからである。加えて、従前からのファイル・システム・アクセスは、ダイレクト・アタッチド・ストレージ（「ＤＡＳ」： Direct Attached Storage）およびストレージ・エリア・ネットワーク（「ＳＡＮ」）という解決策に基づくが、これらは多くの場合複雑であり、設置し、構成し、そして動作させるには費用がかかる。基本的なレベルでは、今日、ファイル・システムにアクセスするために共有ファイル・アクセス・プロトコルおよびＲＥＳＴプロトコルに基づいてＳＦＡ−ＲＥＳ  ＡＰＩ（「ＳＦＡ−ＲＥＳＴインターフェース」）を提供するファイル・サービスをサポートするクラウドベース・プラットフォームは入手できない。クラウド・コンピューティング・プラットフォーム上のファイル・サービスは、プラットフォームをサポートするクラウド・コンピューティング・インフラストラクチャの利用可能性およびスケーラビリティを利用しつつ、クライアントからファイル・システムへの並列アクセスのために総合的なサポートを提供することができる。
【００１５】
[0015]  したがって、本発明の実施形態は、単純で効率的なクラウド・コンピューティング・プラットフォーム・ファイル・サービス、およびこのファイル・サービスに基づくファイル・アクセス方法を提供する。このファイル・サービスはＳＦＡ−ＲＥＳＴインターフェースを含む。具体的には、本明細書において定義されるＳＦＡ−ＲＥＳＴインターフェースのコンポーネントは、広くＳＦＡプロトコルおよびＲＥＳＴプロトコルの機能の統合型実現を指す。これに関して、ＳＦＡ−ＲＥＳＴインターフェースは、ファイル・シェアにアクセスするためのＳＦＡベース動作をサポートし、ＳＦＡ−ＲＥＳＴインターフェースは少なくとも部分的にＳＦＡプロトコルのエレメントを実装することに基づく。更に、ＳＦＡ−ＲＥＳＴインターフェースは、ファイル・シェアにアクセスするためのＲＥＳＴベース動作をサポートし、ＳＦＡ−ＲＥＳＴインターフェースは、少なくとも部分的にＲＥＳＴプロトコルのエレメントを実装することに基づく。更に、ＳＦＡ−ＲＥＳＴインターフェースは、共有ファイルへのアクセスを与えるファイル・サービスのために仮想機械、ストレージ、負荷均衡化、およびネットワーキングを提供するクラウド・コンピューティング・インフラストラクチャにおけるプラットフォーム上に実装することもできる。クラウド・コンピューティング・インフラストラクチャは、独立してファイル・サービスをサポートすることもできる。しかしながら、実施形態では、ブロブ・サービスがファイル・サービスと並列して実行することもできる。ファイル・サービスおよびブロブ・サービスは双方共、クラウド・コンピューティング・インフラストラクチャにおいて利用可能な機能(feature)を利用することができる。
【００１６】
[0016]  統合機能をサポートするＳＦＡ−ＲＥＳＴインターフェースの実施態様例は、ＳＦＡ−ＲＥＳＴインターフェースのキャッシュ・コンポーネントによって例示することができる。このキャッシュ・コンポーネントについては以下で更に詳しく論ずる。このキャッシュ・コンポーネントは、ファイル・サービス・リソース（例えば、ファイルまたはディレクトリー）の内どのくらいのコンテンツをクライアント上にキャッシュできるかについての判定を容易に行うことができる。ファイルのＳＦＡベース・キャッシング(caching)をＳＭＢリース(SMB lease)と呼ぶこともでき、ＲＥＳＴリースとは異なる。ＲＥＳＴリースの機能(feature)についても、以下で更に詳しく論ずる。引き続きＳＭＢリースについて述べると、一例として、ＳＦＡクライアントがファイルを開くとき、ＳＦＡクライアントは最大量のキャッシング（例えば、読み取り、書き込み、処理）を要求することができる。ＳＦＡクライアントは、キャッシングを要求する動作モディファイアを有するＳＦＡベース動作を伝えることができる。このファイルに開いている他のハンドルのタイプおよび数に基づいて、ファイル・サービスは、読み取り、書き込み、またはハンドルを閉じるまたはもっと多くのハンドルを開くためのコールでさえも、指定されたファイルに対して実行できるか否かについての判定を、クライアントに応答することができる。このファイルが第１クライアントによって排他的にアクセスされているとき、システムは最大のキャッシング（読み取り、書き込み、および処理）を付与することができる。第２クライアントがこのファイルに対するハンドルを開こうとすると、システムは、第１クライアントによって行われた変更が第２クライアントに確実に見えるようにするために、ＳＭＢリースを中断(break)しなければならない場合がある。ＳＭＢリースの中断は、このＳＭＢリースが中断される前にサーバーに対する変更を一掃する(flush)ために、ＳＭＢリースを有する第１クライアントと通信することを含む。また、キャッシュ・コンポーネントは、ＲＥＳＴベース動作（例えば、読み取りまたは書き込み）がＳＭＢリースの下であるファイルに対して要求されたときに、ＳＭＢリースの中断もサポートすることができる。
【００１７】
[0017]  ＳＦＡ−ＲＥＳＴインターフェースのキャッシュ・コンポーネントは、ＳＦＡクライアントおよびＲＥＳＴクライアントを介したファイル・システムへの並列アクセスのためにこの場合には可能であるエラー・パス(error path)をサポートするように構成することができる。一例として、リースを所有するクライアントは、ＳＭＢリースを中断しなければならないときは、無応答であってもよい。ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡベース動作およびＲＥＳＴベース動作の統合機能の管理を、ファイル上のＳＭＢリースを参照することにより、サポートすることができる。例えば、読み取りまたは書き込みのためのＲＥＳＴベース動作は、ファイルが開いており既存のＳＭＢリースの下でキャッシュされている間にこのファイルへのアクセスを要求することができる。ファイルは、キャッシングを要求する動作モディファイアを有するＳＦＡベース動作に基づいて開くことができる。その場合、ＲＥＳＴベース動作の読み取りまたは書き込みは、ＳＭＢリースが中断されている間は、停止することができる。尚、ＳＭＢリースの中断は多少の時間がかかる場合もあることが考えられる。したがって、ＳＦＡ−ＲＥＳＴインターフェースは、ＳＭＢリースの中断に時間がかかりすぎる状況では、時間切れエラー(timeout error)を設けることができる。クライアントが後にＲＥＳＴベース動作（例えば、読み取りまたは書き込み）を再試行することを可能にするために、特定のエラー・コードを定義してクライアントに戻すことができる。本発明では、ＳＦＡ−ＲＥＳＴインターフェース・コンポーネントを介してサポートされるＳＦＡベース動作と機能的に(by way of functionality)統合されるＲＥＳＴベース動作の任意の他の変形および組み合わせも想定している。
【００１８】
[0018]  更に、本発明の実施形態は、ＳＦＡ−ＲＥＳＴインターフェース・コンポーネントに基づいて開発されたスキーマ(schema)も含む。このスキーマは、ＳＦＡベースおよびＲＥＳＴベースのファイル・シェアへの並列アクセスを与えるファイル・サービスをサポートする。例えば、ＳＦＡクライアントおよびＲＥＳＴクライアントが双方共同時にファイル・シェアにアクセスすることができる。このスキーマは、複数のテーブルを含み、これらのテーブルは、ＳＦＡプロトコルおよびＲＥＳＴプロトコルのエレメントを有するＳＦＡ−ＲＥＳＴインターフェースに基づくフィールドを含む。更に、このスキーマは、ファイル・システムのスナップショットも可能にする。スナップショットはファイル・システムをバックアップする。スナップショットは、各スナップショットにおける古いバージョンに、後の時点でアクセスできるように、コピー・オン・ライト型パターン(copy-on-write type pattern)に基づくことができる。
【００１９】
[0019]  したがって、本発明の第１の態様では、分散型ファイル・システムにおいてファイルにアクセスする方法を提供する。この方法は、分散型ファイル・システムにおけるファイルに対する動作モディファイアを有するＳＦＡベース動作を受けるステップを含む。ＳＦＡベース動作は、ファイル−表現状態転送（ＲＥＳＴ）インターフェースに基づいて定義される。ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能を含む。この方法は、更に、分散型ファイル・システムにおけるファイルに対するＲＥＳＴベース動作を受けるステップを含み、ＲＥＳＴベース動作はＳＦＡ−ＲＥＳＴインターフェースに基づいて定義される。また、この方法は、動作モディファイアを使用してＳＦＡベース動作を実行するステップを含む。この方法は、ＲＥＳＴベース動作を実行するために動作モディファイアを参照するステップを含む。また、この方法は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて、ＲＥＳＴベース動作を実行するステップも含む。
【００２０】
[0020]  本発明の第２の態様では、データー・ファイル・システムにアクセスするためのファイル・サービス・スキーマを有するシステムを提供する。ファイル・サービス・スキーマは複数のテーブルを含む。複数のテーブルは、ファイル・システムにおけるファイルの状態を格納する。複数のテーブルは、ＳＦＡ−ＲＥＳＴインターフェースのエレメントに対応するフィールドを含み、ＳＦＡ−ＲＥＳＴインターフェースは、ファイル・システムにおけるファイルにアクセスするために、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能を含む。
【００２１】
[0021]  本発明の第３の態様では、ファイル・シェアをスナップショットするコンピューター実装方法を提供する。この方法は、ファイル・シェアを含むシェア・テーブルを更新するステップを含む。シェア・テーブルを更新するステップは、行をシェア・テーブルに追加するステップを含み、行はファイル・シェアの新バージョンと関連付けられる。また、この方法は、ファイル・シェアに関連付けられたノードに、ファイル・シェアの新バージョンに書き込みを開始することをこのノードに指令する通知を伝達するステップも含む。更に、この方法は、ノードがファイル・シェアの新バージョンに書き込んでいることを判定するステップも含む。また、この方法は、スナップショットが正しく完了したことを示すために、シェア・テーブルを更新するステップも含む。
【００２２】
[0022]  以上本発明の実施形態の全体像について端的に説明したので、本発明の種々の態様について一般的なコンテキストを示すために、本発明の実施形態を実現することができる動作環境例について、以下に説明する。最初に特に図１を参照すると、本発明の実施形態を実現するための動作環境例が示されており、全体的に計算デバイス１００として示されている。計算デバイス１００は、適した計算環境の一例に過ぎず、本発明の使用範囲や機能に関して限定を示唆することを全く意図していない。また、計算デバイス１００が、図示するコンポーネントの内のいずれかまたはその組み合わせに関して依存性や要件を有すると解釈しては決してならない。
【００２３】
[0023]  本発明は、コンピューター・コードまたは機械使用可能命令という一般的なコンテキストで説明することができ、コンピューターあるいはパーソナル・データー・アシスタントまたは他のハンドヘルド・デバイスのような、他の機械によって実行される、プログラム・モジュールのような、コンピューター実行可能命令を含む。一般に、ルーチン、プログラム、オブジェクト、コンポーネント、データー構造等を含むプログラム・モジュールは、特定のタスクを実行するまたは特定の抽象データー型を実装するコードを指す。本発明は、ハンドヘルド・デバイス、消費者用電子機器、汎用コンピューター、より特殊な計算デバイス等を含む種々のシステム構成において実施することができる。また、本発明は、分散型計算環境においても実施することができ、この場合、通信ネットワークを通じてリンクされたリモート処理デバイスによってタスクが実行される。
【００２４】
[0024]  図１を参照すると、計算デバイス１００は、以下のデバイスを直接または間接的に結合するバス１１０を含む。メモリー１１２、１つ以上のプロセッサー１１４、１つ以上のプレゼンテーション・コンポーネント１１６、入力／出力ポート１１８、入力／出力コンポーネント１２０、および例示的な電源１１２。バス１１０は、１つ以上のバス（アドレス・バス、データー・バス、またはその組み合わせ等）であってもよいものを表す。 図１の種々のブロックは、明確にするために、線で示されるが、実際には、種々のコンポーネントの区分はそのように明確ではなく、例えて言うと、これらの線をもっと正確にするならば灰色で曖昧になるであろう。例えば、ある者はディスプレイ・デバイスのようなプレゼンテーション・コンポーネントはＩ／Ｏコンポーネントであると見なすかもしれない。また、プロセッサーはメモリーを有する。本発明者は、このようなことは技術の本質であると認識しており、図１の線図は本発明の１つ以上の実施形態と共に使用することができる計算デバイスの一例を例示するに過ぎないことを繰り返しておく。「ワークステーション」、「サーバー」、「ラップトップ」、「ハンドヘルド・デバイス」等というようなカテゴリー間では区別を行わない。何故なら、これら全ては、図１の範囲に該当すると考えられ、「計算デバイス」を指す(reference to)からである。
【００２５】
[0025]  通例、計算デバイス１００は、種々のコンピューター読み取り可能媒体を含む。コンピューター読み取り可能媒体は、計算デバイス１００によってアクセスすることができるあらゆる入手可能な媒体とすることができ、揮発性および不揮発性双方の媒体、リムーバブルおよび非リムーバブル媒体を含む。一例として、そして限定ではなく、コンピューター読み取り可能媒体は、コンピューター記憶媒体および通信媒体を含む。
【００２６】
[0026]  コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のための任意の方法または技術で実現される。 コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいは所望の情報を格納するために使用することができ、計算デバイス１００によってアクセスすることができる任意の他の媒体を含むが、これらに限定されるのではない。コンピューター記憶媒体は信号自体を除外する。
【００２７】
[0027]  通信媒体は、通例、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターを、搬送波または他の移送メカニズムのような変調データー信号内に具体化し、任意の情報配信媒体を含む。「変調データー信号」という用語は、当該信号内に情報を符合化するような形で、その特性の１つ以上が設定または変更された信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体と、音響、ＲＦ、赤外線、および他のワイヤレス媒体のようなワイヤレス媒体とを含む。以上の内任意のものの組み合わせも、コンピューター読み取り可能媒体の範囲内に含まれてしかるべきである。
【００２８】
[0028]  メモリー１１２は、揮発性および／または不揮発性メモリーの形態としたコンピューター記憶媒体を含む。メモリーは、リムーバブル、非リムーバブル、またはその組み合わせであってもよい。ハードウェア・デバイスの例には、ソリッド・ステート・メモリー、ハード・ドライブ、光ディスク・ドライブ等が含まれる。計算デバイス１００は、１つ以上のプロセッサーを含み、このプロセッサーは、メモリー１１２またはＩ／Ｏコンポーネント１２０のような種々のエンティティからデーターを読み取る。プレゼンテーション・コンポーネント（１つまたは複数）１１６は、ユーザーまたは他のデバイスにデーター指示を提示する。プレゼンテーション・コンポーネントの例には、ディスプレイ・デバイス、スピーカー、印刷コンポーネント、振動コンポーネント等が含まれる。
【００２９】
[0029]  Ｉ／Ｏポート１１８は、計算デバイス１００を論理的にＩ／Ｏコンポーネント１２０を含む他のデバイスに結合することを可能にする。Ｉ／Ｏコンポーネント１２０の一部が内蔵されてもよい。例示的なコンポーネントには、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー、プリンター、ワイヤレス・デバイス等が含まれる。
【００３０】
[0030]  図２Ａを参照して、本発明の実施形態における使用に適した、クラウド・コンピューティング分散型インフラストラクチャの一例２００を図示するブロック図について説明する。一般に、クラウド・コンピューティング分散型インフラストラクチャ２００は、クラウド・コンピューティング・プラットフォームを介してサービスを提供する環境を例示する。クラウド・コンピューティング・インフラストラクチャ２００は、スケーラブルで、非常に利用可能性が高く、耐久性が高いサービスを提供する。例えば、ストレージ・サービスは、異なるタイプのストレージ・タイプにデーターを格納する能力(ability)を提供する。各ストレージ・タイプには利点があり、同じアプリケーション内において多数のストレージ・タイプを使用することができる。クラウド・コンピューティング・インフラストラクチャは、ブロブ、キュー、テーブル、およびファイル・システム・ストレージ・タイプをサポートするためにサービスＡＰＩを提供することができる。具体的には、本発明の実施形態は、プラットフォーム上におけるファイル・システムへの並列アクセスのために、ＳＦＡベース動作およびＲＥＳＴベース動作をサポートするファイル・サービスを提供する。ファイル・サービスは、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能を含むＳＦＡ−ＲＥＳＴインターフェースを使用する。ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡ−ＲＥＳＴインターフェースが、ファイル・システムにおけるファイルにハンドルを戻す、ファイルを開くまたは作成することを可能にするように、ＳＦＡプロトコルに基づいて、ファイル・システムを露出する。ハンドルが戻されると、クライアントはそのハンドルを使用してそのファイルに対して読み取りおよび書き込みを行うことができる。また、ＳＦＡ−ＲＥＳＴインターフェースは、ファイル上におけるＰＵＴおよびＧＥＴアクションを含む直接ＲＥＳＴベース動作を可能にするＲＥＳＴプロトコルのエレメントも含む。このプロトコル・コンポーネントは、ファイル・システムへのアクセスを並列に集合的に与えるように統合されている。具体的には、ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡプロトコルのＳＦＡベース動作とＲＥＳＴプロトコルのＲＥＳＴベース動作との間における相互作用に対する規則を定義する。ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡベースＡＰＩおよびＲＥＳＴベースＡＰＩを含み、これらのＡＰＩは、個々の各動作と対応するパラメータおよび戻り値に基づいて、種々の異なる動作を実行し易くする。ＳＦＡベースＡＰＩを参照すると、一例として、作成ＡＰＩは、ファイル名をパラメータとして含み、ステータス、ファイル・ハンドル、ファイル・タイム・スタンプ、ファイル・サイズを戻り値として含むことができる。作成ＡＰＩは、クライアントが、ファイル名を有するファイルを開くまたは作成することを可能にすることができる。追加のパラメータが、ファイルの異なる態様(aspect)を制御し、戻り値を処理することができる。ＳＦＡベースＡＰＩは、更に、サービスからクライアントに設定することができるｏｐｌｏｃｋコマンド(oplock command)もサポートする。ｏｐｌｏｃｋは、ファイルが開かれるまたは作成されるときに作���ＳＦＡベース動作によって作成することができ、一定の状況下にあるサーバーはｏｐｌｏｃｋを中断しなければならない。ｏｐｌｏｃｋ、ＳＭＢリース、およびＲＥＳＴベースＡＰＩとの相互作用をサポートするＳＦＡベースＡＰＩに関する更なる詳細については、以下で更に詳しく論ずる。
【００３１】
[0031]  尚、本明細書ではＳＭＢリースおよびｏｐｌｏｃｋは相互交換可能に使用されてもよいが、その実装は異なることを注記するのは重要である。具体的には、ＳＭＢリースおよびｏｐｌｏｃｋは、クライアント−サーバー相互作用の間、異なって管理される。ｏｐｌｏｃｋは、ｏｐｌｏｃｋを中断する可能性がある同じクライアント上で２つのプロセスを実行する１つのクライアントによって、偶発的に中断させられるおそれがあり、一方ＳＭＢリースは、ＳＭＢリースにおけるこのような偶発的な中断から保護される。この相違については、本発明の実施形態を参照しながら、必要に応じて注記することができる。
【００３２】
[0032]  ＲＥＳＴベースＡＰＩを参照すると、ＲＥＳＴベースＡＰＩはステートレス動作をサポートする。背景として、ステートレス性(statelessness)とは、要求間でサーバー上にクライアント・コンテキストが格納されないことによって、クライアント−サーバー通信が制約を受けるという観念を指すとすればよいであろう。いずれのクライアントからであれ各要求は、その要求にサービスするために必要な全ての情報を含み、そのクライアントにおいてセッション状態が保持されるか、または要求間においてクライアントには状態が全く維持されなくてもよい。これに関して、要求間には依存性がない。更に、ＲＥＳＴベース動作に対する認証は、ＲＥＳＴベース動作を認証する要求の正規化(canonicalized)バージョンに顧客のストレージ・アカウント鍵によって署名し、結果的に得られた署名を要求と共に受け渡すことに基づいて、各要求に対して同様に処理することができる。ＲＥＳＴベースＡＰＩの一例として、クライアントがファイルを作成することを可能にするファイル作成ＡＰＩをあげることができる。ファイル作成ＡＰＩは、名称パラメータおよびステータス・リターン値を有することができる。補足資料として、追加のＡＰＩ例が本明細書に含まれている。
【００３３】
[0033]  引き続き図２Ａを参照すると、図示しないコンポーネントの中でもとりわけ、クラウド・コンピューティング分散型インフラストラクチャ２００は、大まかに、ＳＦＡクライアント２０２、ＲＥＳＴクライアント２０４、クラウド・コンピューティング・プラットフォーム２０６、サービスＡＰＩ２０８、ブロブ２１２、キュー２１４、テーブル２１６、およびファイル・システム２１８を有するストレージ２１０、ならびにネットワーク２２０を含む。ネットワーク２２０は、限定ではなく、１つ以上のローカル・エリア・ネットワーク（ＬＡＮ）および／またはワイド・エリア・ネットワーク（ＷＡＮ）を含むことができる。このようなネットワーキング環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネット、およびインターネットでは極普通である。したがって、ネットワーク２２６についてはここではこれ以上説明しない。
【００３４】
[0034]  ＳＦＡクライアント２０２およびＲＥＳＴクライアント２０４は、クラウド・コンピューティング・プラットフォーム２０６によって提供されるサービスにアクセスするソフトウェアまたはハードウェアを有する計算デバイスである。クライアントは、例えば、図１を参照して説明した計算デバイス１００のような、任意のタイプの計算デバイスを含むことができる。クライアントは、ネットワーク２２０を通じて、クラウド・コンピューティング・プラットフォーム２０６にアクセスすることができる。ＳＦＡクライアント２０２およびＲＥＳＴクライアント２０４は、具体的には、クラウド・コンピューティング・プラットフォーム２０６上のサービスにアクセスするために、それぞれ、ＳＦＡプロトコルおよびＲＥＳＴプロトコルに頼るコンピューター・プログラムを指すことができる。クライアントは、サービスＡＰＩ２０８を使用して、異なるストレージ・タイプにアクセスすることができる。ストレージ・タイプには、文書、写真、ビデオ、および音楽ファイルのような大型のバイナリー・オブジェクトを、関連するメタデーターと共に格納するように設計されたブロブ２１２が含まれる。キュー２１４は、信頼できる非同期メッセージ配信ストレージ・タイプである。テーブル２１６ストレージ・タイプは、テラバイトのデーターを占める軽量データー・オブジェクトを格納する構造化格納能力を提供する。ファイル・シェア２１８は、ＳＦＡクライアント２０２およびＲＥＳＴクライアント２０４から並列に共有およびアクセスすることができるファイルを格納する能力を提供する。
【００３５】
[0035]  図２Ｂに移り、ＳＦＡクライアント２０４およびＲＥＳＴクライアント２０４は、具体的には、ファイル・サービスにアクセスすることができる。ＳＦＡ−ＲＥＳＴインターフェース２３０は、ファイル・サービス・リソース２４０をサポートするために、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能を含む。ファイル・サービス・リソース２４０は、ストレージ・アカウント２４２、シェア２４４、ディレクトリー２４６、およびファイル２４８を含む。具体的には、シェア２４４は、複数組のファイル(sets of files)を編成する方法を提供し、更にクラウド・コンピューティング・プラットフォームにおいてホストされるＳＭＢファイル・シェアとしてマウントする(mount)こともできる。ファイル・サービスは、ファイル・サービスＡＰＩ（「ＳＦＡ−ＲＥＳＴインターフェース」）２３０に基づいてファイル・サービス・リソース２４０へのアクセスを与えることができ、ＳＦＡクライアント２０２およびＲＥＳＴクライアント２０４が同時にファイル・サービス・リソース２４０にアクセスすることができる。ＳＦＡ−ＲＥＳＴインターフェースは、ＨＴＴＰ動作によってアクセス・ファイル・リソースをサポートするＡＰＩを含むことができる。動作をリソース・タイプ、およびＲＥＳＴバーブ(REST verb)と関連付けることができる。例えば、シェア作成動作は、シェアというリソース・タイプと、動作の実行時にストレージ・アカウントに新たなシェアを作成するＲＥＳＴ  バーブＰＵＴとを有することができる。本発明の実施形態では、追加の動作も考えられる。
【００３６】
[0036]  実施形態では、動作は使用するＳＦＡ−ＲＥＳＴ  ＡＰＩのバージョンを指定することができる。例えば、ｘ−ｍｓ−バージョンは、動作のバージョンを指定するために使用するＨＴＴＰヘッダとすることができる。したがって、ユーザーは、ｘ−ｍｓ−バージョン要求ヘッダを設定することによって、ユーザーが使用したい動作のバージョンを指定することができる。ＨＴＴＲＰヘッダにおいてバージョンが識別されたとき、ＡＰＩの新たなバージョンが利用可能であれば、既存のコードの機能を中断することはない。ユーザーは、ｘ−ｍｓ−バージョンＨＴＴＰヘッダを指定することによって、もっと新しいバージョンのＡＰＩをコールするためにコードを修正することができる。
【００３７】
[0037]  図２Ｃを参照すると、ＳＦＡ−ＲＥＳＴインターフェース２３０は、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの異なる統合機能をサポートする、様々な異なるインターフェース・コンポーネント（例えば、ＡＰＩ）を含むことができる。ＳＦＡ−ＲＥＳＴインターフェースは、とりわけ、データー・アクセス・コンポーネント２５０、リース・コンポーネント２５２、キャッシュ・コンポーネント２５４、タイムスタンプ・コンポーネント２５６、メタデーター・コンポーネント２５８、属性コンポーネント２６０、バイト範囲ロック・コンポーネント２６２、命名および参照コンポーネント２６４、ならびにロッキング・コンポーネント(locking component)２６６を含む。
【００３８】
[0038]  図２Ｄを参照すると、本発明の実施形態は、更に、ファイル・サービス・スキーマ・リソース２７０を含む。ファイル・サービス・スキーマ・リソース２７０は、ファイル・システムへのアクセスを容易にする。ファイル・サービス・スキーマ・リソース２７０は、アクセス・テーブル２７２、シェア・テーブル２７４、およびスナップショット・コンポーネント２７６を有するスキーマを含む。アクセス・テーブル２７２およびシェア・テーブル２７４を有するスキーマは、ファイル・シェア、ディレクトリー、およびファイルを有するファイル・システムへのアクセスを与える。
【００３９】
[0039]  尚、本明細書において説明するこの構成およびその他の構成は、例として明示されるに過ぎないことは理解されてしかるべきである。示されるものに加えてまたはその代わりに、他の構成および機能（例えば、機械、インターフェース、機能、命令(orders)、および機能の分類(grouping)）も使用することができ、更にある機能が全て纏めて省略されてもよい。更に、本明細書において説明する機能の多くは、離散コンポーネントまたは分散コンポーネントとして、あるいは他のコンポーネントと併せて、更には任意の適した組み合わせおよび位置で実現することができる機能的エンティティである。１つ以上のエンティティによって実行されるというように本明細書において説明する種々の機能は、ハードウェア、ファームウェア、および／またはソフトウェアによって実行することができる。例えば、メモリーに格納されている命令を実行するプロセッサーによって、種々の機能を実行することができる。
【００４０】
[0040]  データー・アクセス・コンポーネントは、ファイル・システムへのアクセスを容易にすることができる。データー・アクセス・コンポーネントは、ファイル・システムへのアクセスをサポートするＳＦＡベースＡＰＩおよびＲＥＳＴベースＡＰＩを含む。具体的には、ＳＦＡベースＡＰＩはハンドルを実装し、データー・アクセス（例えば、ファイルを開くまたは作成する）は、ファイルにハンドルを返し、このハンドルを使用してファイルに対する読み取りおよび書き込みを許可する。ＲＥＳＴベースＡＰＩは、ＳＦＡプロトコルにおいて見られる同等のハンドル機能をサポートしない。ＲＥＳＴベースＡＰＩは、ハンドル機能を使用しないで、ファイルの読み取りおよび書き込みをサポートするが、ＳＦＡプロトコルに基づく対応エレメントを含む。
【００４１】
[0041]  リース・コンポーネントは、共有アクセスに対するファイル・リースの実行を容易にすることができる。ＳＦＡ−ＲＥＳＴインターフェースは、ＲＥＳＴリースを容易にするＲＥＳＴベースＡＰＩを含む。ＲＥＳＴリースは、ある時間期間にわたる、ファイルへの排他的書き込み共有読み取りアクセス(exclusive write shared read access)を許す。この期間は、定められた時間期間、例えば、１分であっても、または無限時間期間であってもよい。また、ＳＦＡ−ＲＥＳＴインターフェースは、ファイル・ハンドルに基づく共有アクセスをサポートするＳＦＡベースＡＰＩも含む。一例として、ユーザーがＳＦＡベース動作によってファイルを作成するまたは開くとき、ＳＦＡベース動作は動作モディファイアを含むことができる。動作モディファイアは、ＳＦＡベース動作を修正する制約（例えば、アクセス、共有）を定義する。この制約は、読み取り、書き込み、および削除のようなアクセス制約とすることができ、更に、この制約は、読み取り共有、書き込み共有、および削除共有のような、共有制約であることもできる。ファイル・サービスは、ファイルへのアクセスを与えるためにＳＦＡベース動作を実行すべきか否か、現在そのファイルに対して開いている他の全てのハンドルからの動作モディファイアが、ＳＦＡベース動作に対する現在の動作モディファイアと相容れるか否かに基づいて、判定することができる。
【００４２】
[0042]  リース・コンポーネントは、読み取り、書き込み、および削除のためにファイルにアクセスするための、ファイルへのファイル・ハンドルを開き、他のハンドルからの共有読み取りを許可するのと同様にＲＥＳＴリースが機能するために、ＲＥＳＴベースＡＰＩを実装する。リース・コンポーネントは、ＲＥＳＴベース動作がＲＥＳＴリースを取得するまたは更新する(renew)ときに、既存のリースがないことを確認するために有効性判断を実行し、開いているファイルの別のハンドルまたはリースがあり、これらがＲＥＳＴベース動作と相容れないために、リースが許されないことを示すエラーを戻すことができる。しがって、ファイルを開くためのＲＥＳＴベース動作またはＳＦＡベース動作は、以前のＲＥＳＴベース動作に関連付けられたリース、または以前のＳＦＡベース動作に関連付けられた動作モディファイアを参照することに基づいて、行われない可能性がある。
【００４３】
[0043]  キャッシュ・コンポーネントは、便宜的ロック(opportunistic lock)を伴うＲＥＳＴベース動作およびＳＦＡベース動作がどのように相互作用するか管理する。ＳＭＢOｐｌｏｃｋ（便宜的ロック）とは、性能を向上させネットワーク転送を減らすためにＳＦＡクライアントが要求するキャッシング・メカニズムである。これが意味するのは、特定のファイルまたはディレクトリーの最新状態をＳＦＡクライアント上にキャッシュできるということである。ＳＭＢリース・タイプと呼ばれる多数のｏｐｌｏｃｋのタイプがある。読み取り（Ｒ）を取得すると、クライアントはローカル・キャッシュから読み取ることができる。書き込み（Ｗ）を取得すると、クライアントは、データーを一掃して(flush)ＳＭＢサービスに戻す必要なく、ローカルに書き込むことができる。ハンドル（Ｈ）を取得すると、クライアントは、ハンドル閉鎖が生じたときに、ＳＭＢサービスに通知する必要がなくなる。ｏｐｌｏｃｋは、アプリケーションが同じアクセスおよび共有モードでファイルを開き続けるおよび閉じ続ける場合に有用である。ＳＦＡクライアントは、閉じる度に直ちにＳＭＢサービスに通知する必要はない。以上のＳＭＢリース・タイプは、ハンドルを開く間に指定されるアクセスおよび共有モードとは独立である。通例、ＳＦＡクライアントは、アクセスおよび共有モードには関係なく、新たなハンドルをファイルに対して開くときはいつでも全てのリース・タイプを取得しようとする。
【００４４】
[0044]  ＲＥＳＴベース動作に応じて、ＲＥＳＴ要求が既存のＳＦＡクライアントｏｐｌｏｃｋを中止することが必要になる場合がある。これは、書き込みｏｐｌｏｃｋの場合には、ファイル・サービスに対する変更がキャッシュされているならば、ＳＦＡクライアントはそれを一掃しなければならない。以下に、各タイプのｏｐｌｏｃｋを中断しなけらばならない理由の一部を示す。ＰｕｔＲａｎｇｅのような書き込みＲＥＳＴ動作が発行されるときにはいつでも、読み取り（Ｒ）ｏｐｌｏｃｋを中断しなければならない。ＧｅｔＢｌｏｂのような読み取りＲＥＳＴ動作が発行されるときはいつでも、書き込み（Ｗ）ｏｐｌｏｃｋを中断しなければならない。クライアントが削除ＲＥＳＴ動作を発行するときはいつでも、ハンドル（Ｈ）ｏｐｌｏｃｋを中断しなければならない。何故なら、ファイル・サービスは、削除要求が満たされるためには、ハンドルを開く必要がないからである。
【００４５】
[0045]  ｏｐｌｏｃｋの中断は、潜在的に、キャッシュされているＳＭＢクライアントの変更(SMB cached client changes)を一掃することを含み、これはＲＥＳＴサービス動作の応答時間の余分な遅延を生ずる原因となるおそれがあり、またはＲＥＳＴ動作が行われず(fail)、ステータス・コード４０８（要求時間切れ）およびエラー・コード識別子（例えば、ClientCacheFlushDelay）が出される原因となるおそれがある。あるシナリオ例では、ｏｐｂｌｏｃｋ中断および一掃(flush)が必要とされ、ＲＥＳＴクライアント体験が遅延する場合が含まれる。このシナリオでは、ＳＦＡクライアントがファイルを開き、ＲＷＨｏｐｌｏｃｋを取得して、データーをローカルに書き込む。ＲＥＳＴクライアントはＧｅｔＦｉｌｅ要求を送る。ファイル・サービスは書き込み（Ｗ）ｏｐｌｏｃｋを中断し、クライアントにＲＨｏｐｌｏｃｋを託す。ＳＦＡクライアントは、ファイル・サービスと比較して(against)、そのキャッシュされているデーターを一掃し、ｏｐｌｏｃｋ中断を承認する。ファイル・サービスは、ＧｅｔＦｉｌｅ要求を処理し、要求されたデーターを戻すことによって応答する。以上の例では、ＲＥＳＴクライアントは、ｏｐｌｏｃｋ中断、およびＳＦＡクライアントがそのデーターをファイル・サービスと比較して一掃するために要する時間によって生ずる遅延を受ける。その後のＧｅｔＦｉｌｅ要求はいずれも、追加の遅延を全く受けない。何故なら、書き込み（Ｗ）ｏｐｌｏｃｋは既に中断されているからである。
【００４６】
[0046]  他のシナリオ例には、ｏｐｂｌｏｃｋ中断が必要とされるが、ＲＥＳＴクライアントは遅延を受けない場合が含まれる。このシナリオでは、ＳＦＡクライアントは既にＲＨｏｐｌｏｃｋを有する（以上の例からの継続）。ＲＥＳＴクライアントはＰｕｔＲａｎｇｅ要求を発行する。ファイル・サービスはｏｐｌｏｃｋ中断要求をＳＦＡクライアントに送るが、応答を待たない。ファイル・サービスはＰｕｔＲａｎｇｅ要求を処理する。以上の例では、ｏｐｌｏｃｋ中断が必要とされるが、ＲＥＳＴ動作は追加の遅延を全く受けない。何故なら、読み取りｏｐｌｏｃｋを中断するときには応答は必要とされないからである。
【００４７】
[0047]  ファイル・サービスは、同じファイルに対して開いているハンドルを既に有するＳＦＡクライアントのｏｐｌｏｃｋ状態に基づいて、各ＲＥＳＴベース動作に対応する異なる挙動を有することができる。ｏｐｌｏｃｋ中断を停止するとは、ファイル・サービスは、中断が正しく行われたことの承認を待たなければならないが、停止しない(non-blocking)場合には、ファイル・サービスは承認を待つ必要がないという事実に関係する。Ｏｐｌｏｃｋ中断の停止が必要とされる場合、そして指定された要求制限時間(request timeout) および３０秒までにこの中断が正しく行われない場合、ＲＥＳＴ動作は行われず、ステータス・コード４０８（要求時間切れ）およびエラー・コード識別子（例えば、ClientCacheFlushDelay）が出される可能性がある。
【００４８】
[0048]  更に、一例として、ＤｅｌｅｔｅＦｉｌｅ要求もｏｐｌｏｃｋハンドル（Ｈ）リースを中断することを要求する。これは、ＤｅｌｅｔｅＦｉｌｅがＲＥＳＴクライアントから発行されたときに、ＳＭＢ側に開いているファイル・ハンドルがないことを確認するために行われる。共有違反(sharing violation)がある場合、要求が行われず、ステータス・コード４０９（競合）およびエラー・コード識別子（例えば、共有違反）が出される。
【００４９】
[0049]  タイムスタンプ・コンポーネントは、イベントが発生するときを識別するように機能することができる。具体的には、タイムスタンプ・コンポーネントは、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能がＳＦＡ−ＲＥＳＴインターフェースを介して利用可能になるように、マルチタイムスタンプ実装(multi-timestamp implementation)にすることができる。ＲＥＳＴベースＡＰＩは、楽観的同時モデル(optimistic concurrency model)のためのサポートを行う。楽観的同時モデルは高精度のタイムスタンプに基づく。楽観的同時モデルでは、ファイル・サービスがファイルにアクセスするためにＲＥＳＴベース動作を受けたとき、ファイル・サービスはエンティティ・タグ（「ＥＴＡＧ」）を生成して戻す。エンティティ・タグは、ファイルへの書き込み毎に増分されることが保証された正確なタイムスタンプである。読み取りまたは書き込みのような、後続のＲＥＳＴベース動作に、ＥＴＡＧを条件付きヘッダとして差し戻すことができる。この条件付きヘッダは、ファイルがコール間で変化した場合にＲＥＳＴベース動作を行わせず、またはＥＴＡＧが変化していない場合ＲＥＳＴベース動作を行わせない。ＳＦＡベースＡＰＩは、楽観的同時モデルを実装しない。代わりに、ファイル・ハンドルが閉じられるときに、タイムスタンプの更新を実行する。加えて、従前のファイル・システムは、大抵の場合、ＳＡクライアントがファイル上のタイムスタンプを任意の時間に明示的に設定することを許可する。
【００５０】
[0050]  タイムスタンプ・コンポーネントは、各ファイル上で５つの異なるタイムスタンプをサポートする。これらのタイムスタンプの内４つは、ＳＦＡベースＡＰＩに基づくことができる。これらのタイムスタンプは、作成時刻、最後の変更時刻、最後の書き込み時刻、および最後のアクセス時刻を含む。４つのタイムスタンプは、ＳＭＢプロトコルと同じセマンティクスを使用して実装することができる。５番目のタイムスタンプは、楽観的同時(optimistic concurrence)に使用することができるＥＴＡＧである。５番目のタイムスタンプは、ＳＦＡベースＡＰＩを介して露出されない。５つのスタンプは全て、ＲＥＳＴベースＡＰＩを介して利用可能である。これに関して、タイムスタンプ・コンポーネントは、５つの異なるタイムスタンプに基づいて、ＳＦＡベース動作とＲＥＳＴベース動作との間において統合機能をサポートすることができる。具体的には、ＲＥＳＴベース動作は楽観的同時モデルに依存するので、ＥＴＡＧタイムスタンプは、ＳＦＡベース動作がファイル上で実行されるときに、更新される必要がある。したがって、ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡベース動作が実行されるときに、他のタイムスタンプと共にＥＴＡＧの更新をサポートする。条件付きＲＥＳＴベース動作を伴うシナリオ例では、ＳＦＡベース動作を使用してファイルが更新された場合、後続の条件付きＲＥＳＴベース動作は、条件付きＲＥＳＴベース動作を実行できるか否か妥当性を判断するために、更新されたＥＴＡＧが存在すると判定する必要がある。
【００５１】
[0051]  メタデーター・コンポーネントは、データー・コンテンツについての記述的情報をサポートするように構成することができる。ＲＥＳＴベースＡＰＩは、小さな１組の任意名称および値の対をファイルと関連付けさせる。ＳＦＡベースＡＰＩは、ファイルと関連付けることができる拡張属性(extended attribute)を有する。名称の制約は、典型的なＲＥＳＴプロトコルよりも制限される（長さおよび有効なキャラクター）ＳＭＢ−プロトコルに基づく。ＳＦＡプロトコルおよびＲＥＳＴプロトコルが相容れるようにするために、ＲＥＳＴベースＡＰＩには、メタデーターに利用可能な制限された名称が付けられている(implement)。
【００５２】
[0052]  命名および参照コンポーネントは、ファイル・サービス・リソースへのアクセスをサポートすることができる。ファイル・サービス・リソースには、名称または参照シンタックスに基づいてアクセスすることができる。ストレージ・アカウントは０個以上のシェアを収容する(contain)ことができる。シェアは、プロパティ、メタデーター、および０個以上のファイルまたはディレクトリーを収容する。ディレクトリーは、プロパティおよび０個以上のファイルまたはディレクトリーを収容することができる。ファイルは、二進データー、プロパティ、およびメタデーターで構成される任意の１つのエンティティとすることができる。
【００５３】
[0053]  シェア名称を参照して、ＳＦＡプロトコルよりも一層限定的に、ＳＦＡ−ＲＥＳＴインターフェースのＡＰＩにおいて、ファイル・サービス・シェア名称規則を実施することができる。したがって、ブロブ・サービスのためのＡＰＩ、およびＳＦＡ−ＲＥＳＴインターフェースのＡＰＩは、ブロブ・コンテナおよびファイル・シェアに対して同様の命名慣例を共有することができる。
【００５４】
[0054]  ディレクトリー名およびファイル名を参照して、ＳＦＡ−ＲＥＳＴインターフェースは、更に、大文字小文字を区別しないＡＰＩ、および大文字小文字を保存するＡＰＩもサポートする。ファイル名およびディレクトリー名の許容長は、ＲＥＳＴベースＡＰＩにおける個々のコンポーネント（スラッシュ同士の間にある部分）毎に限定され、ＲＥＳＴベースＡＰＩのパス名称の全長は、ＲＥＳＴプロトコルにおいて示されるよりも長いまたは深い名称を許容する。名称および参照コンポーネントは、ＲＥＳＴプロトコルでは通例合法であるが今では違法であるキャラクター、およびＲＥＳＴでは通例違法であるがここではＲＥＳＴベースＡＰＩにおいては合法であるＳＦＡプロトコル・キャラクターをもはやサポートしないＲＥＳＴベースＡＰＩを含む。一実施形態では、ＲＥＳＴプロトコルではサポートされないがここでは命名および参照コンポーネントのＲＥＳＴベースＡＰＩにおいてサポートされるキャラクターを、ＲＥＳＴベースＡＰＩにおいて自由にする(escape)ことができる。キャラクターを自由にするには、選択されたキャラクターを％ＨＥＸコードでエンコードすることを含む。違法なＲＥＳＴプロトコル・キャラクターをエンコードしてこれらをＲＥＳＴベースＡＰＩにおいて合法にする他の変形および組み合わせも、本発明の実施形態では考えられる。
【００５５】
[0055]  パスネーム(pathname)は、「／」スラッシュ・キャラクターによって分離された１つ以上のパスネーム・コンポーネント（ディレクトリー名またはファイル名）を含む。最後のパスネーム・コンポーネント以外の全てのパスネーム・コンポーネントは、ディレクトリーを示すことができる。最後のパスネーム・コンポーネントは、ファイルのディレクトリーを示す。パスネームは、長さを既定数（例えば、１０２４語）以下のキャラクターにすることができる。パスネームは、「／」スラッシュ・キャラクターによって分離された１つ以上のパスネーム・コンポーネントで構成することができる。サブディレクトリーの深さ(subdirectory depth)は、既定長（例えば、２５０）を超えないように構成することができる。ファイルはディレクトリーと同じパスを共有することができず、その逆も当てはまる。即ち、同じペアレント・ディレクトリーを共有するファイルまたはディレクトリーには、同じ名称を使用することはできない。例：「データー」という名称のファイルおよびディレクトリーが、同じペアレント・パスの下に存在することはできない。
【００５６】
[0056]  シェアまたはファイル・リソースについてのメタデーターは、リソースに関連付けられた名称−値対として格納することができる。ディレクトリーは、メタデーターなしで実装することができる。メタデーター名は、Ｃ＃識別子についての命名規則に基づくことができる。メタデーター名は、これらが作られたときの大文字／小文字を保存することができるが、設定されるときまたは読み取られるときは、大文字／小文字を区別しない。１つのリソースに対して、同じ名称の２つ以上のメタデーター・ヘッダが提出された場合、ファイル・サービスはステータス・コード４００（誤った要求）を返す。
【００５７】
[0057]  ＳＦＡ−ＲＥＳＴインターフェースは、シェア、ディレクトリー、またはファイルのためにユニフォーム・リソース識別子（「ＵＲＩ」）参照をサポートすることができる。各ファイル・サービス・リソースは、そのリソース自体を参照する対応基準ＵＲＩを有することができる。ストレージ・アカウントでは、基準ＵＲＩはアカウントの名称のみを含むことができる。シェアでは、基準ＵＲＩはアカウントの名称およびそのシェアの名称を含むことができる。ディレクトリーでは、基準ＵＲＩはアカウントの名称、シェアの名称、およびディレクトリーのパスを含むことができる。ファイルでは、基準ＵＲＩはアカウントの名称、シェアの名称、およびファイルのパスを含むことができる。ＵＲＩは一意にＵＲＩを実装することができる。あらゆるアカウント名は一意であるので、２つのアカウントが同じ名称のシェアを有することができる。しかしながら、所与のストレージ・アカウントの範囲内では、あらゆるシェアを一意の名称で実装することができる。所与のシェアまたはディレクトリー内部のファイルは、そのシェアまたはディレクトリー内部で一意の名称を有することもできる。命名規則に違反する名称でシェア、ディレクトリー、またはファイルを作成しようとすると、要求は受け入れられず(fail)、ステータス・コード４００（間違った要求）が出される可能性がある。
【００５８】
[0058]  バイト範囲ロック・コンポーネントは、ＳＦＡ−ＲＥＳＴインターフェースのためにバイト範囲ロッキング(byte range locking)をサポートすることができる。ＳＦＡベースＡＰＩは、ＳＦＡクライアントがファイルのある範囲に対して排他的なアクセスを要求すること、およびファイルのある範囲への読み取りアクセスを要求することを許可することができる。これによって、その範囲内では他の書き込みがないことを確実とするが、読み取り(readers)は許可する。バイト範囲ロック・コンポーネントは、ＳＦＡバイト範囲ロックのロジックとの競合(conflict)が存在するときは、ＲＥＳＴベースＡＰＩを介した読み取りや書き込みを拒否するように構成することができる。ＳＦＡベースＡＰＩは、バイト範囲ロックがファイルの領域への読み出しおよび書き込みアクセスを管理することを可能にし、ＲＥＳＴベースＡＰＩは、この能力を特定の実装(implementation)のために利用することはできない。したがって、代わりに、ＲＥＳＴベースＡＰＩがファイル全体に対する書き込みアクセスを必要とする場合がある。これは、ＳＦＡクライアントがそのファイル内におけるいずれの範囲でもロックを有する場合には、ＲＥＳＴベース動作は行うことができないということも意味する。しかしながら、バイト範囲ロッキングをサポートするＲＥＳＴベースＡＰＩによって、 ＲＥＳＴベース動作を実施することができる。
【００５９】
[0059]  アクセス・コンポーネントは、２つの異なるプロトコル・エンドポイントに基づいて、ファイル・サービスへのアクセスをサポートする役割を担う。アクセス・コンポーネントは、ＳＦＡプロトコルのためのエンドポイント・ポイント(endpoint point)、およびＲＥＳＴプロトコルのための別のエンドポイントを設ける。これに関して、ＳＦＡクライアントに対する要求および応答は、ＳＦＡプロトコル・エンドポイントを通じて伝達され、ＲＥＳＴクライアントに対する要求および応答は、ＲＥＳＴプロトコル・エンドポイントから伝達される。
【００６０】
[0060]  ロッキング・コンポーネントは、ファイル・ロックを管理する役割を担う。ロッキング・コンポーネントは、ＳＦＡベース動作を処理し、動作モディファイアを使用してこの動作を実行し、動作モディファイアを参照することに基づいて、ＲＥＳＴベース動作を処理するように構成される。動作モディファイアは、アクセス・モードおよびシェア・モードを示すロッキング・モディファイアであってもよい。一例として、ＳＦＡクライアントは、シェアをファイル・シェアとしてマウントすることができる。ＳＦＡ−ＲＥＳＴインターフェースを使用して、ＳＦＡクライアントはロッキング・コンポーネントにおいてファイル・システム・ロッキング・メカニズムを利用して、共有ファイルへのアクセスを管理することができる。ファイルにアクセスするためのＳＦＡベース動作が、動作モディファイアを含むこともできる。ロッキング・コンポーネントを経て、動作モディファイアは、読み取り、書き込み、および削除のために全体的なファイル・アクセス共有を要求するロッキング・モディファイア、または１つのファイル内部の範囲への読み取りおよび書き込みアクセスを管理するためのバイト範囲ロックになることができる。ＳＦＡクライアントがファイルを開くとき、そのファイルを開くためのＳＦＡベース動作は、ファイル・アクセスおよびシェア・モードを有するロッキング・モディファイアを含む。以下のファイル・アクセス・ロッキング・モディファイアは、通例、ＳＦＡクライアントによって使用される。
【００６１】
読み取り：読み取りのためにのみファイルを開く。
書き込み：書き込みアクセスのためにのみファイルを開く。
読み取り／書き込み：読み取り／書き込み許可と共に、ファイルを開く。
【００６２】
削除：削除アクセスのためにのみファイルを開く。
[0061]  以下のファイル・シェア・ロッキング・モディファイアは、通例、ＳＦＡクライアントによって使用される。
【００６３】
無：現在のファイルの共有に同意しない。ファイルが閉じられるまで、このファイルを開く要求はいずれも行われない(fail)。
共有読み取り：読み取りのために、以降ファイルを開くことを許可する。このフラグが指定されない場合、ファイルが閉じられるまで、読み取りのためにこのファイルを開く要求はいずれも行われない。
【００６４】
共有書き込み：書き込みのために、以降ファイルを開くことを許可する。このフラグが指定されない場合、ファイルが閉じられるまで、書き込みのためにこのファイルを開く要求はいずれも行われない。
【００６５】
共有読み取り／書き込み：読み取りまたは書き込みのために、以降ファイルを開くことを許可する。このフラグが指定されない場合、ファイルが閉じられるまで、読み取りまたは書き込みのためにこのファイルを開く要求はいずれも行われない。
【００６６】
共有削除：今後のファイル削除を許可する。このフラグが指定されない場合、ファイルが閉じられるまで、このファイルを削除する要求はいずれも行われない。
[0062]  更に、例をあげて、ＳＦＡクライアントの共有について例示する。例えば、共有違反(sharing violation)なくファイルを開く。クライアントＡがFileAccess.Read およびFileShare.Writeによってファイルを開く（開いている間、以降の読み取り／削除を拒む(deny)。次いで、クライアントＢが、FileAccess.WriteおよびFileShare.Readによってこのファイルを開く（開いている間、以降の書き込み／削除を拒む）。結果：ファイル・アクセスとファイル・シェア・モードとの間には競合がないので、これは許される。
【００６７】
[0063]  ファイル・アクセスによる共有違反：クライアントＡが、FileAccess.Write およびFileShare.Readによってファイルを開く（開いている間、以降の書き込み／削除を拒む）。次いで、クライアントＢがFileAccess.WriteおよびFileShare.Writeによってファイルを開く（開いている間、以降の読み取り／削除を拒む）。結果：クライアントＡによって以前に指定されたシェア・モードによって拒まれるファイル・アクセスを指定したので、クライアントＢは共有違反を犯すことになる。
【００６８】
[0064]  共有モードによる共有違反：クライアントＡが、FileAccess.Writeおよび FileShare.Writeによってファイルを開く（開いている間、以降の読み取り／削除を拒む）。次いで、クライアントＢが、FileAccess.WriteおよびFileShare.Readによってこのファイルを開く（開いている間、以降の書き込み／削除を拒む）。結果：書き込みアクセスのために未だ開いているファイルへの書き込みアクセスを拒む共有モードを指定したので、クライアントＢは共有違反を犯すことになる。
【００６９】
[0065]  ＲＥＳＴベース動作は、動作モディファイアによってファイルを開くことができない。しかしながら、ＲＥＳＴベース動作は、ＳＦＡクライアント上で開いている任意のファイルに対して指定されたシェア・モードを尊重する。例をあげて、ＳＭＢシェア・モードと相互作用するＲＥＳＴベース動作を更に例示することができる。ＲＥＳＴファイル取得共有違反（Get File Sharing Violation)：ＳＦＡクライアントはFileAccess.ReadおよびFileShare.Writeによってファイルを開く（開いている間、以降の読み取り／削除を拒む）。次いで、ＲＥＳＴクライアントはファイル取得（ＲＥＳＴ  ＡＰＩ）動作をそのファイル上で実行する（これによって、先のテーブルにおいて指定されたようにFileAccess.Readを使用する）。結果：ＲＥＳＴクライアントの要求は行われず(fail)、ステータス・コード４０９（競合）およびエラー・コード「共有違反」が出される。何故なら、読み取り／削除アクセスを拒む間、ＳＦＡクライアントは未だファイルを開いているからである。
【００７０】
[0066]  ＲＥＳＴ範囲設定(Put Range)共有違反：ＳＦＡクライアントは、 FileAccess.WriteおよびFileShare.Readによってファイルを開く（開いている間、以降の書き込み／削除を拒む）。次いで、ＲＥＳＴクライアントは範囲設定（ＲＥＳＴ  ＡＰＩ）動作をそのファイル上で実行する（これによって、先のテーブルにおいて指定されたようにFileAccess.Writeを使用する）。結果：ＲＥＳＴクライアントの要求は行われず、ステータス・コード４０９（競合）およびエラー・コード「共有違反」が出される。何故なら、ＳＦＡクライアントはまだファイルを開いているが、書き込み／削除アクセスを拒むからである）。
【００７１】
[0067]  尚、ＳＦＡクライアント共有モードは、ＲＥＳＴベース動作に影響(implication)を及ぼす可能性があることが考えられる。ＳＦＡクライアントがファイルを開くときに指定される共有モードによっては、ファイル・サービスがエラー・コード「共有違反」による競合（例えば、ステータス・コード４０９）を戻す可能性がある。ファイルが共有違反を戻すのは、ＳＦＡクライアント上で開いているファイルが原因である。一例として、ＳＦＡクライアント・ファイル共有モードが、書き込みおよび削除を拒む共有読み取りである可能性がある。したがって、ファイル作成、ファイル・プロパティ設定、ファイル・メタデーター設定、ファイル削除、および範囲設定といったＲＥＳＴベース動作は行われず、共有違反が指示される。ファイル・サービスは、ＳＦＡクライアント上においてファイルが開いていることのために、共有違反を戻すことができる。
【００７２】
[0068]  削除コンポーネントは、削除を管理する役割を担う。削除コンポーネントは、ＳＦＡベース削除動作を処理し、動作モディファイアを使用して実行し、動作モディファイアを参照することに基づいて、ＲＥＳＴベース削除動作を処理するように構成される。ＳＦＡクライアントが削除のためにファイルを開くとき、そのファイル上における他の全てのＳＦＡクライアントの開いているハンドルが閉じられるまで、このファイルに削除保留の印を付ける。ファイルに削除保留の印が付けられている間、このファイル上におけるＲＥＳＴベース動作はいずれも、ステータス・コード競合をエラー・コード識別子（例えば、SMBDeletePending）と共に戻す。ステータス・コード４０４は戻されない。何故なら、ＳＦＡクライアントがファイルを閉じる前に削除保留フラグを取り下げる可能性があるからである。言い換えると、ファイルが既に除去されているときは、ステータス・コード４０４（発見されず）が予期される。更に、ファイルがＳＭＢ削除保留状態にあるとき、これはリスト・ファイル結果には含まれない場合もある。尚、ＲＥＳＴベースのファイル削除およびディレクトリー削除動作が原子的にコミットされ、削除保留状態には至らないことが考えられる。
【００７３】
[0069]  属性コンポーネントは、ＲＥＳＴベース動作に対するファイル属性の関与(implication)を管理するように構成される。ＳＦＡベース動作を使用するＳＦＡクライアントは、アーカイブ、読み取り専用、隠れ、およびシステムを含むファイル属性を読み取ることそして設定することができる。ファイルまたはディレクトリーに読み取り専用属性が設定されている場合（読み取り共有によってＳＭＢにおいて開かれている場合であっても）、このファイルに対して書き込みを行おうとするＲＥＳＴベース動作はいずれも行われず、ステータス・コード４１２（前提条件を満たさない）およびエラー・コード識別子（例えば、読み取り専用属性）が出されるであろう。これらのＲＥＳＴベース動作は、ファイル作成、ファイル・プロパティ設定、ファイル・メタデーター設定、および範囲設定である。更に、ファイル属性が設定されない、またはＲＥＲＳＴクライアントから読み取られない場合もあることが考えられる。一旦ファイルが読み取り専用にされると、ＲＥＳＴクライアントは、ＳＦＡクライアントが読み取り専用属性を取り消すまで、そのファイルに書き込むことができない。
【００７４】
[0070]  引き続き図２Ｄを参照すると、ファイル・サービスはファイル・サービス・スキーマ・リソース２７０をサポートする。したがって、ＳＦＡ−ＲＥＳＴインターフェースは、このスキーマに基づいて、ファイルにアクセスし易くする。ＳＦＡクライアントまたはＲＥＳＴクライアントは各々、ＳＦＡベース動作またはＲＥＳＴベース動作をそれぞれ生成することができ、この動作は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて実装されたスキーマを使用して、ファイル・システムにアクセスする。これに関して、スキーマ・フィールドは、並列ＳＦＡベースおよびＲＥＳＴベースのファイル・システムへのアクセスをサポートするＳＦＡ−ＲＥＳＴインターフェースのエレメントを含む。
【００７５】
[0071]  スキーマは論理スキーマとすることができる。尚、スキーマの物理表現は、基礎のデーターベースのニュアンスを説明するために、異なるものにすることが可能であると考えられる。また、スキーマの物理表現は、下位互換性を有するように変更することもできる。スキーマは、複数のテーブルに基づくこともできる。一実施態様では、スキーマは８つのファイル・アクセス・テーブルと、１つのシェア・テーブルとを含む。主要なテーブルは名前空間テーブルとすればよく、このテーブルには、ファイルおよびディレクトリーがそれらの名称に基づいて格納される。名前空間テーブルはシェアの名称を含むことができる。名前空間テーブルは、階層的にすることができ、ファイルおよびディレクトリーがそれらのペアレント・ディレクトリーのチャイルドとして格納される。ファイルまたはディレクトリーの最大パス(full path)は、名前空間テーブルにおける多数のルックアップ(lookup)に基づいて決定される。ファイルは、このテーブルにおいてＩＤを含むことができる。ＩＤは、他のアクセス・テーブルにおいてそのファイルについての情報を検索する(lookup)ために使用される。
【００７６】
[0072]  更に、スキーマは情報テーブルを含むことができる。この情報テーブルはファイルのコンテンツについての情報を格納するために使用することができる。この情報テーブルはファイルのコンテンツ自体を格納するのではない。このテーブルに対する鍵はファイルＩＤである。
【００７７】
[0073]  また、スキーマはページ範囲テーブルもサポートすることができる。ページ範囲テーブルは、格納されているファイル(filed stored)の実際のデーターを格納するために使用することができる。ページ範囲テーブルに対する鍵は、ファイルＩＤと、格納されているページ範囲のサイズとしてのオフセットとの双方を含む。
【００７８】
[0074]  更に、スキーマはハンドル・テーブルもサポートすることができる。ハンドル・テーブルは、ファイル上で開いているハンドルを表すために使用することができる。ハンドル・テーブルは、ファイル・システム内のファイルにハンドルを戻すファイルを開く、または作成するのをサポートする。ハンドルが戻されると、クライアントはそのハンドルを使用してファイルに対して読み取りおよび書き込みを行うことができる。
【００７９】
[0075]  また、スキーマはリース・テーブルもサポートする。リース・テーブルは、動作モディファイアに基づいて、ファイル・キャッシングに備える(provide for)ＳＭＢリースのサポートのために使用することができる。具体的には、リース・テーブルは、対応するファイルに関連付けられたＳＦＡベース動作の動作モディファイアに基づいて、リース状態を格納するために使用することができる。
【００８０】
[0076]  スキーマにおいて、ディレクトリーに対する変更通知設定およびイベントを格納するために、２つの追加のアクセス・テーブルを構成する(configure)ことができる。これら２つのテーブルは、変更通知テーブルおよび変更通知イベント・テーブルとすることができる。具体的には、動作が登録されるとき、ディレクトリー内部における変化を検出するために、変更通知テーブルを更新することができる。書き込み動作がファイルに実行される毎に、変更通知テーブルをチェックして、データーをイベント・テーブルに入力する必要があるか否か判定するために、対応する動作が実行される。
【００８１】
[0077]  バイト・ロック・テーブルは、ファイルに対するバイト範囲ロックを格納するために使用することができる。バイト範囲ロックは、ファイル・サービスを通じて取得することができる。バイト範囲ロックとは、ＳＦＡクライアントがファイルのある範囲に対して排他的なアクセス、およびファイルのある範囲に対して読み取りアクセスを要求するというシナリオに該当する(refer to)。これによって、その範囲では他に書き込みが行われないが、読み取り(reader)は許可されることが確実になされる。
【００８２】
[0078]  引き続き図２Ｄを参照すると、クラウド・コンピューティング・インフラストラクチャにわたるパーティションに複数のロード・バランサー（図示せず）を実装することができる。原子的に実行されるトランザクションは、１つのパーティション内部で実行される。背景として、原子トランザクション(atomic transaction)とは、全てが行われるかまたは何も行われない一連のデーターベース動作を指す。原子性(atomicity)の保証によって、一連の動作全体を徹底的に拒否するよりも大きな問題を生ずる可能性がある、 部分的にのみ行われるデーターベースへの更新を防止する。原子性とは、それ以上分割できないこと(indivisibility)およびそれ以上縮小できないこと(irreducibility)を意味する。一実施形態では、スキーマはシェア・レベルで区分される。これに関して、シェア上のトランザクションは、１つのパーティション内部で実施することができる。更に、スキーマは、シェアを多数のパーティションに格納できるように、パーティション鍵の一部である番号鍵の増大を許容する。これによって、多数のバックエンド・ノード(backend node)が１つのシェアを担当する(serve)ことが可能となり、一層の性能向上が得られる。
【００８３】
[0079]  ファイル・サービスは、ファイル・ストレージを素早くそして容易にバックアップするスナップショットを実施するスナップショット・コンポーネントをサポートする。スキーマはスナップショットを容易にする。スキーマにおけるシェア・テーブルは、スナップショット動作をサポートする。具体的には、各スナップショットにおける古いバージョンに後の時点においてアクセスできるように、コピー・オン・ライト型パターン(copy-on-write type of pattern)で新たな変更を書き込むことができる。スナップショットが撮られる前の正常な状態において、シェア・テーブルはシェア毎にエントリーを有することができる。シェア・テーブル・スキーマは、シェアに対するアクセス許可、行が有効かまたは無効かの指示、最後の修正時刻、および失効時刻を含み、更にスナップショット動作を実行し易くするスナップショット・バージョンを含む。
【００８４】
[0080]  シェア・スナップショットは、３つの動作に基づくことができる。更新動作は、スナップショットが作成されることを示すために、シェア・テーブルを更新する。作成更新動作(create update operation)は、スナップショット・バージョン識別子を      有する新たな行を追加し、スナップショットのタイムスタンプを含むように、この行をスナップショット・バージョン識別子で更新する動作を含む。この時点において、シェアに書き込むクライアントがいる場合はいずれも、書き込みがスナップショット・バージョン０で継続する。スナップショットが行われない(fail)場合、この動作はスナップショット・バージョン０を削除する(clean up)。何故なら、これは１日後に失効するからである。書き込み通知動作は、シェアをサポートするノードに、そのシェアの新たなスナップ・バージョンに書き込みを開始することを通知する動作を含む。この場合も、動作が行われない(failure occurs)場合、古いスナップショット・バージョンに書き込まれることになり、後に削除を行うことができる。３番目の動作は、完全更新動作であり、スナップショットが正しく完了したことを示すために、シェア・テーブルを更新する。ファイル・サービスは、スナップショットが正しく完了したという通知をクライアントに送ることができる。変更がテーブル上でコミットされることが不可能な場合、クライアントは、同様に有効であるバージョン１に書き込む。
【００８５】
[0081]  スナップショット・コンポーネントは、更に、ガベージ・コレクションもサポートする。ガベージ・コレクションは、スナップショット動作の不実行(failure)のときに、シェア・テーブル上で実行することができる。例えば、行われなかったスナップショット・バージョンを有する行は、既定の時間期間の後、自動的にそれ自体を削除することができる。また、スナップショット・コンポーネントは他のスナップショットを作成し、テーブルを更新することができ、シェアに書き込んでいるノードはスナップショット・バージョン２に書き込む(be writing to)ことができる。
【００８６】
[0082]  更に、スナップショット・コンポーネントは、原子スナップショット、非原子スナップショット、およびクロス−シェア(cross-share)原子スナップショットもサポートすることができる。スナップショット・コンポーネントは、原子スナップショットを作成するために、ノードと通信することができる。各ノードは、ファイル・スキーマのパーティションを変更することができる。具体的には、各ノードは、原子的にパーティションを変更することができる。スナップショット・コンポーネントは、通知をノードに送ることができる。原子スナップショット・プロセスはは、２回の通知を含む。ブロック通知は、選択されたパーティションへの書き込みを停止することを、１つ以上のノードに指令する。ブロック通知は、選択されたパーティションへの書き込みを停止する固定時間量を含むことができる。書き込み通知は、新たなスナップショット・バージョンへの書き込みを開始することを、１つ以上のノードに指令する。固定時間量以内に１つ以上のノードの全てが新たなバージョンへの書き込みを開始することができず、書き込み動作を完了することができない場合、スナップショット・コンポーネントはこのスナップショットを行わないでおくことができる。スナップショット・コンポーネントは、不実行(failure)のとき、他のスナップショット動作を試すこともできる。新たなスナップショット動作は、新たなスナップショットを新たなバージョンとして作成することができる。
【００８７】
[0083]  また、スナップショット・コンポーネントは非原子スナップショットを作成し易くすることもできる。非原子スナップショットは、１つの書き込み通知を使用して作成することができる。スナップショット・コンポーネントは、新たなスナップショット・バージョンに書き込みを開始することを１つ以上のノードに指令する通知を伝達することができる。次いで、スナップショット・コンポーネントは、１つ以上のノードが全てスナップショットの新たなバージョンを使用しているときに、シェア・テーブルを更新することができる。
【００８８】
[0084]  また、スナップショット・コンポーネントは、クロス−シェア原子スナップショットを作成し易くすることもできる。クロス−シェア原子スナップショットとは、多数のシェアにまたがって拡張することができるスナップショットを指すことができる。スナップショット・コンポーネントは、クロス−シェア原子スナップショットを実行するために、一連の動作を実行する。スナップショット・コンポーネントは、スナップショットの一部であるシェアのテーブルに新たな行を追加することができる。次いで、スナップショット・コンポーネントは、新たなスナップショット・バージョンへの書き込みを開始することを、スナップショットのシェアに対応する１つ以上のノードに指令する書き込み通知を伝達する。次いで、スナップショット・コンポーネントはシェア・テーブルを更新することができる。ＳＦＡクライアントまたはＲＥＳＴクライアントは、スナップショット・バージョンに関連付けられたタイムスタンプに基づいて、スナップショット・バージョンを参照することができる。同じタイムスタンプを、多数のシェアからのスナップショット・バージョンに割り当てることができる。これに関して、同じタイムスタンプを有するスナップショット・バージョンのシェアを建設的に(constructively)リンクすることもできる。
【００８９】
[0085]  これより図３に移り、分散型ファイル・システムにおいてファイルにアクセスする方法３００を例示する流れ図を示す。最初にブロック３００において、分散型ファイル・システムにおけるファイルに対する動作モディファイアを有するＳＦＡベース動作を受ける。ＳＦＡベース動作は、ファイル−表現状態転送（ＲＥＳＴ）インターフェースに基づいて定義される。ＳＦＡ−ＲＥＳＴインターフェースは、ＳＦＡプロトコルおよびＲＥＳＴプロトコルの統合機能を含む。ブロック３１０において、分散型ファイル・システムにおけるファイルに対するＲＥＳＴベース動作、即ち、ＲＥＳＴベース動作をＳＦＡ−ＲＥＳＴインターフェースに基づいて定義する。ブロック３３０において、動作モディファイアを使用して、ＳＦＡベース動作を実行する。ブロック３４０において、ＲＥＳＴベース動作を実行するために、動作モディファイアを参照する。ＳＦＡ−ＲＥＳＴインターフェースに基づいて、ＲＥＳＴベース動作を実行する。
【００９０】
[0086]  これより図４に移り、ファイル・シェアをスナップショットする方法４００を例示する流れ図を示す。最初にブロック４１０において、ファイル・シェアを含むシェア・テーブルを更新する。シェア・テーブルの更新は、シェア・テーブルに行を追加することを含み、この行はファイル・シェアの新たなバージョンに関連付けられる。ブロック４２０において、ファイル・シェアの新たなバージョンへの書き込みを開始することをノードに指令する通知を、ファイル・シェアに関連があるノードに伝達する。ブロック４３０において、ノードがファイル・シェアの新たなバージョンに書き込んでいることを判定する。ブロック４４０において、スナップショットが正しく完了したことを示すために、シェア・テーブルを更新する。
【００９１】
[0087]  図５に移り、分散型ファイル・システムにおけるファイルにアクセスする方法５００を例示する流れ図を示す。最初にブロック５１０において、分散型ファイル・システムにおけるファイルに対するＳＦＡベース動作をＳＦＡクライアントから受ける。ＳＦＡベース動作は、ＳＦＡベース動作の便宜的ロックを指示する動作モディファイアを有する。ＳＦＡベース動作は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて定義される。ブロック５２０において、ＳＦＡベース動作の動作モディファイアを参照することに基づいて、ファイル上でＲＥＳＴベース動作を実行する。ブロック５３０において、分散型ファイル・システムにおけるファイルに対するＲＥＳＴベース動作をＲＥＳＴクライアントから受ける。ＲＥＳＴベース動作は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて定義される。ブロック５４０において、ＳＦＡベース動作の動作モディファイアを参照することに基づいて、ファイル上でＲＥＳＴベース動作を実行する。
【００９２】
[0088]  この図の流れ図について、更に例をあげて説明することができる。先に論じたように、ＳＭＢ便宜的ロック（ｏｐｌｏｃｋ）とは、性能を向上させネットワーク転送を減らすためにＳＭＢクライアントが要求することができるキャッシング・メカニズムである。したがって、特定のファイルまたはディレクトリーの最新状態をＳＭＢクライアント上にキャッシュすることができる。多数の便宜的ロック・タイプがあり、ＳＭＢリース・タイプと呼ばれる。読み取り（Ｒ）：取得すると、クライアントはローカル・キャッシュから読み取ることができる。書き込み（Ｗ）：取得すると、クライアントは、データーを一掃して(flush)ＳＭＢサービスに戻す必要なく、ローカルに書き込むことができる。ハンドル（Ｈ）：取得すると、クライアントは、ハンドル閉鎖が生じたときに、ＳＭＢサービスに直ちに通知する必要がなくなる。これは、アプリケーションが同じアクセスおよび共有モードでファイルを開き続けるおよび閉じ続ける場合に有用である。以上のＳＭＢリース・タイプは、指定されるアクセスおよび共有モードとは独立であることを注記するのは重要である。通例、ＳＦＡクライアントは、アクセスおよび共有モードには関係なく、新たなハンドルをファイルに対して開くときはいつでも全てのリース・タイプを取得しようとする。
【００９３】
[0089]  コールされるＲＥＳＴ動作によっては、既存の便宜的ロックを中断する要求が必要になる場合もある。書き込みｏｐｌｏｃｋの場合、ＳＭＢクライアントは、キャッシュされているファイル・サービスへの変更を一掃(flush)しなければならない。各タイプのｏｐｌｏｃｋを中断しなければならないいくつかの場合がある。ＰｕｔＲａｎｇｅのような書き込み動作が発行されるときにはいつでも、読み取り（Ｒ）ｏｐｌｏｃｋを中断しなければならない。ＧｅｔＦｉｌｅのような読み取り動作が発行されるときはいつでも、書き込み（Ｗ）ｏｐｌｏｃｋを中断しなければならない。クライアントが削除動作を発行するときはいつでも、ハンドル（Ｈ）ｏｐｌｏｃｋを中断しなければならない。何故なら、ファイル・サービスは、削除要求が満たされることになる場合、ハンドルを開けることを必要としないからである。また、ＲＥＳＴ動作が既存のＳＭＢハンドルとの共有違反に直面したときも（先のテーブルを参照のこと）、ハンドル（１つまたは複数）がなおもクライアント上のアプリケーションによって実際に開かれていることを検証するために、ハンドルｏｐｌｏｃｋが中断される。
【００９４】
[0090]  ｏｐｌｏｃｋを中断するには、キャッシュされているＳＭＢクライアントの変更を一掃する必要がある場合があるが、これは動作応答時間に遅延を生ずるおそれがあり、または動作が行われず、ステータス・コード４０８（要求時間切れ）およびエラー・コードClientCacheFlushDelayが出されるおそれがある。以下に、ｏｐｌｏｃｋが中断されるいくつかのシナリオを示す。
【００９５】
[0091]  第１の例では、ｏｐｌｏｃｋ中断およびＳＭＢクライアントの一掃が必要であり、ＲＥＳＴクライアントは遅延を受ける。（１）ＳＭＢクライアントはファイルを開き、ＲＷＨｏｐｌｏｃｋを取得し、データーをローカルに書き込む。（２）ＲＥＳＴクライアントはＧｅｔＦｉｌｅ要求を送る。（２）（ｉ）ファイル・サービスは、書き込み（Ｗ）ｏｐｌｏｃｋを中断し、クライアントにＲＨｏｐｌｏｃｋにを託す。（２）（ｉｉ）ＳＭＢクライアントは、そのキャッシュされているデーターをファイル・サービスと比較して(against)一掃し、ｏｐｌｏｃｋ中断を承認する。（２）（ｉｉｉ） ファイル・サービスは、ＧｅｔＦｉｌｅ要求を処理し、要求されたデーターを戻すことによって応答する。以上の例では、ＲＥＳＴクライアントは、ｏｐｌｏｃｋ中断によって生ずる遅延、およびＳＭＢクライアントがそのデーターをファイル・サービスと比較して一掃するために要する時間によって生ずる遅延を受ける。尚、書き込み（Ｗ）ｏｐｌｏｃｋは既に中断されているので、その後のＧｅｔＦｉｌｅ要求はいずれも、追加の遅延を全く受けないことを注記しておく。
【００９６】
[0092]  第２の例では、ｏｐｌｏｃｋ中断が必要とされ、ＲＥＳＴクライアントは遅延を受ける。（１） ＳＭＢクライアントは既にＲＨｏｐｌｏｃｋを取得している。（２）ＲＥＳＴクライアントはＰｕｔＲａｎｇｅ要求を送る。（２）（ｉ）ファイル・サービスはｏｐｌｏｃｋ中断要求をＳＭＢクライアントに送るが、応答を待たない。（２）（ｉｉ） ファイル・サービスはＰｕｔＲａｎｇｅ要求を処理する。以上の例では、ｏｐｌｏｃｋ中断が必要とされるが、範囲設定要求は追加の遅延を全く受けない。何故なら、読み取りｏｐｌｏｃｋを中断するときには応答は必要とされないからである。
【００９７】
[0093]  各ＲＥＳＴ動作に対するファイル・サービスの挙動が、同じファイル上で既にハンドルを取得したＳＭＢクライアントのｏｐｌｏｃｋ状態に基づく場合、そしてＳＭＢハンドル・アクセスおよび共有がＲＥＳＴ動作と競合しないと仮定すると、様々な動作が存在する。競合が存在する場合、クライアント上で既にハンドルが本当に開いていることを確認するために、ハンドルｏｐｌｏｃｋも中断する。ｏｐｌｏｃｋ中断を停止する場合(a blocking oplock break)、ファイル・サービスは、中断が正しく行われた(successful)という承認を待つことができる。ｏｐｌｏｃｋ中断を停止しない場合、待つ必要はない。
【００９８】
[0094]  ｏｐｌｏｃｋ中断の停止が要求される場合、指定された要求制限時間(timeout)以内で、または３０秒以内に中断が正しく行われないならば、どちらが最初に完了しても、ＲＥＳＴ動作は行われず、ステータス・コード４０８（要求時間切れ）およびエラー・コードClientCacheFlushDelayが出される。尚、ファイル削除要求も、ｏｐｌｏｃｋハンドル（Ｈ）リースを中断することを要求すると考えられる。これによって、ＲＥＳＴクライアントがファイル削除をコールするときに、ＳＭＢクライアント上において何らかのファイル・ハンドルが未だ実際にアプリケーションによって開かれていることを確認する。共有違反がある場合、要求は行われず、ステータス・コード４０９（競合）およびエラー・コード SharingViolationが出される。
【００９９】
[0095]  図６に移り、分散型ファイル・システムにおけるファイルにアクセスする方法５００を例示する流れ図を示す。最初にブロック６１０において、分散型ファイル・システムにおけるファイルに対するＳＦＡベース動作をＳＦＡクライアントから受ける。ＳＦＡベース動作は、ＳＦＡベース動作のアクセス−シェア・モードを示す動作モディファイアを有する。ＳＦＡベース動作は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて定義される。ブロック６２０において、ＳＦＡベース動作の動作モディファイアを参照することに基づいて、ファイル上でＲＥＳＴベース動作を実行する。ブロック６３０において、分散型ファイル・システムにおけるファイルに対するＲＥＳＴベース動作をＲＥＳＴクライアントから受ける。ＲＥＳＴベース動作は、ＳＦＡ−ＲＥＳＴインターフェースに基づいて定義される。ブロック６４０において、ＳＦＡベース動作の動作モディファイアを参照することに基づいて、ファイル上でＲＥＳＴベース動作を実行する。
【０１００】
[0096]  この図における流れ図について更に例を挙げて説明することができる。ＳＭＢクライアントがFileShare.Writeによって（しかし、FileShare.Readではない。これが意味するのは、他のクライアントが同時にファイルを読み取ることが許されるということである）ファイルを開くときに、ＲＥＳＴ  ＧｅｔＦｉｌｅ共有違反の条件一致(REST Get File Sharing Violation implement)が起こる可能性がある。次いで、ＲＥＳＴクライアントはファイル上でＧｅｔＦｉｌｅ（ＲＥＳＴ  ＡＰＩ）動作を実行する（これによって、先のテーブルにおいて指定された通りにFileAccess.Readを使用する）。この結果、ＲＥＳＴクライアントの要求は行われず、ステータス・コード４０９（競合）およびエラー・コードSharingViolationが出される。何故なら、ＳＭＢクライアントはまだファイルを開いているが、読み取り／削除アクセスを拒むからである）。
【０１０１】
[0097]  表１を参照すると、ＲＥＳＴベース動作を受けたときに、アクセス・モードに基づいてＲＥＳＴベース動作が実行されるように、様々な異なるＳＭＢアクセス・モードを判定することができる。
【０１０２】
【表１−１】
0006626459.tif 000002
【０１０３】
【表１−２】
0006626459.tif 000003
【０１０４】
【表２−１】
0006626459.tif 000004
【０１０５】
【表２−２】
0006626459.tif 000005
【０１０６】
[0098]  以上で表１に示したように、ファイル・リスト（ＲＥＳＴ  ＡＰＩ）、ファイル・プロパティ取得（ＲＥＳＴ  ＡＰＩ）、およびファイル・メタデーター取得（ＲＥＳＴＡＰＩ）は、ＳＭＢファイル・コンテンツ上では動作せず、ファイルへの読み取りアクセスを要求しない（即ち、これらの動作は、ＳＭＢクライアントが排他的読み取りアクセスのために開いているファイルを有している場合でも正しく行われる）。
【０１０７】
[0099]  更に、ＳＭＢクライアントがファイルを開くときに指定されるシェア・モードによっては、表２において説明したように、ＲＥＳＴサービスがステータス・コード４０９（競合）をエラー・コード共有違反と共に戻す可能性があることも考えられる。
【０１０８】
[00100]  以上、特定の実施形態に関係付けて、本発明の実施形態について説明したが、これらはあらゆる観点において限定的ではなく例示であることを意図している。本発明が属する技術分野における当業者には、本発明の範囲から逸脱することなく、代替実施形態が明らかになるであろう。
【０１０９】
[00101]  以上の説明から、本発明は、以上で明記した全ての目的(ends and objects)を、自明であり構造に固有である他の利点と共に達成するのに非常に適したものであることが分かるであろう。
【０１１０】
[00102]  尚、ある種の特徴およびサブコンビネーションは有用であり、他の特徴またはサブコンビネーションを引用せずに採用されてもよいことは理解されよう。これは、請求項の範囲によって想定されており、その範囲内に該当することである。
【図１】
0006626459.tif 000006
【図２Ａ】
0006626459.tif 000007
【図２Ｂ】
0006626459.tif 000008
【図２Ｃ】
0006626459.tif 000009
【図２Ｄ】
0006626459.tif 000010
【図３】
0006626459.tif 000011
【図４】
0006626459.tif 000012
【図５】
0006626459.tif 000013
【図６】
0006626459.tif 000014