There are a few issues we need to sort out. One is that with something like
this:
> from("blackboxroute1://out")...
You'd have to deal with naming. If everybody will define her "blackboxroute1"
you'll have to deal with name clashes.
You can do something like "route:blackboxroute1://out". Then the lightweight
part I would like not to get lost in this discussion, as in no interceptors, no
dlc.
You can then have processing pipelines (as in subroutes, not camel pipelines, I
hope not creating confusion) that can be developed by independent groups and
reused.
Of course something like that can only be done today with direct: and seda:
based routes, but we can simplify that.
@James, I'll be in London for a couple of days. If you wanna chat about this
over beer on Thu evening (your treat :) ), please let me know.
Cheers,
Hadrian
On Oct 26, 2010, at 12:00 PM, James Strachan wrote:
> On 26 October 2010 16:40, Ashwin Karpe <[email protected]> wrote:
>>
>> Hi Hadrian,
>>
>> Not sure if you recall, but we had discussed a similar idea about 8-10
>> months ago when I was on a consulting gig where we were trying to do
>> something similar (not exactly components, but black boxed subroutes) so
>> that we could do something like
>>
>> from(route:blackboxedroute1)
>> .to(route:blackboxedroute2);
>>
>> where "route:..." was a pointer to an encapsulated route and would
>> instantiate the route on demand.
>
> BTW thats kinda the code Kristof submitted at the start of this thread
> if you take a look. Thats a totally valid approach too BTW.
>
> For this approach you suggest we need to expose the RouteBuilder as a
> named bean so the "route:" component can refer to it, right? So the
> endpoint "route:foo" refers to the "foo" RouteBuilder.
>
> The thing is a typical RouteBuilder might have many inputs and
> outputs; you typically want to be able to route to some of the
> endpoints inside some of the routes and from some of the endpoints. So
> how does this route: component know what endpoints are inside the
> black box RouteBuilder?
>
> So we're often not wrapping up a set of routes as a 'single endpoint'
> - but instead as a black box with a number of endpoints (say one "in"
> and an "out" and "err"). Or maybe multiple in and outs?
>
>
> This was why I suggested the ProtocolBuilder; let lets you take a
> RouteBuilder and turn it into a Component and provide a way of
> converting simple component relative endpoint URIs to actual
> implementation endpoints. e.g. using your example Ashwin...
>
> from("blackboxroute1://out").to("backboxroute2://in")
>
> Then in the ProtocolBuilder class, we do the normal RouteBuilder
> stuff, but also map some input/output names ("in", "out", "error" for
> example) to the actual physical endpoint URIs the routes are using.
>
> The only difference really between the 'generic route component' and
> the ProtocolBuilder I'm proposing is the latter provides a simpler
> endpoint naming approach and can deal with an arbitrary number of
> input and output endpoints. Plus I'm not quite sure how the former
> works when a RouteBuilder defines many inputs and outputs :)
>
> Maybe the "route proxy component" is good when you want to turn a
> RouteBuilder into a single Camel endpoint. The ProtocolBuilder is good
> when you want to turn a RouteBuilder into a number of named input &
> output endpoints - or when you want a simpler URI?
>
> --
> James
> -------
> FuseSource
> Email: [email protected]
> Web: http://fusesource.com
> Twitter: jstrachan
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
