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