アプリケーション スタックおよびサーバーのアーキテクチャ
アプリケーション スタックは、プラットフォーム モデルとアプリケーション固有のモデルに分割されます。 プラットフォーム モデルは、アプリケーション プラットフォーム、アプリケーション基準、そして Test Essentials です。 アプリケーション固有のモデルは多数存在します。 いくつかの例として、アプリケーション スイート、元帳、小売、そしてケース管理があります。
概要
アプリケーション スタックとサーバー アーキテクチャは、次の 3 本の主要な柱に対応します。
- 新しいクライアント
- クラウドの準備
- 新しい開発スタック
アプリケーション スタックはいくつかのモデルに分けられます: アプリケーション プラットフォーム、アプリケーション基準、Test Essentials、そしてアプリケーション スイート。 Fleet Management のサンプル アプリケーションが開発されたのと同様に、分離により、ベース基盤モデルの新しいアプリケーション開発が可能になります。 サーバーのアーキテクチャ内の変更に関する次の重要な点に注意してください。
サーバー上のサービス エンドポイントは、すべてのフォームとコントロールのメタデータとデータをブラウザー ベースのクライアントに返す責任があります。 サーバーとのリモート プロシージャ コール (RPC) ベースの通信はなくなりました。 フォーム オブジェクトは引き続きサーバー上で実行され、レンダリングはサーバーおよびクライアント側 (ブラウザー) の投資を通じてブラウザーおよびその他のクライアント用に最適化されています。
アプリケーション コード ベースを含むサーバーは、Internet Information Services (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 つの主な概念領域で構成されています。
- Lifecycle Services (LCS) – LCS は、広範なライフサイクル関連の機能を可能にするマルチ テナントの共有サービスです。 このリリースに固有の機能には、ソフトウェア開発、顧客プロビジョニング、サービス レベル アグリーメント (SLA) の監視、およびレポート機能が含まれます。
- 財務と運用 – VM インスタンスは、LCS によって Azure サブスクリプションに配置されます。 デモ、開発/テスト、高可用性の運用トポロジなど、さまざまなトポロジが利用できます。
- Microsoft サービスを共有 – 財務と運用アプリケーションは様々な Microsoft のサービスを使用して、顧客がシングル サインインや、財務と運用アプリケーション、Microsoft 365 および他のオンライン サービス間での定期管理および Microsoft との請求関係を管理できる「One Microsoft」ソリューションを有効にします。
Microsoft Azure ストレージ、ネットワーク、監視、SQL Azure など、Azure プラットフォームの多くの機能はいくつかの名前に使用されます。 共有サービスが工程に移り、参加者の環境のアプリケーション ライフサイクルが調整されます。 Azure の機能と LCS があいまって、堅牢なクラウド サービスを提供します。
開発環境
開発環境のアーキテクチャは、クラウド インスタンスのアーキテクチャに似ています。 また、Visual Studio 開発ツールとその他のコンポーネントで構成されるソフトウェア開発キット (SDK) も含まれます。 Team Foundation Server または Visual Studio Online を介したソース管理により、複数開発者のシナリオが可能になります。このシナリオでは、各開発者が別個の開発環境を使用できます。 配置パッケージは、開発環境でコンパイルおよび生成し、LCS を使用してクラウド インスタンスに展開できます。 次の図は、主要なコンポーネントが開発環境でどのようにやり取りするかを示しています。
