David Cheppel Azureサービスプラットフォーム翻訳パート2

翻訳の最初の部分

テクノロジーの詳細。

Azure Service Platformの概要を取得することは重要な最初のステップですが、各テクノロジーをより深く理解することも必要です。 このセクションでは、Azureファミリの各メンバーについて詳しく説明します。

Windows Azure

Windows Azureは主に2つのことを行います-アプリケーションを実行し、データを保存します。 したがって、このセクションは2つの部分に分かれており、それぞれに専念しています。 部品の相互作用も非常に重要なので、その説明もセクションの一部になります。

実行中のアプリケーション

Windows Azureでは、通常、アプリケーションには複数のインスタンスがあり、それぞれがアプリケーションコードの一部またはすべてを実行します。 各インスタンスは、独自の仮想マシンで実行されます。 すべての仮想マシンはWindows Server 2008を実行し、クラウドでの使用専用に設計されたハイパーバイザーによって提供されます。



同時に、Windows Azureアプリケーションは、それが実行されている仮想マシンを認識しません。 開発者は、Windows Azureで仮想マシンイメージを提供して作業することはできませんが、このWindowsのコピーをサポートすることを心配する必要はありません。 代わりに、CTPバージョンを使用すると、開発者は2種類のインスタンス（1つはWebロールを実行し、もう1つはワーカーロールを実行する）で.NET 3.5アプリケーションを作成できます。 図5は、すべての仕組みを示しています。



図 6 CTPバージョンでは、Windows AzureアプリケーションはWebロールインスタンスとワーカーロールインスタンスで構成され、それぞれが独自の仮想マシンで実行されます。



名前が示すように、Webロールインスタンスは、インターネットインフォメーションサービス（IIS）7を介して着信HTTP（またはHTTPS）要求を受け入れます。Webロールは、ASP.NET、WCF、またはIISで動作する他の.NETテクノロジを使用して実装できます。 図に示すように。 6、Windows Azureは、同じアプリケーションの一部である異なるWebロールインスタンス間で要求を分散する組み込みのロードバランサーを提供します。



対照的に、Worker Roleは外部からの要求を直接受け入れません。外部の着信ネットワーク接続を使用できず、その仮想マシンにIISはありません。 代わりに、通常はWindows Azureリポジトリのキューを介して、Webロールから生データを受信します。 Workerロールの作業インスタンスの結果は、Windows Azureストレージに書き込むか、外部に送信できます-送信ネットワーク接続が許可されます。 HTTPリクエストを処理し、リクエストの処理後にオフにするために作成されるWebロールインスタンスとは異なり、ワーカーロールは際限なく機能します。これはバックグラウンドジョブです。 この専門性の欠如により、Worker Roleはmain（）メソッドをサポートする.NETテクノロジーを使用して実装できます（Windows Azureの信頼に関連するいくつかの制限があります。これについては以下で説明します）。



Webロールまたはワーカーロールのインスタンスをホストする各仮想マシンには、アプリケーションがWindows Azureファクトリと対話するWindows Azureエージェントが含まれています（図6を参照）。 エージェントは、アプリケーションがWindows Azureが管理するログに書き込み、Windows Azureファクトリーなどを介して所有者にアラートを送信できるように定義されたWindows Azure APIからアクセスできます。



現在の状況は将来変わる可能性がありますが、CTPの各仮想マシンには独自の物理プロセッサコアがあります。 これがなければ、各アプリケーションのパフォーマンスを保証できます。Webロールとワーカーロールの各インスタンスには専用のカーネルがあります。 アプリケーション全体の生産性を高めるために、その所有者は構成ファイルで指定された作業インスタンスの数を増やすことができます。 Windows Azure Factoryは、新しい仮想マシンを「オーバークロック」し、カーネルを割り当て、さらに多くのアプリケーションインスタンスを起動します。 ファクトリーは、WebまたはWorkerロールのインスタンスがクラッシュしたときにそれを検出し、新しいインスタンスを起動します。



