Hi Guys, I also don't see any harm in starting Mercury as a test implementation under sandesha2. May be we can start it in the scratch area and do a serious performance comparison in a couple of months. (after Mercury become rich with the missing pieces David had mentioned).
Thanks, Chamikara On Mon, May 5, 2008 at 4:00 AM, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > Both projects will carry the term "WS-RM implementation from Apache", > which I think would confuse the user. > Any chance that it will go under Sandesha as a test implementation without > calling it the next version of Sandesha? > > If the performance figures are good (after implementing all what current > Sandesha2 supports) we can decide which path to continue. > > Thanks, > Jaliya > > ----- Original Message ----- > *From:* Amila Suriarachchi <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Monday, May 05, 2008 1:17 AM > *Subject:* Re: Mercury, a new WS-RM implementation > > > > 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. > >
