ニーズに合ったESBを選ぶには

原文(投稿日：2013/04/02)へのリンク

異なるアプリケーション間の通信に関するニーズは，企業の中にも，企業間にも存在します。ESB (Enterprise Service Bus/エンタープライズ・サービス・バス) は，そのようなアプリケーション統合をサポートするツールとして生まれました。では，ESBとは何なのでしょう？ どんな時にインテグレーション・スイートより便利なのでしょうか？ プロジェクトに一番適しているのはどの製品なのでしょう？ 今回の記事では，なぜ万能策が存在しないのか，ESBが必ずしも最善解ではないのはなぜか，という点について説明したいと思います。プロジェクトの成功のためには，適切な製品の選択が不可欠なのです。

"エンタープライズ・サービス・バス" の定義

"エンタープライズ・サービス・バス" という名前は，さまざまなベンダの多数の製品に含まれています。残念なことに，この用語には標準的な定義がありません。そのため，これらの製品が提供する機能もまちまちです。ですからESBという用語を使う前に，その定義を明確にしておく必要があります。以降ではESBを，開発者のアプリケーション統合を支援するとともに，それに必要なルーティング，変換，その他の統合機能のインフラストラクチャを提供するソフトウェア製品，と定義することにします。統合作業の複雑なパスにおいてESBは，以下の図のようにアプリケーションの代替としてフレームワークとスイートの中間に位置する，と考えるのが一般的です。

図１：アプリケーションによる統合を代替
用語としてのESBが定義されたので，次の章では，どのような場合にESBを検討するべきか，あるいはインテグレーション・フレームワークやインテグレーション・スイートがより適しているのはどのような場合か，という点について説明します。

インテグレーション・フレームワーク

