• 戻る（アーキテクチャ設計）
  • アプリケーション・アーキテクチャ
  • プラットフォーム・アーキテクチャ

• 強み
  • UI テクノロジとしてWindows FormsやWPFなどのリッチ・クライアントを採用するため、
    下記の非機能要件を満たす必要がある場合等は有用な選択肢となる。
    • エントリー系の業務等に要求される操作性や性能を実現できる
    • 複雑な業務の、複雑な画面遷移や UI 制御を比較的容易に実現できる。
  • UI 制御はクライアント側ハードウェア・リソースをフル活用するので、
    • サーバ側ハードウェア・リソースへの負荷の心配が少ない。
    • クライアント側のデバイスなどを有効に活用できる。
  • セキュリティ
    • デフォルトでは、サンドボックス化などの、クライアント側リソースのアクセス制限など、
      セキュリティを考慮した機構は持っていないため、関連する制約について意識する必要が無い。
• 弱み
  • プラットフォーム依存の UI テクノロジ。
  • クライアント側の CPU・メモリ等、マシン性能を必要とする。
  • セキュリティ
    • デフォルトでは、サンドボックス化などの、クライアント側リソースのアクセス制限など、
      セキュリティを考慮した機構は持っていないため、個別対応が必要（クライアントへのデータ保存など）。
  • 配布・設定の手間
    クライアント・プログラム、ランタイム、データ・プロバイダの
    • 配布・設定の手間がかかる。
    • 更新があった場合も、配布・設定の手間がかかる。
    • 詳しくは、こちら「プログラムの配付技術」を参照。

補足（同じ「サンドボックスが無い」が強みにも弱みにも挙がっている）: これは矛盾ではなく、
「制約が無い」ことの表と裏を書き分けたものである。

観点	評価
開発者から見ると	ローカル資源に自由にアクセスでき、制約を意識せずに済む（強み）
運用・セキュリティから見ると	保護機構が無いのですべて自前で守る必要がある（弱み）

なお、この「デフォルトではサンドボックスが無い」という記述は
.NET Framework の CAS（コード アクセス セキュリティ）を
使わない前提での話である。
CAS は複雑さの割に効果が乏しく、
.NET Framework 4.0 で非推奨、.NET Core / .NET 5 以降では完全に廃止された。
現在、クライアント側の保護は OS・コンテナ・
アプリ仮想化（MSIX 等）の層で行うのが前提である。

• 強み
  • クライアント端末 ＋ DB サーバと言う簡単な構成で構築可能。
    （シングル・ポイントが少なく、冗長化すべきサーバ台数も少ない）
  • UAP はクライアント側ハードウェア・リソースをフル活用するので、
    • 物理 3 層 C/S と比べるとサーバ側のハードウェア・リソースへの負荷の心配が少ない。
    • クライアント側のデバイスなどを有効に活用できる。
• 弱み
  • クライアント・プログラム、ランタイム、データ・プロバイダまでの配付・設定が必要。
  • セキュリティ
    • （認証方式によるが基本的に）
      DB に直接アクセス可能のためセキュリティに問題がある。
  • ネットワーク境界がクライアント UP ⇔ DB 間になるので、ココの
    回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
    • 一般的にイントラ内部でのみ利用可能
    • DB－AP 間のラウンド・トリップ高
    • DBMS トランザクションを使用する
  • .NET 以外では採用されないアーキテクチャ
    （Delphi、PowerBuilder などを除いて）

補足（物理 2 層の本質的な問題は「DB 資格情報がクライアントにある」）: 「DB に直接アクセス可能」が
問題である理由は、突き詰めると
接続文字列（＝ DB の資格情報）がクライアント端末に置かれるためである。
難読化しても、メモリやネットワークからは取り出せる
（逆コンパイル・難読化を参照）。

したがって物理 2 層では、

• DB のアカウントとオブジェクト権限そのものが
  アプリの権限モデルになる（Windows 統合認証＋ロール、
  ストアド プロシージャ経由のみ許可、等）。
• 業務ロジックによるチェックは回避できる前提で設計する
  （クライアントを改造すれば任意の SQL を投げられる）。

現在も残る主用途は
閉じたイントラネットの管理ツール・分析ツールであり、
業務システムの新規構築で選ぶことはほぼ無い。

