RE: [xmlblaster-devel] Service inteface

["Christian Chevalley" <christian.chevalley at austco.com>]

Hi,

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:

    <get>
      <key oid='_query' queryType='EXACT'>
      </key>
      <qos>
        <querySpec type='a_plugin_type' version='a_plugin_version'>
          <![CDATA[query_parameters]]>
        </querySpec>
      </qos>
    </get>

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:

QuerySpecPlugin[queryTest][1.0]=com.company.plugins.QueryTest

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.

Kind regards,

Christian


-----Original Message-----
From: owner-xmlblaster-devel at server.xmlBlaster.org
[mailto:owner-xmlblaster-devel at server.xmlBlaster.org] On Behalf Of
Marcel Ruff
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 
filters'?

Is your QueryPluginManager directly operating on the I_Queue 
implementation or
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 
example in
xmlBlaster/src/java/org/xmlBlaster/engine/mime/xpath/XPathFilter.java:22
0?

If you use the OID as the decision to choose your plugin, this would 
mean that
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 
missing features?

thanks
Marcel
> Cheers,
>
> Christian Chevalley
>
> Austco Communications
> http://www.austco.com.au
> Phone: +61 8 9244 4499
> Fax:   +61 8 9244 4727
>
>
>