Deciding which is the best path for your case is difficult without
knowing the exact requirements.
I can give you some pointers from my own experience though.
The most important advice is to separate your business code from any
integration framework you use.
If you just need to call webservices then do not use camel. Instead use
CXF to provide and consume services.
Still make sure you are not coupled to cxf too much. E.g. for a client
use the java interface of your service and inject the CXF proxy into
your business code.
So your business code only knows the interface.
For any other transport or data format camel is a good match. Again make
sure you do not integrate camel directly into your business code. Hide
the call to camel behind an interface. If the call comes in from a camel
route implement your business code as a plain java object and use the
bean integration to call your code.
A case where camel fits very well is if you do a pure integration like
watch a dir for files, convert and send to a web service or jms. Make
sure though that you avoid that complex business logic creeps into your
route over time.
In any case do not implement your business code using camel. I have seen
people split their code into very small chunks and use a camel route to
control the flow. While this is appealing at first as camel
is (miss)understood as a kind of business process engine it leads to
complex and unmangeable code. Camel is a very cool framework but think
twice if you are tempted to replace a java "if" with a camel route.
As a rough idea if the implementation in camel and java use about the
same lines of code then please use plain java.
As a last advice. Do not structure your code using technical packages
like routes, processors, converters. I have seen this a lot of times and
I think this bad habbit was at least partly introduced by the spring
people who structured their code like that for a while. The problem with
this is that your code will be highly uncohesive as for every business
function you need a route, processors and converters. Instead structure
the packages from the business side and keep stuff together that is
needed for the same business function.... and like said make sure your
classes either depend on the framework (like camel) or do business
logic. Do not mix both in the same class.
Christian
On 13.06.2014 01:05, blay wrote:
We're a defining an architecture for our company applications, so that
architecture has to take care of integrations with other
applications/systems. The first thing that came our mind was to centralize
all integrations in an ESB (Mule), which would run in standalone mode. But
new requirements appeared and the thing is that every application has to
manage its own integrations (which are not defined yet, but they shouldn't
be very complex). Now we´re evaluating using Apache Camel or Mule but in an
embebbed scenario. Discusing about it with some mates, it isnt very clear to
us which is the best (or more suitable) way to set up this architecture. At
my opinion, as its responsability of each application, I would integrate
Camel directly in my application (as a library); but they say it´s a better
option to deploy Camel in a separate project. These are the scenarios, as I
see them:
My application with Camel embebbed. If my application has to invoke a
webservice, for example, I just code it and send it (From(...).to(...) etc)
My application and another application with Camel embebbed. If my
application has to invoke a webservice, and I want to manage all
integrations through Camel, I think I have to call the camel project (by
JMS, or calling an interface it exposes), define a route in that project
which says: when I read from X (the interface im calling) call this WS. I
mean, it adds more complexity when I think it´s not needed.
Probably I missunderstanding how Camel really works so I´ll be glad to hear
what I´m wrong about ;)
--
View this message in context:
http://camel.465427.n5.nabble.com/Best-suitable-architecture-using-Camel-tp5752219.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
