Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
主要アーキテクチャ †
C/S型システム †
- UIテクノロジとしてWindows FormsやWPFなどのリッチ・クライアントを採用するため、
下記の非機能要件を満たす必要がある場合等は有用な選択肢となる。
- エントリー系の業務等に要求される操作性や性能を実現できる
- 複雑な業務の、複雑な画面遷移やUI制御を比較的容易に実現できる。
- UI制御はクライアント側ハードウェア・リソースをフル活用するので、
- サーバ側ハードウェア・リソースへの負荷の心配が少ない。
- クライアント側のデバイスなどを有効に活用できる。
- セキュリティ
- デフォルトでは、サンドボックス化などの、クライアント側リソースのアクセス制限など、
セキュリティを考慮した機構は持っていないため、関連する制約について意識する必要が無い。
- クライアント側のCPU・メモリ等、マシン性能を必要とする。
- セキュリティ
- デフォルトでは、サンドボックス化などの、クライアント側リソースのアクセス制限など、
セキュリティを考慮した機構は持っていないため、個別対応が必要（クライアントへのデータ保存など）。
- 配布・設定の手間
クライアント・プログラム、ランタイム、データ・プロバイダの
物理2層C/S †
- クライアント端末 ＋ DBサーバと言う簡単な構成で構築可能。
（シングル・ポイントが少なく、冗長化すべきサーバ台数も少ない）
- UAPはクライアント側ハードウェア・リソースをフル活用するので、
- 物理3層C/Sと比べるとサーバ側のハードウェア・リソースへの負荷の心配が少ない。
- クライアント側のデバイスなどを有効に活用できる。
- クライアント・プログラム、ランタイム、データ・プロバイダまでの配付・設定が必要。
- （認証方式によるが基本的に）
DBに直接アクセス可能のためセキュリティに問題がある。
- ネットワーク境界がクライアントUP ⇔ DB間になるので、ココの
回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
- 一般的にイントラ内部でのみ利用可能
- DB－AP間のラウンド・トリップ高
- DBMSトランザクションを使用する
- .NET以外では採用されないアーキテクチャ
（Delphi、PowerBuilder?などを除いて）
物理3層C/S †
- UI層の処理はクライアント側ハードウェア・リソースをフル活用するので、
- Webアプリケーションと比べるとAPサーバ側のハードウェア・リソースへの負荷が少ない。
- クライアント側のデバイスなどを有効に活用できる。
- DBに直接アクセス不可能のためセキュリティに問題が少ない（サーバ信頼モデル）。
イントラネット環境でベースクライアント・セキュリティモデルを採用する場合はこの限りでは無い。
- クライアント・プログラム、ランタイムの配布が必要。
- ネットワーク境界がクライアントUP ⇔ AP ⇔ DB間になるので、ココの
回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
- 特に、クライアントUP ⇔ AP間がインターネット等の場合は、
ネットワーク・サービスのSLAに左右されるため注意が必要。
- 構成が複雑になるため、シングル・ポイントや性能など、
非機能要件に関する検討項目が増えてくる。
- UPの造りの範囲だけで言えば2層・3層C/Sの違いは
大きく無いが、以下については考慮が必要になる。
- 生産性を良くするためには、
クライアント－サーバ間の通信部品の整備が必要になる。
- 排他方式がDBMSトランザクションを用いた悲観排他方式では無く、
タイムスタンプを持ちいた楽観排他方式となる。
（悲観排他の実現には、ロック管理テーブルなどを用意する必要がある）
Webアプリケーション †
- プラットフォーム非依存のUIテクノロジ。
ただし、クロス・ブラウザ対応が必要となり、実現が困難なケースもある。
- クライアント側のCPU・メモリ等、マシン性能を必要としない。
- HTMLはクライアントにダウンロードされた後に解析、レンダリングされるので、
場合によってはクライアント側CPUリソースを大量に消費することもある。
- セキュリティを考慮した機構は持っているため個別対応が不要。
（ActiveXやJava Appletなどを使用しない限りは）
- DBに直接アクセス不可能のためセキュリティに問題が少ない（サーバ信頼モデル）。
イントラネット環境で
「ベースクライアント・セキュリティモデル」
を採用する場合はこの限りでは無い。
- 操作性、複雑な画面遷移やUI制御、エントリー性能に難がある。
- JavaScriptを使用して複雑な画面遷移やUI制御を行った場合、
生産性が落ちたり、マシンパワーを必要とするようになったりする。
- の生成処理の分、物理3層C/SよりAPサーバ負荷が多くなる。
- を送受信するため、物理3層C/Sよりネットワーク・トラフィックが増える。
- UI層はサーバ側でHTML生成するため、
物理3層C/Sよりと比べるとAPサーバ負荷が多い。
- DBMSトランザクションを用いた悲観排他方式では無く、
タイムスタンプを持ちいた楽観排他方式を採用する必要がある。
（悲観排他の実現には、ロック管理テーブルなどを用意する必要がある）
- Microsoft系技術では、
● WWWサーバ（IIS）と
● APサーバ（ASP.NET）を
同じ筐体から分離できないという問題があるので、
ビジネスロジックをDMZからイントラに引き込むためには、
● プロキシサーバを経由させたり、
● Web3層方式を採用したり
する事で工夫が必要になる。
物理2層Web †
- ネットワーク境界がWWWブラウザ ⇔ Web/AP ⇔ DB間になるので、ココの
回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
- WWWブラウザ ⇔ Web/AP間がインターネット等の場合は、
ネットワーク・サービスのSLAに左右されるため注意が必要。
物理3層Web †
- Microsoft系技術では、IISとASP.NETを同じ筐体から分離できないため、
ビジネス・ロジックを非武装セグメントからイントラ内に引き込む際などに利用される。
- 一般的なWebアプリケーションからWebサービスを呼び出す際もこの方式と同じになる。
- ネットワーク境界がWWWブラウザ ⇔ Web/AP1 ⇔ Web/AP2 ⇔ DB間になるので、
ココの回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
- WWWブラウザ ⇔ Web/AP1 ⇔ Web/AP2間がインターネット等の場合は、
ネットワーク・サービスのSLAに左右されるため注意が必要。
ターミナル・サービス †
通常、物理2層C/Sを3層化するために用いられる。
デスクトップ仮想化のサーバサイド型に分類される。
- 強み
- プログラム等の改修（ほぼ）なしで、物理2層C/Sを3層化可能。
- クライアント・アプリケーション配布の問題がない。
- 操作性、複雑な画面遷移やUI制御、エントリー性能にも問題が無い。
- プリンタ・USBなど、クライアント側のデバイスのリダイレクトが可能。
- 弱み
- 画面を転送するので描画が多いと通信データ量、ラウンド・トリップが多くなる。
- ネットワーク境界がユーザ ⇔ クライアントUP ⇔ DB間になるので、ココの
回線品質に対する通信データ量、ラウンド・トリップが多いと性能的に問題になる。
- トレードオフ
以下の、２つのトレードオフがある。
- ユーザ ⇔ クライアントUP間の画面を転送するネットワーク・トラフィック
- クライアントUP ⇔ DBサーバ間のデータアクセスのネットワーク・トラフィック
移行の考慮点 †
XenApp? †
- 概要
- サーバをマルチ ユーザし、サーバで動作している
アプリケーションソフトの画面を端末にリアルタイムに配信するシステム。
- アプリケーションソフトの利用者は端末でソフトの操作が可能だが、
端末ではソフトは動作しておらず、画面表示と入力の受付のみが行われる。
- 経緯
- ターミナル・サービスは、もともとマルチ ユーザ機能を持っていなかったWindowsを
マルチ セッション環境下で利用できるようにしたCitrix製品のOEM供給であった。
- 以降、Windowsにターミナル・サービスが標準搭載されたため、
- セキュリティー、パフォーマンス、拡張性、安定性、柔軟性などを強化した、
ターミナル・サービスに高い付加価値を提供する製品として販売されている。
- 例えばRDPプロトコルよりICAプロトコルのほうが性能的に優れており、
帯域やネットワーク品質の不足がある場合など、XenApp?が導入されるケースがある。
- バージョンと製品名の変遷
- 3：MetaFrame? Presentation Server
- 4：Citrix Presentation Server
- 5：Citrix XenApp?
UIテクノロジ †
リッチ・クライアント †
Java系 †
Javaのリッチクライアント技術は弱いので、
Nexaweb、XPlatformを使用するケースが多い。
- 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が参考とした技術、
自動ダウンロード、自動インストール、自動アップデートして、
サンドボックス化された実行コンテキスト内で実行される。
ActiveX †
その他 †
HTML †
ASP.NET Web Form? †
要約すると、 †
- ASP.NET Web Form?の価値は、
- 画面単位のモジュール化と、イベント・ドリブンの実現
- コンポーネントベース、１画面１Formなど、
実装ルールが明確なため標準化し易い。
- ASP.NET MVCの価値は、
- 実装ルールが緩く標準化が困難だが、
- ASP.NETでは意識し難い生HTMLをガリガリ生成＆弄り易い。
と言う事かと思います。
HTML5/CSS3/JavaScriptが注目される時勢のため、
前者が衰退傾向で、後者が流行しつつあるという認識。
RIA †
- Webシステムの強みを残し、
C/S型システムの以下の弱みを解決したテクノロジ
- プラットフォーム依存
- 配布・設定の手間
- クライアント側へデータ保管が可能であるなど、
セキュリティを考慮した機構は持っていないため個別対応が必要。
- Flash・Flex、Silverlight
Flashは、アニメーションなどを含む柔軟なUI作成に使用されるが、
Flex、Silverlightはより業務アプリケーション開発に適した
UIコンポーネントベースのプログラミング・モデルを採用している。
- Ajax、HTML5
Viewの構成をクライアントが担っているWebアプリケーション。
Flash・Flex †
Flex 2.0でリッチなWebアプリを作ろう
- 第1回 Flexはエンジニア向けのFlash：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20061012/250481/
Silverlight †
WPFと同じXAML＋.NET（VB、C#などの.NET言語）によって開発・実装を行うが、
- RIAであるためサンドボックス化されたコンテキストの内部で実行される。
- ランタイム配付の軽量化のため.NET、WPFと比べ機能が制限されている（若しくは差異がある）。
- クロスブラウザ・クロスプラットフォームを謳っているが、サポートされない環境もある。
Ajax †
HTML5 †
HTML5 - Wikipedia
http://ja.wikipedia.org/wiki/HTML5
HTML5 は、プロプライエタリなプラグインとして提供されているリッチインターネットアプリケーションのプラットフォーム（JavaFX、Adobe Flash、Microsoft Silverlight 等）を置き換えることを標榜しており、ウェブアプリケーションのプラットフォームとしての機能やマルチメディア要素が実装されている。そのため HTML5 が普及すれば Adobe Flash などのプラグインは不要になるという意見がある。
リッチクライアント技術ではあるが、
のプログラミング・モデルを直接サポートしておらず、
現段階では、Flash・Flex、Silverlightのような
業務アプリケーション開発向けの技術では無い。
Single Page Application (SPA) †
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 アプリケーション
を構築するのに適したフレームワークとテンプレート
シン・クライアント †
ターミナル・サービスを指す。
WWWブラウザ †
Office †
通信テクノロジ †
プロトコル †
TCP/IP †
HTTP, HTTPS †
- HTTP
WWWブラウザ等で使用されているHTML参照用のプロトコルだったが、
以下の理由で、現在では、Webアプリケーション、Web APIなどにも利用されている。
- Webサーバ、APサーバ（CGI）と連動させて容易にサービスを構築・提供可能。
- 容易に利用可能なリクエスト＆レスポンス型プロトコル（通信処理部の隠ぺい）。
- プロキシサーバー経由でイントラネット → インターネットへのアウトバウンドがサポート。
- 下記HTTPSを使用して容易に暗号化が可能（IPSECは構築が難しい）。
MSMQ †
DBとの２フェーズコミットが必要な
を構築する場合に利用する。
ただし、
- TPモニタ（MS-DTC）の構築を必要としたり、
- 構築方法、専用APIを理解する必要があったり、
構築~利用までの難易度が高い。
従って、ＤＢをキューとして使用する案件も多い。
このためマイクロソフトは、SQL Serverに
Service Brokerというミドルウェアを実装しているが、
メッセージング基盤、非同期実行基盤は、
カスタマイズ要素が多いためか、普及するに至っていない。
名前付きパイプ †
通信API †
リモーティング †
ASP.NET Webサービス †
ASP.NET Web API †
参考情報 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
