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] > > -- Amila Suriarachchi, WSO2 Inc.
