実際には、これらは非常に似ていますが、プロセッサはBeanよりも制限されています。私は通常、Exchangeと対話するだけの単純なユースケースにプロセッサを使用します。また、 インラインプロセッサ は、個別のクラスを作成せずに対話するための優れた方法です。
Beanは柔軟性を高め、真のPOJOアプローチもサポートします。これにより、既存のAPIとより簡単に統合できます（入力/出力を一致するように変換する必要があるだけです）。
Beansは、Camelルーティング/ EIP統合に関して優れた機能/柔軟性も提供します。
要約すると、好みの問題だと思います。私は通常、POJOアプローチを選択するため、Beanを使用して処理を開始しましたが、時間の経過とともに、徐々にプロセッサーの使用に移行しました。
次のような場合に痛みを感じていました。
- 複数のパラメーターを持つBeanメソッド
- 交換パラメータ/メッセージヘッダーからデータを取得しようとしています
Camel 2.8は、 Beanのアノテーション を許可することで、これらのケースの問題の一部を取り除くことを知っています。これは、CamelがBeanのメソッドを呼び出す方法をガイドします。私はこのルートに行きたくありませんでした-Camelによって呼び出されていることを気にしないBeanにCamelアノテーションを入れるのは間違っていると感じました。
最終的に、アノテーションのない、クライアントに依存しないBeanと、ラクダから必要なものをすべて引き出してそのBeanに渡す非常に薄いプロセッサーを作成しました。
ちょうど私の2セント-豆のルートは本当に悪いものではありません-それは同じように仕事をします（特に2.8で）
[〜＃〜]編集[〜＃〜]
これが書かれて以来、メッセージを処理するためのラクダのPOJOの使用に多くの改善が加えられました-この答えはもはや適用できないかもしれません。