この結果に注意してください。スケーラビリティを確保するために、Webロールインスタンスはその状態を保存する必要がありません。 クライアント固有の状態に関する情報は、Windows Azureストレージに書き込まれるか、Cookieとともにクライアントに送信される必要があります。 Webロールに状態がないことは、Windows Azureに組み込まれているロードバランサーに必要です。 Webロールの特定のインスタンスにバインドできないため、同じユーザーからの異なる要求が同じインスタンスで処理されることを保証できません。



WebロールとWorkerロールは、標準の.NETテクノロジーを使用して実装されます。 ただし、ほとんどの場合、既存のアプリケーションを変更せずにWindows Azureに移行すると失敗します。 一方では、データにアクセスする方法が異なります。 Windows Azureストレージへのアクセスは、ADO.NET Webサービスを介して提供されます。ADO.NETWebサービスは、ローカルアプリケーションにまだ一般的に適用されていない比較的新しいテクノロジーです。 同様に、ワーカーロールは通常、Windows Azureストレージキューを使用して入力を受信します。つまり、ローカルアプリケーションには存在しない抽象化です。 もう1つの制限は、Windows Azureアプリケーションが完全に信頼された環境で機能しないことです。 それどころか、それらはMicrosoftがWindows Azureの信頼と呼ぶものによって制限されます。これは、ほとんどのASP.NETホストが使用する平均的な信頼度に対応します。



開発者にとって、CTPバージョンでのWindows Azureアプリケーションの構築は、従来の.NETアプリケーションの開発と非常に似ています。 Microsoftは、Windows Azure Webロール、ワーカーロール、および両方のロールの組み合わせを作成するためのVS2008プロジェクトテンプレートを提供しています。 開発者は任意の.NET言語を使用して選択できます（ただし、MicrosoftがAzureの開発時にC＃に焦点を当てたと言っても過言ではありません）。 また、Windows Azure SDKには、開発者のコ​​ンピューターで実行されるWindows Azure環境のバージョンが含まれています。 これには、ストレージ、Windows Azureエージェント、およびクラウドで実行されているアプリケーションで利用可能なその他すべてが含まれています。 開発者は、クラウドのローカルな外観でアプリケーションを作成およびデバッグし、準備ができたらそれを実際のクラウドに配布できます。 同時に、クラウド内のいくつかのものは完全に異なっています。 たとえば、デバッガをクラウド内のアプリケーションに接続することはできません。そのため、クラウドアプリケーションのデバッグは、主にエージェントを介したWindows Azureが管理するログを介して行われます。



Windows Azureは、開発者およびその他のサービスを提供します。 たとえば、Windows Azureアプリケーションは、Windows Azureエージェントを介して何らかの警告を含むメッセージを送信する場合があります。エージェントは、メール、インスタントメッセージ、または別の方法で指定された受信者に配信します。 必要に応じて、Windows Azure自体がアプリケーションのクラッシュを検出し、警告を送信できます。 プラットフォームは、プロセッサ時間、着信および発信トラフィック、ストレージなど、アプリケーションによるリソースの消費に関する詳細情報も提供します。

データアクセス

アプリケーションはさまざまな方法でデータを処理します。 必要なのは単純なblobだけである場合もあれば、より構造化された情報の格納方法が必要な場合もあります。 場合によっては、アプリケーションの異なる部分間でデータを交換するメカニズムのみが必要です。 図2に示すように、Windows Azureストレージはこれらの要件をすべて満たしています。 7。



図 7 Windows Azureでは、REST over HTTPを介してアクセスされるBLOB、テーブル、およびキューにデータを保存できます。



Windows Azureにデータを保存する最も簡単な方法-BLOBを使用します。 図7のように、単純な階層があります。ストレージアカウントには1つ以上のコンテナーがあり、各コンテナーに1つ以上のBLOBを格納できます。 ブロブは大きくすることができ（それぞれ最大50 GB）、ブロブの転送を容易にするために、それぞれをサブブロブに分割できます。 送信エラーが発生すると、最後に送信されたサブブロックから再送信が開始される場合があります。 BLOBには、JPEG写真が撮影された場所に関する情報や、MP3ファイルの曲作曲家情報などのメタデータを含めることができます。



