SOAにとって凝集性の考え方は必要か？

作者 Mark Little, 翻訳者 八角研究所 投稿日 2008年5月14日 午後12時30分

コミュニティ

SOA

トピック

Loose Coupling

タグ

Web services,

サービスデザイン,

Patterns and Practices

IONA社(サイト・英語)で働いていた2005年に、Steve Vinoski氏(source)はサービスの凝集度(PDF・英語)と結合度(source)についてのレポート(PDF・英語)を作成した。その中で彼は、長い時間をかけて「良い」ということが認められてきた三つの凝集の型について言及している。

• 機能的凝集型： モジュールが単一の振舞いをするような場合の型。結合性は低く、再利用性は高い。
• 逐次的凝集型： モジュールがいくつかのタスクを順番に実行するような場合の型。 
• 通信的凝集型： モジュールが同一のインプットを持つ、規定された順序性のない複数のオペレーションを実行するような場合の型。

次には、「悪い」とされる四つの凝集の型について言及している。

• 手続き的凝集型： 逐次的凝集に類似しているが、それぞれのタスクで使用されるデータが異なる。Steve氏曰く「このような凝集は（結合度を低くするための）人工的にグループ化されたアクティビティによってもたらされたものである 」。
• 時間的凝集型： モジュールのタスクが時間によってのみ関連づけられる場合の型。Steve氏曰く「このようなモジュールはそのモジュール内のタスクが異なるタイミングで実行される必要があるかどうかというメンテナンス性の問題を引き起こす 」。
• 論理的凝集型： モジュールのアクティビティが共通の実装を共有すると思われるという理由でグループ化される場合の型。
• 偶発的凝集型： モジュールのタスクが同じモジュールに属するという事実によってのみ関連づけられる場合の型。

そしてSteve氏は次のように続けている。

結合度と同じように、凝集度も分散型のオブジェクトやサービスを使用する場合に問題となってしまう。例えば、似たような実装を持つという理由だけで、オブジェクトに複数のメソッドをまとめようとすると、論理的凝集型オブジェクトを作り出してしまうという失敗を犯すことになってしまう。

レポートは次のように締めくくられている。

新しいコンピューティングスタイルへの変わり目の時期では、去りゆくスタイルに対するはっきりとした反対意見が伴う。そのため今日注目されているSOAが分散型オブジェクトに対してちょっとした反発を生み出しているということは驚くことではない。何が残念かというと、分散型オブジェクトシステムのための多くの品質基準が分散型サービスやSOAにも同じように良く適用するのに、流行りであるというせいでそのことが無視されがちであるということだ。しかし、たぶんそれは問題ではない。なぜなら我々はオブジェクトの存在しなかった時代を振り返ることができ、そこで凝集度や結合度と似たような基準を見つけ出すことができ、もう一度そういった基準を適用していくことができるのだから。.

Jim Webber氏(source)のアネミックサービスモデルという最近の投稿(source)があるまで、過去数年間このレポートに記載されたことはそんなに注目されていなかったかも知れない。良いソフトウェアエンジニアリングの実践についての歴史的な考察を飛ばして、Jim氏はSteve氏のレポートと類似した考えについて言及している。

いくつかのソフトウェアはデザインにおいて高い凝集度を持つ反面、結合度も密である。これは、論理的に設計されているにもかかわらず、相互依存度が高いために変更を加えることが難しいということを意味している。これはかなり酷い問題で、そして残念ながらエンタープライズアプリケーションでよく見られる問題でもある。数年前には良いと思われていたソフトウェアも、現在はそのメンテナンスに苦労させられていないだろうか？それは結合度が密であるということに起因しているのだ。

他の悪いソフトウェアの種類として凝集度の低い疎結合なソフトウェアがあげられる。これは、モジュール間の相互依存度は低いが、どのモジュールも必ずしもシステムのアスペクトという点で信頼できるというわけではない。このようなソフトウェアでは、小さな変更であっても複数のコンポーネントやシステムを越えて影響が広がってしまうし、現在進行中のシステムの進化に片っ端から手を加える結果に終わってしまう。そして、それは現在我々の知るところとなったSOAについてもいえることである。

