.NET開発基盤部会」によって運営されています。下記の非機能要件を満たす必要がある場合等は有用な選択肢となる。エントリー系の業務等に要求される操作性や性能を実現できる複雑な業務の、複雑な画面遷移やUI制御を比較的容易に実現できる。UI制御はクライアント側ハードウェア・リソースをフル活用するので、サーバ側ハードウェア・リソースへの負荷の心配が少ない。クライアント側のデバイスなどを有効に活用できる。セキュリティデフォルトでは、サンドボックス化などの、クライアント側リソースのアクセス制限など、セキュリティを考慮した機構は持っていないため、関連する制約について意識する必要が無い。弱みプラットフォーム依存のUIテクノロジ。クライアント側のCPU・メモリ等、マシン性能を必要とする。セキュリティデフォルトでは、サンドボックス化などの、クライアント側リソースのアクセス制限など、セキュリティを考慮した機構は持っていないため、個別対応が必要(クライアントへのデータ保存など)。配布・設定の手間クライアント・プログラム、ランタイム、データ・プロバイダの配布・設定の手間がかかる。更新があった場合も、配布・設定の手間がかかる。詳しくは、こちら「プログラムの配付技術」を参照。DBサーバと言う簡単な構成で構築可能。物理3層C/Sと比べるとサーバ側のハードウェア・リソースへの負荷の心配が少ない。クライアント側のデバイスなどを有効に活用できる。弱みクライアント・プログラム、ランタイム、データ・プロバイダまでの配付・設定が必要。セキュリティ(認証方式によるが基本的に)DBに直接アクセス可能のためセキュリティに問題がある。DB間になるので、ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。強みデータ・プロバイダの配付・設定は不要。UI層の処理はクライアント側ハードウェア・リソースをフル活用するので、Webアプリケーションと比べるとAPサーバ側のハードウェア・リソースへの負荷が少ない。クライアント側のデバイスなどを有効に活用できる。セキュリティDBに直接アクセス不可能のためセキュリティに問題が少ない(サーバ信頼モデル)。イントラネット環境でベースクライアント・セキュリティモデルを採用する場合はこの限りでは無い。弱みクライアント・プログラム、ランタイムの配布が必要。DB間になるので、ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。AP間がインターネット等の場合は、ネットワーク・サービスのSLAに左右されるため注意が必要。非機能要件に関する検討項目が増えてくる。UPの造りの範囲だけで言えば2層・3層C/Sの違いは大きく無いが、以下については考慮が必要になる。生産性を良くするためには、クライアント-サーバ間の通信部品の整備が必要になる。排他方式がDBMSトランザクションを用いた悲観排他方式では無く、タイムスタンプを持ちいた楽観排他方式となる。†シン・クライアント(HTML)強みプラットフォーム非依存のUIテクノロジ。クロス・ブラウザ対応が必要となり、実現が困難なケースもある。クライアント・アプリケーション配布の問題がない。クライアント側のCPU・メモリ等、マシン性能を必要としない。場合によってはクライアント側CPUリソースを大量に消費することもある。セキュリティセキュリティを考慮した機構は持っているため個別対応が不要。Appletなどを使用しない限りは)DBに直接アクセス不可能のためセキュリティに問題が少ない(サーバ信頼モデル)。イントラネット環境で「ベースクライアント・セキュリティモデル」を採用する場合はこの限りでは無い。弱み操作性、複雑な画面遷移やUI制御、エントリー性能に難がある。生産性が落ちたり、マシンパワーを必要とするようになったりする。UI層HTMLの生成処理の分、物理3層C/SよりAPサーバ負荷が多くなる。HTMLを送受信するため、物理3層C/Sよりネットワーク・トラフィックが増える。物理3層C/Sよりと比べるとAPサーバ負荷が多い。DBMSトランザクションを用いた悲観排他方式では無く、タイムスタンプを持ちいた楽観排他方式を採用する必要がある。Web3層方式を採用したりする事で工夫が必要になる。一般的なWebアプリケーションのアーキテクチャ。DB間になるので、ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。Web/AP間がインターネット等の場合は、ネットワーク・サービスのSLAに左右されるため注意が必要。†Microsoft系技術では、IISとASP.NETを同じ筐体から分離できないため、ビジネス・ロジックを非武装セグメントからイントラ内に引き込む際などに利用される。一般的なWebアプリケーションからWebサービスを呼び出す際もこの方式と同じになる。DB間になるので、ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。Web/AP2間がインターネット等の場合は、ネットワーク・サービスのSLAに左右されるため注意が必要。通常、物理2層C/Sを3層化するために用いられる。デスクトップ仮想化のサーバサイド型に分類される。強みプログラム等の改修(ほぼ)なしで、物理2層C/Sを3層化可能。クライアント・アプリケーション配布の問題がない。操作性、複雑な画面遷移やUI制御、エントリー性能にも問題が無い。プリンタ・USBなど、クライアント側のデバイスのリダイレクトが可能。弱み画面を転送するので描画が多いと通信データ量、ラウンド・トリップが多くなる。DB間になるので、ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。トレードオフ以下の、2つのトレードオフがある。ユーザし、サーバで動作しているアプリケーションソフトの画面を端末にリアルタイムに配信するシステム。端末ではソフトは動作しておらず、画面表示と入力の受付のみが行われる。セッション環境下で利用できるようにしたCitrix製品のOEM供給であった。強化した、ターミナル・サービスに高い付加価値を提供する製品として販売されている。帯域やネットワーク品質の不足がある場合など、XenApp?が導入されるケースがある。†Javaのリッチクライアント技術は弱いので、Nexaweb、XPlatformを使用するケースが多い。ToolkitOSのウィンドウシステムに準じたデザインになる。異なるプラットフォーム間で移植性のあるアプリケーションを作成するには限界がある。あり、ネイティブコードは使っていない。OSのウィンドウシステムは使用せず、独自描画される。Swing内部から低レベルなOSルーチンを使用して描画している。代替するものとして開発された。あり、ネイティブコードは使っていない。OSのウィンドウシステムは使用せず、独自描画される。JNI経由でOSルーチンを使用して描画している。AppletWebブラウザ上で動作する。Javaアプリケーションデスクトップ上で動作する。自動ダウンロード、自動インストール、自動アップデートして、サンドボックス化された実行コンテキスト内で実行される。配布・設定の手間クライアント側へデータ保管が可能であるなど、セキュリティを考慮した機構は持っていないため個別対応が必要。Flash・Flex、SilverlightFlashは、アニメーションなどを含む柔軟なUI作成に使用されるが、Flex、Silverlightはより業務アプリケーション開発に適したUIコンポーネントベースのプログラミング・モデルを採用している。Ajax、HTML5Viewの構成をクライアントが担っているWebアプリケーション。等)を置き換えることを標榜しており、ウェブアプリケーションのプラットフォームとしての機能やマルチメディア要素が実装されている。プラグインは不要になるという意見がある。現段階では、Flash・Flex、Silverlightのような業務アプリケーション開発向けの技術では無い。†ターミナル・サービスを指す。