一部のタイプのデータでは、blobが最も多くなりますが、多くの場合、それらは不十分に構造化されています。 アプリケーションが小さな構造単位のレベルでデータを操作できるように、Windows Azureストアはテーブルを提供します。 名前は類似していますが、名前をリレーショナルテーブルと混同しないでください。 実際、これらはテーブルと呼ばれますが、それらのデータはプロパティを持つエンティティの単純な階層として保存されます。 テーブルには特定のデータスキームがありませんが、代わりに、プロパティはInt、String、Bool、DateTimeなどのさまざまなタイプを持つことができます。 また、SQLを使用してデータを処理する代わりに、アプリケーションはLINQ構文を使用したクエリ言語を通じてデータにアクセスします。 1つのテーブルは非常に大きく、数百万のエンティティがテラバイトのデータを格納できます。WindowsAzureは、パフォーマンスを確保するために必要に応じて多数のサーバー間でテーブルを分割できます。



BLOBとテーブルの両方は、データを保存するように設計されています。 Windows Azureストレージにデータを保存する3番目の方法-キュー-は、わずかに異なる目的のために作成されました。 キューの主な役割は、Webロールとワーカーロールのインスタンスが通信できるようにすることです。 たとえば、ユーザーは、Webロールに実装されたWebページを介して、リソースを集中的に使用するタスクを実行する要求を送信します。 この要求を受信するWeb Roleインスタンスは、必要な操作を説明するメッセージをキューに書き込みます。 キュー内のメッセージを待機しているワーカーロールインスタンスは、新しいメッセージを読み取り、必要な作業を行います。 彼は、作業の結果を別のキューまたは他の方法で返すことができます。



保存方法（ブロブ、キュー、またはテーブル）に関係なく、Windows Azureのすべてのデータに対して3つのコピーが保存されます。 1つのコピーの損失は致命的ではないため、これにより転倒からの独立性が得られます。 また、システムは整合性も保証するため、書き込んだばかりのデータを読み取るアプリケーションは、期待どおりの結果を受け取ることができます。



Windows Azureストレージのデータは、Windows Azureアプリケーションと他の場所で実行されているアプリケーションの両方で利用できます。 どちらの場合でも、REST規則を使用してデータを識別し、データへのアクセスを提供することにより、3つのデータストレージ方法すべてに対して等しくアクセスできます。 すべてがURIと呼ばれ、通常のHTTP操作でアクセスできます。 .NETクライアントはADO.NETサービスまたはLINQを使用でき、たとえばJavaアプリケーションからは、Windows Azureデータに標準RESTを介してアクセスします。 たとえば、次のような形式のURIへのHTTP GETを介してblobを読み取ることができます。

  http：// <StorageAcount> .blob.core.windows.net / <Container> / <BlobName> 

これは、作成された各Vaultアカウントに割り当てられる識別子であり、このアカウントで作成されたBLOB、テーブル、およびキューを一意に識別します。 これらは、リクエストで参照されるコンテナとブロブの名前です。



同様に、特定のテーブルへのリクエストは、次の形式のURIへのHTTP GETリクエストで表されます。

  http：// <StorageAcount> .table.core.windows.net / <TableName>？$ filter = <Query> 

ここに、要求されたテーブルと、このテーブルに対して実行するクエリを示します。



URIに対するHTTP GETを介して、Windows Azureアプリケーションおよび外部アプリケーションでキューを使用することもできます。

  http：// <StorageAcount> .queue.core.windows.net / <QueueName> 

