[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xmlblaster-devel] Service inteface
Thanks for the quick reply. I realized I was not clear enough about this
hack, here are more details which I hope will shed some light on it...
A client does a sync query to XB with a get message such as:
<key oid='_query' queryType='EXACT'>
<querySpec type='a_plugin_type' version='a_plugin_version'>
Where 'a_plugin_type' is a plugin name as specified in
XmlBlaster.properties or preloaded with an entry in
XmlBlasterPlugins.xml. For instance in XmlBlaster.properties:
The query parameters are the usual (?) key1=value1&key2=value2&....
That is, oid = _query is fixed.
So far, there is no interaction with the msg queue, this implementation
is more to be seen as generalization of the current __sys_jdbc OID
serviced by the get method in RequestBroker. I made reference to the
AccessPluginManager relatively to its mechanism to load/cache plugins
but not in terms of logic associated to message processing.
From: owner-xmlblaster-devel at server.xmlBlaster.org
[mailto:owner-xmlblaster-devel at server.xmlBlaster.org] On Behalf Of
Sent: Saturday, 27 May 2006 12:53 AM
To: xmlblaster-devel at server.xmlBlaster.org
Cc: christian.chevalley at austco.com
Subject: Re: [xmlblaster-devel] Service inteface
Christian Chevalley wrote:
> Hi All,
> First, Thank you all for this great piece of code!
Nice to hear that you like it :-)
> We are using XB in one of our project for about 2 years now, pretty
> successfully. During the development we came across the need for an
> extensible service framework, similar to the filter mechanism
> implemented, to allow arbitrary handlers of synchronous gets. This
> service interface is used to direct synchronous gets to a Plugin
> specified in a QuerySpecQoS. It is triggered whenever the key OID is
> '_query', hardcoded for the time being like others well-know OIDs. The
> plugin is a standard I_Plugin, I_Query implementation. To achieve
> this, we patched the RequestBroker and implement a QueryPluginManager
> class which is basically a lighter version of AccessPluginManager with
> a much simpler logic. The QueryPluginManager is responsible to
> get/load plugins as well as maintaining a query plugins cache. As we
> are doing this for quite a while now and had to follow up integrating
> this hack for each new XB release I am wondering if this contribution
> is of interest, and, if yes, how to proceed to integrate this change
> into the main devel stream ?
Yes, this is principally possible, your patching to be done is probably
not very satisfactory.
But isn't this in conflict with a similar functionality
i just described in the other mail 'HistoryQos with sSQL92 subscrition
Is your QueryPluginManager directly operating on the I_Queue
is it filtering after the messages are retrieved (as in
RequestBroker.java:1012 of current svn).
The cache functionality: Is it similar to the MIME plugin cache, as for
If you use the OID as the decision to choose your plugin, this would
the *publisher* decides that the topic is generally using a filter
instead of each *subscribe* or *get* accessing client
to decide himself, this is probably a too rigid approach?
Does it make sense to merge the benefits of the two approaches? Is it
possible to port your approach to use our concept or are there
> Christian Chevalley
> Austco Communications
> Phone: +61 8 9244 4499
> Fax: +61 8 9244 4727