[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
>>>
>>>
>>>
>>
>>
>
>
>