Spring IntegrationとCamelを使用する場合

私は、経験豊富なSpringユーザーとして、いくつかの（JMS）メッセージング機能を必要とする最近のプロジェクト（詳細）でSpring Integrationが最も理にかなっていると想定していました。Spring Integrationを使用して数日経っても、要求と応答（異なるJMSキューをリッスンする）の通信を確立するために構成する必要があるチャネルの量を考えると、依然として構成オーバーヘッドが多いように感じられます。

したがって、CamelとSpring Integrationの違いに関する背景情報を探していましたが、そこにはかなり予備の情報があるようです。

• http://java.dzone.com/articles/spring-integration-and-apache（2009年 12月以降、Spring IntegrationとCamelで実際の統合シナリオを実装する場合の非常に中立的な比較）
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html（Camelと他のソリューションの比較、2009年10月）
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a（マットレイブル、2008年10月）

質問は次のとおりです。一方のスタックをもう一方のスタックで使用したときにどのような経験をしましたか？Spring Integrationがサポートを欠いている場合、どのシナリオでキャメルを推奨しますか？それぞれの長所と短所はどこにありますか？実際のプロジェクトからのアドバイスは高く評価されます。

流暢なAPIが本当に素晴らしいので、Spring-IntegrationよりもCamelを選択します。実際には、Springプロジェクトで使用し、Springを使用してその一部を構成します。プログラミングAPIは明確であり、実用的なコンポーネントの大規模なセットがあります。

私たちは小規模な銃撃戦を行いましたが、基本的にはキャメルが獲得した要件のためにその時でした。私たちは主に内部データファイルを外部の当事者との間で転送するために使用します。これは通常、フォーマット変換を必要とし、ftp / sftp / ...を使用して送信するか、電子メールに添付して送信します。

編集、コンパイル、デバッグのサイクルが短縮されたことがわかりました。groovyを使用してルートの設定を実験すると、ボーナスが追加されます。

Spring-Integrationも素晴らしい製品であり、私たちのニーズも満たすと確信しています。

すでにSpringプロジェクトがあり、ファイル、FTP、JMS、JDBCなどを使用して「基本的な」統合を追加する必要がある場合にのみ、Spring Integrationをお勧めします。

Apache Camelには2つの主な利点があります。

1. より多くの技術がサポートされています。
2. さらに、（良い）XML DSLには、Java、Groovy、Scala向けの流暢なAPIがあります。

Apache CamelはSpringと非常によく統合されているため、ほとんどのSpringプロジェクトでは、Spring Integrationの代わりに使用します。

詳細が必要な場合は、私のブログ記事「Spoiled for Choice：Spring Integration、Mule ESB or Apache Camel？

私は最近、Apache Kafkaを統合することを目的として、ラクダと春の統合の銃撃戦を実施しました。熱心な春の開発者であるにもかかわらず、私は悲しいことに、Springの増え続けるプロジェクトスタックと私の疑いが確認された：IOC-コンテナは、他のフレームワークのための接着剤として機能するように、バネは素晴らしいですが、それは実行可能な代替提供で失敗にこれらのフレームワークを。これには例外がある可能性があります。つまり、MVCで行うすべてのこと、Springの由来、優れた機能を備えていることなどがありますが、コンテナー機能に加えて新しい機能を提供する他の試みは3つの理由で不十分であり、SI Kafkaのユースケースで確認されていますそれらすべて：

• XML構成に長い間使用するのが難しいDSLの導入。
• すべてのフレームワークコンポーネントを接続するためのxml構成コードのページ。
• 専用フレームワークと同等の機能を提供するためのリソースが不足しています。

ここで、私の銃撃戦の結果に戻ります。最も重要なのは、エンドポイント間のルートの Camelsの全体的な概念に感銘を受けたことです。Kafkaはこの概念とシームレスに統合され、3行の構成ですべてを稼働させることができます。プロセス中に発生した問題は、プロジェクトチームからの十分なドキュメントとStackoverflowに関する多くの質問によって適切に対処されます。最後に大事なことを言い忘れましたが、Springへの包括的な統合があり、願いが叶いません。

逆にSIを使用すると、Kafkaの統合に関するドキュメントはかなり厳しくなり、Kafkaを統合する方法を明確に説明できません。カフカの統合がされて押された余分な複雑さを加える物事のSI-道へ。Stackoverflowなどの他のドキュメントも、Camelよりも豊富でなく、あまり役に立ちません。

私の結論：コブラーはあなたの仕事に固執する-コンテナーとして春を使用し、システム統合フレームワークとしてキャメルを使用します。

それは本当にあなたが何をしたいかに依存します。独自のメッセージングソリューションを構築するために何かを拡張する必要がある場合、Spring Integrationはより優れたプログラミングモデルを備えています。カスタムコードなしで多くのプロトコルをサポートするものが必要な場合、CamelはSpring Integrationよりも優れています。

小規模な銃撃戦は非常に良いアイデアです。プロジェクトで通常行うタイプのことを実行しようとしていることを確認してください。

-免責事項：私はSpring Integrationコミッターです

私が見たキャメルとSIのほとんどの比較では、次のことは考慮されていません。

1.）Spring Integrationの開発者の生産性に対するSpring Bootの影響

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への移行を検討しています。ここにいくつかの問題があります。

1. Springが提供するCachingConnectionFactoryは、IBM MQで1000のアイドル接続を開き、これらの接続が再利用される保証はありません。それでも、これらの接続は永久に開いたままになり、MQ側で問題が発生します。接続を更新するためだけに、低い環境で毎週アプリケーションを再起動する必要がありました。Apache Camelはキャッシングも提供し、接続は負荷に応じて上下するようです。

2. SpringはQoSパラメータのマッパーを提供していません。QoSを有効にしても、配信モードと有効期限/存続時間のプロパティは失われます（このためにJIRAの問題を提起します）。Apache Camelはこれを処理し、QoSパラメータは上流のアプリケーションに送信され、ドロップされません。

私は現在、SpringがAOPでより適切に処理しているように見えた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苦情フレームワークです。これは、エコシステムとの優れた統合を備えています。SpringBoot、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は、データモデリング、メッセージ値の変換、メッセージの振り付けを実行できるアプリケーションのミドルウェアとして機能します。

現在のアプリケーションがSpringにあり、EIPのSpring Integrationでサポートされている機能が必要な場合は、Spring Integrationが最適なオプションです。それ以外の場合は、サードパーティのサポート/プロトコル/ファイル形式などが必要です