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?