インテグレーション・フレームワークとは，SplitterやContent Based Routerなどのエンタープライズ統合パターン (EIP/Enterprise Intergration Patterns, http://www.eaipatterns.com) の実装を支援することで，標準的手法によるアプリケーション統合を実現するフレームワークです。製品の統合手段に標準的なAPIを用いて実装作業を大きく削減すると同時に，ソースコードを他の開発者が理解するのも容易になります。フレームワークは，異なるプロトコルとテクノロジを採用したアプリケーション同士の統合に適した方法です。統合ロジックとして，エンドポイントやプロデューサ，コンシューマ，EIPなどのコンセプトが用いられます。暗黙的にですがサポートされている自動テストについても，同様のコンセプトが使用されています。
フレームワークは通常のライブラリのセットで構成されています。そのためにどのような開発環境にも，たとえ旧式のテキストエディタを使っているようなものであっても，よく調和します。
代表的なフレームワークとしては，Java環境 ではApache Camel や Spring Integration，.NET用の NServiceBus などがあります。
フレームワークを使用する場合，開発チームは多かれ少なかれ，プロジェクトの成否に自ら責任を負うことになります。商用サポートは提供されないのが普通ですし，ツールの提供も限定的な上，必ずしも "ミッションクリティカル" な提供に適したものばかりではありません。ですので，この記事の以降の章では，ESBと対応するスイートを中心に取り上げることにします。多くの場合，こちらの方がフレームワークよりもよい選択肢と言えます。

エンタープライズ・サービス・バス

フレームワークと同じように，ESBもアプリケーションの統合に使用します。ESBは暗黙的にフレームワークをベースにしていますが，それよりもはるかに強力なプロダクトです。フレームワークとは違ってESBでは，アプリケーション統合に関する基本機能に加えて，アプリケーションの展開や管理，実行時のモニタリングをサポートする高機能ツールが提供されるからです。さらに，さまざまな統合シナリオの実装には，グラフィカルなエディタが使用されます。統合ロジックのモデル作成を "ドラッグ・アンド・ドロップ" で行うことも可能で，対応するソースコードが自動生成されます。ESBのパッケージには，商用サポートも完備しています。
純粋にフレームワークだけを使うのに比較して，ESBを導入した場合の大きなアドバンテージは，ツールが優れている点です。統合に関する問題を，高い抽象化レベルで解決することができるのです。

インテグレーション・スイート

ESBのすべての機能を提供するスイートです。加えて，BPM(Business Process Management)やBAM(Business Activity Monitoring)，MDM(Master Data Management)，レポジトリなど，多数の機能も備えています。単なるアプリケーション統合以外にこれらの機能が必要であるなら，全体をひとつのソフトウェアスタックで実現することのできるスイートの導入は，推奨に値する選択肢です。
ここまでの説明で，フレームワークとESB，そしてスイートの違いが理解して頂けたかと思います。では次に，適切なESBないしスイートを選ぶ方法について説明しましょう。

比較の基準

ご注意：この記事では，入手可能なすべての製品を比較するようなマトリックスを提供していません。記事を書く立場で言うならば，あまりにも多くの (しかも異なる) 機能やコンセプトを持った製品を比較して，適切かつ有用なマトリックスを作成するのはほとんど不可能です。しかもITの世界では，機能のリストは毎日のように変更されるのです。
ですからここでは，あらかじめ自身のニーズを定義した上で，どの製品がもっとも適しているかを評価する方法をお勧めします。プロプライエタリなソリューションはどれも似通っていますし，ユーザ数の多いオープンソースの競合製品も同じような特徴を持っているものです。ですからまずは，プロプライエタリな製品とオープンソースソリューションのどちらが適当かを考えるというのが，理にかなった方法でしょう。
この決定を行うためには，以下の基準を使用することが必要です。

• ユーザビリティ：インストールはどれくらい複雑か？ ツールはいくつ必要か？開発環境は直感的なものか？
• 保守性： 製品の管理方法はどのようなものか？ 監視サービス用のGUIはあるか？
• コミュニティ： 活発なフォーラムやメーリングリストは存在するか？ 公開されている関連記事やチュートリアル，ビデオなどの数は多いか？ サポート企業は複数あるか？
• ビジネスサポート： どのようなオプションが提供されているか ("ビジネス時間内" か "終日" ホットラインか，Eメールかオンサイトサポートか，など)？ 必要とするSLA(Service Level Agreement)が保証されているか？ サポートは希望の言語で提供されているか？
• 機能性： 必要な機能がすべて揃っているか？
• 柔軟性： 製品の機能はニーズに合わせてカスタマイズ可能か？
• 拡張性： 製品の拡張は可能か？製品とそのインターフェースは標準に基づいているか？
• コネクタ： 必要なテクノロジ用のアダプタがすべて用意されているか？ SAPやSalesforceなど，B2B製品用のアダプタはあるか？アダプタの開発はどの程度容易か？
• コスト： 製品のトータルコスト (総所有コスト) – メンテナンス，付加製品，コネクタなどを含む – はどの程度か？
• ライセンス： どのようなライセンス，あるいはサブスクリプションモデルが使用されているか？ 要件が変更された場合 (コンピュータ追加，CPU増設，仮想マシンへの変更など) はどうなるのか？ アップグレードは無償か？ダウングレードも可能か？ コストはすべて"予測可能"か，価格リストは明快か？

表１はプロプライエタリ製品とオープンソースのESBおよびスイートを，利点と欠点について比較したものです (緑 = 良好，黄 = 普通，赤 = 不良)。相違点の結論としては，全般的にプロプライエタリソリューションの方が機能が多く，サポートも "強力" である，と言えます。ただし "本当にそれが必要なのか" という点が疑問として残ります。機能が多ければ，必要な労力や複雑さ，コストもそれ相応に高くなることを忘れてはいけません。オープンソース製品がユーザビリティのよさ，柔軟性の高さ，拡張の容易さ，コストの低さなどで得点を上げているのとは対照的です。

表１：プロプライエタリ製品とオープンソース製品の利点と欠点

代替製品

プロプライエタリ製品とオープンソース製品の違いを説明しましたので，次には特定の製品をいくつか紹介しましょう。このように入手可能な代替製品の概要をいくつも見ておくことで，多少なりとも製品選択のための見識が得られると思います。
IBMやOracleなど，プロプライエタリな統合製品を提供するベンダのほとんどが，およそ考え得るすべての機能に対してソリューションを提供しています。オープンソース系の代替製品に関しては，Unified Platform of TalendとWSO2 Platformを特に上げたいと思います。この２製品は完全なスイートを提供しているからです。その他に，ESBのみに集中した製品もいくつかあります。そのようなオープンソース製品の中で，もっとも注目すべきなのはMule ESBとFuse ESBの２つということになるでしょう。

Oracle Service Bus / Fusion Middleware

Oracle Service Bus はOracleが現在提供しているESBです。Oracle Fusion Middleware (OFM) スタックのコンポーネントのひとつで，今回の記事の定義ではインテグレーション・スイートに分類されます。その他にもSOA Suite, Coherence, Complex Event Processing, BPEL Process Manager, Enterprise Messaging Service, Service Registryなど，たくさんの製品が提供されています。
Oracleのスイートが提供していない機能は，おそらくほとんどないのではないでしょうか。ツール類は非常に多機能かつ安定していますし，ほとんどの製品にグラフィカルなエディタが用意されています。さらに，考えられるほとんどすべてのSLA (Service Level Agreement) をサポートしています。これほどの機能とSLAが本当に必要であれば，Oracleは最適な選択肢になるでしょう。当然ですが，機能の豊富さは価格となって表れています。さらに製品の持つ複雑さについても軽視することはできません。同時にライセンス料金とサポートコストの高さ，さらに不明確な価格モデルにも注意を払うべきでしょう。
OFMはJava EEやBPEL，SOAP，SCAなどの標準規格に準拠しています。製品はすべてプロプライエタリで，これまでOracleが実施してきたいくつもの買収の結果と言えるものです。そのためコードベースがそれぞれ違いますし，製品毎に異なるツールが必要なことも少なくありません。ダウンロードの合計は20GBを優に超えています。インストール作業はかなり煩雑で，ラップトップ用の単純なインストールでさえ，場合によっては数日を要します。かなり重い部類に入る製品で，実行時に必要なリソース規模も非常に大きいものがあります。
ちなみに "Oracle" を "IBM" に，"Fusion Middleware" を "WebSphere" に置き換えてみても， ESBポートフォリオ上にあるのがMessage Broker, ESB, DataPower SOA Appliance という３製品になることを例外とすれば，この章の内容はほとんど変わらないでしょう。さらにTibcoやMicrosoft，SAPなどといった企業も，プロプライエタリなESBおよびインテグレーション・スイートの市場では重要な役割を担っています。
この章の結論として言えるのは，プロプライエタリなインテグレーション・スイートが考え得るほぼすべての機能を提供し，ほとんどのSLAをカバーしている，ということです。ただしこれらの機能やSLAの大部分は，大部分のプロジェクトには必要のないものです。そうであれば，オープンソースの代替製品も評価してみるべきでしょう。最も重要なものについては，次の章で説明します。

Mule ESB

Mule ESB は最初に成功したオープンソースESBです。先に挙げた他のオープンソースESBと同様の資質を数多く備えていて，どれにも非常に簡単な（"ワンクリック")インストーラと，直感的な操作が可能なEclipseベースのツーリングが付属しています。一般的にオープンソースESBは，とても軽量で拡張性のあるソリューションです。 無償のオープンソース版と有償のエンタープライズ版があり，有償版では追加機能や製品サポートが提供されます。
事情を知らない方のために，""オープンソース" は "無償" という意味ではないことを説明する必要があるでしょう。オープンソースソフトウェアのベンダも資金が必要です。無償で製品を開発したり，サポートを提供するわけには行きません。ただしその価格はずっとカスタマフレンドリで，プロプライエタリ製品のように不明瞭な価格リストに基づくものではありませんし，オープンソース版ならば (業務用途でも) ライセンス費用も必要ありません。ただしオープンソース版は試用あるいはコンセプトの評価用であることも多く，その場合は後に機能追加とサポートのあるエンタープライズ版にアップデートすることを前提としています。
その名前が示すように，Mule ESBは純粋なESBです。Apache CamelやSpring Integrationなどのフレームワークと比較した場合のメリットとしては，インテグレーションシナリオの効果的な実装を可能にするグラフィカルなエディタや，SAPあるいはSalesforceなどのB2B製品用のコネクタが提供されていることがあります。しかしMule ESBには，スイートとしての機能が欠けています。そのようなユースケースに対しては，他ベンダの製品と組み合わせる必要があります。Mule ESBの欠点としては，コミュニティが小さいこと，ライセンスモデルが限定的なこと，ソースコードの利用に制限があることなどが挙げられます。この面では，他製品の方にメリットがあります。

