-----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. 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 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----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
