[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] distributed cluster protocol

Hello Michael,
Michael Atighetchi wrote:

thanks for the quick and very nice answer on this one.

I completely agree with your options, and really like the message flow
diagram you guys put together recently.
That diagram was the sole fruit of Marcel's artistic vein and I must admit it helped me already meny times put an order in the caos I had in my head ;)

My plan is to stick with option c) for now and live with the potential overhead. I'll move over to option a) whenever changes to the core have been made (I would put changing the core to support a) low on the priority list unless anyone else needs this).

Thanks again for the great support - the recent interactions clearly
show that we made the right decision in choosing xmlblaster for our
project (instead of JBOSS JMS). Xmlblaster and its community rock !

Thanks for that! That's a very flattering note



On Tue, May 06, 2003 at 01:56:18PM +0200, Michele Laghi wrote:

Hi Michael,
I believe there are three possible solutions:

a) AccessMimePlugin
b) DispatchPlugin
c) I_MessageSecurityInterceptor

for a description of the plugins please have a look at:


Solution a) is probably the cleanest and better performing. It would imply some modifications to the interface itself (I_AccessFilter) from

boolean match(SessionInfo, SessionInfo, MsgUnit, Query) to
MsgUnit match(SessionInfo, SessionInfo, MsgUnit, Query)

Here the return value would be

- the message as you want to give it back to the subscriber,
- null if nothing has to be updated or
- the same reference as MsgUnit if it has to be sent without modification.

This solution would also need some (relatively simple) changes to the core.

Solution b) can be implemented without any modification but its implementation could be a little complex since the only example available is quite specific and not that simple (see the dispatch plugin).

Solution c) can be implemented right the way and is easy to implement. Just make an own implementation of the I_MessageSecurityInterceptor (and implement the exportMessage method). This is probably the easiest and fastest way to do it (probably just some hours) but it would be kind of a hack since you use the security plugin for purposes which are not security-related.

I said alternative a) is better performing because it modifies the message before putting it into the callback queue (b and c would do it after the queue). Since the dispatcher framework would put the message into the queue again in case of delivery failure, then for b) and c) you would modify the content before each trial while a) would do it only once.

Please let us know if you opted for solution a) since we would need to prepare the core for the changes.


Michael Atighetchi wrote:


is it possible to write a plugin for changing the behavior of a
xmlblaster server after it has matched publications with subscriptions?

I'm in need for this, as I'd like to only send a selective part of
the initially published information to the subscribers, and hence
would like to do post-matching filtering (would be a nice complement
to the PublishFilter plugin, which does pre-matching filtering).

If it's not high on anyones priority list, I might consider
implementing this myself and integrating it into the latest cvs
tree. Any opinions on the prefered design ?


Michele Laghi
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964