SOA の 10 原則

作者 Stefan Tilkov , 翻訳者 編集部 投稿日 2008年1月29日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

Webサービス ,

SOA ,

Best Practices ,

Web services ,

プログラミング ,

エンタープライズアーキテクチャ ,

Architecture ,

設計 ,

XML

私は、多くのお客様と関わる中で、SOAの基本的な原則をまとめる必要性を感じています。以下のセクションでは、サービス指向アーキテクチャ(SOA)が持つとされる基本原則を紹介します。これらの原則は、絶対的な真理というよりは、SOAに関連した検討を行う際の基準の1つと考えてください。最初の4つは、Don Boxの4つの原則(サイト･英語)に、個人的な解釈を少し加えて紹介します。

1. 明示的な境界

サービスが機能を提供するのに必要なすべてのものは、そのサービスが呼び出されたときに受け渡しされる必要があります。サービスへのアクセスは、必ずパブリックに公開されたインターフェイスを経由します。そのサービスを呼び出すために暗黙の想定の存在が必要であってはいけません。“サービスとのやり取りはすべてメッセージを介して行われるので、サービスはメッセージングとの結びつきが強いと言えます。”(source)一般的なパターンとして、サービスの呼び出しは、共通のコンテキストに依存するべきではありません。サービスの呼び出しは、ステートレスとしてモデル化される必要があります。サービスによって公開されるインターフェースは、機能的、および非機能的な能力や特性を記述するコントラクトによって制御されます。サービスの呼び出しは、ビジネス的効果を持つ1つのアクションであり、リソース消費という点から考えて高価になる可能性があります。また、エラーの分類も、ローカルなメソッド呼び出しやリモートプロシージャコールとは異なります。サービスの呼び出しは、リモートプロシージャコールではありません。

サービスの利用および提供は、できるだけ簡単にする必要があるため、サービスと対話が行われているという事実を隠し過ぎることは好まれません。サービスとやり取りするメッセージ、サービスコントラクト、およびサービスそのもの、これらはすべてSOAの中で第一級市民(ファーストクラス)である必要があります。たとえば、使用されるプログラミングモデルおよびツールは、少なくとも、これらの概念を示すAPIをサービスプログラマに提供する必要があります。つまり、サービスは、内部をカプセル化した明示的なインターフェースを介して機能を公開します。サービスとの対話は、提供者と利用者間のメッセージの受け渡しに依存する明示的な行為です。

2. クラスではなく共有のコントラクトとスキーマ

サービスの記述(コントラクト)を始めとして、サービスの利用者も、提供者も、サービスの提供または利用に必要なものはすべて備えている必要があります。疎結合という原則に従えば、サービス提供者は、サービス利用者が自身の環境にコードを備え、それを使用するということを前提にはできません。結果としては、他のプログラムやランタイム環境を使用するとしても、それに依存することはできません。この原則のために、SOAで交換できるデータの種類には厳しい制限が課せられています。データの交換は、複数のスキーマで検証可能なXMLドキュメントとして行うのが理想です。これは、XMLドキュメントであれば、現在考えられるすべてのプログラミング環境でサポートされるためです。

つまり、DCOMベース、またはRMIベースの環境では、この原則を尊重することはできません。このような環境は、基本的にSOAの有効な選択肢からは除外されます。

3. ポリシードリブン

サービスと対話するには、次のような、方向性の異なる要件の両方を満たす必要があります。

1. 提供者の機能性、構文、および動作が利用者の要件に適合する必要がある。
2. 技術的能力および要求が一致する必要がある。
   

たとえば、サービス提供者は、利用者が必要とする適切なサービスを提供できるとします。しかし、利用者がHTTPしか使用できないのに、提供者はJMSで提供している場合があります(たとえば、.NETプラットフォームで実装したからなどの理由で)。また、提供者がXMLの暗号化標準によるメッセージレベルの暗号化を要求していても、使用者はSSLを使用したトランスポートレベルでのセキュリティしかサポートできない場合などもあります。両者が必要な能力を備えている場合でも、それらを “有効化” する必要があります。たとえば、提供者は、利用者それぞれの要求に合わせたアルゴリズムを使用して応答メッセージを暗号化します。

