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

Re: [xmlblaster-devel] Service inteface



Hi Christian,
yes please send it to me directly.

regards
Michele

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