Fuse ESB

Fuse ESB もMule ESBと同じく，スイートを持たない純粋なESB製品です。統合環境としては，Apache CXFやApache Camelといったデファクト標準に基づいています。その意味では，当初からすばらしいコミュニティが保証されていると言えるでしょう。開発環境はEclipseベースのもので，非常に直感的な操作が可能です。

Fuse ESBはもともとFuseSourceの一部でした。しかしFuseSourceが Red Hat に買収された結果，現在は同社のJBoss部門に属しています。現時点のロードマップにFuse ESBも含まれているので，今後もサポートは継続すると思われます。同じく買収されたBPMソリューションのPolymitaと同じように，将来的はJBoss Enterprise SOA Platformに統合されると予想されます。ただしスイートとして統合されるには，まだかなりの時間が必要でしょう。FuseSourceとPolymitaの 統合 にもまだ数ヶ月を要する上，JBoss ESB, Switchyard, そしてこのFuse ESBという３つのESB製品をひとつに統合する必要があるからです。その点では，他のオープンソースベンダがすでによい結果を出しています。

Talend ESB / 統合プラットフォーム

Talend ESB はTalendスイートの一部ですが，独立したコンポーネントとしても，あるいはTalend統合プラットフォームの他のコンポーネントと組み合わせても使用することができます。コンポーネントはすべてオープンソースで，無償利用が可能です。付加機能とサポートを備えたエンタープライズ版も提供されています。プロプライエタリ製品との違いは，すべてのコンポーネントが同一のコードベースに基づいていること，ひとつのツーリングをすべての場所で利用可能なことです。ESBやBPM，ETL，MDMといった異なる領域にも柔軟に対応しています。しかもこれらは，それぞれ独立した統合プロジェクトなのではありません。
Talendスイートのツールはすべて，Eclipseをベースにしています。なじみのある "ルック・アンド・フィール" や，Eclipseの直感的な操作性はそのままです。また，すべての部分でビジュアルデザイナを提供すると同時に，"ゼロ・コーディング" アプローチを採用することにより，統合シナリオの効率的な実装を実現しています。もちろん，プロジェクト特有の統合ロジックをJavaクラス (POJO) やその他のスクリプト言語で記述することも可能です。
Fuse ESBと同じくTalend ESBも，Apache Camel, Apache CXF, Apache Karaf, Apache Zookeeperといった統合環境のデファクト標準に基づいています。Apache Camelが備えているJMS, HTTP, FTPなどのテクノロジ用のコネクタに加えて，AlfrescoやJasper, SAP, Salesforce, あるいはホストシステム用のB2Bアダプタも用意されています。500以上のコネクタがデフォルトですべて含まれています。ただしその影響のひとつとして，他社製品に比較してIDEのハードウェア要件が高くなっています。性能の低いラップトップへのインストールは避けた方がよいでしょう。もうひとつの欠点は，SOAガバナンス機能が不足している点で，これは次期リリースに予定されています。

