camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache Camel > Camel 3.0 - Roadmap
Date Tue, 19 Oct 2010 05:26:00 GMT
    <base href="">
            <link rel="stylesheet" href="/confluence/s/1810/9/1/_/styles/combined.css?spaceKey=CAMEL&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="">Camel
3.0 - Roadmap</a></h2>
    <h4>Page <b>edited</b> by             <a href="">Martin
                         <h4>Changes (1)</h4>
<div id="page-diffs">
            <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >h4. REST <br>We already have
REST support with [CXFRS] and [Restlet] but it can be better. We should make sure those components
is dead easy to use and you can invoke REST services in one line of code etc. And we should
make more examples and tidy up the [CXFRS] documentation. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">
<br>h4. More load tests <br>More load tests for frequently used Camel components
(jetty, jms ...) and camel-core. <br>* Ensure correct behaviour under load <br>*
Source for performance numbers (throughput etc). <br>* Detection of memory leaks <br>*
Detection of performance decreases after refactorings <br>* ... <br></td></tr>
</div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h2><a name="Camel3.0-Roadmap-Camel3.0roadmap"></a>Camel 3.0 roadmap</h2>

<p>This is a roadmap which details the overall and major goals for Camel 3.0. Fell free
to discuss this at the Camel <a href="/confluence/display/CAMEL/Mailing+Lists" title="Mailing
Lists">Mailing Lists</a> if you have ideas or feedback.</p>

<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td
valign='top'><img src="/confluence/images/icons/emoticons/forbidden.gif" width="16"
height="16" align="absmiddle" alt="" border="0"></td><td><b>Nothing is
committed/confirmed</b><br />The items listed on this wiki page is just <b>ideas</b>
for the roadmap. Anything is subject for change.<br/>
Speak up if you want to ensure a feature is on the roadmap, or if you have new ideas etc.

<p>When development of Camel 3.0 starts we will update status here which items have
been implemented in the source code, and which have been discarded/deferred etc.</p></td></tr></table></div>

<h4><a name="Camel3.0-Roadmap-JDK1.6"></a>JDK 1.6+</h4>

<p>Camel 3.0 should bump the JDK minimum version to 1.6.<br/>
Camel 1.x/2.x supports JDK 1.5+. </p>

<h4><a name="Camel3.0-Roadmap-Spring3.x"></a>Spring 3.x</h4>

<p>Camel 3.0 should bump the minimum version of Spring to 3.0+.<br/>
Camel 1.x/2.x supports Spring 2.0+</p>

<h4><a name="Camel3.0-Roadmap-ClearerArchitectureofCamelCore"></a>Clearer
Architecture of Camel Core</h4>

	<li>The camel components should know as little as possible about camel core</li>
	<li>The classes needed to setup camel should be separate from the things needed at
run time</li>

<p>So why should this be important? Currently components depend on camel-core as a whole
and there are no further rules which classes the components should use and which classes should
be private to core. Even classes from the impl package are needed. So this means that any
refactoring we do in camel core could affect all components. As camel is growing steadily
this can become quite problematic.</p>

<p>Split camel-core into three parts:</p>

<p>api, builder, impl</p>

<p>These should be structured in a way that these big building blocks do not have cyclic
dependencies. Any other cycles can be ignored in this step.</p>

<p>Allowed depdencies ( "-&gt;" means may use, may depend on):</p>

	<li>* -&gt; api</li>
	<li>end user config code -&gt; builder</li>
	<li>builder -&gt; impl</li>

<h4><a name="Camel3.0-Roadmap-Routingengineoptimization"></a>Routing engine

<p>The internal routing engine should be optimized. See more details at <a href="/confluence/display/CAMEL/Camel+2.x+Speed+optimizations"
title="Camel 2.x Speed optimizations">Camel 2.x Speed optimizations</a>.</p>

<h4><a name="Camel3.0-Roadmap-Tightenuproutedefinitions"></a>Tighten up
route definitions</h4>

<p>Currently cross cutting concerns such as error handlers, interceptors, onCompletion
etc. can be define anywhere in the route. We should tighten this up and only allow this to
be configured in the start of the route. This also ensures when end users use code assistance
in their route development, the IDE will not popup a big list which includes these cross cutting
concerns. See also next note. (ProcessorDefinition will therefore be trimmed)</p>

