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'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'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]
