-----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]
