特集
|
|
|
3. サービス指向アーキテクチャのベスト・プラクティス
次に挙げているのはマイクロソフトが運営するサイトの1つで、実証済みのアーキテクチャに関するコンテンツやサービス連携のパターンなどの情報が公開されている。
このサイトにはSOA設計に関するベスト・プラクティスも含まれており、ここではその中の「.NETのアプリケーション・アーキテクチャ:アプリケーションとサービスの設計」の内容について詳しく解説する(このアーキテクチャの詳細については「アプリケーション・アーキテクチャ設計入門」を参照してほしい)。
次の図は、リファレンス・アーキテクチャにおける「ユーザー・インターフェイスとサービスの連携」を示したものである。
リファレンス・アーキテクチャにおけるユーザー・インターフェイスとサービスの連携 |
この図では、ユーザー・インターフェイス(以降、UI)に関連する層が上半分に、サービスに関連する層が下半分に描かれている。 |
このアーキテクチャでは、ユーザーに最も近い「ユーザー・インターフェイス」にはビジネス・ロジックを含めずに、なるべく個々のUI(例えば、WebアプリケーションのUI、WindowsアプリケーションのUI、モバイル・アプリケーションのUIなど)に独立させる。さらにユーザー・インターフェイスからビジネス・ロジックへの橋渡しとして「UIプロセス」を設けて、そこに例えば画面の表示状態などを一時的に保管する。このようにすることで、UIの表示順序を並べ替えたり、UIの1つを追加・削除したりといったことにも柔軟に対応できるようになり(詳細後述)、変化に強いシステム・アーキテクチャとなる。
サービス側では、粒度の荒いビジネス・ロジックとして「ビジネス・プロセス」(「ビジネス・ワークフロー」とも呼ばれる)が配置され、さらにより細かで単純な1機能を実現するビジネス・ロジックとして「ビジネス・コンポーネント」が配置される。これを相互に連携させて、粒度の荒いビジネス・プロセスの方でビジネス・ロジックを共有する。
ユーザー・インターフェイスの層とサービスの層がやり取りを行う部分には、「サービス・インターフェイス」を配置する。このサービス・インターフェイスでは、両者が通信するためのプロトコルや呼び出し方を定義する。
また単一機能を実装するビジネス・コンポーネントは、互いに完全に独立した存在で外部のコンポーネントに依存しないように設計しなくてはならない。このため、複数のビジネス・コンポーネント間でデータのやり取りが必要になった場合には、そのやり取りを行うための新しい概念が必要になる。それが「ビジネス・エンティティ」である。しかしこれはあくまでもビジネス・ロジックの間で共有される一時的なデータである。
それではデータを永続化する場合にはどうするかというと、「データアクセス・コンポーネント」を配置して、そこからデータベースへデータを格納する。データアクセス・コンポーネントでは、ビジネス・コンポーネントに対して生のデータを見せるのではなく、そのビジネス・コンポーネントが利用しやすい形に加工する。
さらに、ほかのWebサービスなどとコミュニケーションする場合には、それを「サービス・エージェント」を使って呼び出す。ほかのWebサービスのライフサイクルを管理することはできないので、その呼び出しが失敗したときの処理などをこのサービス・エージェントの中に閉じ込める。
以上のようなアーキテクチャを採用することで、比較的安定したアプリケーションを構築できる。
実際にSOAのサービスを設計する際には、(冒頭のセッションの流れで述べたように)次のような点を十分に検討しなければならない。
・コントラクトとサービス・インターフェイス
・ビジネス・プロセスのアーキテクチャ
・物理制約
・セキュリティ・ポリシー
それでは次に、コントラクトとサービス・インターフェイスを定義するうえでの注意点を述べていこう。
4. コントラクトとサービス・インターフェイス
実はこのコントラクトとサービス・インターフェイスが、SOAのサービス設計でも特に重要となる。
■コントラクト
コントラクト(Contract:契約)とは、複数のサービス間における一連のやり取りを取り決めた合意事項のことである。例えば次の図は、2社の間で販売から購入までの一連の流れを図で示したものである。
サービス間のコントラクトの定義例 |
この図では、最初の「見積もり依頼」を送るところから、最後の「領収書」を受け取るまでメッセージや物品がやり取りされる様子が示されている。この図で示される一連の処理の流れは、あらかじめ決められた合意事項「コントラクト」である。 |
SOAのコントラクトでは、一連のメッセージ交換のシーケンスとメッセージの種類があらかじめ定義されており、そのコントラクトは具体的には「サービスのプログラミング・インターフェイス」(以降、サービス・インターフェイス)によって実装(インプリメント)されている。
■サービス・インターフェイス
サービス・インターフェイスとは、サービスにアクセスするためのエントリ・ポイントである。サービス・インターフェイスは、「サービスの信用の境界」(Fiefdoms境界。サービス・インターフェイスから外側は信用しないという意味)や、「サービスの呼び出し手段」(具体的には、サービスを公開するためのプロトコルとして、例えば「XML Webサービス」「.NETリモート処理(.NET Remoting)」「MSMQ」「COM+」などのどれを利用するのか)、また「サービスでの認証メカニズム」(どうやってメッセージを検証するか)などを定義する。
通信プロトコル | 特徴 |
XML Webサービス |
・ファイア・ウォールを越えてリクエストが可能 |
.NETリモート処理 |
・ファイア・ウォールを越えてリクエストが可能 |
MSMQ |
・非同期通信をサポートする際に利用する |
サービス・インターフェイスの代表的なプロトコル |
ただしサービス・インターフェイスは、あくまでインターフェイスなので、ビジネス・ロジックを含めてはならない。ビジネス・ロジックは、ビジネス・コンポーネントとして分離する必要がある。
また1つのテクニックとして、複数のプロトコル(例えばXML WebサービスとMSMQ)で同じ認証のメカニズムを共通的に使いたいという場合があった場合には、それらのサービス・インターフェイスとビジネス・コンポーネントの間に、ビジネス・ファサード(Business Façade)を組み合わせるとよい。このビジネス・ファサードに、例えばポリシー関連(例えば「認証」「検証」など)のコードなどを共有するのである。
認証メカニズムを共有するテクニックとしてのビジネス・ファサード |
複数のプロトコル(例えばXML WebサービスとMSMQ)で同じ認証のメカニズムを共通的に使うには、サービス・インターフェイスとビジネス・ロジックの間にビジネス・ファサードと呼ばれるコンポーネントを配置して、そこでポリシー関連(例えば「認証」「検証」など)のコードを共有すればよい。 |
次にサービスにおいてビジネス・ロジックを実現させるためのビジネス・プロセスおよびビジネス・コンポーネントについて見ていこう。
INDEX | ||
[特集] | ||
Tech・Ed 2005セッション・レポート | ||
.NETにおけるSOAの設計手法 | ||
1. サービスとコンポーネントの違いとは? | ||
2. サービス指向アーキテクチャのベスト・プラクティス | ||
3. ビジネス・プロセスのアーキテクチャ | ||
- 第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用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|