Deepal, that's cart before the horse .. this project needs to get to
graduation first :).
Serge, are you asking for the WS PMC to sponsor this project for incubation?
If so, how does this relate to the WS-Notification impl we already have on
top of Axis2? (Muse?) Having one by no means does not mean there can't be
another; just trying to understand the relationship.
Is there code already developed that you're looking to contribute to the
ASF? Or are you proposing to write new code?? The first line of the
proposal starts with "Poloka will be a standalone reference implementation
..". Later text suggests there's working code, but if there is no working
code the right model is to join the existing community and build on that
codebase.
What does "reference implementation" mean?
[Hi Peter (Niblett)! Long time :) ..]
Sanjiva.
Deepal jayasinghe wrote:
I think we can keep this as the same level as Sandesha and Ramparrt. I
mean we do not have any modules other than core stuff under Axis2.
Deepal
Serge,
Unfortunately i won't be able to help much at this time due to time
pressures. Hopefully one of my fellow PMC members may be interested in
moving this forward. Best Wishes.
thanks,
dims
On Fri, Nov 7, 2008 at 3: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
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
