You have many possibilities. And the best solution depends on multiple criteria: - 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 not up? - 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. Best, Christian On Fri, Mar 30, 2012 at 3:02 PM, unludo <unl...@gmail.com> wrote: > My idea is to use camel to decouple modules. In order to support > scalability > and failover, I am wondering if the following architecture is adviced? > > I have two applications with Camel embedded AppCamel1 and AppCamel2. Then I > have standalone camel nodes Camel1 and Camel2. > > AppCamel1 would have a route with fail-over/load balancing to Camel1 and > AppCamel2. This way, if Camel1 crashes for example, Camel2 is used for > failover. > > Camel1 and 2 would do a REST call with the http component for example. Also > there would be a request-reply from AppCamel1 up to camel1 or 2. > > Is it a valid scenario? > > What should I use to interconnect the different Camel instances (AppCamel1 > to Camel1 or 2)? (I would like to know if it's possible to avoid another > component like a jms server in the middle) > > Thank you! > > Also there: > > http://stackoverflow.com/questions/9943507/a-scalable-bus-with-multiple-camel-instances > > http://stackoverflow.com/questions/9943507/a-scalable-bus-with-multiple-camel-instances > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/scalable-bus-with-multiple-Camel-instances-tp5606593p5606593.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
