RE: [xmlblaster-devel] Service inteface

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

Hi Michele,

OK how would you prefer me to send the code to you ?

No probs regarding the timeframe, I'm fairly busy at the moment...

Cheers -- Christian

-----Original Message-----
From: owner-xmlblaster-devel at server.xmlBlaster.org
[mailto:owner-xmlblaster-devel at server.xmlBlaster.org] On Behalf Of
Michele Laghi
Sent: Monday, 29 May 2006 9:02 PM
To: xmlblaster-devel at server.xmlBlaster.org
Subject: Re: [xmlblaster-devel] Service inteface


Hi Christian,
thanks for the further explanation. If I understood you right the
functionality you need is the Request Response pattern. Then the
business logic (what you execute in your plugin) would happen in a
service: another xmlBlaster client (could be standalone or a plugin). I
think we need to implement this pattern sooner or later since this is
one of the patterns specified in JMS.

I find your idea of wrapping this pattern behind our already existing
GET method a nice idea.

Since this solution is also related to issues such as
blocking/non-blocking get with or without timeout (which we currently
only have solved with administrative gets via the I_Query interface) I
would suggest that you send us the Code for the interface of the plugin
and the code where you invoke the plugin in the RequestBroker get
method.

This way we could discuss it to see if there are other use cases which
could benefit from this approach.

Note that due to our current schedules such a discussion could first
take place in aproximately two/tree weeks time.


Regards
Michele


Christian Chevalley wrote:
> 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
>>
>>
>>   
> 
> 
>