疎結合と XML

» Permanent link | |

疎結合(loosely-coupled)って何でしょう?

僕自身、適当に疎結合という言葉を使ってしまいがちですが、 ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。 いいかげんな定義で話をはじめると、 各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。 ということで今回は僕なりに疎結合ってこんなもの、 というのを考えてみます。

ものすごく一般化してしまうと、 疎結合というのは複数のコンポーネント間の結び付きが ゆるいことを指すんでしょうね。 たぶん、ここまでは誰でも同意してくれるはず。 ただこれだけでは議論ができなくて、 このコンポーネントに何をもってくるかを決めて、 はじめて具体的な話ができます。

僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、 コンポーネントは Web サービスになります。 コンポーネントがオブジェクトだとかもっと細かいレベルの話もあると思いますけど、 ここではしません。

あ、Web サービスという言葉も危いですね。 ここでは Web 上で機械(プログラム)可読なフォーマットで情報を提供するもの、 だとします(実際、僕の Web サース感はこれに近い)。 SOAP インターフェースの株価サービスかもしれないし、 AtomAPI のはてなブックマークかもしれない。 RSS フィードも含みます。

ところで、この「疎結合」をもろに扱った本があります。 タイトルがずばり「疎結合」です。 SOAP よりの Web サービスの文脈での疎結合を扱っている本です。 この本は10章で疎結合とは何かを解説しているんですが、 そこにはこんなことが書いてあります。

(前略) 多くの人々が「疎結合」という言葉を口にしますが、 その意味を正確に説明できる人はほとんどいません。 これは、疎結合が方法論もしくは作法であり、 確立された規則や仕様ではないからです。

疎結合は、俊敏性(アジリティ)、すなわち変化に適応する能力を重要視する 分散アプリケーション設計へのアプローチの一種です。 (後略)

つまり疎結合というのは分散アプリケーションの作り方、 設計の仕方に関する考え方のひとつであり、 特に決った規則や仕様はないってことです。 これは逆の意味でしっくりきました(僕には)。 これだけ曖昧な定義なら、議論の方向性が定まらないのも仕方ないですね。

僕が今考える疎結合システムのイメージはこんな感じです。

まず、サービス(コンポーネント)間のインターフェースは統一し、 半永久的に変更しません。 サービスのインターフェースに少しでも修正が入ると、 旧インターフェースを利用していたクライアントを修正しなければならないからです。

インターフェースを統一して不変にしたときに、 ではいったいどこでサービス同士の機能を差別化するのか。 それはサービス間でやり取りするデータで行います。 データ形式を思いっきり自由に拡張可能にして、 どんな種類のデータでも統一インターフェースで受け渡し可能にします。 オブジェクトだとこの拡張性が厳しいのですが、 XML と名前空間の組み合わせならぜんぜん問題ありません(ちょっと言い過ぎか)。

XML が拡張可能ということは、自分が知らない要素や属性が出てくる可能性があるということです。 でも、そんな拡張された未知のデータでもエラーにせずに、使えなければなりません。 そのために、知らない要素は無視する、という動作をデフォルトで行わなければならないのです。 SOAP の mustUnderstand 属性がデフォルトで false なのは、こういう理由からではないかと思います、たぶん。

で、このデフォルトで無視という動作は、 吉松さんがこのポストで言っている 「無邪気なまでにデータの読み手に解釈をゆだねる姿勢」 のデータの読み手側の一番簡単な実践なんだと思うのです。 本当はさらに吉松さんのポストのコメントで萩原正義さん(らしき人)が言っている「semantics を重視した…」 というのも直感的にわかりそうなのだけれど、今の僕には残念ながら理解しきれません。 だからとりあえず、 XPath なりで知ってる要素と属性をパターンマッチして知らないやつは無視、からやってみるしかないんだな、 というなんだか当たり前の結論になっちゃったなあ。