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? >
