camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Borkowski <grzegorz...@gmail.com>
Subject Re: Question on the proper usage of Camel
Date Sun, 12 Feb 2012 22:50:38 GMT
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.krizanovic@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 <grzegorzbor@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?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message