さまざまな装備および能力を持つ、できるだけ多くの利用者がサービスにアクセスできるようにするために、SOAツールセットの一部として、ポリシーメカニズムが取り入れられています。機能的な面は、サービスインターフェースに記述します。一方、非機能的な能力および要求はポリシーを使用して指定します。

4. 自律性

明示的な境界の原則にも関連しますが、サービスと外の世界との関係は、少なくともSOAの観点からすれば、インターフェースを経由した関係のみであるため、サービスは自律的であると言えます。特に、サービスの実行環境を変更することが可能である必要があります。たとえば、軽量なプロトタイプ実装から、複数のコンポーネントが連携する本格的なアプリケーションサーバーベースの集合体に変更しても、利用者に影響を与えることがあってはいけません。サービスは、それぞれ個別に、変更、配置、バージョンアップ、および管理できる必要があります。サービス提供者は、利用者がサービスの新バージョンにすぐに適応すると想定することもできません。利用者によっては、サービスインターフェースの新バージョンに適応できない、または適応を望まない場合があります(特に、サービス提供者の制御下にない利用者の場合はこのようなことがあります)。

5. プログラミング言語のAPIではなく通信形式

サービスは、サポートされる必要のある特定の通信形式を使用して公開されます。この原則は、最初の2つの原則と深く関係しますが、新たな視点から考えてみると次のようになります。「最大のアクセス可能性、および長期的な使用可能性を確保するために、サービスインターフェースに準拠したメッセージ交換をサポートするすべてのプラットフォームは、その対話が、サービスに定義されたポリシーに従っている限り、サービスにアクセスできなければならない」ｓ この原則が尊重されているかどうかは、Perl、Python、またはRubyなどの主要な動的プログラミング言語でサービスの提供または利用を行うことが可能かどうかを考えてみるとわかります。これらの言語が現在のテクノロジ群に含まれていないとしても、この仮定を考えてみることにより、次のような基準が満たされているかどうかがわかります。

• すべてのメッセージ形式が、オープンスタンダードを使用して、または人が読める形で記述されている。
• このようなスキーマに従ったメッセージを、特定のプログラマのライブラリを必要とすることなく、合理的な労力で作成できる。
• 正常な通信に必要な追加情報(セキュリティや信頼性といった目的のためのヘッダーなど)の意味および構文が、パブリックな仕様または標準に従っている。
• サービスとの対話に使用されるトランスポート(トランスファー)プロトコルのうち、少なくとも1つは、標準ネットワークプロトコルである(つまり、標準ネットワークプロトコルを介してアクセス可能である)。

6. ドキュメント指向

サービスと対話するには、データをドキュメントとして渡す必要があります。ドキュメントとは、データのコンテナであり、明示的にモデル化され、階層構造を持ちます。自己記述性は、ドキュメント指向の重要な要素の1つです。ドキュメントのモデル化は、購入注文書、請求書、または取引明細書など、実世界のドキュメントに従って行われるのが理想的です。ドキュメントは、対象の分野のコンテキストにおいて有用であるように設計される必要があります。これは、ドキュメントが1つまたは複数のサービスの提供に使用される可能性を示唆しています。

実世界の書類と同様に、サービスで交換されるドキュメントには冗長な情報も含まれます。たとえば、顧客IDと一緒に、(顧客IDだけで十分であるにも関わらず)顧客の住所情報が含まれることがあります。このような冗長性は、積極的に受け入れられています。これは、サービスの利用者および提供者のどちらの基盤となっているデータモデルからも、サービスインターフェースを分離するのに役立つためです。ドキュメント指向パターンを適用することにより、サービス呼び出しは、コンテキストに関係しないRPC呼び出しではなく、意味のあるビジネスメッセージの交換となります。ドキュメントの形式および構文としては、絶対ではありませんが、通常、XMLの使用が想定されます。