• 強み
  • データ・プロバイダの配付・設定は不要。
  • UI 層の処理はクライアント側ハードウェア・リソースをフル活用するので、
    • Web アプリケーションと比べると AP サーバ側のハードウェア・リソースへの負荷が少ない。
    • クライアント側のデバイスなどを有効に活用できる。
  • セキュリティ
    • DB に直接アクセス不可能のためセキュリティに問題が少ない（サーバ信頼モデル）。
      イントラネット環境でベースクライアント・セキュリティモデルを採用する場合はこの限りでは無い。
• 弱み
  • クライアント・プログラム、ランタイムの配布が必要。
  • ネットワーク境界がクライアント UP ⇔ AP ⇔ DB 間になるので、ココの
    回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
    • 特に、クライアント UP ⇔ AP 間がインターネット等の場合は、
      ネットワーク・サービスの SLA に左右されるため注意が必要。
  • 構成が複雑になるため、シングル・ポイントや性能など、
    非機能要件に関する検討項目が増えてくる。
• UP の造りの範囲だけで言えば 2 層・3 層 C/S の違いは
  大きく無いが、以下については考慮が必要になる。
  • 生産性を良くするためには、
    クライアント－サーバ間の通信部品の整備が必要になる。
  • 排他方式が DBMS トランザクションを用いた悲観排他方式では無く、
    タイムスタンプを用いた楽観排他方式となる。
    （悲観排他の実現には、ロック管理テーブルなどを用意する必要がある）

移行メモ（正誤）: 原典の「タイムスタンプを持ちいた」は
「用いた」の誤りであるため修正した（Web アプリケーションの節も同様）。

補足（この「排他方式が変わる」が層を跨ぐ最大の設計上の影響）: 物理 2 層では
画面を開いている間 DB 接続とトランザクションを保持できるため、
SELECT ... FOR UPDATE 相当の悲観排他が自然に書けた。

3 層以降（3 層 C/S・Web）では、

• サーバ側はリクエスト単位でステートレス、
• DB 接続はプールから借りて即返す

という構造になるため、
ユーザの思考時間を跨いでロックを持ち続けることができない
（持てば接続とロックが枯渇する）。
よって、更新時にタイムスタンプ列や行バージョンを突き合わせ、
変わっていたら弾く楽観排他が必然的な選択になる。

SQL Server では rowversion（旧 timestamp）型が
このために用意されている
（DBMSのロックと分離レベル）。
なお、timestamp は時刻とは無関係な単なる更新順序の連番であり、
名前が紛らわしいため現在は rowversion の使用が推奨されている。

シン・クライアント（HTML）

• 強み

  • プラットフォーム非依存の UI テクノロジ。
    ただし、クロス・ブラウザ対応が必要となり、実現が困難なケースもある。
  • クライアント・アプリケーション配布の問題がない。
  • クライアント側の CPU・メモリ等、マシン性能を必要としない。
    • HTML はクライアントにダウンロードされた後に解析、レンダリングされるので、
      場合によってはクライアント側 CPU リソースを大量に消費することもある。
  • セキュリティ

    • セキュリティを考慮した機構は持っているため個別対応が不要。
      （ActiveX や Java Applet などを使用しない限りは）

    • DB に直接アクセス不可能のためセキュリティに問題が少ない（サーバ信頼モデル）。

      イントラネット環境で
      「ベースクライアント・セキュリティモデル」
      を採用する場合はこの限りでは無い。

• 弱み

  • 操作性、複雑な画面遷移や UI 制御、エントリー性能に難がある。
  • JavaScript を使用して複雑な画面遷移や UI 制御を行った場合、
    生産性が落ちたり、マシンパワーを必要とするようになったりする。
  • UI 層
    • HTML の生成処理の分、物理 3 層 C/S より AP サーバ負荷が多くなる。
    • HTML を送受信するため、物理 3 層 C/S よりネットワーク・トラフィックが増える。
  • DBMS トランザクションを用いた悲観排他方式では無く、
    タイムスタンプを用いた楽観排他方式を採用する必要がある。
    （悲観排他の実現には、ロック管理テーブルなどを用意する必要がある）

• Microsoft 系技術では、

  • WWW サーバ（IIS）と
  • AP サーバ（ASP.NET）を

  同じ筐体から分離できないという問題があるので、
  ビジネスロジックを DMZ からイントラに引き込むためには、

  • プロキシサーバを経由させたり、
  • Web3 層方式を採用したり

  する事で工夫が必要になる。

