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.
