[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Service inteface
yes please send it to me directly.
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
> 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.
> Christian Chevalley wrote:
>> 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
>> 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
>> Kind regards,
>> -----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.
>>> 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
>>> 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
>> 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
>> 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
>> example in
>> 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
>>> Christian Chevalley
>>> Austco Communications
>>> Phone: +61 8 9244 4499
>>> Fax: +61 8 9244 4727