camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Abstracting Routes using Components
Date Tue, 26 Oct 2010 15:17:56 GMT
So the idea is to use route templates and in order to parameterized them use URIs the camel
way. That's nice and consistent.
Not sure though it a component is the best way to go. To me this is similar to another idea
discussed a while ago, lightweight routes (sub-routes, routelets ?)
that do not have the DLC, are,well, lightweight and are composed into a route.

My $0.02,

On Oct 26, 2010, at 10:46 AM, James Strachan wrote:

> Hi Kristof
> BTW I raised a thread on the dev list to describe our chat...
> On 24 October 2010 22:19, kristofsajdak <> wrote:
>> Hi,
>> I'm currently working on a poc for a customer.
>> As part of their core business they offer a platform which mediates between
>> trading partners.
>> What is special about their use case is the fact that they want the actual
>> routes between
>> partners to be defined by employees with limited technical knowledge
>> (solution consultants).
>> I know there is the xml dsl and the upcoming camel rider which lowers the
>> threshold for non developers.
>> But even when using these features, the route configuration would be way too
>> fine grained for them and
>> they would still require too much knowledge on the details of the technical
>> components.
>> Last week I was at the FUSE community day in Paris and spoke to James
>> Strachan on the customer
>> need to abstract some parts of the routes. He mentioned the idea of using a
>> component as a kind
>> of proxy for a route.
>> I believe this is a real nice solution to the problem.
>> A complex route were a pdf is generated from an xml using xslt and fop and
>> the result is signed using a
>> third party service exposed over http could be reduced to the following.
>>        <route>
>>            <from uri="{{}}"/>
>>            <to
>> uri="route:generateAndSignPdf?signatureReason=JustForFun&amp;signatureVisible=true&amp;xslUri=com/xti/poc/camel/route/sample1/krusty.xsl"/>
>>            <to uri="{{data.out}}"/>
>>        </route>
>> The route component concept abstracts the route low level technical details
>> and makes reuse easy.
>> The solution consultant only needs to define the route:generateAndSignPdf
>> with the correct parameters.
>> As this construct would provide great value to the customer I went ahead and
>> implemented this idea as part of the poc. Attached to this post is my
>> codebase with a unit test executing the scenario mentioned above.
>> I would really appreciate some feedback from the community on the code I
>> wrote.
>> I tried fitting this in with the component lifecycle the best I could but
>> still have some doubts on whether it's done correct.
>> Getting an expert opinion on this would be a big help.
> Great stuff Kristof!
> I also met a bunch of folks at the recent FuseDay in Washington who
> had similar ideas and use cases too; this general approach and idea
> seems to be gaining momentum.
> I think its going to be increasingly common to take some routes, wrap
> them up in a 'black box' as a 'Protocol' that can then be handed off
> to other users/scenarios which are then configured and/or routed into
> or out of.
> As I mentioned in the previous thread...
> I like the idea of using a component instance for each 'black box' (or
> protocol lets say); as this then provides a nice name scoping for
> endpoints.
> For example imagine if the "generateAndSignPdf" protocol had a single
> input ("in") and a default output ("out")  along with a failure
> endpoint ("err") - then we have in/out/err like unix pipes.  (Note a
> protocol could have a completely arbitrary number of inputs and output
> endpoints - am just thinking the in/out/err are common)...
> You could then wire into the black box as...
> <!-- we can route from multiple physical endpoints to the logical
> input endpoint... -->
> <route>
>  <from uri="activemq:SomeInputQueue"/>
>  <to uri="generateAndSignPdf://in"/>
> </route>
> <route>
>  <from uri="file://someDir/foo"/>
>  <to uri="generateAndSignPdf://in"/>
> </route>
> If you then wanted to process the output of the protocol...
> <route>
>  <from uri="generateAndSignPdf://out"/>
>  <to uri="activemq:SomethingOrOther"/>
> </route>
> In this example we're hiding the protocol behind a component URI
> naming convention and we can then refer to the logical exported
> endpoints by name which then map to actual physical endpoints. If the
> black box were totally stand alone & it wasn't intended for Camel to
> route into/out of it, then you might as well just make this protocol a
> bean...
> <bean id="foo" class="com.acme.MyRouteBuilder">
>  <!-- lets configure the endpoints used in the route builder... -->
>  <property name="in" vallue="activemq:UseThisInputQueue"/>
>   ...
> Or to say that a slightly different way; if you just want a
> parameterised RouteBuilder, well thats just a bean; no need for
> anything new, Camel can do that nicely today. Whats different about
> this idea of "Protocols" and a ProtocolBuilder is the idea we can add
> the ability to expose endpoints within the namespace of the
> component/bean which you can route to outside of the Protocol. So its
> not just a black box; its a black box with defined public connector
> endpoints folks can route to without needing to understand any
> knowledge of whats inside.
> As Willem mentioned on the previous thread; we could have a single
> component for these 'protocols'; though given the simplicity and URI
> naming simplicity; I'm preferring to combine the RouteBuilder and
> Component together into a single bean - which can then be configured
> using Dependency Injection, but can also expose arbitrary logical URIs
> which lets other folks route into and between these Protocols
> e.g. we can create many instances of protocols; each get their own
> unique URI scheme in Camel and we can easily refer to the in/out/err
> of those protocols (if they use a standard shape of input/outputs).
> -- 
> James
> -------
> FuseSource
> Email:
> Web:
> Twitter: jstrachan
> Blog:
> Open Source Integration

View raw message