camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james.strac...@gmail.com>
Subject Re: Abstracting Routes using Components
Date Tue, 26 Oct 2010 14:46:31 GMT
Hi Kristof

BTW I raised a thread on the dev list to describe our chat...
http://camel.465427.n5.nabble.com/implementing-Protocols-or-a-way-to-make-it-easier-to-black-box-routes-and-compose-them-with-other-ros-td3218777.html#a3218777

On 24 October 2010 22:19, kristofsajdak <kristof.sajdak@gmail.com> 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="{{data.in}}"/>
>            <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...
http://camel.465427.n5.nabble.com/implementing-Protocols-or-a-way-to-make-it-easier-to-black-box-routes-and-compose-them-with-other-ros-td3218777.html#a3218777

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: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

Mime
View raw message