Am 11.02.2012 14:00, schrieb Grzegorz Borkowski:
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?
I think as long as you are using a library to access the external system
there is not much benefit in using Camel. One important question is though
if the concept if these libraries is a good solution. It means that the
developers of the external system have to give you a new version of the
library every time they update the system. This also means that you have
to update you own system at this time. I think this is a quite tight
coupling which
is not really desireable. The problem is multiplied when more than one
system uses the external system in this way. Another problem with these
libraries is that you
"import" all the technology the library uses into your own project. So
e.g. if they use spring then you will also have spring in your
depdencies. If you attach to two different
of those systems then this can be really difficult as they might require
to use different version of a lib at the same time.
So instead of your current aproach I would rather suggest to use kind of
a service oriented aproach. Instead of sharing a library you can define
the data format, transport and semantics to talk
to the external systems. This allows both sides to choose the technology
to provide or use the services freely. In this concept camel can help
you a lot for example you can use jaxb or json for the dataformat and
http or jms as transport. Camel frees you a lot from implementing these
classses.
Another thing you should consider is using pojo beans to implement your
business logic. Camel allows very good mapping to such beans and they
allow you to keep your business logic free of camel code. This makes
testing
the logic really easy as you can use pure junit tests instead of camel
tests for a lot of the cases.
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?
The camel routing is good if you deal with e.g. xml instead of java
objects. In your case where you already communicate with the other
system using objects I would rather code the routing in simple
java.
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.
Yes the async adapters in camel make it very difficult to debug and
probably also consume a lot of time for simple sync cases. I hope we can
address this issue in future camel versions. The reason why we have this
is that in many cases the async behaviour allows higher performance for
some cases. Of course async alone will already make debugging a lot
harder anyways.
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?
I assume he suggests something similar like I described above. Trying te
decouple the systems. I think though that this does not work well with
the shared lib concept you currently have.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
