SOAにおける疎結合の定義

作者 Dilip Krishnan , 翻訳者 編集部 投稿日 2008年6月22日

セクション

設計/アーキテクチャ,

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

トピック

SOA ,

Webサービス ,

設計 ,

Loose Coupling

SOAにとって凝集性が重要かどうかという議論(参考記事)で、Carlos Perez氏がソフトウェア構造での結合について(source)また、SOAとの関連でそれがどのように展開してきたのかについて見解を述べた。まずBertrand Meyer氏(source)によるモジュール性の原理から始め、独自のサービス指向の原理へと展開する。

はじめにCarlos氏はBertrand Meyer氏のモジュール性の原理を引用して、以下のように述べている。

1. モジュールの分解しやすさ - ソフトウェア問題を複雑性が少ない問題に分解するという作業を支援し、その問題は単純な構造で結びつけられ、また各項目でその後の作業が単独で実行できる のに十分独立していれば、ソフトウェア構造メソッドはモジュールの分解しやすさを満たす。
2. モジュールの組み合わせやすさ - ソフトウェアエレメントを支持し、場合によっては、もともと開発された環境とは全く違う環境で相互に自由に結合され、新しいシステムを構築すれば、モジュールの組み合わせやすさを満たす。
3. モジュールの分かりやすさ - 他を知る必要なしに(最悪でもいくつかのみを調べる必要によって)人間による読み出しが各モジュールを理解することができるようなソフトウェアの製造を支援すれば、モジュールの分かりやすさを満たす。
4. モジュールの持続性 - 問題の仕様で小さな変化をもたらすソフトウェアアーキテクチャが、1つのモジュールもしくは少数のモジュールにおける変化の要因となれば、モジュールの持続性を満たす。
5. モジュールの保護 - モジュールで実行時に異常が発生した影響がそのモジュールに限定されたままであり、また最悪な場合、近くにあるモジュールに伝播するアーキテクチャを作成すれば、モジュールの保護を満たす。

それからThomas Erl氏、Don Box氏(source)、Stefan Tilkov氏(ブログ・英語)およびDavid Orchard氏(source)といったソートリーダーによって表されているように、サービス指向の教義を考察し批評している。

... (Thomas Erl氏の原理)は、極端な原理である。というのも問題を重複しているからである。

... [David Orchard氏(source)]のリストは、バランスが取れているのだが、WS-* インクルードには疑問を抱かずにはいられない。

サービスの独自の定義(source)に基づき、サービス指向の原理を以下のとおりにまとめた。

1. 分解しやすさ - ソフトウェア問題を複雑性が少ない問題に分解するという作業を支援し、その問題は単純な構造で結びつけられ、また各項目でその後の作業が実行できるのに十分独立していれば、分解しやすさを満たす。
2. 組み合わせやすさ - ソフトウェアエレメントを支持し、場合によっては、もともと開発された環境とは全く違う環境で相互に自由に結合され、新しいシステムを構築すれば、組み合わせやすさを満たす。
3. 分かりやすさ - 他を知る必要なしに(最悪でもいくつかのみを調べる必要によって)人間による読み出しが各モジュールを理解することができるようなソフトウェアの製造を支援すれば、分かりやすさを満たす。
4. 持続性 - 問題の仕様で小さな変化をもたらすソフトウェアアーキテクチャが、1つのモジュールもしくは少数のモジュールにおける変化の要因となれば、持続性を満たす。
5. 保護 - モジュールで実行時に異常が発生した影響がそのモジュールに限定されたままであり、また最悪な場合、近くにあるモジュールに伝播するアーキテクチャを作成すれば、保護を満たす。
6. イントロスペクション - モジュールやコミュニケーションの構造が実行時に照会され、検討されるようにするメカニズムをサポートするアーキテクチャを作成すれば、イントロスペクションを満たす。
7. リモータビリティ - 別の物理的環境でホストされるその他のモジュールによるモジュール通信を可能にするメカニズムをサポートするアーキテクチャを作成すれば、リモータビリティを満たす。 
8. 非同期性 - モジュール起動から迅速な応答を見込んでいないアーキテクチャを作成すれば、非同期性を満たす。つまり、ネットワークか起動済みモジュールに待ち時間が発生することを想定している。
9. ドキュメントの指向性 - 内部モジュールからモジュールへのメッセージ通信が明確に定義され、共有され、起動間で暗黙状態がないアーキテクチャを作成すれば、ドキュメントの指向性を満たす。
10. 標準プロトコルエンべロープ² - モジュール通信全体で共通のエンベロープメッセージフォーマットの共有を要求するアーキテクチャを作成すれば、 標準プロトコルエンべロープを満たす。
11. 非集中管理 - すべてのモジュールに対して単一の管理を要求しないアーキテクチャを作成すれば、非集中管理を満たす。

それから「「疎結合」(ブログ・英語)という用語を包含するすべてのもの。そこから上記の特性の多くを引き出すことが可能である。要約すると、SOAは疎結合のAPIにすぎない」という捨て台詞で締めくくった。

どう思うか?Bertrand Meyer氏(source)によるソフトウェア品質(source)の原理が、サービス指向との関連でどのくらいあてはまるのか?必ず、Carlos Perez氏のオリジナルの投稿(ブログ・英語)を参照すること。

原文はこちらです：     http://www.infoq.com/news/2008/06/loose-coupling-soa

• 次へ >