This time we want to do shorter development cycle on 3.0, than we did on 2.0. 2.0 took about 11 months to do.
The goal for 3.0 is to have a drop in upgrade for 2.x. While we take on JDK 1.6 as the new min. supported JDK.
And at the same time we do some internal optimizations.
So the next thing we take to the next level could be, besides Camel 3.0:
- support for asynchronous transactions
- OSGi blueprint drop in replacement for Spring DM (work in progress as we got most work done in 2.x)
- Easier OSGi testing (general make using OSGi with Camel easier)
- Persistent state store for doing JMS request/reply (poor mans state engine for simple human flow tasks)
And an area people have asked about before is human work flows, which is an area to take to the next step.
However I believe this work is happening at Apache ServiceMix / Apache Karaf where there are plans to work with
the Activiti project (http://www.activiti.org/) and have it integrate with those projects. Camel works well with ServiceMix / Karaf also.
Also the Apache Hise project (http://incubator.apache.org/hise/) looks interesting and it already integrates out of the box with Camel.
So the human work flow side definitely looks something that we take to the next level with Camel, so you can leverage both.
And if you look at the current survey on Camel, then people are suggesting to improve monitoring and management of Camel.
In that area we would like to expose a REST API which has the same feature set as the current JMX.
Also it would be great with a Camel plugin into the Apache Karaf shell, which then leverages this REST API to fully manage Camel running in Karaf.
And we at FuseSource is working on a GUI tool for Camel. FuseSource Rider. The tool is 100% web based so you only need a web browser to use it.
The tool allows you to visual browse the Camel routes using the EIP icons. The tool is also a designer tool so you can create new routes using it.
Or modify existing etc. We also plan to include a debugger feature so you can debug Camel routes using the visual GUI. So you can add a breakpoint
on an EIP pattern. Then have the tool stop when a message hit that breakpoint. Then you can view the message (alter it if you need) and then single step
the message in the route to see how its being routed. The tool is going to be GA in Q1 2011. And we will post more details at the
FuseSource (http://fusesource.com) website in the near future.