アプリケーション スタックおよびサーバーのアーキテクチャ

アプリケーション スタックは、プラットフォーム モデルとアプリケーション固有のモデルに分割されます。 プラットフォーム モデルは、アプリケーション プラットフォーム、アプリケーション基準、そして Test Essentials です。 アプリケーション固有のモデルは多数存在します。 いくつかの例として、アプリケーション スイート、元帳、小売、そしてケース管理があります。

概要

アプリケーション スタックとサーバー アーキテクチャは、次の 3 本の主要な柱に対応します。

• 新しいクライアント
• クラウドの準備
• 新しい開発スタック

アプリケーション スタックはいくつかのモデルに分けられます: アプリケーション プラットフォーム、アプリケーション基準、Test Essentials、そしてアプリケーション スイート。 この分離により、Fleet Management サンプル アプリケーションの開発と同様に、基本基盤モデルでの新しいアプリケーション開発が可能になります。 サーバーのアーキテクチャ内の変更に関する次の重要な点に注意してください。

• サーバー上のサービス エンドポイントは、すべてのフォームとコントロールのメタデータとデータをブラウザー ベースのクライアントに返す責任があります。 サーバーとのリモート プロシージャ コール (RPC) ベースの通信はなくなりました。 フォーム オブジェクトは引き続きサーバー上で実行され、レンダリングは、サーバーとクライアント側 (ブラウザー) の投資を通じてブラウザーやその他のクライアント用に最適化されています。
• アプリケーション コード ベースを含むサーバーをインターネット インフォメーション サービス (IIS) Web アプリケーションに展開します。 クラウドでは、Microsoft Azure サービスとしてのインフラストラクチャ (IaaS) 仮想マシン (VM) にデプロイします。
• これは Azure でホストされており、インターネット経由でアクセスできます。 ユーザーは、クライアントと資格情報の組み合わせを使用してアクセスできます。 推奨されるプライマリ ID プロバイダーは OrgID で、ID のストアは Microsoft Entra ID です。 セキュリティ サブシステムは、ユーザーとロールに対して同じ AuthZ セマンティクスを使用します。
• クラウドへのアクセスには、アクティブ クライアントとパッシブ クライアントの 2 種類のクライアントを検討する必要があります。

  • アクティブなクライアントは、サーバーからの応答に基づいて、アクションをプログラムで開始できます。 アクティブなクライアントは認証用の HTTP リダイレクトに依存しません。 スマート クライアントまたはリッチ クライアントは、アクティブなクライアントの例です。

  • パッシブ クライアントは、サーバーからの応答に基づいて、アクションをプログラムで開始できません。 パッシブなクライアントは認証用の HTTP リダイレクトに依存します。 Web ブラウザーは、パッシブ クライアントの例です。

    現在、Access Control Service (ACS) は非対話型認証のためのメカニズムをサポートしていません。 したがって、アクティブなクライアントが ACS を使用して認証を試みる場合でも、パッシブ クライアント認証を使用する必要があり、パッシブ クライアント認証では、ブラウザーのダイアログ ボックスに、ユーザーに資格情報の入力を求めるプロンプトが表示されます。

• 完全に改訂されたメタデータ サブシステムには、新しいコンパイラおよび Microsoft Visual Studio ベース開発モデルが組み込まれています。 モデル ストアは、モデルによって編成された一連のフォルダーと XML コンポーネントとして表されます。 XML ファイルは、テーブル、フォーム、クラスなどのモデル要素を表し、メタデータとソース コードの両方が含まれています。

次の図は、アプリケーション スタックを個別のモデルに分割する方法を示しています。 また、主要コンポーネントがサーバーでどのようにスタックされているかも示します。

財務と運用アプリケーションは、エントリ ポイントのセキュリティ モデルを使用します。 フォームへのナビゲーションに使用するメニュー項目に読み取り権限しかない場合、フォームは読み取り専用アクセスを提供します。 ただし、作成アクセス許可、削除アクセス許可、または更新アクセス許可を提供する別のメニュー項目を使用して、同じフォームに移動すると、フォームに対する書き込み操作が許可されます。 開発者は、特定のエントリ ポイントからフォームの動作を指定できるため、この動作は開発の経験を簡素化します。

クラウド アーキテクチャ

クラウド アーキテクチャには、ソフトウェアの展開とプロビジョニング、運用の監視とレポート、およびシームレスなアプリケーション ライフサイクル管理を自動化するサービスが含まれます。 クラウド アーキテクチャは、3 つの主な概念領域で構成されています。

• ライフサイクル サービス (LCS) – LCS は、ライフサイクル関連のさまざまな機能を可能にするマルチテナント共有サービスです。 このリリースに固有の機能には、ソフトウェア開発、顧客プロビジョニング、サービス レベル アグリーメント (SLA) の監視、およびレポート機能が含まれます。
• 財務と運用 – LCS を介して AZURE サブスクリプションに VM インスタンスをデプロイします。 デモ、開発/テスト、高可用性の運用トポロジなど、さまざまなトポロジが利用できます。
• Microsoft サービスを共有 – 財務と運用アプリケーションは様々な Microsoft のサービスを使用して、顧客がシングル サインインや、財務と運用アプリケーション、Microsoft 365 および他のオンライン サービス間での定期管理および Microsoft との請求関係を管理できる「One Microsoft」ソリューションを有効にします。

このアーキテクチャでは、Microsoft Azure Storage、ネットワーク、監視、SQL Azure など、Azure プラットフォームの多くの機能を使用しています。 共有サービスが運用され、参加者の環境のアプリケーション ライフサイクルが管理および調整されます。 Azure の機能と LCS があいまって、堅牢なクラウド サービスを提供します。

開発環境

開発環境のアーキテクチャは、クラウド インスタンスのアーキテクチャに似ています。 また、Visual Studio 開発ツールとその他のコンポーネントで構成されるソフトウェア開発キット (SDK) も含まれます。 Team Foundation Server または Visual Studio Online を介したソース管理により、複数開発者のシナリオが可能になります。このシナリオでは、各開発者が別個の開発環境を使用できます。 開発環境でデプロイ パッケージをコンパイルして生成し、LCS を使用してクラウド インスタンスにデプロイできます。 次の図は、主要なコンポーネントが開発環境でどのようにやり取りするかを示しています。