Search code examples
javaspring-bootapache-camel

Proper way to use Apache Camel with Spring Boot

I have been working on 3 different projects and all of them had different way to work with Camel. First one was mostly calling couple of services per route through bean(we end up with large services that only had methods that were used in Camel routes only), like this:

from("direct:someUrl")
  .bean(myService, "loadData")
  .bean(myService, "validateData")
  .bean(myService, "saveData")
  .bean(myService2, "sendEvent")

and so on. Second created separate processor per each task(had to create long constructor to inject them all). Like:

from("direct:someUrl")
  .process(myParseProcessor)
  .process(myValidationProcessor)
  .process(mySaveToDbProcessor)
  .process(myPublishEventProcessor)

And in third one routes were calling each other(was super hard to see the full flow, because you had to jump across multiple classes). Like:

 FisrtRoute.java
 from("direct:someUrl")
  .process(()-> doSmth)
  .to("direct:someUrl2")
  
 SecondRoute.java
 from("direct:someUrl2")
  .process(()-> doSmth)
  .to("direct:someUrl3")

 ThirdRoute.java
 from("direct:someUrl3")
  .process(()-> doSmth)
  .to("direct:someUrl4")

I am trying to understand what is the preferred way to work with Camel? Personally I prefer second one, as it is easier to see the whole flow in one place and to cover with tests all small processors, but on the other hand we end up with tons of processors and huge list of them being injected into our Route.

Solution

  • Since I had to wrap my head around that problem myself, I can give you an answer based on your description. Although I am not sure that this is the most correct answer.

    Your first and second solution utilize a singleton pattern within Spring Boot while maintaining route visibility and transparency. Both is good and desirable. Thus, both ways are fine as far as I can tell.

    Whether you should use a service layer or Processor objects depends imho a bit on their respective purpose. Thus, if you can identify shared functionalities among different processing steps those steps could be organized in a service and called by whatever route needs them. If the processing steps are pretty much isolated its probably cleaner to use the Processors. Here it pretty much comes down to this kind of evaluation or some further technical implications like testing or async processing etc.

    Best