ApacheCamelおよびその他のESB製品


81

ねえ、
Apache Camelがあるのなら、なぜApache ServiceMixやMuleのような他のソリューションを使うのですか?
これらの製品と比較して、Apache Camelでできないことはありますか?
Mule / ServiceMixをいつ使用し、Camelをいつ使用するか?

回答:


73

Apache Camelは、エンタープライズ統合パターン(EIP)を実装するライブラリです。SpringをIOCフレームワークとして使用できますが、Springに依存することすらないため、プラットフォームに完全に依存しません。それは「ただの」図書館です。したがって、単純なjvm、servlet、ejb、osgiなどの任意のJVM環境で実行できます。Muleのようなコンテナの利点(またはオーバーヘッド)はありません。私の意見では、この分野の関心の分離はより明確になっています。

Muleはさまざまな環境に組み込むこともできますが、MuleにはEIPライブラリをコンテナに結合することの長所と短所の両方があると思います。Muleをサーブレットまたはejb環境内にデプロイする場合、Muleコンテナのすべての手荷物を本当に運びたいですか?私はMuleの専門家ではありません。おそらく、比較的控えめな労力を費やして、冗長な機能の一部を一掃できると思います。(これはすべての場合に悪い機能ではないことに注意してください。別のコンテナー内に埋め込まれて実行している場合は冗長です。)

Apache ServiceMixは、Camelを使用してESBの基盤としてEIPを実装するOSGIコンテナーです。ServiceMixは歴史的にJBIにルーツを持っていましたが、JBIから離れ、OSGIコンテナーで最高のApache CXF、Camel、およびActiveMQを組み合わせた優れた階層化アーキテクチャ(IMO)に進化しました。ここでの主な価値は、実際にはServiceMixとそのJBIサポートではなく、基盤となるOSGIコンテナー標準です。Webサービス用のCXFやJMS用のActiveMQなどの実績のあるApacheトランスポートと組み合わせます。OSGIは、.NETの登場前にMicrosoftを悩ませていたのと同じタイプの「DLL」地獄に対処するコンテナを提供する成熟した標準です。.NETもOSGIも根本的な問題の本質的な複雑さを解決しませんが、少なくともそれらに対処する手段を提供します。OSGIには他の利点もありますが、製品選択の観点からは標準ベースのコンテナーが主要であり、Mule(および一般にJava)が対応していない本質的な機能は依存関係の管理です。

MuleとApacheコミュニティを比較する際に注意すべきいくつかの重要な点。Muleは、オープンソースライセンスであるにもかかわらず、私の意見ではオープンコミュニティではないという意味で、Redhatに似ています。誰でもApacheに参加できますが、MuleSoftはMuleコミュニティと最終ロードマップを所有しています。第二に、Muleコミュニティは間違いなくかなり活発ですが、Apacheコミュニティははるかに大きいと思います(そして当然のことながら、ゲーテッドコミュニティではないためです)。どちらのアプローチにも、プラスとマイナスの両方があります。Apacheアプローチの良い点の1つは、Camel、CXF、ActiveMQ、およびOSGIに基づくESBのベンダーが複数あることです。たとえば、Talendは、ServiceMix JBIの履歴がなくても、同じコアテクノロジーでESBを提供します。これには、Apacheコミュニティ内にプラスとマイナスの両方があります。しかし、本当のポイントは、ApacheとMuleの違いを強調することです。Muleコミュニティには複数のベンダーはありません。したがって、IMOはTalendやServiceMixのようなApache ESBであり、Muleのような閉じたコミュニティよりも広く、より包括的で、最終的には競争力のあるコミュニティです。

エドオスト


77

2016年になり、最初に質問されてから大きく変わったので、新しい視聴者のためにもう一度見てみたいと思います。

戦略的に言えば

  • Apache Camelはそのルーツに忠実であり続けており、重量級でも本格的なランタイムプラットフォームにも進化していません。用途が広くモジュール式で、以下を実行できます。

    1. あらゆる種類のJavaコンテナ(サーブレットコンテナ、アプリケーションサーバー、Spring Boot)に埋め込まれています。
    2. Javaプロセスとしてのスタンドアロン
    3. OSGi環境内Apache Karaf)。
  • 私がOpenHubから抽出したこの時点でのグラフに示されているように、Apache Camelは進化を続け、月ごとに牽引力と活動を獲得しています。ユーザーベースも増え続けています。

