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, Hadrian 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... > 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 <[email protected]> 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&signatureVisible=true&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: [email protected] > Web: http://fusesource.com > Twitter: jstrachan > Blog: http://macstrac.blogspot.com/ > > Open Source Integration
