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


Reply via email to