InfoQは、Tijs RademakersとJos Dirksen両氏の著書“Open Source ESBs In Action”(参考記事)から見本として1章を公表していますが、オープンソースのESBを実世界のプロジェクトで使用した経験について、両氏にインタビューする機 会を得ました。
InfoQ：オープンソースのESBの現状を考えた場合、オープンソースのESBが商業ベースのESBに比肩するとお考えでしょうか。
Tijs Rademakers (TJ) 氏：私は商業ベース（クローズドソース）とオープンソースの両方のESBに携わるという恩恵にあずかってきました。Mule ESBを使用して印象に残ったことは、企業統合やサービス指向の複雑な作業がMule ESBによっていくらか容易になるということです。商業ベースのESBに携わるということは、巨額の前払いライセンス費用や大変なインストール手順がある ことを意味し、新しいIDEを習得したり、与えられたドキュメンテーションやアフターサービスのコンサルタントから学んだりしなければならないことを意味 します。こうした先に済ませなければならない費用や学習に対処すれば、WebSphereやTibco、 Sonicなど、有名どころのクローズドソースESBは、うまいこと働きます。オープンソースのESBの場合は、ESBをダウンロードするところから始 め、その10分後には、利用可能な見本をESBで実行しているでしょう。続いて、見本のコンフィギュレーション・ファイルを眺めてから、とても簡単に自分 の統合ソリューションを実装できるでしょう。カスタムの機能を1つ実装するということは、Javaクラスを書いて、Mule ESB Java APIを使って作業することを意味します。Java開発者なら、とても簡単に理解することができます。何もわからなくても、活動中の大きなコミュニティが メーリングリストに載っていて、質問することができます。
Jos Dirksen (JD)氏：中核をなすESBの機能を見た場合、オープンソース界を現在リードしている製品は、商業ベースのESBに間違いなく比肩すると思います。オー プンソースのESBはたとえば、ルーティング、変換、接続性のすべての面で多数の商業ベースのESBと同等ですし、あるいは上をいっている場合さえありま す。さらに、使いやすさの点でも、オープンソースのESBの方が多数の商業ベースのESBより優れていると思います。
TJ：少しびっくりするのは、オープンソースESBの機能が商業ベースのESBの機能に非常に似ていることです。もっと驚くのは、コンフィギュレーション の簡単な仕組みとクリーンなAPIのおかげで、開発者にとって統合ソリューションのコンフィギュレーションと開発がはるかに扱いやすくなっていることで す。商業ベースのESBでは、統合ソリューションをドラッグ＆ドロップして、クリックできるIDEが提供されることが多いですが（これはとても上手く機能 しますが）、ドラッグ＆ドロップでサポートされていないものを実装しようとすると、非常に大変な作業になる可能性があります。ですから要するに、自分の所 属する組織のESBを選ぶときには、オープンソースのESBを本気で考慮に入れるべきです。
InfoQ：SOAにおけるESBの役割についてどうお考えですか。ESBを中心的に据え、焦点を当てるべきでしょうか。それとも端の方へ置いておくべきでしょうか。
JD：シナリオによりけりです。あらゆるSOAアーキテクチャの中核にESBを置くべきと耳にすることが多いでしょうが、実は私はそのようには思いませ ん。すでに最新式の（例：Webサービス指向の）アーキテクチャがあるなら、ESBの導入が常に必要というわけではありません。そのシナリオにレジストリ を導入したら、非常に優れていて、洗練されたサービス指向アーキテクチャを作れます。異種環境（たとえば、レガシーが多い、.netをjavaやメインフ レームと組み合わせる、など）の場合は、サービス指向的な方法でこうしたアプリケーションを公開するためには、よりいっそう「インテリジェントな」レイヤ が恐らく必要でしょう。そうしたシナリオでは、ESBをSOAの中心に置くべきと考えます。
TJ：SOAはもう終わったと宣言している人もいますので、そのリストにESBを入れるのは絶対に嫌です :-) SOAは、単なるレガシーシステムの統合やESBを介してのサービス提供よりはるかに大きなトピックと思っています。SOAにはビジネス的な目的と技術的 な目的があり、ESBの一番の目的は技術です。ですからESBは、SOAを実装するために利用できる、小さいけれども重要な部分です。ESBは、ルーティ ング、変換、セキュリティ、プロトコル翻訳といった機能性を提供する不可欠な部分であり、これによりサービスがお互いに通信でき、（BPEL）プロセスが サービスと通信できるのです。
InfoQ：オープンソースのSOAソリューションで、もっとも改良の余地があるのはどこでしょうか。最も足りないと思っていることは何ですか。
JD：最も足りないと思っているもの… 面白い質問ですね。個人的に最も足りないと思っているものは、真に優れた統合化ソリューションです。オープンソースを使ってSOAプロジェクトを実行する とき、通常はESBの他にも使用するものがあり、たとえばBPMエンジンなども必要です。現在、BPMエンジン、ルールエンジン、ESBの統合は、良く なってきているとはいえ、完ぺきではありません。ですから、こうしたコンポーネント間の統合コードを自ら書かねばならないことが多々あります。この分野で 大きな改善が可能と思います。
TJ：オープンソースのSOAプロジェクトの世界では実際、色々な取り組みが行われています。ESBプロジェクト（Mule、ServiceMix、Synapse、 Open ESBなど）、BPMプロジェクト（JBoss jBPM、Apache ODE、Open ESB BPELコンポーネントなど）、サービスレジストリ（Mule Galaxy、WSO2レジストリなど）、ビジネスルールエンジン（Drools/JBoss Rules）があります。ですから利用可能な素晴らしいSOAプロジェクトが多数存在します。けれども、こうしたコンポーネントを統合する点で改良の余地 はあると思います。商業ベースやクローズドソースのSOA製品は、完全な一揃えのSOAツールを提供するので、少しばかり先を行っています。しかしそこに は、ベンダーロックインという欠点も、もちろん存在します。
JD：オープンソースのESBでは、管理サポートとグラフィカルサポートの分野を改善できると思います。市場に出回っている商業ベースESBの管理サポー トは通常、オープンソースのものより優れていますし、開発環境のサポートツールの分野でも、オープンソースのESBは改良できるでしょう。しかし後者は、 パワーユーザーにとってはそれほど重要ではないでしょう。パワーユーザーは、グラフィカルツールの制限を超えたESBの深部にまで潜り込むでしょうから。 個人的には、統合化された優れたソリューションにより、BPM、ビジネスルール、優れたサービスリポジトリが提供されるところを見てみたいです。
InfoQ：非機能的な統計をケーススタディから教えていただくことはできますか。
TJ：難しい質問ですね。非機能的な統計は回収が困難なことが多く、ESB環境は確実に難しいです。しかし、JORAMをメッセージングエンジンとして利用し、Mule ESBで毎秒複数のメッセージを扱うプロジェクトを行いました。
JD：現在取り組んでいるプロジェクトでは、都市部の住民と地元当局の間の相互作用を処理しています。Muleベースのシステムで、80万人の市民が. netフロントエンドを通してバックエンドのサービスに通信しています。サービス間のすべての相互作用をMule上で行っています。Muleはさらに、古 いバックエンドのアプリケーションをWebサービスとして公開しています。
InfoQ：MuleESBとServiceMixを比較した場合、それぞれの長所と短所をどのように分類しますか。どちらをどのような場合に使ったらよいか、助言はありますか。
JD：どちらにも長所と短所があります。ServiceMixのモデルが気に入っていますが、新しい統合フローのホットデプロイが簡単にできますし、標準ベースであることも好きな点です。JBI標準にそれほど牽引力がないとしても、とてもすばらしいスペックであり、JBIを理解していればServiceMixを使った作業が非常に簡単になります。統合向けのプラガブルなコンポーネントが用意されている方法が気に入っていますし、そのコンポーネントをホットデプロイさえできることにも満足しています。Camelが含まれていることもServiceMixの大いなる強みです。統合フローの開発にDSLを使えるのが大変気に入っています。ServiceMixの 短所は、長所とほとんど直結しています。JBIスペックにより、難しさの度合いが一段階アップしますし、XMLの重視が、統合時に遭遇する要件と常にぴっ たり合うわけではありません。他方Muleでは、統合フローの作成がとても簡単で、非常に単刀直入です。用意されているルーターが広範囲にわたり、拡張が 簡単で、難しい設定をせずに、接続性やルーティング、変換のオプションがすぐに多数利用できます。Muleを使えば、かなり複雑な統合フローをほんの短時 間で作成、実行できます。しかし、Muleにも短所はあります。それほどたくさんあるわけではありませんが、私個人にとっての最大の短所は、新しい統合フ ローをホットデプロイできないという事実です。もしMuleがOSGiを統合したなら、あるいは統合を簡単に更新する他の方法を統合したなら、それは大き なプラス要因になるでしょう。
TJ：ServiceMixは現在、ServiceMix 3.2.x/3.3.xとServiceMix 4の２つ異なるプロジェクトに分かれています。私たちが書いた本では（JBIベースの）ServiceMix 3.2.xを使っていますが、ServiceMix 4（OSGiベースで、JBIもサポート）にも少々馴染みがあります。そこでServiceMixとMule ESBの主な違いですが、ServiceMixがJBI ベースで、Mule ESBがJavaベースのカスタムモデルを実装します。しかし、この2つのESBには共通点もたくさんあります（Springのサポート、CXFを使った Webサービスのサポート、XMLコンフィギュレーション）。ここでは、相違点に焦点を絞ることにしましょう。
Mule ESBはJava中心のESBなので、Java開発者ならとても簡単に作業を開始できます。非常に強力なXMLのスキーマセットが用意されているので、実 にクリーンで読みやすいXMLコンフィギュレーションを作成でき、コードコンプリーション・サポートも提供します。変換ロジックやルーティングロジックを 実装したいとき、単純なJavaクラスやSpring bean、スクリプトファイルを簡単に作成し、それをXMLコンフィギュレーションに入れることができます。Muleの短所を1つ挙げなければならないと したら、ホットデプロイがサポートされていないことでしょう。
ServiceMixはJBI 中心のESBで、JMSやWebサービス、Camel、BPELなど、多数のJBIコンポーネントを提供します。そしてもちろん、PEtALSやOpen ESBのようなJBIベースの他のESBからも、JBIコンポーネントを使えますが、これについては本の中で説明しています。ServiceMixはそれぞれのJBIコンポーネントに対して簡単なXMLコンフィギュレーション言語を提供し、統合ソリューションをデプロイするためのホットデプロイの機能を提供します。ServiceMixの短所は、JBIに到達するまでの学習曲線です。ですから、何を一番好むかによって、MuleとServiceMixのどちらを選ぶかが決まります。ServiceMixはJBIのサポート、BPEL統合、XMLメッセージ重視、ホットデプロイの機能を提供します。MuleはJava中心のモデル、jBPMのサポート、メッセージ・アグノスティックの（メッセージに依存しない）サポートを提供しますが、ホットデプロイの機能はありません。
JD：どちらを使うかは、実際は要件に依存します。XML標準に焦点を合わせたランドスケープに統合するのであれば、ServiceMixがすばらしい選択肢です。より低レベルの統合が必要なら、Muleの方が良いかもしれません。両ESBとも、多数の統合問題にぴったりの、すばらしいオープンソース統合ソリューションです。
InfoQ：他の選択肢ではなく、ServiceMixとMuleを選んだ理由は何ですか。Apache SynapseやSpring Integrationついて御意見をお聞きしたいのですが。
TJ：ServiceMixとMule は非常に活発なコミュニティを有する、成熟したオープンソースESBのすばらしい見本であり、JBIに重点を置いたESBとJava中心のESB アプローチを象徴しています。Apache Synapseをメインとして、他の選択肢も考慮しました。ところで、Apache SynapseとSpring Integrationの両方とも、本には例を入れてあります。Apache SynapseはApache Axis2をベースにしており、Webサービス重視のESBとしてはすばらしい見本です。WS-*のサポートとRestのサポートを最重視している場合 は、Apache Synapseは必ず考慮に入れたいESBです。Spring Integrationは、Apache Camelに酷似した優れたフレームワークです。両方とも、HohpeとWoolfが説明しているエンタープライズ統合パターン（Enterprise Integration Patterns）をサポートしており、別の統合コンテナを必要とせずに、Javaアプリケーションに簡単に統合できます。ですから、こうしたフレーム ワークは、中枢にESBコンテナを導入せずとも、アプリケーションレベルに統合機能を実装できるようにする上で、非常に有用です。
JD：個人的にはSpring Integrationをこれまであまり使っておらず、現在、小規模プロジェクトで試用しています。これまでのところで気に入っているのは、非常に軽量な ソリューションのため、記述していたその他のSpringアプリケーションとの組み合わせが非常に簡単という点です。本を書き始めた当初、オープンソース ESBの世界は現在ほど成熟しておらず、今の方が成熟度の高いソリューションが存在します。
TJ：オープンソースESBの世界から目を離さないでください。なぜなら、活動が盛んで、プロジェクトも多く、活発なコミュニティもたくさんあって、よりどりみどりだからです！
InfoQ：ありがとうございました！
原文はこちらです：http://www.infoq.com/articles/ESB-Tijs-Rademakers-Jos-Dirksen