A given exchange can only be used between two endpoints. Though a given endpoint could create several copies of the incoming exchange and forward then to different destinations. This is what is done by the servicemix-eip static recipient list.
On Mon, Feb 9, 2009 at 11:54, Gabriela Gheorghe <[email protected]> wrote: > Thanks again for the explanation, Guillaume! > > Related to the same matter - another question would be whether this > route-altering could be done using a publish-subscribe mechanism (e.g., in > the NMR, one exchangeListener could subscribe to listen to me-s from certain > a group of endpoints and not another group) that already exists. You > mentioned some clustering logic - I don't know much about it, but probably a > pub/sub could be useful in several situations. > > Thanks again! > > Best, > Gabriela > > -----Original Message----- > From: Guillaume Nodet [mailto:[email protected]] > Sent: Thursday, February 05, 2009 8:11 PM > To: [email protected] > Subject: Re: altering routing within the NMR > > When intercepting the exchange, you can either: > * process it and let the routing unchanged > * re-route it to another endpoint > > If you choose the later (that's what the code I gave do), the exchange > will not be between A and B, but between A and C. C needs then to > create a new exchange and send it to B, so you end up with A -> C -> > B. Of course, you should not intercept the exchange C -> B, else, you > would loop. However, the test in the implemenation I gave take care > of intercepting only *new* exchanges: those that are active, have a > consumer role and have an In message, without any out or faults. > > If you choose the former, you need to process the exchange > synchronously: when the call to exchangeSent() returns, the exchange > will be delivered to the target endpoint (B if the routing has not > changed) immediately. > > If the processing is simple (modifying the content / properties), go > with the simple way. In my case, I was in need for rerouting the > exchange to go through a JMS layer between A and B endpoints. > > Hopes this help. > > On Thu, Feb 5, 2009 at 17:21, Gabriela Gheorghe > <[email protected]> wrote: >> Thanks for the hints, Guillaume and Gert! >> >> The code seems pretty straightforward (apart from the createMap call). >> >> The observation is that leaving the source and destination endpoints >> untouched, might cause a loop. >> >> Here's why: A sends a ME for B, the NMR intercepts the ME and forwards it > to >> C; C performs some modifications on the ME but does not tamper with the >> source and destination endpoints (otherwise the ME would not work as it >> should and the mechanism would no longer be transparent for A and B) and >> then it sends the same ME to the router. The router is supposed to send > the >> ME to B. But the router will intercept it again via this same mechanism, >> because the ME would have the same source and destination. >> >> Where am I missing something? There should be a way to tell apart the >> initial ME and the modified one - can it be done via the property object, >> without generating too much overhead? >> >> Cheers, >> Gabriela >> >> -----Original Message----- >> From: Guillaume Nodet [mailto:[email protected]] >> Sent: Thursday, February 05, 2009 3:09 PM >> To: [email protected] >> Subject: Re: altering routing within the NMR >> >> As Gert said, we haven't any generic solution for servicemix 4, though >> I was in need for that for the clustering stuff. >> The idea is to use an ExchangeListener and intercept new exchanges. >> Here is the code I have so far: >> >> public void exchangeSent(Exchange exchange) { >> // Intercept exchanges >> if (exchange instanceof InternalExchange >> && exchange.getStatus() == Status.Active && >> exchange.getRole() == Role.Consumer >> && exchange.getOut(false) == null && >> exchange.getFault(false) == null) { >> // Filter JBI endpoints >> InternalEndpoint source = ((InternalExchange) >> exchange).getSource(); >> for (ClusterRegistration reg : getServices()) { >> if (reg.match(source)) { >> >> > exchange.setTarget(getChannel().getNMR().getEndpointRegistry().lookup(Servic >> eHelper.createMap(Endpoint.NAME, >> name))); >> return; >> } >> } >> } >> } >> >> As you can see, the exchange is routed and the target overwritten. >> This will re-route the exchange to a known endpoint. >> In this case, the old target is discarded and will be recreated by the >> endpoint itself, because we still have the JBI addressing properties >> available. Another way would be to save the old target into a >> property on the exchange that would be later used by the endpoint. >> >> On Thu, Feb 5, 2009 at 11:59, Gabriela Gheorghe >> <[email protected]> wrote: >>> Hi, >>> >>> >>> >>> I need to do a bit of tuning inside the NMR so that messages sent to and >>> from the SAs could be transparently sent to a certain configurable >> endpoint >>> prior to taking their actual route. This of course without having to >> change >>> the routes already associated with the deployed components. >>> >>> >>> >>> Could you please tell me what I should do/use in this case? >>> >>> >>> >>> Thanks in advance, >>> >>> Gabriela >>> >>> >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