SOAの参加者間で受け渡しされるメッセージは、それぞれ別個に改訂されるさまざまなシステムを接続しています。疎結合の原則を尊重するには、共通の認識への依存を可能な限り少なくすることが必要です。メッセージが分散オブジェクト、またはRPCインフラストラクチャに送信される場合、クライアントおよびサーバーは、プロキシクラスの集合(スタブとスケルトン)が同じインターフェース記述ドキュメントから生成されるということを前提にできます。この前提が成立しない場合は、コントラクトが両者間の対話をサポートしていないということになり、通信が停止します。このため、RPCスタイルのインフラストラクチャでは、クライアントおよびサーバーのプログラムコードが同時に改訂されることが必要となります。

これは、以下を比較してみるとわかります。次のメッセージを考えてみましょう。

2006-03-1347113

上のメッセージを、下のメッセージと比較してください。

   2006-03-13
   4711
   3

2つ目のメッセージは明らかに人が読める形式ですが、最初のメッセージはそうではありません。また、2つ目のメッセージを使用する参加者、つまりXPathなどのテクノロジを介して情報にアクセスする参加者は、構文が固定されていることを前提とする参加者に比べて、互換性のある小さな改訂であれば影響を受けないで済む可能性が高くなることもわかります。逆に言えば、スタブとスケルトンの生成などのRPCパターンを使用できるにも関わらず、XMLなどの自己記述型のメッセージ形式を使用することは、帯域幅の無駄遣いであるというXMLへの批判を助長するだけです。XMLを使用する場合は、その利点が活かされる必要があります。(なぜ現在の多くのWebサービスがこの基準を満たしていないのかについて考察した、優れたレポート(source))が存在します。)

7. 疎結合

SOAの提唱者は、多くの場合、疎結合が重要な概念であるということに賛成しています。しかし、どのような特性があればそのシステムが “疎結合” であると言えるのかについてはさまざまな意見があります。システムの疎結合、または密結合には、要件およびコンテキストによって複数の次元があります。疎結合であると言われるあるシステムが、別の状況では密結合であると見なされることもあります。次のような次元があります。

• 時間: 時間的に疎結合である場合、参加者は通信するときに同時に稼働中である必要がありません。これには、参加者間にバッファやキューの何らかの手段が必要です。ただし、どのようなアプローチを取るかは関係ありません。1人の参加者がメッセージを他の参加者に送る場合、送信側は、メッセージがすぐに戻ってくる(論理的にも、物理的にも)ことを前提とせずに処理を続行します。
• 場所: 参加者が、通信先の参加者のアドレスを照会するような状況において、その場所を変更するために、通信パターンの再プログラム、再構成、または再始動を必要としません。これは、サービスエンドポイントのアドレスを保管するディレクトリやアドレスを使用する検索プロセスのようなものを意味します。
•  型: プログラミング言語において静的と動的、あるいは厳密な型指定とそうでない型指定という対立する概念が存在するのと同じように、参加者は、処理を実行するためにドキュメント構造の全体に依存することも、一部のみに依存することもできます。
• バージョン: 参加者は、サービスインターフェースの特定のバージョンに依存する場合と、ある程度の変更に耐えられる場合とがあります。バージョンの一致が厳密に求められるほど、この次元においては疎結合でないということになります。ポステルの法則(source)に従うことをお勧めします。でつまり、サービス提供者は、可能な限り多数のバージョンに対応できるよう実装し、対応の可、不可について不公平が生じないように(できれば、エラートレランスも)します。一方、サービスの利用者は可能な限り正確な文法およびドキュメント型に従うようにします。これにより、システム全体の安定性および柔軟性が向上します。
• 濃度: サービスの提供者と利用者の間には、1対1の関係が成立する場合があります。特に、要求と応答の対話が行われる場合、または明示的なメッセージキューが使用される場合はこのような関係が成立します。しかし、サービス利用者(この場合は“メッセージ送信者”または“イベントソース”と呼ぶ方が適切です)が、メッセージ受信者の数を認識、考慮しない場合もあります。
• 検索: サービスを呼び出す参加者は、通信するサービス提供者の(物理的または論理的な)名前に依存することもできますが、一連の能力の記述を使用して最初に検索操作を実行することもできます。これは、利用者の要求と提供者の能力とをマッチングさせることができる(直接的に、または非直接的に)、登録およびリポジトリを意味します。
• インターフェース: 参加者は、サービス固有のインターフェースに従う必要がある場合と、汎用インターフェースをサポートする場合とがあります。汎用インターフェースが使用される場合は、その汎用インターフェースを利用するすべての参加者が、それを提供するすべての参加者と対話できます。これは、一見、扱いにくいように思えますが、単一の汎用(統一)インターフェースという原則は、WWWアーキテクチャのコアとなっています。
  

