You have many possibilities. And the best solution depends on multiple
- What's your payload?
- How big is it?
- Do you have ambitious performance requirements?
- Do you have ambitious throughput requirements?
- Do you also have to process the requests (later) if Camel1 and Camel2 is
- Is loosing messages acceptable?
In my company, we use ActiveMQ to decouple different services/applications.
We use persistent messaging to be sure we do not loose messages. It's fast
(we have "normal" performance requirements) and fits our requirements.
If performance is the most important requirement, I would go for
camel-netty, camel-mina2 or camel-mina.
One remark: I really ofter hear "as fast as possible" but in most cases,
it doesn't matter whether it takes 10ms or 50ms longer for one request. If
this is the same for your requirement, have a look at some other protocols
you may are more familiar with, e.g.: camel-http(4), camel-cxf (for JAX-RS
or JAX-WS), ...
But in all this cases, your applications/services are not so loosely
couplet (as possible). If Camel1 and/or Camel2 is down, AppCamel1 and/or
AppCamel2 will recognize it. This is not the case with a message broker in
What's your strategy if you have to scale CamelX? Adding Camel3, Camel4,
...and so on, I asume. But in this case, you have to touch AppCamel1 and
AppCamel2 again. With an message broker, simple add more consumers onCamel1
and Camel2 . And if this is not enough, add Camel3 and Camel4. But in this
case, you don't have to touch AppCamel1 or AppCamel2.
It's not "Camel mainly makes sense with a broker like ActiveMQ". There are
many other easons why you should use Camel also without a message broker.
I want only let you know
1) what the benefit of a message broker is and
2) what customers says is sometimes not what they really want... ;-)
On Mon, Apr 2, 2012 at 7:00 PM, Christian Müller
<[hidden email]> wrote:
> It's not "Camel mainly makes sense with a broker like ActiveMQ". There are
> many other easons why you should use Camel also without a message broker.
> I want only let you know
> 1) what the benefit of a message broker is and
> 2) what customers says is sometimes not what they really want... ;-)
> On Mon, Apr 2, 2012 at 4:25 PM, unludo <[hidden email]> wrote:
>> I see that Camel mainly makes sense with a broker like ActiveMQ, as a core
>> for a scalable/decoupled system.
>> Thanks for helping me understanding this!
>> View this message in context:
>> http://camel.465427.n5.nabble.com/scalable-bus-with-multiple-Camel-instances-tp5606593p5612599.html >> Sent from the Camel - Users mailing list archive at Nabble.com.