1か月あたりのApacheCamelコントリビューター

  • 2012年、Red Hatは、Apache Camel、ActiveMQ、ServiceMix、CXFの背後にある主要なプロモーターおよび開発者の1つであるFuseSourceを買収しました。現在、いくつかのコミッターとPMCメンバーが、ApacheCamelで作業するためにRedHatに採用されています。

  • Mule ESBは、製品の2つのバージョンを提供しています。コミュニティ(CPALライセンスの下で無料)とエンタープライズ(有料)です。彼らはコミュニティバージョンを次のように定義しています。

評価または実動前の使用に最適です。

=>本番環境で使用するために有料のエンタープライズサブスクリプションを取得する必要があることを意味します。

  • 実際、Mule ESB CommunityEditionは CPALライセンスのます。これは、まだこのバージョンを使用することにした場合、Muleは次のことを必要とすることを意味します。

    • 実行可能ファイルおよびソースコードまたはより大きな作業が起動または最初に実行されるたびに、エンドユーザーがそのような対象コードにアクセスするために使用するグラフィックユーザーインターフェイスに、ミュールソフトのアトリビューション情報が目立つように表示される必要があります(スプラッシュ画面での表示が含まれる場合があります)。 )、もしあれば。=>基本的に、Muleで構築したものはすべてMuleで実行されていることをアドバタイズする必要があります。

    • Mule ESBのデプロイメントがネットワーク経由でアクセスされる場合(統合プラットフォームであるため、常にアクセスされます!)、デプロイメントのソースをアクセス者が利用できるようにする必要もあります。

  • 他の誰かが上で述べたように、Apache Camelは完全にオープンなプロジェクトであり、コミュニティのためにコミュニティによって推進されています。すべてのソースコードは公開されており、プルリクエストを送信したり、コンポーネントを提供したり、フォーラムでヘルプや問い合わせを行ったりすることをお勧めします。逆に、Muleコミュニティはゲーテッドコミュニティです。

  • 最後だが大事なことは; おそらく最も重要な部分です。これが、GoogleトレンドがMuleESBとApacheCamelについて言っていることです。標準のクエリキーワードではなく、新しいセマンティックトピックの測定を使用して精度を高めていることに注意してください。そうすれば、動物(ラバ対キャメル)の人気ではなく、ソフトウェアの人気を測定できます!解釈:Muleは2007年から2011年にかけて大幅に減少傾向にあり、ApacheCamelは上昇傾向にありました。2011年以降、Muleは頭打ちになっていますが、ApacheCamelは順調に上昇を続けています。

グーグルトレンドのラバ対ラクダ

ApacheCamelの技術的進化

2010年9月25日、最初に質問したときからのApacheCamelの進化に関するいくつかの機能メトリックを提供したかっただけです。これは、その時点でのソースツリーでした

  • 当時、キャメルは88個のコンポーネントを持っていた、それが今でFacebookやTwitter、Salesforceの、との統合を含む、220個の部品があるのApacheのIgniteアパッチカサンドラ、AWS、Apacheのカフカ、MongoDBは、Apacheのスパークなど
  • 多くの、多くの技術的改善:非同期ルーティングエンジン、メッセージ履歴、サーキットブレーカーEIP、集約、分割、動的ルーティングなどのEIPに対する多くの多くの改善と機能強化。
  • エコシステムは今も含まれるように成長していHawtioを、監視および管理のためにfabric8など、展開のために
  • それ以来、新機能、改善、バグなどを含む5500以上のチケットが解決されました。
  • そして、はるかに!

最終メモ

どちらの製品も過去5、25年で大きく進化しました!ただし、ライセンスの違いと、MuleESBとApacheCamelのコミュニティの性質により、これらはもはや互いに比較可能ではないと思います。

Apache Camelは完全にオープンソース❤️ですが、Mule ESBコミュニティでは、ユーザーがMulesoftの属性を取得し、Muleを使用するソフトウェアのソースコードを公開する必要があります。Apacheソフトウェアライセンスはビジネスフレンドリーなライセンスです。帰属やその他の要件なしでCamelを自由に使用できます。ビールのように本当に無料

過去数年間のこの反省が新しい視聴者に役立つことを願っています!:)


免責事項:私はApacheCamelプロジェクトのコミッターおよびPMCメンバーです。


