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. thanks, Amila. > <http://incubator.apache.org/learn/rules-for-revolutionaries.html> > > 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.
