Springのベテランユーザーとして、Spring Integrationは、いくつかの(JMS)メッセージング機能を必要とする最近のプロジェクト( 詳細 )で最も意味があると思っていました。 Spring Integrationを使用して数日間作業した後でも、要求と応答(異なるJMSキューをリッスン)の通信を導入するために構成する必要のあるチャネルの量を考えると、多くの構成オーバーヘッドのように感じます。
したがって、私はCamelがSpring Integrationとどのように異なっているかの背景情報を探していましたが、そこにある情報はかなり余裕があるようです、私は見つけました:
質問は次のとおりです。1つのスタックを他のスタックよりも使用してどのような経験をしましたか? Spring Integrationにサポートがない場合、Camelをどのシナリオで推奨しますか?それぞれの長所と短所はどこにありますか?現実のプロジェクトからのアドバイスは大歓迎です。
流APIなAPIは本当に素晴らしいので、Spring-IntegrationよりもCamelを選択します。実際にSpringプロジェクトで使用し、Springを使用してその一部を構成します。プログラミングAPIは明確であり、賢明なコンポーネントの大規模なセットがあります。
私たちは小規模な銃撃戦を行いましたが、基本的にはその時点でキャメルが勝ちました。これは主に、内部データファイルを外部との間で転送するために使用します。通常は、ftp/sftp/...を使用して送信するか、電子メールに添付して送信する形式変換が必要です。
Edit-compile-debugサイクルが短縮されることがわかりました。 groovyを使用してルートのセットアップを実験すると、ボーナスが追加されます。
Spring-Integrationも素晴らしい製品であり、私たちのニーズも満たすと確信しています。
既にSpringプロジェクトを取得しており、ファイル、FTP、JMS、JDBCなどを使用して「基本」統合を追加する必要がある場合にのみ、Spring統合をお勧めします。
Apache Camelには2つの主な利点があります。
Apache CamelはSpringと非常に良好に統合されているため、ほとんどのSpringプロジェクトでSpring Integrationを使用する場合は、代わりにそれを使用することもあります。
さらに詳細が必要な場合は、ブログ投稿で私の経験を読むことができます: Spoilt for Choice:Spring Integration、Mule ESB、またはApache Camelのどの統合フレームワークを使用しますか?
私は本当にあなたが何をしたいかに依存しています。独自のメッセージングソリューションを構築するために何かを拡張する必要がある場合は、Spring Integrationのプログラミングモデルが優れています。カスタムコードなしで多くのプロトコルをサポートするものが必要な場合は、CamelがSpring Integrationの先を行っています。
小規模なシュートアウトを行うことは非常に良い考えです。プロジェクトで通常行うタイプのことをしようとしていることを確認してください。
-免責事項:私はSpring Integrationコミッターです
私が見たキャメルとSIのほとんどの比較では、以下を考慮していません。
1.)Spring BootがSpring Integrationの開発者の生産性に与えた影響
2.)Spring XDの効果は、Spring Integrationアプリケーションをコードコンパイルなしで使用可能にすることにあります。また、Spring XDを拡張する場合、Spring XDのソースとシンクは単にSpring Integrationチャネルアダプタです。
3.)Spring XDの効果は、Spring Integration、Spring Batch、Spring Data(+ Hadoop!)を1つのスタックに統合し、バッチ処理とストリーム処理、HDFS/Apache HadoopサポートなどをSpring Integrationに効果的にもたらします。
4.)まもなくリリースされるSpring Integration 4.0の効果Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring -Integration-Java-DSL-Reference
あなたの検討のために、
/ Pieter(免責事項Pivotalで働いています)
Spring Integrationフレームワークで多くの問題が発生したため、アプリケーションにSpring Integrationを使用しており、Apache Camelへの移行を検討しています。ここにいくつかの問題があります。
Springが提供するCachingConnectionFactoryは、IBM MQで何千ものアイドル接続を開きますが、これらの接続が再利用される保証はありません。それでも、これらの接続は永久に開いたままになり、MQ側で問題が発生します。接続を更新するためだけに、低い環境で毎週アプリケーションを再起動する必要がありました。 Apache Camelはキャッシュも提供し、負荷に基づいて接続が上下するようです。
SpringはQoSパラメーターのマッパーを提供していません。 QoSを有効にしても、配信モードと有効期限/有効期限のプロパティは失われます(これについてJIRAの問題を提起します)。 Apache Camelがこれを処理し、QoSパラメーターがアップストリームアプリケーションに送信され、ドロップされません。
私は今、AOPでSpringがより良く処理できると思われるApache Camelでの例外とトランザクションの処理に関する問題に取り組んでいます。
実際、FTPはインキュベーション期間を卒業したと言えます。 SIフォーラム/ JIRAで簡単な検索を実行して、実装された新機能と修正されたバグを確認できます。さまざまなおしゃべりから、すでに生産的な使用法がいくつかあるように思えますので、もう一度見て、もちろんあなたの懸念を私たちに伝えてください
http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT
乾杯オレグ
免責事項:私はSpring Integrationコミッターです
Apache Camelは非常に優れたフレームワークであり、非常に完全です。しかし、アプリケーションがSpringを使用する場合、私の個人的なアドバイスはSpring Integrationを使用することです。
Spring Integrationは、Spring-Sourceエコシステムの統合EIP苦情フレームワークです。エコシステムとの優れた統合があります:Spring boot、Batch、XD。コアでさえ、Spring Framework 4以降の同じ抽象化を使用します。SpringIntegrationの基本的なメッセージング抽象化が非常に強力であることの証拠として、フレームワーク内でメッセージング抽象化の一部が移動されました。現在、Springフレームワークは、Spring Webのメッセージング抽象化、Webソケットサポートを使用しています。
Apache Camelの使用に関するSpring統合に関するSpringアプリケーションのもう1つの良い点は、Spring統合では1つのアプリケーションコンテキストしか使用できないことです。 Camel ContextはSpringコンテキストであることに注意してください。新しいSpringバージョンを使用する可能性がある場合、Spring Integration Java DSLを構成に使用することをお勧めします。私は新しいプロジェクトでそれを使用し、より読みやすく明確に感じました。この反省があなたの評価に役立つことを願っています。
Spring IntegrationでCamelを使用する1つの理由は、より機能的なEIPセットが必要な場合です。 Spring Integrationは、ThreadPoolなどの事柄に対する抽象化を提供しません。
Camelは、このための追加の構成要素を提供し、同時実行コードの操作のいくつかの側面を簡素化します。
http://camel.Apache.org/camel-23-threadpool-configuration.html
この種の必要がなく、ファイル、JMS、FTPエンドポイントなどを接続するだけの場合は、Spring Integrationを使用します。
Camelは、データモデリング、メッセージ値の変換、メッセージの振り付けを実行できるアプリケーションのミドルウェアとして機能します。