Revision 1 as of 2008-06-12 01:11:06
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|This is a proposal for how to deal with the alternate Axis2 WSRM implementation that has been donated to Apache [https://issues.apache.org/jira/browse/SANDESHA2-144]||This is a proposal for how to deal with the alternate Axis2 WSRM implementation that has been donated to Apache [[https://issues.apache.org/jira/browse/SANDESHA2-144]]|
|Line 6:||Line 6:|
|[http://incubator.apache.org/learn/rules-for-revolutionaries.html Rules for revolutionaries]||[[http://incubator.apache.org/learn/rules-for-revolutionaries.html|Rules for revolutionaries]]|
This is a proposal for how to deal with the code known as Mercury
This is a proposal for how to deal with the alternate Axis2 WSRM implementation that has been donated to Apache https://issues.apache.org/jira/browse/SANDESHA2-144
Firstly, it has been suggested that anyone participating in this discussion familiarize themselves with: Rules for revolutionaries
Secondly, this proposal is open for discussion, editing and modification. It is in the wiki to encourage free editing and involvement in the Apache WS and Sandesha communities.
- There will be a new branch created in SVN for Mercury. It will not replace the Sandesha2 trunk.
- This is not a proposal to replace Sandesha2. It is a proposal to write a new implementation with a different core design. Of course much can be learnt from Sandesha2 and if possible code re-used.
- The aim of Mercury will be to create a WSRM implementation that:
- Is based on a state machine model
- Has a clean separation between the WSRM 1.0 and WSRM 1.1 logic
- Has a clean separation of the logic for Replay and Make-Connection
- Has excellent performance (comparing with RM vs without should have minimal impact when using in-memory)
- Has clean, maintainable, well-documented code
- Interoperates with Sandesha2, .NET and other implementations of WSRM
- Supports persistence and in-memory
- Supports transactions
- The Rules for Revolutionaries are very useful but may not completely fit this model. In that, there is an assumption that the revolution either replaces the existing code or dies. Neither may happen in which case we will diverge from the RfR.
- We want to have the discussion in the Sandesha community - the community has a significant proportion of the world's experts on implementing WSRM, and the ideal scenario is that this knowledge gets shared during the design and coding of Mercury. Therefore it is proposed that the discussion happens on sandesha-dev with a prefix of [Mercury] to help filter it.
- We need to validate the approach with the incubator/legal teams - that it is ok to do a software grant from existing committers into an existing community. This has been done before in the Apache WS project but we should be clear in case the policy has changed. However, this clearly requires that the existing community (Apache WS/Sandesha) is willing to accept the code, so the proposal is to wait until there is agreement on this proposal (or it is kicked out!).