Re: [xmlblaster] distributed cluster protocol

[Michael Atighetchi <matighet at bbn.com>]

Michele,

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.

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 !

Michael




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:
> 
> http://www.xmlBlaster.org/MessageFlowPubSubOverview.html
> 
> 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.
> 
> Michele
> 
> 
> 
> 
> Michael Atighetchi wrote:
> >Michele, 
> >
> >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 ? 
> >
> >Michael
> >
> 

-- 
matighet at bbn.com   BBN Technologies