Both projects will carry the term "WS-RM implementation from Apache", which I think would confuse the user. Any chance that it will go under Sandesha as a test implementation without calling it the next version of Sandesha?
If the performance figures are good (after implementing all what current Sandesha2 supports) we can decide which path to continue. Thanks, Jaliya ----- Original Message ----- From: Amila Suriarachchi To: [email protected] Sent: Monday, May 05, 2008 1:17 AM Subject: Re: Mercury, a new WS-RM implementation On Mon, May 5, 2008 at 10:32 AM, Amila Suriarachchi <[EMAIL PROTECTED]> wrote: On Mon, May 5, 2008 at 10:09 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amila, If it does the same things as Sandesha does it should *not* be in wscommons. It should be parallel to sandesha. yes Mercury does the same thing in a different way. My recommendation would be to use a branch named mercury under sandesha since i would treat it as a revolutionary branch of Sandesha and the work should be in full view of the dev list, the jira, commit list etc... http://incubator.apache.org/learn/rules-for-revolutionaries.html Could you please explain this bit more. As I saw here the idea is to do this as a separate branch and later merge to the trunk. I think this is not a practically feasible thing. if it is a different code base and can have independent releases (Mercury 1.0, Mercury 1.1 etc) that is fine with me. Here we can decided the name Sandesha2 2.x or Sandesha3. thanks, Amila. thanks, - -- dims Amila Suriarachchi wrote: | On Fri, Apr 25, 2008 at 5:13 PM, David Illsley <[EMAIL PROTECTED]> | wrote: | |> Amila, |> I've taken a pretty deep look, and while you've done a lot, |> nevertheless there appears to be quite a lot missing compared to |> Sandesha2. First and foremost, the lack of RM 1.1, MakeConnection 1.0 |> and any security integration for RSP compliance make it not very |> useful to me as-is. These are not small pieces of work and added |> significant complexity to Sandesha2, and in my view will also add |> significant complexity to Mercury. | | | I agree with you that adding new functionalities add more complexity to a | system. But on the | other hand I think we should not pessimistic as well. | |> |> I'm also in agreement with Jaliya that in the end, to support |> persistence, we'd need something like the Sandesha2 storage managers, |> (and while I really dislike the Sandehsa2 storage manager interfaces, |> I don't see anything particularly different in the Mercury persistence |> manager). I also have a number of concerns about the Mercury |> transactions/locking model. I've spent a number of months over the |> last year working on Sandesha2 performance including the |> transactions/locking model, and while it is not a thing of beauty, |> it's functional, flexible, and high performance. The substantial |> number of synchronized methods in the Mercury state model therefore |> worry me, and point to a lot of potential future work. |> |> Overall, while I rather like the idea of an RM implementation built |> around the state model, I think we've come a long way with Sandesha2, |> and that there's scope for evolving that platform in ways suggested by |> Mercury rather than by adopting it as a replacement codebase, and |> abandoning all the experience of Sandesha2. | | | I have not here suggested to abandon the Sandesha2. What I have suggested is | to | start the mercury as a new project. | I agree with you that Sandesha2 has come a long way and there is no point in | abandoning that. | And also I believe that implementing RM over Axis2 is a research oriented | work. Meaning no | one can say this is *the way*. Better thing would be to try out with | different things. | So do you mind starting the Mercury as another wscommons project and | proceed? In this way | we may have a similar comparison at about 6 months time and see whether what | we can do to | make a much better RM implementation. | | thanks, | Amila. | |> |> I'm not against the idea of a follow-on to Sandesha2 at some point, |> but I don't feel the time is currently ripe. When we do that I think |> we'll want to drop older function (not yet feasible) and use lessons |> from production experience, which I don't believe we have enough of |> yet. |> |> David |> |> On Tue, Apr 15, 2008 at 7:37 AM, Jaliya Ekanayake <[EMAIL PROTECTED]> |> wrote: |>> |>> |>> Hi Amila, |>> |>> Thanks for the comparison. I like the state machine model you have |> proposed. |>> However let me explain why we shift to a storage centric implementation |> in |>> Sandesha2. |>> |>> In Sandesha1 we have adopted the context based architecture |>> (http://ws.apache.org/sandesha/architecture.html) |>> Then in Sandesha2 we shift it to a storage centric architecture, mainly |>> because we need to support the persistence. In Sandesha2, most messages |> are |>> first pushed to the storage (either in memory or a database) and then |>> processed by the message processors. This ensures the persistence even |> with |>> the InOrder delivery assurance. (Remember we need to store the messages |> that |>> we have not processed to support this) |>> |>> So, IMO even with an state machine model, supporting the *real* |> persistence |>> requires a similar approach to the above. For example persisting the |>> InvokerBuffer will requires saving of few Hashtables which will |> ultimately |>> boils down to an storage manger. |>> |>> So, if you and the other Sandesha devs agree on moving forward with the |> new |>> implementation I would like to propose it as a continuation of the |> Sandesha |>> project rather than starting a totally new project. |>> |>> Cheers, |>> Jaliya |>> |>> ----- Original Message ----- |>> From: Amila Suriarachchi |>> To: Jaliya Ekanayake |>> Sent: Monday, April 14, 2008 10:53 PM |>> Subject: Re: Mercury, a new WS-RM implementation |>> |>> |>> |>> |>> On Wed, Apr 9, 2008 at 8:26 AM, Jaliya Ekanayake <[EMAIL PROTECTED]> |>> wrote: |>> |>>> |>>> Hi Amila, |>>> |>>> Could you please do the following. Do a comparison of what Mercury vs. |>> Sandesha that we can understand the requirement better. |>> |>> |>> I went through the sandesha2 architecture document and here are some of |> the |>> comparisons I could found. Please correct me if I wrong. This is only |> the |>> impression I got reading the architecture document. |>> |>> 1. Mercury uses a state machine model to handle RM specific tasks. |> (Handle |>> message loss, retransmissions, duplications). Sandesha2 do not have a |> such a |>> model and it handles these things at the persistence layer. As a result |> of |>> this Sandesha2 can not run without a persistence storage (i.e at least |> it |>> needs a inmomory data base). But for mercury persistence is an optional |>> extension. |>> |>> 2. In sandesha2 code there is a class used to handle Transactions. This |>> means Sandesha2 core is coupled with persistence. But for Mercury it is |>> fully decoupled with persistence. Transaction handling happens only at |> the |>> persistence implementation. |>> |>> 3. For Mercury there is no Message processor like in Sandesah2. For |> mercury |>> all the received messages are considered as events for State machine. |>> Therefore these events only update the state machine. |>> |>> Overall I think Mercury has a completely different architecture than |>> Sandesha2. |>> |>> thanks, |>> Amila. |>> |>> |>> |>>> |>>> |>>> This way you can show if you have handled cases that have not been |>> addressed by Sandesha 2. |>>> Thanks |>>> Jaliya |>>> |>>> |>>> |>>> |>>> |>>> |>>> ----- Original Message ----- |>>> |>>> From: Amila Suriarachchi |>>> To: [email protected] |>>> Sent: Tuesday, April 08, 2008 12:35 PM |>>> Subject: Mercury, a new WS-RM implementation |>>> |>>> |>>> |>>> |>>> |>>> |>>> hi all, |>>> |>>> Recently I developed a new WS-RM implementation called Mercury[1] |> (Mercury |>> is the messenger of God) which runs on top of Axis2. This mail is to |> make a |>> suggestion to donate the Mercury to Apache and hence start a new |> wscommons |>> project called Mercury. Following is a full description about how I |> started |>> it and current status of Mercury. |>>> Couple of months back I started looking into Sandesha2 to fix some |>> reported issues. Actually what I wanted was to get familiar with the |>> Sandesha2 code base. Although I went through some architecture documents |> and |>> some of the code I could not really understand most of the Sandesha2 |>> internals (My bad ). Then I went through the specifications and I saw a |>> state machine model has proposed in WS-RM 1.1 specification. |>>> I really interested about it and started to model a state machine for |> RM |>> 1.0. First I developed this using a pen and a paper and looked fine. |> Then I |>> started implementing it. |>>> Although I have worked more than one year with Axis2 I did not have a |> much |>> knowledge about axis2 kernel since my contribution mainly on Codegen. |>> Therefore I wrote an Axis2 simulator[2] and on top of that I implemented |> my |>> state machine. On the other hand concentrating more on Axis2 kernel |> would |>> have made this state machine implementation very difficult. This allowed |> me |>> to test this state machine model for various unreliable conditions and |> that |>> worked fine. |>>> Then I started looking into real Axis2 kernel code and implemented |> this |>> state machine model. For the first stage I implemented the WS-RM |>> specification which is about the Duplex channel mode. Then I implemented |> the |>> persistence model. This was very easy since the only thing I had to do |> was |>> to persist the state machine. Finally I was able to implement the Replay |>> model specification which uses the back channel to send the responses. I |>> tested all these scenarios for many unreliable conditions and it worked |>> fine. |>>> Since I myself is an apache comiter and I worked for an open source |>> company I would like to start this as an apache project. I hope this |> would |>> help others to use this code freely and make any contribution that they |>> would like to made. |>>> The attached patch contains all the Architecture documents and details |> of |>> the state machine model. I think going through the simulator code first |>> would make it easy to understand the real implementation. |>>> The name Mercury and the package structures are simply the internal |> names |>> I have chosen. I am open to change that name. (eg Sandesah3) And also I |> am |>> open to make any changes to package structure, design to suit to any |> other |>> requirements as well. |>>> We have our New year holidays (Sri Lankans celebrates New year on |> 13-14 |>> april :) ) until 15th. So please take your time and feel free to make |> any |>> thoughts. |>>> have attached the patch in here[3], |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> |>>> thanks, |>>> |>>> Amila. |>>> |>>> |>>> |>>> |>>> [1]mercury.tar.gz |>>> |>>> [2]Simulator.tar.gz |>>> |>>> [3]https://issues.apache.org/jira/browse/SANDESHA2-144 |>>> |>>> |>>> -- |>>> Amila Suriarachchi, |>>> WSO2 Inc. |>> |>> |>> -- |>> Amila Suriarachchi, |>> WSO2 Inc. |> |> |> -- |> David Illsley - IBM Web Services Development |> |> --------------------------------------------------------------------- |> To unsubscribe, e-mail: [EMAIL PROTECTED] |> For additional commands, e-mail: [EMAIL PROTECTED] |> |> | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIHo9sgNg6eWEDv1kRAu8VAKDUZ33lqrGK7MZc5jYNSKUAWjYh6gCgqxk0 XYBBOehO3fbIvubTAe0MFPc= =oChq -----END PGP SIGNATURE----- -- Amila Suriarachchi, WSO2 Inc. -- Amila Suriarachchi, WSO2 Inc.