ここに挙げたすべての次元において疎結合であるシステムを作成することは、必ずしも現実的ではありません。また、そのようなシステムが望ましいというわけでもありません。サービスの種類に応じて、トレードオフが必要になります。疎結合の次元についてさらに詳しく知りたい方は、Carlos Perez　による優れた説明を参照してください。リンク先はこちら(source)かこちら(source)です。

8. 標準への準拠

SOAアプローチを取るときに中心的概念となるのは、独自のAPIや形式への信頼ではなく、標準への信頼です。標準は、データ形式、メタデータ、トランスポートおよびトランスファーのプロトコルなどの技術的部分にも、ドキュメントの型などのビジネスレベルの生成物(たとえばUBL(サイト･英語)内)にも存在します。

 標準が存在するということは、多くの場合において絶対的に明確であるように思えますが、EAIまたはメッセージングベンダによって提供されるような独自のソリューションがSOAの原則に従っているという主張もあります。この原則では、標準の重要性を重視します。つまり、多くが従っているものほど良いと考えます。もちろん、選択肢がたくさんある(source)ので、どれが適切かという議論はあります。どの標準においても最も重要なのは、それが受け入れられているかどうかという点です(つまり、普通に考えれば、Webサービスの場合、"開発者はマイクロソフトをリストに載せる必要がある"ということになります)。

9. ベンダへの非依存性

アーキテクチャの原則は、特定のベンダ製品に依存しないものとする必要があります。抽象概念から具体的な稼動システムを検討する際、商用ソフトウェアにせよ、無償のオープンソースソフトウェアにせよ、特定の製品を決定することは避けられません。どのような決定をしても、アーキテクチャレベルでは特に違いはありません。しかしこの決定では、合理的に可能であるかということ以外に、相互運用性および移植性の両方の標準への依存度が高いかという点を重視します。
このような判断を行うことにより、サービスの提供者や利用者を、ベンダのロードマップに制限されることなく、適切な標準をサポートする何らかのテクノロジを使用して構築することが可能になります。

10. メタデータドリブン

SOA全体においてメタデータとして生成されたものは、設計時および実行時のいずれにおいても検出、取得、および解釈できるように保管される必要があります。この生成物の中には、サービスインターフェースの記述、参加者、エンドポイントとバインディング情報、組織単位と責任、ドキュメントの型やスキーマ、および利用者と提供者の関係などが含まれます。これらの生成物の使用については、可能な限り、コードの生成または解釈が自動化される必要があります。また、サービスおよび参加者のライフサイクルの一部となる必要があります。

これで、私の紹介する原則はすべてです。これらの原則に完全には賛成できないという方もいらっしゃるでしょうが、少なくとも、すべてについて反対というわけではないだろうと思っています。これらの原則から、より活発な議論が行われることを期待しています。


Stefan Tilkov(ブログ・英語) は、InfoQのSOA編集者です。また、ドイツおよびスイスにオフィスを構えるコンサルタント会社innoQ(サイト･英語)の共同創設者であり主任コンサルタントでもあります。

原文はこちらです：http://www.infoq.com/articles/tilkov-10-soa-principles
（このArticleは2007年2月17日に原文が掲載されました）