BPEL製品とEAI製品は違うのか？
BPEL製品とEAI製品で、それぞれの製品のベンダーが謳っているコンセプトのレイヤーが違っているというのはわかります。ただ、いざ業務アプリケーションの開発ベンダーの立場でそれらを活用することを考えると、本当にこれらって違うのか？ということが疑問に思えてきました。
とりあえず、それぞれの定義を引用すると、
BPEL （Business Process Execution Language for Web Services） - @IT情報マネジメント用語辞典
XMLベースのワークフロー記述言語。複数のWebサービスを連携させることで、複雑なプロセスフローを定義することができる。
企業内で使われている、複数の異種コンピュータ・システム同士を連携させ、データやプロセスを統合すること。あるいは、それを実現するための技術やソフトウェアの総称。
「システムの連携」という部分は共通していますが、BPELがビジネスプロセスのフローに焦点を当てているのに対して、EAIではデータに焦点を当てているといったところでしょうか。
この定義だけを見ると、確かにコンセプトのレイヤーは異なっているのですが、システム連携というものについて少し掘り下げて考えてみたいと思います。
技術的にどういう手段をとるにせよ、システム連携においては以下の3つのレイヤーを考える必要があります。
１．ビジネスプロセスのフロー
２．データ（エンティティ）に着目したときの処理のフロー
３．項目レベルでのマッピング
簡単な例として、製品Aと製品Bで顧客情報を連携する、という例を考えてみます。
１．ビジネスプロセスのフロー
製品Aで顧客情報を登録する→製品Bで顧客情報を登録する
２．データ（エンティティ）に着目したときの処理のフロー
製品AのデータベースのCUSTOMERテーブルにレコードが追加される
→追加されたレコードを抜き出す
→値の変換を行う
→製品BのデータベースのCOMPANYテーブルにレコードを登録する。
（※テーブル名は一例です）
３．項目レベルのマッピング
２の「値の変換を行う」の部分を、細かく定義していきます。
例えば、製品Aでは登録者を文字列で登録しているのを、製品Bでは社員マスタの社員コードを登録する、などです。
さてここで、BPEL製品のベンダーの売り文句だけを鵜呑みにすると、あたかも１だけやればシステム連携ができるようなことを謳っていますが、そんなことはありません。
確かに、各製品が適切なWebサービスのインターフェースを持っていれば、BPEL製品上での実装作業というのは1の部分だけで済みます。しかし、「適切なWebサービスのインターフェースを持っていれば」という前提が必要で、その「適切なWebサービスのインターフェース」を実装する際に、２と３の課題を解決（実装）する必要があるはずです。
そうすると、Webサービスのインターフェースを別途作るくらいなら直接DBで連携した方が楽なのではないか、という考えも出てきます。実際、BPEL製品と言いつつDBに直接接続するアダプタを持っていたりするので、現実にはDBに直接つなぐことが多いのでしょう。
で、DBに直接つなぐとなると、BPEL製品上でプロセスフローを描いても２のレベルのフロー図を描くことになり、３のマッピングをBPEL上で実装することになります。。。EAIツール使ってるのと同じですね（苦笑）。
逆に、EAIツールの方もWebサービスのアダプタを持っていたりするので、「適切なWebサービス」を実装してEAIツールでつなぐってこともできるはずです。
というわけで、BPEL製品とEAIツールって、業務アプリケーションのベンダーからすると変わらないんじゃないの？と思うわけです。
そうなると、価格が高くてハードウェアスペックも必要とするBPEL製品を使うシーンが思いあたりません。。。
あえてBPEL製品が使われる状況というのを無理やり考えてみると、ITコンサルタントなんかが担いで、ビジネスフローレベルでのコンサルティングを行いながらシステムに落としていくときに使うくらいかなと思います。ただこれも無理やりで、別にBPEL製品を使わなくたって、フローを描くだけのツールでフローを描いて、スクラッチ開発なりEAIツールなりでつないだっていい（その方が安い）はずです。
まあ、すでにBPELという言葉をほとんど聞かなくなってしまっているので今さらという感はありますが、最近になってちょっとBPEL製品に触れる機会があったので、考えをまとめてみました。