Windows Azureプラットフォーム上のコンピューティングリソースとストレージのコストは、個別に請求されます。 つまり、ローカルアプリケーションはWindows Azureストレージのみを使用でき、説明したようにRESTを介してデータにアクセスします。 しかし、Windows Azureストレージの主な目標は、Azureアプリケーションからのデータを操作することだと言っても過言ではありません。 また、データはAzureアプリケーションで直接利用できないため、それらを使用するAzureアプリケーションが実行されていなくても利用できます。



クラウドまたはオンプレミスにかかわらず、アプリケーションプラットフォームの主な目標は、アプリケーションとデータをサポートすることです。 Windows Azureは、両方の環境を提供します。 将来に目を向けると、ローカルのWindowsアプリケーションであるはずのアプリケーションが、この新しいクラウドプラットフォーム上に構築されることが期待できます。

.Netサービス

クラウドでアプリケーションを実行すること自体が既に有用ですが、クラウドで提供されるインフラストラクチャサービスも同様に有用です。 これらのサービスは、オンプレミスアプリケーションとクラウドアプリケーションの両方を使用でき、そうでなければ解決するのがはるかに難しい問題を解決します。 このセクションでは、この分野でのMicrosoftの提供物について説明します。.Netアクセス制御サービス、.Netサービスバス、および.Netワークフローサービス（総称して.Netサービスと呼ばれます）。

アクセス制御サービス

ID管理は、ほとんどの分散アプリケーションの基本的な部分です。 ユーザーのIDに基づいて、アプリケーションはこのユーザーに許可されるものを決定します。 アプリケーションは、セキュリティアサーションマークアップ言語（SAML）を使用して定義されたトークンを使用して、このデータを転送できます。 SAMLトークンにはクレームが含まれ、各クレームはユーザーに関する特定の情報を表します。 1つのステートメントにはユーザー名が含まれ、別のステートメントには「マネージャー」や「ジェネラルディレクター」などの役割が示され、3番目にはそのメールが含まれます。 トークンは、ソースを確認するために各トークンにデジタル署名するセキュリティトークンサービス（STS）と呼ばれるアプリケーションによって作成されます。



クライアント（Webブラウザなど）がユーザートークンを受信するとすぐに、それをアプリケーションに提供できます。 これで、アプリケーションはトークンからのアサーションを使用して、このユーザーに許可されているものを判断できます。 同時に、いくつかの問題がすぐに現れます。

• トークンにアプリケーションが必要とするステートメントが含まれていない場合はどうなりますか？ クレームベース認証を使用すると、各アプリケーションは、ユーザーが提供する必要があるクレームのセットを定義できます。 同時に、トークンを作成したSTSがアプリケーションが必要とするものを正確に追加したという事実ではありません。
• アプリケーションがトークンを発行したSTSを信頼しない場合はどうなりますか？ アプリケーションは、STSによって連続して発行されたすべてのトークンを受け入れることはできません。 代わりに、アプリケーションには通常、STSの信頼できる証明書のリストがあります。これにより、アプリケーションはトークンサブスクリプションを検証できます。 信頼できるSTSからのトークンのみがアプリケーションによって受け入れられます。

このプロセスに新しいSTSを追加すると、両方の問題を解決できます。 トークンに必要なステートメントが含まれていることを確認するために、この追加のSTSはステートメント変換を実行します。 STSには、初期ステートメントと最終ステートメントの関係を定義するルールがあり、これらのルールを使用して、アプリケーションが必要とするステートメントを正確に含むトークンを作成できます。 一般にIDフェデレーションと呼ばれる2番目の問題のソリューションでは、アプリケーションがこの新しいSTSを信頼する必要があります。 このSTSと元のトークンを発行したSTSの間に信頼関係を確立することも必要です。



追加のSTSを追加すると、クレームとIDフェデレーションを変換することができます。どちらも非常に便利です。 しかし、このSTSはどこで実行する必要がありますか？ 組織内で機能するSTSを使用できます。これは一部のベンダーが提供するサービスです。 クラウドでSTSを使用しないのはなぜですか？ これにより、あらゆる組織のユーザーやアプリケーションがアクセスできるようになります。 また、STSの管理とサポートをサービスプロバイダーに移行します。



