As I am wrapping up a project which uses Cameland Hiram asked me to
send my feedback to the list so... :-)
Firstly, Camel has proven really nice to work with for the most part.
It simplified a much nastier first take on my project!
So, to the details:
* The async exchange stuff in trunk is pretty much required. I needed
guaranteed delivery in-memory and wanted to just use the fie
component, but the inability for it to handle async delivery was a
deal breaker. I wound up writing a spool component, which was much
like the file component except that it took urls of the form "spool:/
var/baz/spool:store" and "spool:*:delete" and things were delivered
to the "delete" variant when I wanted the file removed. Ugly, but it
worked.
* Failure to convert a type should raise an exception, a clear type
conversion exception which provides enough details to solve the
problem. The conversions expected by the existing components need to
be documented clearly on the components.
* Speaking of documentation, any method that is part of the fluent
API really needs javadocs.
* So, as to what I did -- I defined a bunch of routes and created a
number of components. Specifically I replaced the file and seda
components, and created several "end" components which were the final
destinations of messages in the system. I used the fluent API, and
avoided the magic (see later point).
* The use extensive of discovery magic is a bit troublesome. It is
nice and all for the demo, but I want something which I can see how
it works, and more importantly the next person to come along can
understand without needing to know about the properties file which
mentions the classes which are interpreted out by some strings
somewhere else. This applies to both components and type conversion.
* Producer vs Consumer: The naming right now makes sense if you are
implementing the routing system (or JMS as Hiram has pointed out to
me). It does not make sense if you are implementing components. Users
of Camel will likely implement components, and will almost surely not
re-implement the routing system. It is also the opposite of JBI,
which implies it is the opposite of some WS standard thing that JBI
is based on. As it is also undocumented, this is triply painful.
So, looking to improve Camel:
* Exception and dead letter channel handling needs to be clarified.
This may just be a documentation issue, but even after exploring it
in tests I am unsure of exact semantics.
* Async exchange handling should always be assumed.
* Thread semantics need to be cleaned up. I believe all built in
components should be single-thread oriented (ie, only one message at
a time coming out).
* Corollary -- the seda component should go away and be replaced with
a thread pool policy. This should be done as a policy/interceptor as
it is not an endpoint unto itself, it just controls how messages make
their way between. Given:
from("file:foo").threadPool(10).to("wombat:nugget")
or
from("file:foo").threads(10).to("wombat:nugget")
The file component would push to a blocking queue which ten threads
pull from and pass on to "wombat:nugget" This provides clear control
over how threads are allocated and used to the developer -- a Good
Thing(r).
--
More to say, but need to run and this email has been gathering for
too long so will send it out incomplete.
-Brian