移行メモ（重複）: 原典の「弱み」には
「UI 層はサーバ側で HTML 生成するため、物理 3 層 C/S よりと比べると
AP サーバ負荷が多い。」という、
直前の項目とほぼ同内容（かつ「よりと比べると」と重複した）の
記述が続いていたため、統合した。

補足（最新化：この評価は「サーバで HTML を作る」前提のもの）: 本節の弱みは
サーバ側で HTML を生成する古典的な Web アプリを前提としている。
現在主流の構成では、次のように前提が変わっている。

構成	HTML 生成	通信量	サーバ負荷
古典的 Web（Web Forms / MVC のビュー）	サーバ	画面全体の HTML	高
SPA + Web API	クライアント（JS）	JSON のみ	低（API のみ）
Blazor Server	サーバ（差分を SignalR で配信）	差分	高＋接続維持
Blazor WebAssembly	クライアント（WASM）	JSON のみ	低

つまり「HTML 生成の分だけサーバが重い」という指摘は
SPA / WASM 系では当てはまらない一方、
その分クライアント側の CPU・メモリを使うようになり、
本節が C/S の弱みとして挙げた項目に近づいている。
アーキテクチャの選択はどちらが得かの配分の問題に収束した、
と見るのが実態に近い。

また、「操作性・エントリー性能に難がある」という評価も、
SPA と現代のブラウザでは大きく改善している。
一方で「クロス・ブラウザ対応が必要」という指摘は
依然として有効である
（IE、WWWブラウザのいろいろ）。

• 一般的な Web アプリケーションのアーキテクチャ。
• 注意点
  • ネットワーク境界が WWW ブラウザ ⇔ Web/AP ⇔ DB 間になるので、ココの
    回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
    • WWW ブラウザ ⇔ Web/AP 間がインターネット等の場合は、
      ネットワーク・サービスの SLA に左右されるため注意が必要。

• Microsoft 系技術では、IIS と ASP.NET を同じ筐体から分離できないため、
  ビジネス・ロジックを非武装セグメントからイントラ内に引き込む際などに利用される。
• 一般的な Web アプリケーションから Web サービスを呼び出す際もこの方式と同じになる。
• 注意点
  • ネットワーク境界が WWW ブラウザ ⇔ Web/AP1 ⇔ Web/AP2 ⇔ DB 間になるので、
    ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
    • WWW ブラウザ ⇔ Web/AP1 ⇔ Web/AP2 間がインターネット等の場合は、
      ネットワーク・サービスの SLA に左右されるため注意が必要。
• 参考：Web/APの分離

通常、物理 2 層 C/S を 3 層化するために用いられる。
デスクトップ仮想化のサーバサイド型に分類される。

• 強み
  • プログラム等の改修（ほぼ）なしで、物理 2 層 C/S を 3 層化可能。
  • クライアント・アプリケーション配布の問題がない。
  • 操作性、複雑な画面遷移や UI 制御、エントリー性能にも問題が無い。
  • プリンタ・USB など、クライアント側のデバイスのリダイレクトが可能。
• 弱み
  • 画面を転送するので描画が多いと通信データ量、ラウンド・トリップが多くなる。
  • ネットワーク境界がユーザ ⇔ クライアント UP ⇔ DB 間になるので、ココの
    回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
• トレードオフ
  以下の、2 つのトレードオフがある。
  • ユーザ ⇔ クライアント UP 間の画面を転送するネットワーク・トラフィック
  • クライアント UP ⇔ DB サーバ間のデータアクセスのネットワーク・トラフィック

補足（このトレードオフの読み方）: ターミナル・サービスの本質は
「境界をどこに置くか」を物理的にずらすことにある。

【物理2層C/S】
  ユーザ端末（UP＋DBアクセス） ══ 細い回線 ══ DBサーバ
                                ↑ ラウンドトリップが多いと致命的

【ターミナル・サービス化】
  ユーザ端末（画面のみ） ══ 細い回線 ══ サーバ（UP） ═ 太い回線 ═ DBサーバ
                         ↑ 画面転送量が支配的に変わる

つまり、細い回線に載るものが「DB アクセス」から「画面」に変わる。
したがって効果が出るのは、

• DB アクセスのラウンド・トリップが多く、
• 画面の描画更新が少ない（入力主体の業務画面）

という場合である。
逆に、地図・帳票プレビュー・動画のように
描画量が多い画面では、かえって悪化する。

これは「アプリを直さずに 3 層化する」という
移行手段としての価値が主であり、
新規構築の選択肢ではない点にも注意したい。

