Question

In a Camel route, should I be thinking about putting my business logic in a discretely hosted bean endpoint, like a message-driven bean or a web service, vs just implementing it in Camel processors?

It seems like cleaner separation of concerns to use Camel just for mediation & orchestration, using Processors as filters, rather than as a container for business logic. However I don’t forsee the need for an EJB container at this time, and it seems like I’d need one to host MDBs.

So cleaner architecture vs smaller footprint, fewer technologies – Does anyone have thoughts, perspectives, or strong feelings about this?

Answer 1

I generally use Camel to perform the following…

• any component integration (file, jms, http, etc)
• to implement EIP logic (content based routing, filters, throttling, etc.)
• timer based processes (using timer or quartz)
• exception handling (retry logic, error logging/notification/queueing)

Otherwise, for business logic that is self contained (especially legacy integration), it may be preferable to use POJOs or WebServices. This promotes testability and makes your application more modular, etc. Then, you can use Camel for the following…

• to interface with these services using Processors, Bean Binding and CXF
• to wire these services together into routes
• manage/monitor message flow, exception handling

In regards to long running processes, Camel can facilitate this via various asycnhronous patterns/technologies (JMS, CXF, polling consumers, scheduled jobs, etc.) as well as gives you control over threading…

That all said, there are many ways to slice it. Camel is lightweight, flexible and designed to ease integration with existing technologies, not replace them…good luck