« バグという言葉について | トップページ | 小さなサービスの組み合わせというSOAの発想は失敗する運命にある、のかも »

2006/10/04

SOAに関する諸々の誤解・混乱 #3

「ESBでシステム間インターフェースの問題は簡単に解決する」というノリに反対してみる。

暫く前に流行ったEAIと最近流行っているESBの違いは何か。実質的には何も違わない、というのがぼくの結論だ。BPMなどとの連携(特にBPMNなどの標準を使ったそれ)が違いとして挙げられるかも知れないが、VitriaはBPM的なところから出てきたし、他のベンダーもBPM製品を数年前からラインアップに加えているはずなので、とりあえず無視出来る。

さて、EAIとESBが違うとしたら、ESBではWebサービスが標準になった、つまり、
・システム間インターフェースの通信プロトコルがSOAPに統一され、
・インターフェースでやり取りされるファイル形式がXMLになった、
という点だけだろう。これらはいずれもEA4階層モデルのテクノロジー層に属するものだ。そのようなテクノロジー層に属するものが標準化されても、アプリケーション層やデータ層でやらなければならないことは全く変わらないのは論ずるまでもない。
…で終わってしまてもつまらないので、これらの標準化によってテクノロジー層にもたらされる恩恵がどの程度のものか、またそれがアプリケーション層やデータ層に本当にインパクトが無いのか、言い換えると、テクノロジー層での恩恵は他の層へも派生しないのか、若干論じてみる。

まず、通信プロトコルについて。
SOAPを採用すれば特定のミドルウェアベンダーにロックインされることなく、どのようなアプリケーション同士でも容易にインターフェース出来る、とされるが、これは本当だろうか。インターフェースの口を何らかの形で開発する必要があるのは、SOAPだろうが他の通信プロトコルだろうが変わることはない。特定のプロプライエタリな通信プロトコルに基づき口を作った場合、別の通信プロトコルに変更しなければならない場合には、当然再度口を開発することになる。プロプライエタリなプロトコルを採用した場合の余計なリスクあるいはコストはそれだけである。プロトコルではなく、例えばインターフェースするデータを変更する場合、標準プロトコルだろうがプロプライエタリなプロトコルだろうが、データを処理する部分を再度開発しなければならない。通信プロトコルの変更とインターフェースデータの変更と、どちらが頻度が高いだろうか? プロトコルの変更などはそう滅多に起こるものではないだろう。したがって、EAIパッケージとESBパッケージそれぞれの製品コストが同じようなものであった場合、システム間インターフェースの開発・運用に関わるライフサイクルコストは、EAIとESBでそれほど大差が無い。そうであれば、特定のベンダーにロックインされても別に構わないはずだ。但し乗り換えをいつか行うとすると、当然それに関わる工数が追加で掛かるが、そもそもその点も勘案したアーキテクチャー採用戦略を取るべき、つまり、或る特定の通信ミドルウェア環境を何年間使うのかちゃんと計画しその期間内でコストが回収出来るようにするべきである、というだけの話だろう。これはESBを採用する際にも妥当する。
もう一つ、SOAPのEAIなどに対する利点として、異なるインフラ(EAIなどのミドルウェア)を持つ企業間でのインターフェースが容易になる、という点が挙げられることがあるが、そもそもそのような企業間インターフェースはいわゆる業務システムの世界では稀であろう。あるとすると子会社や関連会社とのインターフェースであり、その場合インフラ環境も共通である蓋然性は高い。ついでに、企業間インターフェースの開発の際に一番工数が掛かるのはインターフェースの技術的な面でなく、セキュリティレベルの設定などの政治的な面での調整だろう。したがって、この場合もESBのEAIに対する利点はあまり大きくない。「稀」と書いたが業務システムに本当に必要な企業間インターフェースのプロトコルは昔から標準化の努力がされてきた。念のため書き添えておく。

次に、ファイル形式について。
固定長やCSVあるいはバイナリでなくXMLの標準フォーマットにすればインターフェース開発の工数が本当に減るか?
アプリケーションのライフサイクルと見た場合、インターフェース開発の工数は、そのアプリケーションと同時に他のアプリケーションとのインターフェースを開発する一次開発に関わるものと、その後何らかの理由によりインターフェースを改修あるいは追加や削除する二次開発に関わるものとに分類される。また、それぞれの開発作業には設計と実装という二つの作業が内実として存在する。設計は言うまでも無くITに関わるアプリケーション、データ、テクノロジーそれぞれの設計が必要だ。テクノロジーの設計については、基本的にテクニカルなアーキテクチャーの選択がなされた時点で終わっている。この場合、XMLを選ぶのか、他のファイル形式を選ぶのか、という作業と、選んだファイル形式の実装のためのアーキテクチャーを設計する(ツールなどを作ったり選定したりする)という作業だけで、これはどのファイル形式を選んでもあまり変わらない。したがって設計で考慮するべき変動要素はアプリケーションとデータの設計だろう。
まず、一次開発のためのアプリケーションとデータの設計に掛かる工数は同じであり、変わるはずがない。実装については、何らかの標準的なツールが出て来れば、全体的な工数は減るかもしれない。複数のプロジェクトあるいはアプリケーションで同じツールを使いその経験値が溜まれば、の話だ。しかし、CSVでそのようなファイル形式編集・管理ツールがあってもよかったはずだろう。Excelか何かで適当なフォーマットで設計情報を入れればそれに応じたプログラミング言語のコード等が生成されるようなツールをここではイメージしている。この点はしたがってXMLだろうと他のファイル形式だろうと同じ話だ。
では、二次開発についてはどうか。設計については、ひとえに一次開発の設計文書が残っているかどうかに掛かっている。実装については一次開発で述べたことと変わることは無い。実装で気を付けなければならないのは、動いているものをいじるのに当たって十分なテストを行うことだが、必要十分なテストを行うことが出来るかどうかはやはり一次開発時の設計文書あるいはそれに呼応するテスト文書に依存する。
強引にまとめると、ESBなりによって動いているコードをよりよく管理出来それを再利用する基盤が整ったとして、実際に再利用を行うためにはそのコードの成り立ちを説明する設計文書が必ず必要になる。またどのようなテストが行われたのかを明らかにするテスト文書も参照するべきだ。でないと再利用するものがどの程度まで動くことが保証されているかが分からないので、再利用など出来ない。現状では、そのような文書類が存在しないために、二次開発の工数が膨大になり、また二次開発の結果出来るコードはスパゲッティになる。これが三次四次と繰り返されていけばどのようになるか、想像が付くだろう。何が、何故、どのように動いているのか、誰も分からなくなる。
このような状況を出来させないために、XMLというファイル形式によるインターフェース開発に何が出来るのか? 何も出来ない。問題はインターフェースの物理的な形式、コードではないのだから。
このXMLについての節は何も知らないボンクラIS部員に向かって、XMLという標準フォーマットを使えばアプリケーション間の依存関係が無くなって、ESBでアプリケーション同士を自在につぎはぎ出来る、などと世迷言をよく吐いている(ボンクラとまでは言わないが)ちょっと不注意な上司に対する反論になっているのだが、彼の目に触れることは無いだろう。

以上、ESBだけではシステム間インターフェースの問題は何も解決しない、と言えることが証明出来たと思う。

|

« バグという言葉について | トップページ | 小さなサービスの組み合わせというSOAの発想は失敗する運命にある、のかも »

system engineering」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/3241/12033580

この記事へのトラックバック一覧です: SOAに関する諸々の誤解・混乱 #3:

« バグという言葉について | トップページ | 小さなサービスの組み合わせというSOAの発想は失敗する運命にある、のかも »