• ターミナルサービス系への移行

• 概要
  • サーバをマルチ ユーザ化し、サーバで動作している
    アプリケーションソフトの画面を端末にリアルタイムに配信するシステム。
  • アプリケーションソフトの利用者は端末でソフトの操作が可能だが、
    端末ではソフトは動作しておらず、画面表示と入力の受付のみが行われる。
  • アプリケーションを仮想化する Citrix XenApp - Think IT
    http://thinkit.co.jp/article/1006/1
• 経緯
  • ターミナル・サービスは、もともとマルチ ユーザ機能を持っていなかった Windows を
    マルチ セッション環境下で利用できるようにした Citrix 製品の OEM 供給であった。
  • 以降、Windows にターミナル・サービスが標準搭載されたため、
    • セキュリティー、パフォーマンス、拡張性、安定性、柔軟性などを強化した、
      ターミナル・サービスに高い付加価値を提供する製品として販売されている。
    • 例えば RDP プロトコルより ICA プロトコルのほうが性能的に優れており、
      帯域やネットワーク品質の不足がある場合など、XenApp が導入されるケースがある。
  • バージョンと製品名の変遷
    • 3：MetaFrame Presentation Server
    • 4：Citrix Presentation Server
    • 5：Citrix XenApp
• 移行ツール
  • シトリックス、アプリ移行支援ツール「AppDNA」を提供
    http://www.atmarkit.co.jp/news/201209/25/citrix.html
  • Introducing the Application Compatibility Toolkit for XenApp
    http://blogs.citrix.com/2008/11/04/introducing-the-application-compatibility-toolkit-for-xenapp/

補足（最新化：製品名の変遷の続き）: 本文の変遷表の続きは次のとおり。

時期	名称
〜2015	Citrix XenApp
2018〜	Citrix Virtual Apps（XenDesktop と統合され Virtual Apps and Desktops）
2022〜	Citrix DaaS（クラウド サービスとして提供）

Microsoft 側も、リモート デスクトップ サービス（RDS）に加え
Azure Virtual Desktop（旧 Windows Virtual Desktop）と
Windows 365（Cloud PC）を提供しており、
ターミナル・サービス系の選択肢はクラウド側に移っている
（プラットフォーム・アーキテクチャ）。

Java のリッチクライアント技術は弱いので、
Nexaweb、XPlatform を使用するケースが多い。

• UI サブシステム（GUI ツールキット）
  • AWT（Abstract Window Toolkit）
    • OS のウィンドウシステムに準じたデザインになる。
    • プラットフォーム固有のコードが開発者に透けて見えるため、
      異なるプラットフォーム間で移植性のあるアプリケーションを作成するには限界がある。
  • Swing
    • 100% Java であり、ネイティブコードは使っていない。
    • OS のウィンドウシステムは使用せず、独自描画される。
    • しかし、Swing 内部から低レベルな OS ルーチンを使用して描画している。
  • SWT（Standard Widget Toolkit）
    • AWT と Swing を代替するものとして開発された。
    • 100% Java であり、ネイティブコードは使っていない。
    • OS のウィンドウシステムは使用せず、独自描画される。
    • JNI 経由で OS ルーチンを使用して描画している。
    • SWT を使うプログラムは移植性があるが、
      ツールキット自体の実装は、各プラットフォーム固有
  • JavaFX
    FXML というマークアップ言語に対応した新しい UI サブシステム（GUI ツールキット）
• Java Applet
  Web ブラウザ上で動作する。
• Java アプリケーション
  デスクトップ上で動作する。
• Java Web Start
  ノータッチデプロイメント、ClickOnceが参考とした技術、
  自動ダウンロード、自動インストール、自動アップデートして、
  サンドボックス化された実行コンテキスト内で実行される。

移行メモ（体裁）: 原典は「AWT（Abstract Window Toolkit」「SWT（Standard Widget Toolkit」のように
閉じ括弧が欠落していたため補った。

補足（最新化）: Java 側の状況も大きく変わっている。

技術	現状
Java Applet	Java 9 で非推奨、Java 11 で削除。主要ブラウザもプラグインを廃止
Java Web Start	Java 11 で削除（OpenWebStart 等の代替あり）
JavaFX	Java 11 で JDK から分離され、OpenJFX として別配布
AWT / Swing	JDK に残存。保守用途では現役

ブラウザ プラグイン方式（Applet、Silverlight、Flash）が
軒並み廃止されたという点は、
後述の RIA の項とあわせて理解しておきたい。