WSO2 ESB / プラットフォーム

WSO2 はあまり知られていないベンダですが，BPS (Business Process Server)，BRS (Business Rules Server)，BAM (Business Activity Monitor)，さらにはガバナンスレジストリなども含むスイートのコンポーネント全般を提供しています。WSO2プラットフォーム全体のインストールは非常に簡単です。Eclipseベースの軽量な開発環境も提供されています。TalendやFuseSourceと同様にWSO2も，Apache Synapse (軽量なESB) やAxis (Webサービスの実装)，ODE (ビジネスプロセスエンジン) といった主要なオープンソースプロジェクトをコンポーネントとして含んでいます。
Talendを除けば，WSO2は，単一のコードベースと開発環境をベースとして完全なスイートを提供する唯一のベンダです。したがって，ごく小さな機能から着手して，その後ステップ・バイ・ステップで機能を追加するという，反復型の開発プロセスを行うのにも何ら障害はありません。欠点はグラフィカルなツールです。プラットフォームのすべてのコンポーネントをサポートしていますが，競合製品のツーリングと比較すると直感的な操作性に欠けています。

“Do it yourself” 統合スイート(?)

結論の前に： フレームワークや製品を組み合わせて独自の統合スイートを構築する方法は，たいていは必要以上に費用が掛かる上，それ特有のリスクも多々あります。いくつかのソリューションがすでに存在するのですから，わざわざ部品を集めてあらたに作り上げるようなことは推奨できません。"グルーコード" を書いて，テストして，バグフィックスを行う必要がありますし，問題が起きても問合せをする場所もないのです。例えば別のベンダのESBとBPMソリューションを組み合わせたとします。問題が発生したら，どちらに問合せますか？ ベンダはおそらく，他方に聞くように言うでしょう。ですから結局，他に同じような問題への対処例があるか，スタック全体 (これもオープンソース) がすでに利用可能かなど，自分自身で対処しなければならないのです。

