Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

      thanks,
      Amila.

      [1]mercury.tar.gz
      [2]Simulator.tar.gz

      1. mercury-0.91-src.zip
        799 kB
        Amila Chinthaka Suriarachchi
      2. Simulator.tar.gz
        319 kB
        Amila Chinthaka Suriarachchi
      3. mercury.tar.gz
        673 kB
        Amila Chinthaka Suriarachchi

        Activity

        Hide
        Amila Chinthaka Suriarachchi added a comment -

        Source code for mercury implementation

        Show
        Amila Chinthaka Suriarachchi added a comment - Source code for mercury implementation
        Hide
        Amila Chinthaka Suriarachchi added a comment -

        Axis2 simulater and initial design on top of it

        Show
        Amila Chinthaka Suriarachchi added a comment - Axis2 simulater and initial design on top of it
        Hide
        Hans G Knudsen added a comment -

        Hi Amila!

        I just ran a quick test of the Mercure RM implementation.

        When combining Mercury with Rampart and using the Replay Model the response to LastMessage does not get handled by Rampart.

        CreateSequenceResponse + Payload Response are handled.

        It seems that the

        msgCtx.getEffectivePolicy()

        is not available on for the LastMessage (response).

        The response is then sent without security. The Mercury based client receives the response - and gives a failure in Rampart - as no Security header is present.

        The client then sends TerminateSequence - which fails on server in Rampart on the response with an

        org.apache.rampart.RampartException: No security processing results from the incoming message

        The HTTP response given to the client is '202 Accepted' (empty message) - which is accepted by the client.

        /hans

        Show
        Hans G Knudsen added a comment - Hi Amila! I just ran a quick test of the Mercure RM implementation. When combining Mercury with Rampart and using the Replay Model the response to LastMessage does not get handled by Rampart. CreateSequenceResponse + Payload Response are handled. It seems that the msgCtx.getEffectivePolicy() is not available on for the LastMessage (response). The response is then sent without security. The Mercury based client receives the response - and gives a failure in Rampart - as no Security header is present. The client then sends TerminateSequence - which fails on server in Rampart on the response with an org.apache.rampart.RampartException: No security processing results from the incoming message The HTTP response given to the client is '202 Accepted' (empty message) - which is accepted by the client. /hans
        Hide
        Amila Chinthaka Suriarachchi added a comment -

        Can you take an update from here[1] Updating the src/main/java/org/wso2/mercury/state/InvokerBuffer.java would be enough.

        I fixed this issue. this is because of a change done to Axis2 regarding policy handling.
        With this fix I tested with the Axis2-1.4 RC3

        [1]https://svn.wso2.org/repos/wso2/trunk/commons/mercury

        Show
        Amila Chinthaka Suriarachchi added a comment - Can you take an update from here [1] Updating the src/main/java/org/wso2/mercury/state/InvokerBuffer.java would be enough. I fixed this issue. this is because of a change done to Axis2 regarding policy handling. With this fix I tested with the Axis2-1.4 RC3 [1] https://svn.wso2.org/repos/wso2/trunk/commons/mercury
        Hide
        Amila Chinthaka Suriarachchi added a comment -

        Mercury 0.91 source code

        Show
        Amila Chinthaka Suriarachchi added a comment - Mercury 0.91 source code

          People

          • Assignee:
            Unassigned
            Reporter:
            Amila Chinthaka Suriarachchi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development