If all your doing is using an API, and you don't really care what is
happening underneath, then I can see no need for Camel.
It would be the equivalent of trying to use Camel to do a series of String
manipulation calls. For all you know, the String class makes remote calls
over proprietary Oracle protocols to their Cloud platform to offer you the
result of substring. Of course it doesn't, but the point is, the API
ensures you don't care, just like in your case.
Seems to me that you're just importing a lot of conceptual overhead, (ie
having to understand Camel) for no reason.
regards,
dk-
ps. What is questionable in this case, is why someone would bother writing
a wrapper library these days.
On 10 February 2012 22:34, Grzegorz Borkowski<grzegorz...@gmail.com>
wrote:
Hi All,
In our project we've been using Camel for a year, but with very mixed
feelings. I'd like to ask you if the way we use it is correct - maybe our
problems come from the wrong usage of the tool. Camel experts, please
share
your opinions on this. Below you'll find description of the project.
Out project is an integration tool, integrating 3 other systems, call
them
A, B and C. We receive the message from system A, query for some data
from
system B and send the message to system C. Camel seemed to be ideal tool
for such scenario.
In practice, there are couple of problems though.
1. It turned out that we don't use any typical communication channels to
integrate with the systems. All those systems provided us with a library
(jar) which is simply a stub, which presents us with an API to call
remote
systems synchronously. Even if those stubs use JMS or other channels
underneath, we don't interact with them directly. The only thing we do,
is
just calling simple synchronous Java method on the stub. Something
similar
to the old Java RMI. Thus, the whole power of Camel components is of no
value for us.
2. There is one place where we use Camel JMS component - we have a test
input, for receiving test data, which uses JMS communication. So
currently
this is the only place in the code we use Camel components for real
integration with external systems. We're also now developing additional
interface, and this will be the second entry point based on JMS. So those
are only places when we use Camel capabilities.
3. Inside the application, we have a workflow build on the Camel routers,
predicates, and processors. All of them are glued by the "direct"
components. So when XML message comes, we pass it to a router, which
passes
it to a proper processor, then to next router etc. There are around 20
processors and 10 routers in the flow. In practice however, we see only
one
advantage of using Camel for this: ability to generate visual diagram of
the flow (using camel:dot feature). There are many downsides though.
First,
there are many couplings between the processors, so we end up passing
tens
of headers in the messages between processors. We already call it
"header-oriented programming" or simply "header hell". It's a nightmare.
Then, it's horror to debug the code when for example the router passed
the
message to the wrong path. If it was a normal java code written by us,
with
"if then else", we could just put a breakpoint there and debug it. But in
camel, if you configure routers using the built-in predicates, like:
from(...).choide().when(header(..).isEqualsTo(...)).to(...) - then you're
not able to debug it easily, because the if-then-else logic at runtime is
performed by camel engine, not our code.
4. Using the "direct" component connections everywhere seems to be
extremely inefficient. Say I have a flow: message goes through 2 routers
and two processors, linked by direct components. If you generate stack
trace at the end of this path, you will see literally hundreds of camel
calls. Where do they come from? It's especially frustrating when you try
to
debug it - it's infeasible. I hate debugging Spring proxies because they
insert about 5-10 framework method calls between my classes. Camel does
the
same, but it uses hundreds of framework calls instead. The stack trace is
littered with DelegateAsyncProcessor and AsyncProcessorHelper calls. I
wouldn't really be surprised if I saw StackOverflowError somewhere in the
flow.
5. Testing the Camel flow is not a nice experience as well. For every
test,
you have to set up those dummy endpoints, and record expected number of
incoming messages. Then, when there is an exception thrown in the flow,
instead of just breaking the test where it was thrown, we see the cryptic
message at the end "expected receiving 1 message, received 0". Then you
have to analyze the log to find what was the real reason. Also, Camel
waiting for the messages, make the tests much slower, because time is
lost
on this waiting.
Thoughts? Recommendations? What do we do wrong?
