Using Camel as a Fast Back-end Bus with REST services

Question

This is the use case I am trying to address:

I have:

• a client C, which is a web app,

• a frontend module A, exposing a REST API,

• a back-end module B, also exposing a REST API. (I can't change this module which is not mine and which only has a REST API)

For one of the services, C calls A which calls B. Everything happens in REST. It is fast as the REST calls are synchronous (i.e. blocking).

Now I would like to decouple A and B, for A to not know about B directly.

So I am wondering about putting Camel as a message bus in the middle. It would give:

C ---(REST call)----> A ----> Camel ---(REST call)---> B

---

My question

Is it a good idea and if yes would it still be fast (without anything between A and B, I have a response in less than 10 ms on a local network)?

TieBreaker

Would it work the same with ServiceMix?

Thanks!

Answer 1

Are you asking whether or not a message bus is a good architecture or are you asking, given that you've chosen to use a message bus, if Camel / ServiceMix is the right solution?

I'll take a stab at both - IMHO message-based architectures (specifically event-driven architectures) are great. Do a search on Event Driven Architectures on infoq.com for a wealth of info. Provides fantastic decoupling, scalability, separation of concerns, etc.

Will it be fast? Too many factors there to answer. It will certainly be a bit more overhead than a peer-to-peer rest call, but maybe not enough to matter. Also depends on what messaging broker you choose, if you need selective queues, etc etc etc. I use Camel for a solution like this and it's 'fast enough' for what I need. You'll have to try it.

Not sure how to answer 'will it work the same'.. ServiceMix uses Camel for its routing, so some of it will work the same. But ServiceMix also has built in ActiveMQ, so if you decide to use something other the ActiveMQ (eg RabbitMQ) then it will work differently :)