特集
Tech・Ed 2005セッション・レポート

.NETにおけるSOAの設計手法

デジタルアドバンテージ 一色 政彦
2005/08/11
Page1 Page2 Page3

 2005年8月2日から4日間、パシフィコ横浜にてマイクロソフト主催のカンファレンス「Tech・Ed 2005」が開催された。このカンファレンスでは、マイクロソフト・テクノロジーに関するさまざまなセッションが、ITプロ、デベロッパー、アーキテクトなどを対象に行われた。

 本稿では、その初日のラーニング・デーに実施された「SOAの設計手法」(スピーカーは、日立システムアンドサービスの酒井 達明氏)のセッション内容を、(技術解説的に)お伝えする(なおSOAといっても、本稿は新たなひとつの企業システムを構築するための手法を説明するものであって、ESBBPELなどによる既存システムの連携については解説しないので、注意してほしい)。

 この「SOAの設計手法」のセッションでは、次のような流れで話が進められた。

 まず前半は、SOAで用いられるサービスについての説明である。アジェンダは次のとおりだ。

  1. サービスとコンポーネントの違いとは?
  2. Fiefdoms/Emissariesモデルから見えるサービスのあるべき姿

 そして後半が、SOAのサービスを実際に設計する際のポイントや注意事項についての解説だ。そのアジェンダは次のとおりである。

  1. サービス指向アーキテクチャのベスト・プラクティス
  2. コントラクトとサービス・インターフェイスの定義
  3. ビジネス・プロセスのアーキテクチャ
  4. 物理制約の考慮
  5. セキュリティ・ポリシーの設計

 本稿では、この流れにそって、セッションで説明された内容を解説していく。なお本稿は筆者が理解した内容を、筆者の言葉で解説している。実際のセッション内容と異なる部分があることをあらかじめお断りしておく。また図表やキーとなる考え方などの説明文は、セッション資料の内容をそのまま使用しているところがある。

 SOA(Service-Oriented Architecture:サービス指向アーキテクチャ)については、読者諸氏はすでにご存じだと思う。システムが持つ各機能を、「サービス」という単位で独立させて分散させるシステム・アーキテクチャである。

 とはいっても従来から、このような機能を細かく分けて独立させ、それを別サーバ上などに分散させる形式のシステム・アーキテクチャ(以降、分散システム)は存在していた。従来の分散システムにおいて、そのように分散された機能は、「コンポーネント」と呼ばれている。代表的なコンポーネントの例としては、エンタープライズJava環境のEJBや、N階層システムにおけるCOM+コンポーネントなどがある。

 それでは、従来からある分散システムなどにおける「コンポーネント」と、SOAのシステムにおける「サービス」には、どのような違いがあるのだろうか。

1. サービスとコンポーネントの違いとは?

 サービスとコンポーネントの最も根本的な違いは、抽象度(=分散された機能の粒度)が異なるということだ。一般にサービスの方が、コンポーネントよりも抽象度が高い。サービスでは、そのたった1つのサービスが1つの業務システムそのものを表しているということが珍しくない。しかし逆にコンポーネントは、業務システムの中に含まれる非常に小さな機能単位であることが多い。

 そのほかにもいくつか特徴的な相違点がある。これについては、次の表にまとめた。

比較項目 分散システムなどのコンポーネント SOAにおけるサービス
同期処理 一般的に、同期的に呼び出されて処理を行うことが想定されている 非同期で処理を行うことも想定され得る。例えば、サービス内部でバッチ処理が動作するような場合、処理結果がすぐには返せないことがあり得る(その対処方法を考慮しておかなければならない)
ライフサイクル管理(=オブジェクトの生成から破棄までを管理すること) 利用者側からコンポーネントのライフサイクルを管理する。コンポーネントを自ら生成して利用すればよいので、確実に呼び出せる可能性が高い 利用者側からサービスのライフサイクルを管理しない。従って、サービスを呼んでみたら使えなかったという事態が起こり得る(その対処方法を考慮しておかなければならない)
Feature(=機能)の利用 メソッド経由 メッセージ経由
サービスとコンポーネントの相違点

 これらの相違点を考えると、やはり、複数のコンポーネントで構築されるシステムはそれらのコンポーネント間を密結合させた方が都合よく、複数のサービスで構築されるシステムはそれらのサービス間を疎結合させた方が都合よいだろう。

 セッションでは、このようなサービスのあるべき姿について、「Fiefdoms/Emissariesモデル」を用いて解説されていた。これについて掘り下げて説明していこう。