3
CamelとMuleの間のいくつかの追加のキー差別化要因(IMHO
Claus Ibsen

2
更新してくれたRaulに感謝します。私は最初にClausのブログを読んでコメントを付け、ここで質問をします。ApacheCamelの商用実装を、TalendやJBossFuseなどのランタイムとMuleのAnypointと比較したほうがよいと思いませんか?そうでなければ、前述のように、Camelはオープンソースであり、Muleはお金に関するものなので、製品の進化に影響を与える違いがすでにあります。
Souciance Eqdam Rashti 2016

1
問題は、製品ではなくプロジェクトを比較しているということです。事実、Muleはプロジェクトであると同時に製品でもあるため、分離することは不可能です。実際、公正なことは、Muleと(Apache Camel + JBoss Fuse + Talend ESB)を比較することです。これにより、Camelエコシステムのメトリックがさらに高くなります。しかし、私のデータによると、Camelユーザーの大部分はとにかくバニラのApache Camelユーザーであるため、分析をそれほどプッシュしたくありませんでした。それが理にかなっていることを願っています。
raulk 2016年

それは本当ですが、私が言いたいのは、Muleを使用し、エンタープライズエディションを使用し、ランタイム、開発、監視環境などが付属しているほとんどの企業です。基本的に完全なパッケージであるため、JBossまたはTalendを比較する方がおそらく合理的です。機能の比較によって機能をミューリングして実行します。オープン性とコミュニティへの貢献は重要ですが、統合レイヤーを選択する際の決定要因ではありません。
Souciance Eqdam Rashti 2016


5

Camelはメディエーションエンジンであり、Muleは軽量の統合プラットフォームです。違いは、Muleが、アプリケーション、REST、およびWebサービスをデプロイするためのコンテナーを含むESBのすべての機能を提供することです。MuleはCamelと同じ方法で埋め込むことができ、アプリケーション開発者はそこにアプリケーションコードと統合コードを埋め込むことができます。どちらもSpringと緊密に統合されています。

Muleは正当な理由でJBI使用せず、JBI仕様が解散されたため(元々JBI仕様を渡したOracleが所有するワーキンググループはありません)、JBIを使用する適切な専門的または技術的な理由はありません。


2
CamelはSpringとうまく連携しますが、Springと緊密に統合されていません。
ZenUML.comで鵬

4
キャメルはJBIを使用しておらず、使用したこともありません。
raulk 2016年


0

クロース、キャメルFAQには多くの間違いがありますが、当然のことながら、どれも私たちに有利ではありません:)

  • MuleのUMOモデルはMuleに含まれなくなりました。Mule 2でそのモデルから移行し始め、Mule 3で完全に変更されました。これで、非常に単純なメッセージプロセッサモデルができました。
  • Muleはここ数年明示的な型変換を行ってきましたが、これはCamelの差別化要因ではありません
  • Muleは、OSI承認のCPAL1.0ライセンスの下でライセンスされています。これはオープンソースライセンスであり、商用ライセンスではありません。これをできるだけ早く更新してください

FAQを更新して、Mule 1.x /2.xに基づいていると述べました。これは、ジェームズがFAQエントリを書いたときでした。
クラウスイプセン

0

まず、ServiceMixはApacheCamelコードを実行できるコンテナーのようなものであり、MuleESBはそれ自体が別個の製品であることを理解する必要があります。

ESB製品間で提供できる多くの違いがある可能性があります。

差別化を検討する前に、いくつかのことを知っておく必要があります。彼らです

  1. 製品の開発方法
  2. そのライセンス
  3. そのサポート機能
  4. オープンソースかどうか
  5. オープンソースがソースを変更して使用できるかどうかなど。

上記は、選択を行う前に調べる必要がある最良の要因になります。上記はほとんどの製品選択に一般的であり、ここでも特別な注意が必要です。

二次製品の違いは、ツールとそのドメインに固有です。これはおそらくあなたが探している答えです。選択する前に、内省する必要のあるリストを見つけてください。

  1. コミュニティサポート
  2. 製品スタック
  3. 独自のコードを変更するという点での拡張性
  4. 学習能力とユーザビリティ
  5. エンタープライズとして購入した場合の製品サポート

これはおそらく、違いを選択するために自分で行う必要がある調査です。市場で最高と言うのではなく、製品を組織に適したものにする多くの付加価値があります。

Apacheキャメルまたはその他のESBに関しては。違いは

  1. 輸送の数
  2. さまざまなDSLoverMuleなどを提供するApacheCamelは、Camelのように複数のDSLを備えていないということです。
  3. 製品スタックのMuleには、API管理と社内のクラウドコネクタが含まれていますが、FUSEESBを考慮した場合のApacheCamelはフレームワークであるため、JBossStackは選択を補完する可能性のある他の製品を大量に提供します。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.