特集 Tech・Ed 2005セッション・レポート .NETにおけるSOAの設計手法 デジタルアドバンテージ　一色 政彦 2005/08/11
Page1 Page2 Page3

5. ビジネス・プロセスのアーキテクチャ

■ビジネス・プロセス

　ビジネス・プロセス（ビジネス・ワークフロー）とは、先ほど述べたビジネス・ファサードの別名である。ビジネス・プロセスの役割は、ビジネス・コンポーネント（ビジネス・ロジック）へ処理の要求を送信したり、その結果を受信したりすることである。

　また、ビジネス・プロセスには個々のビジネス・コンポーネントを外部から隠ぺいするという役割がある。これによって、システムが変化に対して格段に強くなり、ビジネス・ロジック（ビジネス・コンポーネント）の実行順序の変更や、追加、削除などにも柔軟に対応できるようになる。さらに、ビジネス・プロセスには、ビジネス・コンポーネント間で共有される＜一時的な状態＞を保持するという役割もある（永続的な状態はデータベースに格納する）。

■ビジネス・コンポーネント

　ビジネス・コンポーネントは、ほかのコンポーネントの存在を前提としてはならない。つまり、各ビジネス・コンポーネントは完全に独立していなければならない。

　しかし現実には、コンポーネント間が完全に独立せずに、コンポーネント間に参照関係が設定されてしまって、次の図のようなスパゲッティ状態の関係が構築されてしまうことがよくある。このような状態では、ビジネス・コンポーネントを変更した際の影響範囲を予測することが難しい。

スパゲッティ状態になっているコンポーネント間の参照関係

ビジネス・コンポーネント「A」がそのほかのビジネス・コンポーネント「B」を直接参照している場合、ビジネス・コンポーネント「B」を変更しようとすると、（その変更による影響が及ぶ可能性があるために）どのビジネス・コンポーネントがこれを参照しているかを把握しなければならなくなる。

　従って、このようなスパゲッティ状態の参照関係が設定されるのは避けなければならない。もしほかのコンポーネントに対して関係を結びたいのであれば、この図のように直接参照を行うのではなく、ビジネス・プロセスを通じてそれを依頼する必要がある。

　またVisual Basic 6.0の開発ではよく起こりがちなのだが、複数のコンポーネント間で共通モジュールを利用しているような場合、その共通モジュールに変更を行うとその影響がそれを利用している複数のコンポーネントに及ぶ可能性がある。

共通モジュールを利用している場合のコンポーネント間の関係

　このような問題を回避するためには、その共通モジュールの抽象インターフェイス／抽象クラスを作成してそれを継承するテクニック（＝依存関係を逆転させるテクニック。これについては、「.NETで始めるデザインパターン 第7回 デザインパターンの落とし穴」が参考になる）などを活用すればよい。

■トランザクション・ポリシー

　サービス内部で行うACIDトランザクションは、大原則として、そのサービス内部で完結させるべきである。このようなACIDトランザクションを.NETで実現する方法には、大きく分けて次の2つがある。

• サービス・コンポーネント（Serviced Component。COM＋）
• ADO.NETネイティブ・トランザクション

　実はパフォーマンスでいうと、ADO.NETのネイティブ・トランザクションの方が格段に早い。よって、基本的にはこれを用いればよい。

　しかし、場合によっては、サービス・コンポーネント（COM＋）を使わざるを得ないケースが存在する。例えば、＜複数＞のアセンブリや＜複数＞のデータソースでトランザクション状態を共有したいケースなどである。エンタープライズの世界ではこのようなケースがよく発生するので、現実的には、トランザクションにサービス・コンポーネントが用いられることの方が多い。

　また別のトランザクションの方法として、ロング・トランザクションという考え方がある。ロング・トランザクションとは、キャンセル・ポリシーに従って特別なキャンセル処理を行うロジックを実装したトランザクションのことである。

　例えばホテルの予約で、宿泊日前日までのキャンセルなら20％、当日なら80％、不泊の場合には100％のキャンセル料が発生するというキャンセル・ポリシーがある場合、キャンセルをしたときのトランザクション処理の内容が状況によって変化する。要するに、ACIDトランザクションではキャンセルすると完全になかったことにしてしまうが、そのような処理ができず、状況により変化する場合にはこのロング・トランザクションを採用する必要ある。

6. 物理制約の考慮

　次にサービスの配置についても述べておこう。先ほど示したリファレンス・アーキテクチャはあくまで論理アーキテクチャであって、実際の物理配置ではないことに注意していただきたい。それではサービスをどのように配置するか。

　まずはそのサービスの配置に関する原則を示す。

物理境界は最小限に抑える

　物理境界をできるだけ少なくする理由は、物理境界がシステムのパフォーマンスを低下させてしまうからである。例えばアプリケーションが、単一のコンピュータ内で動作するよりも、複数のコンピュータがネットワークを通じて通信を行えば、パフォーマンスは当然ながら低下するということは、容易に想像できるだろう。

　それならば1つのコンピュータ上にすべてを載せて、物理境界をゼロにしてしまえばよいと考えられるが、必ずしもそういうわけにもいかないケースがある。例えば、Webサービスを利用して外部のサービスと接続するのにインターネットが必要な場合などがそれだ。このような場合、インターネットに対する物理境界がなければ、システム自体が機能しなくなってしまうので、どうしても物理境界を作成する必要がある。