<h4><a name="Camel3.0-Roadmap-Moreflexibleroutesatruntime"></a>More flexible
routes at runtime</h4>

<p>When routes is added in Camel 2.x architecture, global cross cutting concerns such
as error handlers, interceptors, onCompletion etc. is applied when the route is added. We
need to separate this and have those applied during routing. The <tt>Channel</tt>
needs to do this and therefore it must be more dynamic than its currently is. And we need
to enlist the various global cross cutting concerns by their xxxDefintions in the CamelContext,
so we can access them at any time. This allows end users also much more easily to add/remove
interceptors, error handlers and whatnot at runtime. And it makes it much easier to add routes
generated from JAXB or other sources, as we don't need to prepare or anyhow <em>mold</em>
the <tt>RouteDefinition</tt> given. See ticket <a href=""
class="external-link" rel="nofollow">CAMEL-3024</a> for some details. </p>

<h4><a name="Camel3.0-Roadmap-Supportforasynchronoustransactions"></a>Support
for asynchronous transactions</h4>

<p>When using the asynchronous routing engine it would be desirable of transactional
context could be propagated to the new threads.<br/>
This requires the TX manager supports suspend/resume on the TX. G.Nodet have worked a bit
on this. See <a href="" class="external-link"
rel="nofollow">CAMEL-2902</a>. Also see <a href=""
class="external-link" rel="nofollow">CAMEL-2729</a>.</p>

<h4><a name="Camel3.0-Roadmap-Remove@deprecated"></a>Remove @deprecated</h4>

<p>@deprecated features, methods, etc. is to be removed.</p>

<h4><a name="Camel3.0-Roadmap-Logging"></a>Logging</h4>

<p>We should switch from <tt>commons-logging</tt> to <tt>slf4j</tt></p>

<h4><a name="Camel3.0-Roadmap-Streamcaching"></a>Stream caching</h4>

<p>We could add support for using <a href="/confluence/display/CAMEL/HawtDB" title="HawtDB">HawtDB</a>
as the persistent store for streams which overflow to disk store.</p>

<h4><a name="Camel3.0-Roadmap-EIP"></a>EIP</h4>

<p>The <a href="/confluence/display/CAMEL/Resequencer" title="Resequencer">Resequencer</a>
EIP currently doesn't support persistence, we could introduce this and let it leverage <a
href="/confluence/display/CAMEL/HawtDB" title="HawtDB">HawtDB</a> such as we did
with the <a href="/confluence/display/CAMEL/Aggregator2" title="Aggregator2">Aggregator2</a>

<h4><a name="Camel3.0-Roadmap-ScheduleinDSL"></a>Schedule in DSL</h4>

