Apache Camel: do Processors and Beans serve the same purpose?

Question

It seems like both serve the same purpose. Is there any difference that makes one useful in certain situations and not the other ?

Answer 1

In practice, they are very similar, but a Processor is more limited than a Bean. I generally use a Processor for simple use cases that just interact with the Exchange. Also, inline processors are a great way to interact without having to create a separate class.

Beans provide more flexibility and also support a true POJO approach. This allows you to more easily integrate with existing APIs (just need to convert the inputs/outputs to match, etc).

Beans also provide great features/flexibility with regards to Camel routing/EIP integration, including...

• rich set of bindings that allow you to quickly bind data from the Exchange to attributes of a bean method, etc.

• POJO consuming/producing allow you to interact with endpoints in a reusable manner

• used as expressions/predicates (for POJO EIP implementation...filters, etc)

Answer 2

Boils down to a matter of preference, I'd say. I generally opt for the POJO approach and so I started using beans to do my processing, but over time I've slowly moved to using Processors.

I was feeling pain in the following cases:

• Bean methods with more than one parameter
• Trying to get data out of the exchange params / the message headers

I know that Camel 2.8 takes out some of the pain of these cases by allowing annotations in your bean which guide Camel on how to call your bean's methods. I didn't want to go this route -- felt wrong to put Camel annotations into a bean that shouldn't care that it's being called by Camel.

In the end we created an annotation-free, client-agnostic bean and a very thin Processor that pulls everything it needs from camel and passes it to that bean.

Just my 2 cents - the bean route really isn't a bad one - it'll do the job just as well (esp in 2.8)

EDIT

Many improvements have been made to camel's use of POJOs to process messages since this was written - this answer may no longer be applicable.