2. Fiefdoms/Emissariesモデルから見えるサービスのあるべき姿

 このモデルで用いられている「Fiefdoms」(フィーフダム)という用語は「封建領土」を、「Emissaries」(エミサリー)という用語は「特使」を意味する。

 ここで、ヨーロッパ中世の封建社会を思い描いていただきたい。

 この封建社会の中では、完全に自立運営されているFiefdoms(例えば、江戸時代の鎖国状態の日本を想像してみるとよいだろう)が複数存在する。それぞれのFiefdomsはおのおのに得意な分野(例えば洋服の生産、農作物の生産など)を持っている。それぞれのFiefdoms同士は、Emissariesを使って連絡や物資のやり取りを行う。このようにすべてのFiefdomsがお互いに協力し合うことで、1つの社会システムが機能している。

 ここで特徴的なことは、このFiefdomsは完全に自律した存在で、外部からの管理は一切受けないし、外部の存在に関してはEmissaries以外のものはまったく信頼しない。それだけでなく、Fiefdomsへの物資の要求方法や物資のやり取り方法を熟知しているEmissariesでさえも、すぐには信じず、その素性など事細かに調べ上げる(=検証する)という徹底ぶりである。

Fiefdoms/Emissariesモデルの世界

 ここまでいえば、FiefdomsがSOAにおける何を表し、Emissariesが何を表すのか、察しが付いたのではないだろうか。そう、Fiefdomsは「サービス」を意味し、Emissariesは「メッセージ」を表す。そしてFiefdomsの間でやり取りされる物資は、「サービスが保持するプライベートでミッションクリティカルなデータ」を表している。またEmissariesが熟知している物資の要求方法は、「サービスの呼び出し規約」を意味している。この封建社会が表現するものは、各サービスがメッセージによって疎結合されたSOAのシステムである。

SOA(サービスとメッセージ)の世界

 この世界では、あるFiefdoms(これを仮に「A」としよう)から別のFiefdoms(これを「B」とする)に対して、何らかの物資を要求するとき、Emissariesを派遣することになる(Emissaries以外では受け入れてもらえないため)。このEmissariesは、Fiefdoms「A」が持つ物資のカタログ情報(=参照データ)を持ち帰ったり、物資の注文内容(=設定データ)をFiefdoms「A」に引き渡したりする。

 ここで注意が必要なのは、トランザクションである。Fiefdomsにおけるトランザクションは、そのFiefdoms内部(つまりサービス内部)に限定すべきである。要するにFiefdomsの間で(つまりサービス間で)ACIDトランザクションを共有してはならないということだ(ACIDトランザクションについては「混迷するWebサービス・トランザクション制御」の「ACIDトランザクションとは」という項目を参照されたい)。その理由は、サービスが前述のように非同期で動作する可能性があるからである(処理が戻ってこない可能性がある)。

 またデータに関しても注意が必要である。Emissariesが持ち帰ったカタログ情報はその時点ですでに古い情報である、つまりそのデータはスナップショットであるということだ。そこでそのようなスナップショットのデータを取り扱うためのテクニックが必要となる。例えば、そのスナップショットに対して何時何分のデータかという情報を付加することで、空間と時間を越えた「不変のデータ」として存在させ、サービス側でそのような「最新ではないデータ」を適切に処理することなどが挙げられる。

 以上のFiefdoms/Emissariesモデルをまとめて「SOAのあるべき姿とはどのようなものか」を考えると、次のようなことがいえるだろう。

  • 各サービスは自律分散される
  • 各サービスはメッセージにより疎結合で連携する
  • メッセージは解釈前に検証される
  • 各サービス間ではACIDトランザクション状態は共有しない
  • 得られたデータはスナップショットである

 以上の話はサービスに関する概念的な話であったが、以降、もう少し具体的に.NETでサービスを作る際の設計手法について説明していこう。

 

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


Insider.NET フォーラム 新着記事
  • 第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用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間