Mule 2.0のリリース告知(source)からおよそ2週間後、「軽量で非常にスケーラブルなESB」、Mule(source)の創設者であるRoss Masonは、JBI(Java Business Integration)(source)とMuleのアーキテクチャを、どのように比較するかについて論じた(source)。
Rossは、JBIを実装する代わりに、彼自身のアーキテクチャに取り組ませた、JBI 1.0仕様に不足している、いくつかの点について述べた。彼が懸念する点の中で、もっとも注目すべき項目は、とてもXMLに依存すること、JBIアーキテクチャ(バインディングコンポーネント、サービスエンジン)の再利用性の欠如、重厚なAPIのセットだ。
Ross Mason(source)は、JBIの広範なスコープが、JBIアーキテクチャの再利用性を低減する、理由の一つだと考えている。:
それらの性質によってベンダーは、競争のために彼ら自身を差別化する必要があります。JBIはすべてがどのように動作すべきかを定義しようとするので、ベンダーは彼らのサービスコンテナを差別化するために、仕様を超えた機能や次善策を組み込む必要があります。これは再利用のストーリーを壊すので、もし私が一つのコンテナでJBIバインディングコンポーネントを利用しても、それが別のコンテナで同じ方法で動作することを意味しません。
JBIコミュニティ内部の各ベンダーは、ベンダーがいつもやるように、その他の競争相手から彼らの製品を差別化しようとするが、パフォーマンス、信頼性および業界全体の標準サポートのレベルについては、より良いアーティファクトを実装しようとするだろう。JBI 1.0は、統合要求に対する答えを提供しようとする最初の試みで、確かに、JBI 2.0(source)で取り組まれると考えられていた、いくつかの欠点がある。
Rossはまた、JBIの重厚なAPIと、JBIアーティファクトを開発するために開発者が持っていなければならない、JBI仕様に関する必要以上の知識について、懸念を述べた。
あなたはサービスを実装するために、とても重厚なAPIを実装しなければなりません。ssary. これはあなたのサービスを書くために、JBIに関して必要以上に理解しなければならないという意味です。Muleはサービスが、POJO、EJBセッションビーンあるいは別のコンポーネントへのプロキシなど、どんなオブジェクトでもよいと常に信じてきました…
Accenture(サイト・英語)のシニアコンサルタントであるJames Lorenzen(source)は、JBIの重厚なAPIに関するRossの見解に対して、以下のように答えた。:
私は、JBIユーザがJBIについて必要以上に知らなければならないという意見には賛成できません。しかしながら、私もまたコンポーネント開発者なので、その個人を演じるのは難しいでしょう…
そして、
さらに私は、仕様を一気に飛ばして、どのようにJBIを利用できるかのデモンストレーションを行いますが、それでも、非JBIユーザに、JBIについて教えるのに苦労したことはありません。
Rossのブログの投稿で、もう一つの重要な点は、NMR(Normalized Message Router)(サイト・英語):
XMLメッセージはデータをあちこち移動するために利用されるでしょう。これはいくつかのシステムについては真実ですが、それらを構築するときにXMLが存在しなかった、ほとんどのレガシーシステムでは、COBOLコピーブック、CSV、バイナリレコード、カスタムフラットファイルなど、さまざまなメッセージタイプを利用します。
James Lorenzenは、このXML中心の性質による、NMRのメリットについて説明する。
すべてはNMRを通るためにXMLにコンバートされるので、そのために必要な変換はXMLだけです。あなたの話は真実ですが、それはJBIユーザにとって問題ではないと思います。逆に、もしNMRがその他のメッセージタイプを許可したなら、さらなる変換機能が必要になるでしょう。しかし私は、JBIにおける変換機能は、バインディングコンポーネントだと思います。
バインディングコンポーネントは、別のコンポーネントによってNMRにインジェクションされた情報を、それぞれのバインディングコンポーネントに送ることができるようにするため、よく知られていて、よく記述された形式で、NMRと簡単に相互作用できなければならない。そうでなければ、バインディングコンポーネントの間のコミュニケーションを持続させるのは、とても複雑になるだろう。
Ross Masonは、オープンソースに勝利をもたらす問題空間に対するベンダー視点について、彼の関心を述べた。
この世界の「ベンダー視点」は、オープンソースがうまくやってこれた主な理由の一つです。伝統的にオープンソースは、取り組まれる問題により近い開発者によって書かれてきました。それらの開発者はドメインの知識、経験、より良くするのに必要な何かを利用して、問題を解決するより良い方法を提供することができます。これはMuleとプロジェクトの成功における最終的なゴールで、そのゴールは(私たちの続けていることが)常に改善できるという警告によって実現されると信じています。
各ベンダーが実装する新しい標準を開発するため、仕様の策定に参加する異なるベンダーのコミュニティリーダーによって、仕様は開発されると主張する人がいるかもしれない。通常この「専門家グループ」を形成するグループは、開発者コミュニティから来るので、問題のドメインに取り組むJSRと非標準のオープンソース製品の間に、深い相違があってはならない。
Ross MasonとJames Lorenzenのどちらも、NMRやJBIアーティファクトの間でストリーミングコンテンツを扱うにはJBI仕様は不足しており、特にNMRに入るものはなんでもXMLにコンバートされるので、リソースを消費する処理になるだろうと主張する。
原文はこちらです：