そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

BPELを使う理由 その2

3つめの変化対応力について。
セールストークとしてよく言われているものとして、ビジネスは常に変化するので、システムをそのスピードで対応させるのは大変ですよね、BPELだと変化対応力が高いですよ、GUIでちょこっと変更できますよ、というもの。


これは、BPELでも呼び出すサービスを変えたり、順番を変更したりすることはそんなに簡単なものではないし、テストも必要です。
それに、他の言語でもちゃんと考えて作っていれば、BPELと同等の変化対応力はシステムに持たせることはできると思います。


でも、この「ちゃんと」というところがポイントなのかも知れません。BPELという作り方が制限されたものを使うことで、何も考えなくても(?)、「ある程度」変化に対応できやすい。
これはJavaで作るときにフレームワークを使うことで、だれが作ってもある程度の品質を確保するのと同じことだと思います。


さて4つめ、BPELによる開発は生産性はあがるのでしょうか。適用するところによって、Yesであり、Noであると思います。

ある程度の数のサービスをまとめてコンポジットサービスを作る。これがBPELの一番簡単で効果もあるところじゃないでしょうか。ところが、「それってJavaでもできるよね」と言われるとおり、本来プログラム言語で実装したほうがいいところまで、BPELでできてしまいます。

レイヤー分けされていないドでかいサービスをBPELで実装していったり、呼び出すサービスの数が何十個になってくると、プロセスは見づらいし、ましてデータベースのトランザクションまでBPELで意識しながら実装するとなると、、、職人さんじゃないと実装も変更もできなくなります。

じゃなくって、やっぱりバックの実装がどうとか意識せずにサービスとサービスを連携させるところをBPELにやらせて、機能の実装はサービス側にまかせましょうよ、と思います。