これはまさにAccess Control Serviceが提供するものです。これはクラウドのSTSです。 このようなSTSがどのように使用されるかを想像するために、インターネット経由でアクセス可能なアプリケーションを提供するISVを考えてみましょう。ISVは、さまざまな企業のユーザーが使用できます。 すべての企業がユーザーにSAMLトークンを提供できる場合でも、アプリケーションが必要とするクレームのセットが正確に含まれることはほとんどありません。 図8は、アクセス制御サービスがこの問題をどのように解決するかを示しています。



図 8 Access Control Serviceは、ルールベースのクレーム変換とIDフェデレーションを提供します。



最初に、ユーザーアプリケーション（この例ではブラウザーですが、WCFクライアントなど）がアクセス制御サービスユーザートークンを送信します（手順1）。 サービスはトークンの署名をチェックし、トークンが信頼できるSTSによって発行されたことを確認します。 その後、サービスは、アプリケーションが必要とするステートメントを含む新しいSAMLトークンを作成して署名します。



この変換を行うために、アクセス制御サービスのSTSはアプリケーション所有者によって定義されたルールを使用します。 たとえば、会社のマネージャーとして働くすべてのユーザーに特定の権限を付与するアプリケーションを想像してください。 各会社はトークンにステートメントを含めることができますが、これはユーザーがマネージャーであることを示していますが、異なる会社からのステートメントは異なる場合があります。 1つの会社は文字列「Manager」、別の会社は「Supervisor」、3番目は一般的に整数として表される特別なコードを使用できます。 アプリケーションがこの多様性のすべてで機能するように、アプリケーション所有者は、これら3つのステートメントすべてを文字列「Decision Maker」を含むステートメントに変換するルールを定義できます。 その後のアプリケーションの寿命は、文の変換を伴う作業がすでに行われているため、はるかに簡単になります。



新しいトークンを作成した後、アクセス制御サービスは新しいトークンをクライアントに返し（ステップ3）、クライアントはそれをアプリケーションに渡します（ステップ4）。 アプリケーションはトークン署名をチェックして、アクセス制御サービスのSTSによって正確に発行されていることを確認します。 アクセス制御サービスのSTSはすべてのユーザー企業のSTSとの信頼を確立する必要がありますが、アプリケーション自体はアクセス制御サービスのSTSのみを信頼する必要があることに注意してください。 トークンの信頼性が確認されると、アプリケーションはトークンに含まれるステートメントを使用してユーザーの権利を判断します。



アクセス制御サービスを使用する別の方法は、その名前に由来します-アプリケーションは、サービスへのユーザーアクセス権を決定することについての心配を変えることができます。 たとえば、アプリケーションの特定の機能にアクセスするには、ユーザーが特定のステートメントを送信する必要があると想像してください。 アクセス制御サービスのアプリケーションルールは、承認が別の承認を提供するユーザー（たとえば、前述のマネージャー）にのみ与えられることを決定できます。 アプリケーションは、ユーザートークンを受信すると、このステートメントの可用性に応じて、アクセスを発行または拒否できます。アクセス制御サービスを使用して効果的に決定されました。 このようなスキームにより、管理者は1つの共通の場所でアクセス制御ルールを定義できます。また、このスキームは、異なるアプリケーション間でルールを分離するのにも役立ちます。



アクセス制御サービスとのすべての対話は、標準プロトコルWS-TrustおよびWS -Federationを介して行われます。 これにより、あらゆるプラットフォームのあらゆるアプリケーションでサービスを利用できるようになります。 ルールを決定するために、サービスはブラウザーを介したGUIとプログラムからアクセスするためのAPIの両方を提供します。



クレームベース認証は、分散アプリケーションの標準メカニズムになる道を開きます。 クレームを変換する機能によって補完されるクラウドでSTSを提供することにより、アクセス制御サービスはこの新しい認証メカニズムをさらに魅力的なものにします。

