ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "FrontPage/ws-sandesha/MercuryProposal" by PaulFremantle
Date Thu, 12 Jun 2008 01:11:11 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by PaulFremantle:
http://wiki.apache.org/ws/FrontPage/ws-sandesha/MercuryProposal

New page:
=== 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:
[http://incubator.apache.org/learn/rules-for-revolutionaries.html 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:
  i. Is based on a state machine model
  i. Has a clean separation between the WSRM 1.0 and WSRM 1.1 logic 
  i. Has a clean separation of the logic for Replay and Make-Connection
  i. Has excellent performance (comparing with RM vs without should have minimal impact when
using in-memory)
  i. Has clean, maintainable, well-documented code
  i. Interoperates with Sandesha2, .NET and other implementations of WSRM
  i. Supports persistence and in-memory 
  i. 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!).


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message