連載アプリケーション・アーキテクチャ設計入門 第4回 セキュリティ、運用管理、および通信のポリシーとその設計 日本ユニシス 猪股 健太郎 |
|
|
通信ポリシー
通信ポリシーは、同期性、フォーマット、プロトコルを取り上げている。しかし、特に重要なのは通信の同期性である。
まずは、コンポーネント同士の通信に、メッセージベースの通信技術を使うのか、DCOMや.NETリモート処理(.NET Remoting)のような、より密に結合する通信技術を使うのかを注意深く選択する。アプリケーション間の通信技術には、XML Webサービスやメッセージ・キューイングなどのメッセージベースの技術を用いるべきだろう。アプリケーションの内部では、DCOMなどの密結合技術を利用した方が高性能だし、トランザクションやセキュリティなどのコンテキストの受け渡しが簡単に実現できる。もちろん、トランザクションやセキュリティのコンテキストを渡す必要がなければ、XML Webサービスを選択できる。
推奨する選択肢は、アプリケーション内部の異なる物理層(ティア)間でもできる限りメッセージベースの通信技術を利用することである。その理由は、疎結合の通信技術で統一することで、モジュール性を高めることができるからである。しかし、疎結合の通信技術には、セキュリティ・コンテキストの受け渡しに特別の考慮が必要、分散トランザクションや大容量転送などの標準仕様がない、プレゼンテーション層やデータ層などを疎結合に設計することは難しいなどの問題がある。従って、サービスの統合がさほど大きな位置を占めないようなアプリケーションであれば、外部サービスとの通信にのみ疎結合技術を用いるという設計も可能だ。
■非同期通信
非同期通信の利点には以下のようなものがある。
-
同期通信よりもスケーラビリティと可用性に優れる
-
コネクションの存在を前提にしないため、真の位置透過性が得られる
-
業務モデルによく適合する
-
内部のボトルネックに影響されないため、SLAを順守しやすい
-
通信技術に依存しない
一方、非同期通信の欠点には以下のようなものがある。
-
会話状態を自分で管理する必要がある
-
送信メッセージと受信メッセージを対応付ける機構を実装する必要がある
-
メッセージが遅延したときの対処を実装する必要がある
-
1つのトランザクション内で送信と受信を同時に行えない
-
メッセージが重複したときの対処を実装する必要がある
-
メッセージの順番を自分で管理する必要がある
非同期通信による要求と回答 |
非同期通信では要求を出してすぐに次の処理に移ることができ、その回答は非同期に返ってくる。 |
非同期通信の代表例は、メッセージ・キューイングである。メッセージ・キューイングはトランザクションを実装でき、メッセージの到達保証が得られる。また、クラスタ構成を取ることができる。メッセージ・キューイングを利用する場合は、ServicedComponentクラスか、またはメッセージ・キューイングのトリガを使うことができる。そのほかにも、XML Webサービスや.NETリモート処理で非同期通信を実現することもできる。
■同期通信
.NET Frameworkは同期通信技術のさまざまな選択肢を用意している。選択肢にはエンドポイント、プロトコル、フォーマットが含まれ、それらの組み合わせで同期通信は構成される。それらの組み合わせはチャネルと呼ばれる。
同期通信による要求と回答 |
同期通信では、要求を出した後、次の処理に進まずに回答が返ってくるまで待つ。 |
以下の質問に答えることで、適するチャネルを選ぶことができる。
-
分散トランザクションか、Windowsセキュリティ・コンテキストの引き渡しが必要か?
→ どちらかが必要であれば、ServicedComponentクラスを使ったDCOM通信を選択する。 -
さまざまなシステムと通信するか?
→ そうであれば、トランスポートにHTTP、フォーマットにSOAPを選ぶ。質問4へ。そうでなければ質問3へ。 -
呼び出し元を認証するか?
→ 質問3にたどり着いている場合は、.NETリモート処理のチャネルを利用できる。HTTPを通した呼び出しで呼び出し元を認証する必要があれば、エンドポイントにIISを利用する。認証の必要がなければ、.NETリモート処理のチャネルはどのようなプロセスでホストしても構わない。 -
ビジネス・コンポーネントに対するファサードを実装するか?
→ ビジネス・コンポーネントの直前に1層設けて何らかの処理を行う場合は、ASP.NETのXML Webサービスを利用するとよい。その必要がないのであれば、.NETリモート処理のHTTP/SOAPチャネルを利用する。
■同期通信で非同期通信をラップする
非同期通信にはさまざまなメリットがあるが、一部の場合では、クライアントが回答を同期的に必要とすることがある。そのようなときには、非同期的な通信に同期的なインターフェイスを与える方法が考えられる。つまり、要求に対する回答を受け取るまで待ち、結果を呼び出し元に返すようなサービス・エージェントを作成するのである。実際に設計する際には、タイムアウト処理や、要求メッセージと回答メッセージの対応付けの仕組みが必要となる。
まとめ
以上で、アプリケーションの論理層(レイヤ)をまたがって考慮すべき、セキュリティ、運用管理、および通信のポリシーについての説明を終える。実装の詳細については、MSDNの「.NET による分散アプリケーションの構築」や、「分散アプリケーションのデザイン」などに解説があるので、そちらも併せて読んでほしい。
次回は、「物理配置、ならびに運用上の要求」について解説したい。
INDEX | ||
[連載] アプリケーション・アーキテクチャ設計入門 | ||
第4回 セキュリティ、運用管理、および通信のポリシーとその設計 | ||
1.セキュリティ・ポリシーに関する設計:認証 | ||
2.セキュリティ・ポリシーに関する設計:承認、安全な通信、プロファイル管理、監査 | ||
3.運用管理ポリシーに関する設計 | ||
4.通信ポリシーにおける非同期通信と同期通信 | ||
「アプリケーション・アーキテクチャ設計入門」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|