　このような物理境界を作成しなければならない要因として、ほかにもさまざまな問題がある。例えば、次のような問題を挙げることができる。

• セキュリティ上の問題
  （例：機密データの配置場所を特別なサーバに隔離する場合）

• システム管理の問題
  （例：コンピュータやアプリケーションのライセンスの問題）

• パフォーマンス／可用性／スケーラビリティの問題
  （例：障害の発生が想定されるサーバを分離する場合）

• そのほかに社内の政治的な問題
  （例：人事部のデータは部外のサーバには置かないという場合）

　現実にはこれらの問題を考慮したうえで、物理境界を最小限に抑える必要があるのだ。

■ビジネス・コンポーネントの展開

　続いてビジネス・コンポーネントの配置について詳しく述べよう。

　当然、ビジネス・コンポーネントを配置するときも、UI／UIプロセスから同期的に呼び出されるビジネス・コンポーネントの場合は、（パフォーマンスを考慮して）極力同じ境界内に置いた方がよい。また、同期的に呼び出され、更新が少なく頻繁に利用するデータで、かつセキュアである必要がないデータの場合には、できる限り同じ境界内に配置した方がよい。特にWebアプリケーションではこれが推奨される。つまり、同期か非同期を考慮してビジネス・コンポーネントを展開することで、システム・パフォーマンスを最適化できるわけである。

　これを図で見てみよう。次の図はあまりよくない物理配置の例である。

あまりよくない物理配置の例（固定的な3階層への配置）

セキュリティだけを見れば最適だが、物理境界が多く、パフォーマンスに劣る。UIが頻繁に利用するカタログ・データが別ゾーンに配置されているが、このデータをUIの近くに配置すればもっとパフォーマンスを稼げるはず。

　これを理想的な配置に置き換えたのが次の図である。

理想的な物理配置の例（柔軟な配置）

セキュリティだけを見れば最適だが、物理境界が多く、パフォーマンスに劣る。UIが頻繁に利用するカタログ・データが別ゾーンに配置されているが、このデータをUIの近くに配置すればもっとパフォーマンスを稼げるはず。

　この理想的な物理配置のモデルでは、UIから頻繁に利用され、なおかつ高度なセキュリティが要求されないデータは、UIと同じ境界内に配置され、UIからあまり利用されないようなデータは、境界外の安全な領域に配置されている。また、サービスに含まれるビジネス・ロジックとデータベースを同じ物理境界内に配置している。これにより、SOAシステムのパフォーマンスが最適化されている。

　SOAでは、このようなシステムの物理制約と、セキュリティ、パフォーマンスなどの現実的な問題とを総合的に考慮したうえで、実際のコンポーネント配置を行うようにすべきである。

7. セキュリティ・ポリシーの設計

　SOAを設計する際にも、セキュリティ・ポリシーの設計は欠かすことができない。そこで実際にセキュリティを導入するには、基本的に、新たに独自のセキュリティ・ソリューションを実装するのではなく、既存の実証済みのもの（例えば、SSLなど）を導入、利用すべきである。

　また外部からの入力やデータは必ず疑うべきである。例えば、Webアプリケーションなどで外部から入力を受け付ける場合、その入力がSQL実行文を含むSQLインジェクションなどの攻撃の可能性もあるので、必ずそれを検証しなければならない。このような外部からの攻撃を防ぐには、例えば次のような手段を講じるとよい。

• 認証＆承認ロジック、WS-Securityの実装
• 電子署名による改ざんの検出
• ADO.NETのCommand.Parametersプロパティの利用

　特に（SQL文を手動で作成せずに）Command.Parametersプロパティを利用すれば、そのプロパティ内部で入力値に不正な文字がないかをチェックしてくれるので、SQLインジェクション攻撃を無効にできる。

　外部システムが持つセキュリティも当てにすべきではない。むしろセキュリティ保護されていないものと見なして、機密データならば暗号化すべきである。また、外部への露出部分および特権の付与は、必要最低限にすべきである。

■

　省略した部分もあるが、以上がセッションの全体的な内容である（ちなみに日立システムアンドサービスのWebサイト上に、スピーカーである酒井氏が執筆した「.NETアーキテクチャ入門」の記事があるので、興味がある読者諸氏は併せてそちらも参照するといよい）。

　セッション自体は、ベスト・プラクティスとされるSOAのシステム・アーキテクチャを一通り解説しているわけだが、特に印象的だったのは、物理配置において、頻繁に利用するセキュアではないデータは同じ境界内に配置したり、またサービスが持つビジネス・ロジックとデータベースを同じ境界内に配置したりして適切にパフォーマンスを最適化するという考え方だ。

　優れたSOAのシステムを構築するうえでは、本稿で説明したような、現実の物理制約やパフォーマンス、セキュリティなどをしっかりと総合的に考慮したうえでのシステム構成と物理配置が必要になるだろう。読者諸氏が実際にそのような優れたSOAのシステムの設計を行ううえで、本稿のセッション・レポートが何らかの役に立てば幸いである。

INDEX
	[特集] Tech・Ed 2005セッション・レポート
	.NETにおけるSOAの設計手法
	1. サービスとコンポーネントの違いとは？
	2. サービス指向アーキテクチャのベスト・プラクティス
	3. ビジネス・プロセスのアーキテクチャ

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）