Grzegorz-
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 components...it'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?
