[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Service inteface
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.
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 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.
> 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. 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
> 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
> 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?
>> Christian Chevalley
>> Austco Communications
>> Phone: +61 8 9244 4499
>> Fax: +61 8 9244 4727