82

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

4

7 に答える 7

78

今は 2016 年ですが、最初に質問されてから多くのことが変わったので、新しい視聴者のために再訪したいと思います。

戦略的に言えば

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

    1. あらゆる種類の Java コンテナ (サーブレット コンテナ、アプリケーション サーバー、Spring Boot) に組み込まれています。
    2. Java プロセスとしてスタンドアロン。
    3. OSGi 環境内( Apache Karaf )。

  • OpenHubから抽出したこの時点の下のグラフに示されているように、Apache Camel は進化を続け、月次ベースで牽引力と活動を獲得しています。ユーザーベースも増加し続けています。

1 か月あたりの Apache Camel コントリビューター数

  • 2012 年、 Red Hat は、Apache Camel、ActiveMQ、ServiceMix、および CXF の背後にある主要なプロモーターおよび開発者の 1 つであるFuseSource を買収しました。Red Hat は現在、何人かのコミッターと PMC メンバーを雇用して Apache Camel に取り組んでいます。

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

評価または生産前の使用に最適です。

=> 本番環境で使用するには、有料の Enterprise サブスクリプションを取得する必要があることを意味します。

  • 実際、Mule ESB Community Edition はCPAL ライセンスの下で配布されています。これは、このバージョンを引き続き使用することにした場合、Mule は次のことを要求することを意味します。

    • 実行可能コードとソース コード、またはより大きな成果物が起動されるか、最初に実行されるたびに、対象コードにアクセスするためにエンド ユーザーが使用するグラフィック ユーザー インターフェース上に、Mulesoft の帰属情報を目立つように表示する必要があります (スプラッシュ スクリーンへの表示を含む場合があります)。 )、もしあれば。=> 基本的に、Mule で構築したものはすべて Mule で実行されていることを宣伝する必要があります。

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

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

  • 最後だが大事なことは; おそらく最も重要な部分です。Mule ESB と Apache Camel の比較について、Google トレンドは次のように述べています。精度を高めるために、標準のクエリ キーワードではなく、新しいセマンティックトピック測定を使用していることに注意してください。そうすれば、動物 (ラバとラクダ) の人気を測定するのではなく、ソフトウェアの人気を測定できます! 解釈: Mule は 2007 年から 2011 年にかけて大きく下降傾向にあり、Apache Camel は上昇傾向にありました。2011 年以降、Mule は横ばい状態ですが、Apache Camel は順調に上昇傾向にあります。

Googleトレンドのミュールvsキャメル

Apache Camel の技術的進化

最初に質問をした 2010 年 9 月 25 日以降の Apache Camel の進化に関する機能的な指標を提供したかっただけです。これがその時点でのソース ツリーです。

  • 当時、Camel には 88 個のコンポーネントがありましたが、現在は Facebook、Twitter、Salesforce、Apache Ignite、Apache Cassandra、AWS、Apache Kafka、MongoDB、Apache Sparkなどとの統合を含む 220 個のコンポーネントがあります。
  • 非常に多くの技術的改善: 非同期ルーティング エンジン、メッセージ履歴、サーキット ブレーカー EIP、集約、分割、動的ルーティングなどの EIP に対する多くの改善と拡張。
  • エコシステムは現在、監視と管理用のHawtio、展開用の fabric8 などを含むように成長しています。
  • それ以来、新機能、改善、バグなどを含む5500件以上のチケットが解決されました。
  • そして、はるかに！

最終的な注意事項

どちらの製品も、過去 5 年、25 年にわたって大きく進化してきました。ただし、ライセンスの違いと、Mule ESB と Apache Camel のコミュニティの性質により、両者を比較することはもはやできないと思います。

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

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

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

于 2016-01-15T19:20:27.063 に答える
74

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

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

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

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

エド・オスト

于 2011-10-27T02:58:40.017 に答える
8

私のブログ投稿はまさにこの質問に答えています: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel は軽量の統合フレームワークであり、ServiceMix となどは完全な ESB です。

于 2012-01-11T08:56:45.940 に答える
5

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

Mule は正当な理由でJBI を使用しておらず、JBI 仕様が解散した現在 (JBI 仕様を最初に渡した Oracle が所有するワーキング グループはありません)、JBI を使用する正当な専門的または技術的な理由はありません。

于 2010-09-29T14:31:50.673 に答える
4

Apache Camel には、このhttp://camel.apache.org/faqに光を当てるいくつかの FAQ エントリがあり ます。

Apache Camel のリンク集 http://camel.apache.org/articles.html

コミュニティの人々が話し、Camel を他のプロジェクトと比較するリンクをいくつか用意してください。

于 2010-09-26T13:31:04.337 に答える
0

クラウス、Camel FAQ には多くの間違いがありますが、当然のことながら、私たちに有利なものはありません :)

  • Mule の UMO モデルは Mule にはありません。Mule 2 でそのモデルから離れ始め、Mule 3 で完全に変更されました。現在、非常に単純な Message Processor モデルがあり、それについてのあなたの声明は冗長になります。
  • Mule には数年前から明示的な型変換がありましたが、これは Camel の差別化要因ではありません
  • Mule は、OSI 承認の CPAL 1.0ライセンスの下でライセンスされています。これは、商用ライセンスではなく、オープン ソース ライセンスです。これをできるだけ早く更新してください
于 2010-09-29T14:55:23.997 に答える