On Mon, May 5, 2008 at 5:34 PM, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
> 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). As I mentioned earlier we have started this as a WSO2 commons project. And also we have used this one of our customer projects and now we have to add some improvements for them. On the other hand Synapse and WSO2 ESB has started to use the Mercury. So we have hardly any option in keeping Mecury as only a test branch. I think the possible option is to go ahead as WSO2 Mecury, put all the Sandesha2 features and consider again this option from another time. thanks, Amila. > > > 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. > > > > > -- Amila Suriarachchi, WSO2 Inc.
