camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Przemyslaw Budzik <>
Subject Re: [jira] Commented: (CAMEL-280) Dynamic Router implementation
Date Fri, 28 Dec 2007 14:09:11 GMT

JIRA wrote:
>     [
> ] 
> Hadrian Zbarcea commented on CAMEL-280:
> ---------------------------------------
> Great initiative!
> I think we'll need to think a bit about this one.  AFAIK, the intent
> behind CAMEL-8 is to support the following scenario:
> * client sends message to router (camel)
> * camel processes and send to a server, server replies, but the response
> contains a service url (e.g. a 'createAccount' operation that returns the
> url for the newly created Account service).  Now the issue is that the new
> url may be of no use to the client for quite a few reasons, for instance
> client may not support the protocol - but camel does - or the server may
> be behind a firewall, accessible to camel, but not to the client)
> * camel creates new endpoint and deploys route to the new service,
> modifies the response to send its own url back to the client
> We can implement a control feature in camel to support dynamic creation
> and deployment of routes.
> From looking at your patch, i am not sure how it's different than using a
> Processor.  Do I miss something?  How is your scenario different from
> CAMEL-8?
> I'll be out for a week, but I'd be more than happy to tackle this one when
> back.  Happy New Year!


Right, I shouldn't have named it like that. It is undoubtedly not a DR.
However it seems that your description/vision doesn't fit in description of
that pattern from EIP site either. I've just read it and from my
understanding DR is a subsystem/design that is kinda repository of N
endpoints + rules. initially N may be equal to 0. there are two channels:
input and control. messages sent to control channel are supposed to
configure DR - probably providing endpoints and assigned rules. DR can
add/deploy new endpoints and apply rules to incoming messages in order to
route them to proper endpoints.
It is fairly complicated pattern. No question about that. Anyway I've been
thinking about it for couple of minutes ;-) Starting to (dis)like it.

Going back to your questions. Scenario is different, right, again I was
wrong. Let's say it's DR in 10% ;) It is different from using processors by
its aesthetic form. It is always better to express more via DSL, syntax is
more compact. Moreover it is real life need (it solves my problem). Still
think that it brings some value. I mean we have message and we want to apply
rules to decide where it should go next, dynamically. Of course it is not
DR, but still does its job. Maybe I am that wrong that there is exactly the
same functionality in DSL already, but I know only about recipientList. It
is ok, but may be either static or expect precalculated value. Here, this is
two in one. We focus on processing rules, in other words it is only one node
in flow. It may provide implementations ready to use eg. for Drools etc.etc.

View this message in context:
Sent from the Camel - Development mailing list archive at

View raw message