RabbitMQとMuleの比較
RabbitMQとMuleの違いは何ですか？私はメッセージ指向アーキテクチャを使用してアプリケーションを構築し、AMQP（RabbitMQ）は必要なすべてを提供しますが、ESBのような多くの関連技術の選択と同様の概念に戸惑っています。他の選択肢を考慮せずに選択をしているのかどうか疑問に思っています。
RabbitMQがメッセージブローカーであり、プロデューサーとコンシューマーの間でメッセージを仲介するのに役立ちます（すべてのフォームまたはパブリッシュサブスクライブし、TwitterやFacebookの更新などの実際の例からどのように使用されるか理解できました）。
Muleとは何ですか？ラバを使用してRabbitMQでできることを達成できた場合、ラバをRabbitMQと同様に検討する必要がありますか？
ラバの目的はメッセージブローカーの目的とは異なりますか？
Muleは、その下に適切なmuleリスナーにメッセージを配信するメッセージブローカーがあると想定していますか（RabbitMQでリスナーを簡単に作成できます）。
ラバは完全ですJava bases system（RabbitMQで行った現在の実験では、クライアントをC＃として、サーバーをJava、そのようなことはMuleで簡単に行えます）。
MuleはESB（Enterprise Service Bus）です。 RabbitMQはメッセージブローカーです。
あ ESB ルーティング、変換、ビジネスプロセス管理などのメッセージブローカーの上に追加のレイヤーを提供します。これは、アプリケーション間の仲介者であり、Webサービス、RESTエンドポイント、データベース接続、電子メール、およびftpサーバーを統合します-あなたはそれに名前を付けます。それは、異なるプロトコルを話すアプリケーション。
あ メッセージブローカー 開発者がパブリッシャーとサブスクライバー間で、通常は同じシステムのコンポーネント間で生のメッセージを中継できるようにする下位レベルのコンポーネントですが、常にではありません。非同期処理を有効にして応答時間を低く保つために使用されます。一部のタスクは処理に時間がかかるため、時間に敏感でない場合は、タスクが遅れることを望まない場合があります。代わりに、（パブリッシャーとして）キューにメッセージを投稿し、サブスクライバーにそれを選択して「後で」処理してもらいます。
Muleは、メッセージブローカーを使用して実装された「上位レベル」のサービスです。 docs から
ESBのメッセージングバックボーンは通常JMSを使用して実装されますが、他のメッセージサーバー実装も使用できます。
ESBはrabbitで構築できます。ただし、送信するのはbyte []パッケージに限定されるため、トピックやキューなどのメッセージングプリミティブからシステムを構築する必要があります。翻訳の層が少ないため、（ベンチマーク、テスト、またはデータがまったくないことに基づいて）少し高速になる可能性があります。 Muleはこれに加えて抽象化を提供し、さまざまなトランスポートを話し、いくつかのルーティングロジックを処理できます。
オープンソースのメッセージブローカーソフトウェアであるRabbitMQは、Erlangプログラミング言語で記述されており、クラスター化とフェイルオーバーのためにOpen Telecom Platformに基づいて構築されています。使いやすく、多数の開発者プラットフォームをサポートし、すべての主要なオペレーティングシステムで実行できます。 Exchangeと呼ばれる概念で動作します。 MuleはRabbitMQをAMQPコネクタに接続します。
ラビットはクライアントサーバー時代のもので、ラバはAPIネットワーク時代に属しています。レガシープラットフォームの制限で実装を余儀なくされない限り、MuleとRest APIを使用することをお勧めします。とにかく、数年後には、Rabbit用に作成したコードを修正して、現在および将来のAPI主導のアーキテクチャをサポートする必要があります。それで、なぜ今それをしないのですか？私の数セント。
Muleはエンタープライズサービスバスで、エンドツーエンドの統合ソリューションを提供します。Rabbitはサブスクライバーとレシーバーの間でメッセージをキューイングするメッセージブローカーです。