Business logic in Camel processors vs service endpoints

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

Answer 2

You should try to separate technical things like routing or filtering from you business logic.

So the most important part is to not mix up these in the same class. To separate them into discrete deployment units may make sense but is less important.

Camel can be used very nicely to implement "message driven beans". Simply define your data structures using pojos + JAXB annotations or generate them from XSD. Then you can use camel pojo messaging to connect these to http, jms or even file endpoints.

See http://www.liquid-reality.de/x/NoBe

When you run on OSGi an obvious choice is to offer your services as OSGi services. Camel can then be used in a separate bundle to connect these services to the transports. This way you can make your services completely plain java.

You can also use CXF to offer your services as SOAP services or rest resources. I prefer XML over JMS with camel though as it is more light weight and has some nice advantages regarding high availability and load balancing thanks to jms.