camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <>
Subject Re: Question on the proper usage of Camel
Date Sat, 11 Feb 2012 15:30:16 GMT

1. I was under the impression that you had a bunch of custom code doing 
things like Web Service or database access.  My contention was that 
using Camel components to replace a lot of that boiler code is a big 
win.  There are still nice gains to be had from using Camel in your 
scenario where you are talking with beans.  The EIP patterns, the 
management capabilities, etc.

2. Sure.  There aren't any hard and fast rules about how you use it.  
Using Camel is like making beer.  Its only a bad idea if it doesn't 
taste good ;-)

3. I don't think seeing a large stack trace is indicative of Camel 
having suspect engineering.  Its fast, it works and compared to most 
other integration frameworks (especially the commercial ones!), its a 
short stack trace :-).

4. I was just suggesting using queues as a way to shrink the custom code 
stack I presumed from #1.  I'm not suggesting over engineering, I don't 
know enough about your specific implementation.  For folks that are 
moving from big stacks of EJBs that talk to 3rd party systems, using JMS 
is one potential simplification approach.  If your direct calls are 
simple enough, no need to stick JMS in the middle.

Matt Pavlovich

On 2/11/12 7:00 AM, Grzegorz Borkowski wrote:
> Ashwin, Matt,
> Thanks for you feedback. Here is some additional explanation of my points:
> 1. The external systems provide us with the ready-to-use
> proxies/stubs/facades. We just call the Java method on such stub and it
> does some remote calls internally, but it's beyond our control. What we
> see, is just a method to be called. Because of this, it turned out we don't
> need Camel components for communication with external systems. I don't see
> much advantage in wrapping those libraries in custom's just
> more code to maintain, with no apparent benefit. So now we almost don't use
> Camel components. Then the question is, if you don't use Camel components
> (which are considered to be the biggest advantage of Camel), does it make
> sense to use Camel at all?
> 2. In the current form, we use mainly Camel as a workflow engine, using
> only links between processor and routers. As Ashwin suggested, we could
> just directly couple the processors without without using "direct'
> components. Perhaps that's something to consider. But again the question
> is, is it a valid use case for Camel, if we just build the single-VM
> worfklow out of Camel processors and routers, with no components involved?
> 3. The direct endpoints efficiency - maybe the "efficiency" was not a best
> word, I didn't meant it's slow or so. It's just that if all you want is to
> pass a message from method X to method Y, you expect it to be easy
> operation. But then when you see the Camel stack trace, and you see several
> hundreds of the almost identical calls on the framework classes, then it's
> just suspicious, and you think something wrong is going on here. Why does
> Camel need hundred of calls on the stack to pass the message through a
> couple of processors/routers/direct components? From what I see, it's all
> littered with some async wrappers - i'm not getting the point of those
> async wrappers if all I need is a plain sync method call. Also, I haven't
> observed stack overflows yet - it's just that I'm very suspicious about the
> huge stacks produced by Camel.
> 4. Matt, I don't get your point about replacing direct calls with JMS. It
> sounds like a terrible over-engineering for me. I just need to call a Java
> method, why involve JMS?

View raw message