• XMAP

• Web システムの強みを残し、
  C/S 型システムの以下の弱みを解決したテクノロジ
  • プラットフォーム依存
  • 配布・設定の手間
  • クライアント側へデータ保管が可能であるなど、
    セキュリティを考慮した機構は持っていないため個別対応が必要。
• Flash・Flex、Silverlight
  Flash は、アニメーションなどを含む柔軟な UI 作成に使用されるが、
  Flex、Silverlight はより業務アプリケーション開発に適した
  UI コンポーネントベースのプログラミング・モデルを採用している。
• Ajax、HTML5
  View の構成をクライアントが担っている Web アプリケーション。

Flex 2.0 でリッチな Web アプリを作ろう
　- 第1回　Flex はエンジニア向けの Flash：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20061012/250481/

HTML5 - Wikipedia
http://ja.wikipedia.org/wiki/HTML5

HTML5 は、プロプライエタリなプラグインとして提供されているリッチインターネットアプリケーションのプラットフォーム（JavaFX、Adobe Flash、Microsoft Silverlight 等）を置き換えることを標榜しており、ウェブアプリケーションのプラットフォームとしての機能やマルチメディア要素が実装されている。そのため HTML5 が普及すれば Adobe Flash などのプラグインは不要になるという意見がある。

リッチクライアント技術ではあるが、

• イベント・ドリブン
• UI コンポーネントベース

のプログラミング・モデルを直接サポートしておらず、
現段階では、Flash・Flex、Silverlight のような
業務アプリケーション開発向けの技術では無い。

補足（最新化：この「意見」はそのとおりになった）: 引用中の
「HTML5 が普及すれば Adobe Flash などのプラグインは不要になる
という意見がある」は、その後事実となった。

技術	サポート終了
Silverlight	2021 年 10 月（IE 11 と同時に実質終了）
Adobe Flash Player	2020 年 12 月末で提供終了、2021 年 1 月にコンテンツ実行をブロック
Java Applet	前掲のとおり Java 11 で削除

また、「イベント・ドリブン／UI コンポーネントベースの
プログラミング・モデルを直接サポートしていない」という指摘も、
フレームワーク層で解決された。
React / Vue / Angular などの
コンポーネント指向フレームワークが標準的な選択肢となり、
.NET 系では Blazor が
C# でコンポーネント指向の Web UI を書ける手段を提供している。
本節の評価は、この間の経緯を示す記録として読むとよい。

Single Page Application (SPA) を使ってみよう MVC 4 新機能シリーズ
　- THE TRUTH IS OUT THERE - Site Home - MSDN Blogs
http://blogs.msdn.com/b/chack/archive/2012/02/28/single-page-application-spa-mvc-4.aspx

　JavaScript と ASP.NET Web API をベースとした
　クライアント サイド インタラクション中心の Web アプリケーション
　を構築するのに適したフレームワークとテンプレート

ターミナル・サービスを指す。

• IE、WWWブラウザのいろいろ
• ウェブブラウザの利用シェア - Wikipedia

• アプリケーション アーキテクチャ ガイド 2.0 (AAG 2.0)
  http://msdn.microsoft.com/ja-jp/architecture/gg998968.aspx
  • 旧版「.NET のアプリケーション アーキテクチャ : アプリケーションとサービスの設計」(AAfN)
    http://msdn.microsoft.com/ja-jp/library/ms954595.aspx\ ※注意: AAfN の全面改定版が AAG 2.0 である
• Windows フォームと Web フォーム間の選択
  http://msdn.microsoft.com/ja-jp/library/5t6z562c.aspx

補足（現在の後継）: AAG 2.0（2009 年）は既に提供が終了しており、
現在これに相当する位置付けの資料は
Azure Architecture Center である。

• Azure Well-Architected Framework
  （設計の原則：コスト・運用・性能・信頼性・セキュリティ）
• クラウド アプリケーション アーキテクチャ ガイド
  （アーキテクチャ スタイルと設計上の選択）
• 参照アーキテクチャ
  （具体的な構成例）

本ページが扱う C/S・Web・ターミナル サービスという分類が
物理配置による分類であるのに対し、
現在の分類は
n 層・Web-Queue-Worker・マイクロサービス・イベント ドリブンといった
処理構造による分類に移っている点が大きな違いである。

---

Tags: 移行, アーキテクチャ, .NET開発