<p>We could consider adding DSL syntax sugar for scheduling routes. For example currently
you have to use <a href="/confluence/display/CAMEL/Quartz" title="Quartz">Quartz</a>
or a <tt>ScheduledPollingConsumer</tt> which has the <tt>delay</tt>
option. We could add DSL which has something like:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
schedule().every(5).minute().pollFrom(<span class="code-quote">"xxx"</span>).to(<span

<p>The hard part is to come up with a good DSL syntax. We can look at <a href="/confluence/display/CAMEL/BAM"
title="BAM">BAM</a> and see what we got there as well.</p>

<p>The DSL should support both cron and non cron based, eg <a href="/confluence/display/CAMEL/Quartz"
title="Quartz">Quartz</a>, <a href="/confluence/display/CAMEL/Spring" title="Spring">Spring</a>
(spring 3 has cron) and regular JDK timers.</p>

<h4><a name="Camel3.0-Roadmap-Fixrouteswithmultipleinputs"></a>Fix routes
with multiple inputs</h4>

<p>The current implementation of routes with multiple inputs is to clone the route,
which means you essentially got 2+ routes if a route has multiple inputs. However routes with
multiple inputs is seldom used. The correct implementation is to only create one route but
have multiple input consumers. This change will require a bit of change in current code as
it relies on the <em>only 1 input consumer</em> on the route.</p>

<h4><a name="Camel3.0-Roadmap-UptodateScalaDSL"></a>Up-to-date Scala DSL</h4>

<p>The Scala DSL is slightly out of date as we have improved the DSL a bit here and
there. We should check the gap and ensure the Scala is up-to-date.</p>

<h4><a name="Camel3.0-Roadmap-MoreEIPsas@annotations"></a>More EIPs as @annotations</h4>

<p>Currently its only the <a href="/confluence/display/CAMEL/Routing+Slip" title="Routing
Slip">Routing Slip</a>, <a href="/confluence/display/CAMEL/Recipient+List" title="Recipient
List">Recipient List</a> and <a href="/confluence/display/CAMEL/Dynamic+Router"
title="Dynamic Router">Dynamic Router</a> which are avail as @annotation as well.
We could add more <a href="/confluence/display/CAMEL/EIP" title="EIP">EIP</a>s
as annotations such as <a href="/confluence/display/CAMEL/Splitter" title="Splitter">Splitter</a>.<br/>
And also maybe annotations for <tt>AggregationStrategy</tt> to make this less
Camel API dependent, so you can use a plain POJO for that.</p>

<h4><a name="Camel3.0-Roadmap-Asynchronoustransactions"></a>Asynchronous

<p>With the <a href="/confluence/display/CAMEL/Asynchronous+Routing+Engine" title="Asynchronous
Routing Engine">Asynchronous Routing Engine</a> it would be great if we could support
asynchronous transaction as well. See <a href=""
class="external-link" rel="nofollow">CAMEL-2729</a> and <a href=""
class="external-link" rel="nofollow">CAMEL-2902</a></p>

<h4><a name="Camel3.0-Roadmap-Unifiedstatistics"></a>Unified statistics</h4>

<p>Currently the performance statistics is only avail when using JMX. We should allow
those stats to be enabled regardless if JMX is enabled or not. Then we can use those stats
from the web console. This also allows to expose those stats in the cloud where JMX is often
not possible to be used.</p>

<h4><a name="Camel3.0-Roadmap-SEDA%2FVMcomponentstoleverageasyncroutingengine"></a>SEDA/VM
components to leverage async routing engine</h4>

<p>This allows to use non blocking request-reply over <a href="/confluence/display/CAMEL/SEDA"
title="SEDA">SEDA</a> and <a href="/confluence/display/CAMEL/VM" title="VM">VM</a>.
The reason why we havent converted in 2.4 is it causes a bigger API breakage. </p>

<h4><a name="Camel3.0-Roadmap-camelosgitest"></a>camel-osgi-test</h4>

<p>When testing your Camel apps with OSGi you may use PaxExam for that. We should create
a test kit for osgi, like we have camel-test for regular junit testing. The test kit should
make it easy for end users to have their apps tested with OSGi. We already have pieces in
the <tt>tests/camel-itest-osgi</tt>. We just need to clean and shape it up so
its ready for end users as well. And of course add documentation as well.<br/>
And then we should use it in <tt>camel-itest-osgi</tt> of course.</p>

<h4><a name="Camel3.0-Roadmap-REST"></a>REST</h4>
<p>We already have REST support with <a href="/confluence/display/CAMEL/CXFRS" title="CXFRS">CXFRS</a>
and <a href="/confluence/display/CAMEL/Restlet" title="Restlet">Restlet</a> but
it can be better. We should make sure those components is dead easy to use and you can invoke
REST services in one line of code etc. And we should make more examples and tidy up the <a
href="/confluence/display/CAMEL/CXFRS" title="CXFRS">CXFRS</a> documentation.</p>

<h4><a name="Camel3.0-Roadmap-Moreloadtests"></a>More load tests</h4>
<p>More load tests for frequently used Camel components (jetty, jms ...) and camel-core.</p>
	<li>Ensure correct behaviour under load</li>
	<li>Source for performance numbers (throughput etc).</li>
	<li>Detection of memory leaks</li>
	<li>Detection of performance decreases after refactorings</li>

        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href=""
class="grey">Change Notification Preferences</a>
        <a href="">View
        <a href="">View
        <a href=";showCommentArea=true#addcomment">Add

View raw message