Skip to content
2009/05/04 / highmt

SOAについての自分なりのまとめ

自分のSOAについての理解についてのメモ。
(メモなんだから理解が間違っててもいいよね的な免罪符としての「メモ。」
じゃあちゃんと調べてから書けばいいのにと思わなくもない。)

  • 「アーキテクチャ」とは「構成要素および構成要素間の関係を決めるものであり、
    システムの機能を個々の構成要素に割り振っているもの」
  • ではSOAの構成要素とは何か?
    まともな説明は、「サービス」であって「プログラムが他のプログラムの要求に応える
    何らかの活動」とかとても抽象的な説明になるが、これはとてもわかりにくい。
    要するに「サブシステム」のこと。
    (だんだんと従来のサブシステムという概念では捉えられないようなものになっていくが
    本質はこれ。)
  • つまり、SOAは、「サブシステム分割(あるいは再分割)についての考え方のひとつ。」 
  • SOAがサブシステム分割をする目的はなにか?
    システムを長期的、段階的かつ迅速に刷新可能とすること。
  • そのためにSOAがサブシステム分割に用いる手法はどんなものがあるか?
    いち。疎結合。これもいろんな説明がなされているが、さまざまな概念が含まれているかのように
    説明されるのでわかりにくい。
    本質は「データの所有者であるサブシステムがデータを維持するために持っているロジックを
    バイパスして直接データにアクセスしないようにすること。」
    やりとりに使うテクノロジ/インフラが疎か密かみたいな説明がよくされるが、
    本質はそこではないはず。
    他からコントロールできる度合いを減らそうとした結果、そのようなテクノロジ/インフラが
    必要になる、ということだと思う。
    に。階層構造。たとえば、フロントエンドとコアなロジックをわけて、機能を共有する。
    サブシステム間で相互に密接なやりとりがあるとき、中間層を設けて複雑なやりとりをカプセル化し、
    この中間層で各サブシステムへのアクセスをトラップする。
    さん。メタ。やりとりを仕様によって決める。特定の実装をやりとりの規則としない。
    その他もろもろ。
  • この結果、サブシステムは「他から利用できるもの」になり、システムのビルディングブロックとして
    利用できるようになる。
    サブシステムは「サービス」となる。
  • システムを上記のようなサービスで構成していくと、
    サービスは、サブシステムという概念では捉えられないようなものになってくる。
    階層構造に分解されることで粒度は小さくなっており、
    また、データオーナシップというよりは役割によって凝集したものになる。
    疎結合の概念は、サービスがカプセル化している内容に直接アクセスしないこと、と言い直される。

たとえばもともと一枚岩のシステムの各サブシステムを上記のように構成することを想像すると、
なんだか、とても難しそう、という感じがしてくる。
難しいことの本質は、サービス間のやりとりにある。

  • テクノロジ/インフラ的なこと。
    たとえば、DBのテーブルを介して直接的にやりとりしていたようなシステムでは、
    いったいどうすればいいのか見当もつかないだろうと思う。
  • 開発プロセス的なこと。
    ひとまず、サービス間のやりとりについて技術的な見当がついたとして、
    どうやってやりとりのインタフェースを定義していけばよいのだろう。
  • 設計的なこと。
    やりとりの物理的なしくみがわかって、
    やりとりのインタフェースをどのように定義すればよいかがわかったとして、
    実際に、システムをサービスに分解する、ということをやらなければならない。
    今までだってサブシステム間のやりとりはあった。
    だけどそれはシステムの流れの中に直接織り込まれたものだった。
    これをどこで切るのか。粒度が大きいだけにオブジェクト指向よりもっと敷居が高いはず。
  • 組織的なこと。
    いろんな調整をしないとやりとりは決められない。
  • 設計とテクノロジの統合的なこと。
    DBのトランザクションのような小さな単位でシステムの整合性を守る手法は、
    粒度の大きなやりとりでは通用しなくなるなど、
    設計を実際のシステムに落としこむのにノウハウが必要になる。

上記のようなことをやろうとすれば、一枚岩でつくるより、コストが大きくなりそうな感じはある。
これは、「システムを長期的、段階的かつ迅速に刷新可能とすること」というSOAの目的とのトレードオフと
なるかもしれないし、あるいは杞憂かもしれない。

  • 技術的な敷居は高そう。
  • インフラ的にも投資が必要そう。
  • 工数は増えるか?問題領域が分解されるのだから個々の設計部分は減ってもおかしくない気はする。
    (というか減らないとSOAの目的と合致しない。)
    でも、分解とやりとりの仕様化には時間がかかりそう。
  • ある程度利便性を犠牲にする?
    疎結合の結果、リアルタイム性など木目細かな制御が失われる場面もあるかも。

とここまで書いておいて、WebでのSOAについての記事を読むと、
上のような見方は技術的なことに注目しすぎているっぽい。
「そもそもビジネス的な視点で導入するものだよ」
というものらしい。

そりゃビジネスのためにやるのだからビジネス側がやる気にならないとなかなか導入は進まないだろうけど。
で、実際導入はあまり進んでいないっぽい。
ジェフリー・ムーアは「まだキャズム超えてない」(http://enterprisezine.jp/article/detail/1350)といっている。

キャズムの先の人たちがやる気になるにはまだ技術的に未熟で実用性が見えにくいのかもしれない。
WebでのSOAについての記事は「SOAにメリットを感じるようなビジネスをやっているのなら
コストとか技術とか考える前にひとまずやってみたら」といった論調が多いような気がするけど、
キャズムの手前にいる人には響いてもキャズムの先にいる人は受け入れないだろうなと思う。

SOA勉強してみるかなぁ。

広告
%d人のブロガーが「いいね」をつけました。