Ioannis, Denis, Thanks for you input. What you say is exactly the same what I think now, that we tried to "overuse" Camel. We actually used it as a workflow engine for the message processing, instead of integration engine. Instead of using Java if-then-else logic inside a processor, we used Camel routers, end that's why we ended with 20 processors, where in fact it should be definitely less than 5. For the questions about throughput and external system outages: the load is really small in this system, and it's very unlikely to grow to the point where it's of some concern for us. When the systems B or C are down, we return immediate error message to the system A, but we also try to reprocess the message after some time (we use timers which trigger reprocessing).
W dniu 12 lutego 2012 22:34 użytkownik Denis Krizanovic < denis.krizano...@gmail.com> napisał: > 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? > > >
