BPELでシステム開発

日経SYSTEMSの最新号（2008年12月号）にBPELを使用したシステム開発事例が載っていました。

「事例に見る問題解決の軌跡：『BPELで業務アプリを開発 スキル底上げや性能向上に腐心』」（p.76）

UFJISさんが社内・グループ会社に展開するシステム開発でBPELを採用した事例です。記事を読む限りでは、BPMのためにBPELを使ったわけではなく、システム開発の手法としてBPELベースのモデリングと実装を取り入れたようです。それでも、最終的に画面数120の受発注アプリを開発したとのことですので、BPELを本格的に使用した先進事例として貴重な内容だと思います。

BPELの実行エンジンとモデリングツールは「Oracle BPEL Process Manager」と「JDeveloper」を使用したそうです。この記事を読んで参考になったのは、以下の３点です。

１．BPELを使用したプロジェクトの進め方について

初めから120画面のアプリを開発したわけではなく、約2年間の期間をかけて、開発基盤の整備、小規模アプリの開発、中規模アプリの開発という流れでプロジェクトを進めていったそうです。それぞれのフェーズにおいて、解決しなければいけない課題がいくつか見えてきたとのことですので、やはり大規模なシステム開発にいきなりBPMやBPELの手法を持ち込むのは非常にリスクが高いと思いました。

→ これまで慣れてきた開発手法や考え方を新しいやり方に置き換えていく必要があります。やはり、BPMのシステム開発では、スモールスタートから始めて、少しずつ開発のノウハウを蓄積していくことが望ましいと考えられます。

２．設計・モデリングのパターン化について

今回のシステムでは、画面をJSF、業務ロジックをWebサービスで実装したそうです。画面とロジックの連携部分も含め、確かにこのあたりの方式検討もしっかり行っておく必要があると思います。
また、BPELのモデリングを当初は開発者にすべて任せてしまったために、品質や性能のバラツキが発生してしまったとのことです。この問題に対しては、設計のベストプラクティスやBPELのサンプルソースを共有することで、対策を行ったということです。

→ 一般的なBPMプロジェクトでも、最終的にはBPMNをBPELに変換することになります。システムに落とし込むための最適なモデリング手法をパターン化して、開発者間で共有する必要があると思います。

３．BPELファイルの分割について

あるアプリに含まれるアクティビティ数が10万を超えていたため、BPMツールの制約により動かなかったそうです。この問題については、BPELソースを分割することで対応したそうです。

→ 使用するBPMツールの制約やメンテナンス性を考えた上で、適切なファイルの分割単位を検討しておく必要がありそうです。