arclamp.jp アークランプ

　SOA自体、特に難しい概念ではありません。しかし、どうしてもややこしくなるのがサービスという概念です。栗原さんの書かれた「本当は単純な「SOA」という考え方」では、

実際には、SOAの考え方は極めて単純である。ソフトウェアを「サービス」という部品の集まりとして構築しようというだけのことなのだ。

サービスとは「複数のアプリケーションをまたがって共用され得るソフトウェア部品である」と言える。

サービスはビジネスプロセスの一部（サブプロセス）を表現していることが多い。

このことから、SOAとBPMの相性は極めて良いということが言える。SOAにより、ビジネスプロセス（を実装するソフトウェア）を部品化し、BPMでそれを組み合わせ、ワークフロー管理することで自由度の高い業務システムを構築することができる。＜中略＞「ビジネスコンポーネント指向ソフトウェア構築手法」とでも言えば、SOAをより適切に表現できるかもしれない。

と書かれています。

　SOAがサービス（コンポーネント化された処理）とプロセスマネージメント（その呼び出し手順）によって構成される、というのは良いのです。しかし、それがどんな粒度で行なわれるのかというのが難しい。
　あまり細かい粒度になると、組み合わせが複雑になりすぎ構築できなくなります。逆に粗すぎると汎用的過ぎてニーズが拾いきれずに構築できなくなります。

　特に前者の「複雑すぎて構築できない」というのが、現状でSIerがSOAに取り組んだ場合に問題なる点だと思います。BPELについては良いウワサを聞きませんが、大抵が「複雑な状況（IF、AND、例外）においてBPELが使えない」という話だったりします。ま、逆に言えば、あまり複雑な状況ではBPELが向いていないということなのでしょうが。

　では、どうするべきか。僕はサービスの階層化を進めればよいと思っています。

　現実の世界を考えると非常に簡単です。商品販売をサービスとして提供する会社は、別の会社から商品供給をサービスされています。さらにその会社は、別の会社から原材料を供給するサービスを受けている。しかも、それぞれの会社では、同じ会社から文房具を供給するサービスを受けていることもあるでしょう。
　それぞれのサービスは、単体で利益を上げられるモデルになっています。なお、全体を1社でまかなうモデルだと、効率は上げられますが柔軟性が失われます。これもSOAに通じる考え方です。

　この場合、注意すべきはサービスの"複雑さ"です。サービスというのはその利用者のリテラシーや利用方法によって規定されています。ですからリテラシーが低い、あるいは利用方法が悪いとサービスが複雑に見えてしまいます。
　特定の商品を購入するのに100項目の指定が必要でも、利用者のリテラシーが十分で、利用方法が合理的であれば、なんの問題もありません。そうでない場合に不幸が起きる。

　サービスの定義があいまになりがちなのは、その利用者と利用方法が明確でないからに過ぎないと感じています。

　これをSOAに重ね合わせれば「SOAは、その利用者ごとに、サービス（コンポーネント化された処理）とプロセスマネージメント（その呼び出し手順）によって構成されたものが、階層化、組み合わせたもの」と考えればよいことになります。
　なにか1つ、あるいは2つの方法で、すべてを統合することはありません。

　僕は、すごく単純にサービスというのはインターフェース指向であること、つまり、なんらかの方法でインターフェースが定義され、処理が隠蔽化されていれば良いと考えています。そう考えると、実はクラス1個だってSOA的に処理を行なっていることになります。

　例えば、Javaプログラマにとっては数十個のクラスで構成されたものであれば良い。その数十個のクラスは1つのモジュール（サービス）として他のプログラマからは見えることでしょう。
　一方、情報システム部門の人にとっては、複数のモジュールを組み合わせたものが、グラフィカルなインターフェースでにおける1個のアイコンになるわけです。
　
　ちなみに（ｗ、スクリプト言語というのは、この階層化された世界において、XMLとJavaコードの真ん中、つまりパワーユーザやエンドユーザーエンジニア向けのDSLとして大いに可能性があるわけです。例えば、BEPL仕様のスクリプト言語というのがあればよい気がしています。XMLで表現するBPELは難しいものですが、スクリプト言語であれば、可能性が広がるのではないでしょうか。

　サービスの定義は、それを利用する人にとって違うという当たり前の事実をちゃんと考えるべきです。階層化は技術の問題ではなくアーキテクチャや概念の問題です。
　プログラマも含めて、システム内の利用者を階層化し、そこを利用者のモデル像を明確にした上でサービスを考える。そして、その階層を上下に動かしながら矛盾のないように考えていく必要があります。もちろん、まだまだノウハウが存在しない領域ですが、少しづつパターンもでてくるのではないでしょうか。
　

　世界はフラット化されたと言われていますが、僕はなんとなく"階層化された"という印象を持っています。