サービスバス

内部で動作し、インターネットを介して他のユーザーに会社へのアクセスを許可したいアプリケーションがあるとします。 一見すると、これは非常に単純な問題のようです。 アプリケーションの機能がWebサービス（RESTまたはSOAP）を介して利用可能であると仮定すると、これらのWebサービスを外の世界で利用できるようにするだけです。 実際にこれを行おうとすると、すぐにいくつかの問題が発生します。



まず、他社（またはアプリケーションの一部）のアプリケーションは、サービスに接続できるアクセスポイントをどのように見つけることができますか？ アプリケーションの検索に使用できるレジストリのようなものがあれば素晴らしいでしょう。 アプリケーションが見つかった後、他社のアプリケーションからのリクエストはどのようにアプリケーションに届きますか？ ネットワークアドレス変換（NAT）は一般的であるため、多くの場合、アプリケーションには固定外部IPアドレスがありません。 また、NATが使用されていない場合でも、この要求でファイアウォールをどのように通過できますか？ もちろん、アプリケーションの特定のポートを開くことができますが、ほとんどのネットワーク管理者はこれを非常に不満に思っています。



Service Busはこれらの問題を解決します-図9。



図 9 Service Busを使用すると、アプリケーションはアクセスポイントを登録でき、他のアプリケーションはそれらを検出して使用してアプリケーションサービスにアクセスできます。



まず、アプリケーションは1つ以上のアクセスポイントをService Busに登録します（ステップ1）。アクセスポイント自体が既にアクセスできるようになっています。 Service BusはルートURIを組織に割り当てます。その内部で、任意の名前階層を作成できます。 これにより、アクセスポイントに特定の検出可能なURIを割り当てることができます。 アプリケーションは、作成する各アクセスポイントのサービスバスへの接続を開く必要があります。 Service Busはこの接続を確立したままにして、2つの問題を解決します。 まず、NATは迷惑ではなくなりました。ServiceBusからのトラフィックは、開いている接続を介して常にアプリケーションに到達するからです。 第二に、接続は会社のネットワーク内から開始されたため、アプリケーションへの情報の流れに問題はありません。ファイアウォールはこのトラフィックをブロックしません。



別の会社（またはアプリケーションの別の部分）のアプリケーションがアプリケーションにアクセスする必要がある場合、Service Busレジストリにアクセスします（ステップ2）。 要求の場合、Atom Publishing Protocolが使用され、応答は、アプリケーションのアクセスポイントへのリンクを含むAtomPubドキュメントとして返されます。 このデータを受信すると、アプリケーションはこれらのアクセスポイントを介して利用可能なサービスにアクセスできます（ステップ3）。 各要求はService Busによって受信され、アプリケーションに渡され、アプリケーションはリターンパスに沿って応答します。 また、これは図には示されていませんが、サービスバスがアプリケーションとそのクライアントの間に直接接続を確立し、通信をより効率的にする可能性があります。



通信の簡素化とともに、Service Busはセキュリティを向上させることもできます。 顧客にはService Busに属するIPのみが表示されるため、組織のIPアドレスを開く必要はありません。 これにより、外部の世界にはそのIPが表示されないため、アプリケーションが事実上匿名になります。 Service Busは外部DMZとして機能し、攻撃者からの保護に役立つ「アドレス変換層」を提供します。 最後に、サービスバスはアクセス制御サービスで使用するために設計されました。 特に、サービスバスはSTSアクセス制御サービスからのみトークンを受け入れます。



通常、サービスバスを介してサービスへのアクセスを開くアプリケーションは、WCFを使用して実装されます。 クライアントは、WCFまたはJavaなどの他のテクノロジーを使用して作成でき、SOAPまたはHTTPを介して要求を送信できます。 アプリケーションとそのクライアントは、独自のセキュリティメカニズムを使用して、攻撃者およびService Bus自体から通信を保護できます。



