JIRA [EMAIL PROTECTED] wrote: > > > [ > https://issues.apache.org/activemq/browse/CAMEL-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40929 > ] > > 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! >
Hadrian, 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: http://www.nabble.com/-jira--Created%3A-%28CAMEL-280%29-Dynamic-Router-implementation-tp14523401s22882p14526264.html Sent from the Camel - Development mailing list archive at Nabble.com.
