I think it would be beneficial for the project to have a clear distinction between the WS-BrokeredNotification engine and its web service binding, so that it could be reused without any binding inside ServiceMix. My understanding is that the POLOKA implementation goes way beyond what ServiceMix WS-BrokeredNotification engine currently provides, so ServiceMix may be able to switch to use it. About the RETE engine, it would also be nice to ensure that this engine is reusable by itself and may become a subproject on its own (or maybe even a TLP at some point).
I also think, that aiming for its own TLP may be better for POLOKA, but it will be to the PPMC to decide when times to graduate comes. Imho, we should just start a vote at some point on the incubator mailing list, which should be able to sponsor this project itself (there is no requirement to have any other TLP so sponsor a podling). That said, I'd like to offer my help as a mentor on this project. On Fri, Nov 7, 2008 at 9:54 PM, Mankovskii, Serge <[EMAIL PROTECTED]> wrote: > Hi Davanum, > > > > In our search for a Champion and Sponsor for the Poloka proposal > http://wiki.apache.org/incubator/PolokaProposal We looked into the > Savan, ServiceMix, Axis2, and MUSE projects. > > > > We find that it makes most sense, so far, to have Poloka as a project > under Axis2. It also makes sense to go into the ServiceMix, that > implements WS-Notification already, but objectives of ServiceMix and > POLOKA are somewhat different in respect to POLOKA goal to provide a > stand-alone reference implementation of the spec. Bringing entire > ServiceMix in the picture might be too much. However ServiceMix could > benefit from the POLOKA work in the future. > > > > Poloka (http://poloka.org) could create an Axis2 module implementing > handlers creating a messaging network for a federation of Axis2 servers. > This way we would be able to support > > - Standalone WS-Notification compliant notification producer and > notification consumer > > - Standalone WS-BrokeredNotification broker > > - Federation of WS-BrokeredNotification brokers. > > > > It would make sense to integrate Savan functionality within Poloka as > time goes but not other way around. I think so because Poloka objective > is broader than Savan objective in respect to: > > - Broker support > > Broker support is defined in WS-Notification and not in WS-Eventing. > Although it is possible that once a broker with WS-Eventing interface is > created, the picture might change. > > - Subscription > > WS-Eventing defines subscription language based on XPath (content-based > semantic). WS-Notification defines subscription Filers using Topic > Dialects (topic-based semantic), XPath over message content > (content-based semantic, same as in WS-Eventing), and resource > properties (optional and unclear semantics, needs refinement in the > spec). > > - Matching performance > > It seems that we can improve performance of XPath matching based on the > research done by the PADRES http://research.msrg.utoronto.ca/pub/Padres > project. It would be equally applicable to WS-Notification and > WS-Eventing. Naweed Tajuddin, a Master student of Prof. Arno Jacobsen, > is looking specifically into this issue for his master thesis. > > > > What do you think? > > > > We are looking for the input and guidance of the Apache community in > moving the POLOKA proposal forward. Please help! > > > > Regards > > Serge > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