どうやって最近のSOAの考え方がこのような性質に向き合っていくのか、さらなる説明が続く。

一方においては、SOA群の存在によって我々は勇気付けられ、このアーキテクチャが疎結合であるという理由から、目的にフィットするというように考えてしまう傾向にある。あらゆるコンポーネントやサービスも他のコンポーネントやサービスから分離しているので、無数に存在するレゴのようなスタイルで何度もそれらに対してアレンジを加えることが可能である。基礎的なサービスのセットから業務的なサービスを作り上げるということは、どれだけ本にその方法が記載されているかということにかかっている。我々はポイントアンドクリックな BPMツールを使用して非常に簡単に作業を行い、デベロッパやマネジメントの変化に起因するようなオーバーヘッドを除外できるのではないだろうか？

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

だが、それは間違いである。（略）これはアーキテクチャ的な幻想であって、現実世界のエンタープライズシステムには通用しない。業務的な問題を解決しないサービスは、SOAに存在しなくていい。

現在この投稿には多くの興味深いコメント(source)が寄せられている。しかしながら、これを発端とした本当のディベートは別の場所で、特にJJ氏のレスポンス(source)で、行われている。:

「何某指向アーキテクチャ」を用いて独力でSOAを倒そうと頑張っているのがJim Webber氏というMEST(source)な人物である。（略）彼の投稿は完全に間違っている。私が何かを見落としているのかも知れないが、Jim氏は凝集と疎結合の関係性について注目しているようだ。（略）私には凝集という言葉は「DSM」(サイト・英語)によく似た優れた工学原理のように聞こえる。（略）疎結合のゴールはまさに優れた工学原理としての凝集を軽減することにある。接続された外部のシステムでは凝集を実現することはできない。凝集を実現しつつ疎結合性を保つこともできない。英語においてでさえ、この二つの言葉を関連づけることはできない。

疎結合のゴールは、別の時期に別のテクノロジと別のセキュリティモデルを使って書かれたプログラムでも、互いに協調して動作させることにある。（略）。

SOAは再利用のためのシナリオを利用可能とする凝集的なシステムから分離されつつある。ネスト化された凝集的なシステムは「ネスト化された」（ライブラリスタイルの）再利用モデル、つまり上位のレイヤが下位のレイヤを再利用できるという再利用モデルを提供する。残念ながら、それは情報システムが構築されるべき方法とは異なる方法でシステムを作成することを私たちに強いる。凝集は問題であり、疎結合はソリューションなのである。Jim氏、人々が「ひとつのモジュールに機能をまとめて詰め込んだままにしておく」ことを望んでいると本当に考えているのか？

JJ氏は、凝集は良く知られたソフトウェア工学原理であるけれども、「モダンな」SOAでは意味を持たないものであると考えている。:

SOAに対する誤解を持った5年前の考え方で「SOA」を実現しようと頑張っている人々を見るとイライラする。（Jim氏は）2008年現在のSOAを表現していない、時代遅れな考え方を示している。

そして議論はSteve氏のオリジナルのレポートについても及ぶ(source)。:

凝集性に対する要求はサービスのインタフェースや実装の設計にまったく不要な制約を課し、これらの制約はサービスの再利用性や別のアセンブリでの利用可能性を実際に減らしてしまう。双方向のインタフェース、アセンブリ、編成された言語、拡張可能で意味的にアクセス可能なデータ構造を含むモダンな疎結合のコンセプトにそろそろ慣れても良いだろう。古いプログラミング技術は、このようなコンセプトをプログラミングモデルに含まないため、正確にデザインされている。

議論は続いていく。凝集性とSOAは根本的に相容れないものなのか？たとえば、SOAに関連させて凝集性について補填するためにソフトウェア工学の本(source)が書き直される必要性があるだろうか？もちろん凝集という考え方自体は悪くないが、もしかしたら、結合性にも度合があるように凝集性には度合があり(source)、その度合いがすべてに適合するのは難しいのかもしれない。

• 次へ >