【第2回】BPELを用いた業務プロセスの接続とその導入効果

システム間を連携させる方法論として注目を集めるSOA 。ビジネス機能を再利用（共有）可能な「サービス」に切り分け、必要なコンポーネント（ソフトウェア部品）をラッピングすることにより、システム間を連携する。そんなSOAの実装方法として注目されているのが、業界標準であるWebサービスとBPELの組み合わせだ。標準化されたWebサービスを用いてインターフェースを作成し、BPELでビジネスプロセスのオーケストレーション（サービスを呼出す順序付けや紐付け）を記述する。今回はBPELによるビジネスプロセスのオーケストレーションと実行について解説するとともに、先進的な海外の事例も紹介する。

システム連携とSOA

　まずはWebサービスとBPELの組み合わせの有効性を語る前に、前回の復習を兼ねながら、SOAが注目されている背景を見ていくことにしよう。SOAが現在求められている背景には、全社最適を実現したいという企業の要求が存在する。数年前までのエンタープライズシステムに対する要件は、一貫して業務効率の向上にフォーカスしており、組織内の業務ごとにシステムが最適化されていった経緯がある。システムが業務ごとに個別に最適化していった結果として、業務を連携（アプリケーションの連携）させるのには適さないものになってしまい、組織全体でのビジネスプロセスの効率化が困難になってしまったのだ。

　では、アプリケーションの連携あるいはシステム統合を実現するためには、どのような選択肢があるのか。そこには3つの選択肢が存在し、1つがカスタム開発、2つめが伝統的なEAI（Enterprise Application Integration）、3つめがSOAとなる。

　カスタム開発は、異なるシステム間を接続するためのインターフェースやデータ変換プログラムを開発するやり方である。接続したいシステム数が多いと開発工数も増えるし、複数システムを相互に接続させるとなると非常に複雑なプログラムになる。一方、伝統的なEAIを用いる方法もあるが、ここであくまで「伝統的」と付けているのは、最近のEAIツールはSOAを採り入れているためだ。伝統的なEAIは、異種システムを統合したがEAIベンダ固有の技術が使われており、ベンダ依存度は高くなる傾向にある。しかもハイエンドなソリューションであるため非常に高価である点もネックとなっているのだ。

接続性のWebサービスとプロセスのBPEL

　そうした課題を踏まえて、注目されているのが第三の選択肢であるSOAだ。SOAは柔軟にアプリケーションを連携させる方法論として脚光を浴びている。SOAの実装手法として期待されるのが、業界標準の接続性を提供するWebサービスと、プロセスを定義する業界標準の言語BPEL（Business Process Execution Language for Web Services）だ。

　Webサービスは、トランスポートに一般的なHTTP、メッセージ・プロトコルにSOAP（Simple Object Access Protocol）を用い、XML Messageによるサービスの呼び出し機能を使ってサービス同士を連携する。サービスのインターフェースをWSDL（Web Services Description Language）で記述しておくことで、サービスがどのように実装（ビジネスロジックの実装方法の違い）されているかを意識する必要がない。Webサービスでは、実装に関して細かい部分を意識する必要がなく、「疎結合」と言われている。

　WebサービスはSOAを実現するための接続性を提供するが、そこよりも重要となるのがビジネスプロセスだ。SOAでは、業務を遂行するのにシステムが必要とされる機能を再利用可能な「サービス」に切り分ける。サービスの大きさを「粒度」と呼び、一般に「発注する」「在庫を確認する」といった程度のビジネス単位を実装できる粒度が適しているとされる。

　そして、SOAでは「発注する」「在庫を確認する」「決済する」といったサービスの組み合わせや組み換えによって、様々なビジネスに必要な機能を構築する。また、業務上のビジネス規則もサービス内部から分離させてルールエンジン上に定義し、サービスと同様に、プロセスフローから呼び出す形で利用するようにできる。こうすることで、サービスとビジネスルールとプロセスフローを分離させて管理でき、プロセスフローの追加や改善をサービスと離れたところで柔軟に行えるようになる。このプロセスフローの定義に欠かせないものがBPELである。