外の世界からアプリケーションへのアクセスを開くことは、見かけほど簡単ではありません。 Service Busの目標は、この便利な動作の実装を可能な限りシンプルかつ明白にすることです。

ワークフローサービス

Windows Workflow Foundationは、ワークフローアプリケーションを作成するためのコアテクノロジーです。 ワークフローを適用するための古典的なシナリオの1つは、エンタープライズアプリケーションの統合でよくあることですが、時間のかかるプロセスを制御することです。 より一般的には、WFアプリケーションは、多くの種類の作業を調整するのに適した選択肢です。 特に、複数の企業間で調整された作業が発生する場合、クラウド内のロジックを監視することは非常に優れたソリューションとなります。



ワークフローサービスは、実際にそのような機会を提供します。 WF 3.5に基づくアプリケーションのホストプロセスを提供することにより、開発者はクラウドで実行するワークフローを作成できます。 外観-図 10



図 10ワークフローサービスでは、HTTPまたはService Busを介して通信できるWFアプリケーションを作成できます



各WFワークフローは、多数のアクティビティを使用して実装されます。図では、赤で強調表示されています。 各アクティビティは、メッセージの送信、受信、条件式の実装、ループの制御などの特定のアクションを実行します。 WFは、Base Activity Library（BAL）と呼ばれるアクティビティの標準セットを提供し、Workflow ServiceはアプリケーションがBALのサブセットを使用できるようにします。 このサービスは、独自のアクティビティのセットも提供します。たとえば、図で示すように、サービスで実行されるアプリケーションは、HTTPまたはService Busを介して他のアプリケーションと対話できます。 10、つまり、ワークフローサービスには、両方を実装するための組み込みアクティビティが含まれています。ワークフローサービスは、XMLメッセージを操作するためのアクティビティも提供します。これは、アプリケーション統合を整理する際に頻繁に必要になる要件です。



ただし、クラウドでの実行にはいくつかの制限があります。たとえば、ワークフローサービスで実行されるWFベースのアプリケーションは、一貫性のあるワークフローモデルのみを使用できます。また、任意のコードの実行は許可されていないため、BALのコードアクティビティもユーザーアクティビティも使用できません。



開発者は、ワークフローサービス用のアプリケーションを作成するために、Visual Studioの標準ワークフローデザイナーを使用できます。アプリケーションが作成されると、ブラウザを介してアクセス可能なポータルを介して、または提供されたAPIを介してプログラムでクラウドに公開できます。アプリケーションの実行は、ポータルまたは提供されたAPIを介して制御することもできます。また、Service Busと同様に、Workflow Serviceと対話するアプリケーションは、最初に唯一の信頼できるSTSであるAccess Control Serviceからトークンを受信する必要があります。



WFアプリケーションは、問題を解決する方法ではありません。ただし、適切なタイプの問題を解決する必要がある場合、ワークフローを使用すると、開発者の生活がはるかに簡単になります。クラウドでWFアプリケーションをホストするための管理可能でスケーラブルな方法を提供することにより、Workflow Serviceはこの便利なテクノロジーをより手頃な価格にします。

SQLサービス

SQL Serviceは、クラウドテクノロジーグループとなるものの一般名です。それらはすべて、データの操作、つまりストレージ、分析、データのレポートなどに焦点を当てています。これらの基本的なデータベース機能は、おそらく最も基本的なものであり、SQL Data Servicesと呼ばれるファミリーの最初のメンバーです。



クラウド内のデータベースは多くの理由で魅力的です。一部の組織では、信頼性、バックアップ、およびその他のサポート機能に関する懸念をサービスプロバイダーに移行することは非常に便利です。クラウド内のデータは、モバイルデバイスを含め、どこでも実行されるアプリケーションでも簡単に利用できます。そして、クラウドでのスケーリングはプロバイダーの満足のいくようにはるかに経済的に実装されるため、最終的には組織にとっては、クラウドにデータを保存する方が安価です。 SQL Data Servicesの目標は、これらすべての利点を提供することです。