結論

統合の問題を解決する万能策 (銀の弾丸) はありません。まず最初に，フレームワークで十分かどうかを決める必要があります。フレームワークでは，ソースコードの大部分を自分で開発しなければならないこと，十分なツールやサポートが期待できないことに注意が必要です。それを望まないのであれば，ESBの方がよい選択です。ただし，スイートの付加機能がいずれ必要になるのであれば，最初から統合スイートのESBを使用するのもよいでしょう。そうすることで，複数の製品を組み合わせることによる新たな問題や追加費用を心配することなく，継続性を確保することができます。

ESBあるいは統合スイートを使用する必要がある場合には，プロプライエタリ製品とオープンソース製品のどちらかを選択しなければなりません。プロプライエタリ製品にはあらゆる機能があり，サポートも充実していますが， その分コストが高く，複雑なものになります。対照的にオープンソースソリューションは，低コストで使い易く，柔軟性があります。 この問題が解決したら，それぞれの製品を詳細に評価するための比較リストを作成します。最終的な決断を下す前には，コンセプトの実証を行うことを強く推奨します。コンサルタントやベンダではなく，チーム自身の手でプロトタイプ (最初のインストールから最終的な配置，監視まで) を行うことが大切です。将来的にコンサルティングが期待できない状況になれば，チーム自身で製品のインストールや統合上の問題解決を行わなければなりません。

著者について

Kai Wähner はTalendの主席コンサルタントで，JavaEE，SOA，クラウドコンピューティング，BPM，ビッグデータ，エンタープライズアーキテクチャ管理などを専門としています。Eメール (kontakt@kai-waehner.de) や Twitter (@KaiWaehner)，SNS (LinkedIn / Xing) で感想をお寄せください。