同時に、インターネットスケーラビリティを備えた信頼性の高い高性能データベースの実装は、決して簡単なことではありません。いくつかの妥協が必要です。上記で説明したように、たとえば、SQL Data Servicesは標準のリレーショナルデータベースを提供せず、通常のSQLクエリでは機能しません。代わりに、データは図11のような構造を使用して編成されます。



図11 SQL Data Servicesデータセンターは機関に分割され、各機関にはコンテナが含まれ、各コンテナにはプロパティを含むエンティティが含まれています。



SQL Data Servicesの情報は、さまざまなデータセンターに保存されます。図11のように、各センターには一定数の当局が含まれています。権限の分離は地理的な場所ごとに行われ、それぞれが特定のマイクロソフトデータセンターに格納され、一意のDNS名を持ちます。機関にはコンテナが含まれ、各コンテナはデータセンター内で複製されます。コンテナは、データの負荷と可用性のバランスを取るために使用されます。エラーが発生した場合、SQL Data Servicesはコンテナの別のレプリカの使用を自動的に開始します。各リクエストは1つの特定のコンテナに対して実行されます-機関全体からのデータリクエストは許可されていません。各コンテナには多くのエンティティが格納されており、それらのエンティティにはプロパティが含まれています。各プロパティには、そのタイプの名前、タイプ、および値があります。SQL Data Servicesがサポートするタイプには、String、DateTime、Base64Binary、Boolean、およびDecimalが含まれます。アプリケーションは、MIMEタイプのBLOBを保存することもできます。



このデータにアクセスするために、アプリケーションにはいくつかのオプションがあります。その1つは、SOAPまたはRESTを介して送信されるC＃のLINQと構文が類似したクエリ言語の使用です。もう1つのオプションは、RESTなどのデータにアクセスする代替方法であるADO.NET Data Servicesを使用することです。どちらの場合も、アプリケーションは== 、! =、>、<、AND、OR、またはNOTなどの演算子を使用してコンテナにリクエストを作成します。クエリは、ORDER BYやJOINなど、SQLに似た一部のステートメントでも実行できます。



ただし、リクエストの場合、受信または更新するオブジェクトはエンティティであり、プロパティではありません。クエリは、たとえば、含まれるすべてのプロパティを含む、いくつかのエンティティを返します。同様に、エンティティの1つのプロパティのみを変更することはできません。エンティティ全体を置き換える必要があります。また、エンティティには事前定義されたデータスキーマがないため、1つのエンティティのプロパティに異なるタイプを指定できます。1つのコンテナ内のエンティティは互いに異なる場合があり、各エンティティには異なるプロパティセットが含まれます。



SQL Data Serviesのデータは、Windows Azureストレージサービスに非常によく似たURIで名前が付けられます。特定のエンティティを識別するURIの一般的な形式は次のようなものです。

 http：// <authority> .data.database.windows.net / v1 / <Container> / <Entity> 

SQL Data Servicesはクライアントで.Netを必要としないことを再度強調する必要はありません。含まれるデータには、REST（つまり、通常のHTTP）を介して、またはSOAPを介して任意のプラットフォーム上の任意のアプリケーションにアクセスできます。データアクセスアプリケーションは、実行しているプラ​​ットフォームに関係なく、特定のSQL Data Servicesユーザー名とパスワード、またはAccess Control Service STSによって作成されたトークンでユーザーを識別する必要があります。



マイクロソフトは、SQL Data Servicesをよりリレーショナルな技術に開発する計画を発表しました。Windows Azureストレージとは異なり、SQL Data ServiceストレージはSQL Server上に実装されていることを思い出すと、この進化は自然になります。提供されるモデルに関係なく、テクノロジーの目標は変わりません。あらゆるタイプのアプリケーションにスケーラブルで、信頼性があり、安価なクラウドデータベースを提供します。新しいクラウドベースのデータサービスを含むSQL Data Servicesの拡張により、すべてがこのファミリーの最初のメンバーに依存することが期待できます。

続く