On Fri, Jun 13, 2008 at 7:40 PM, Jaliya Ekanayake <[EMAIL PROTECTED]>
wrote:
> Hi Amila,
>
> I have to correct something related to your previous post. This has nothing
> to do with the Mercury effort.
>
> You mentioned,
> AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
> people has joined and contributed to it at various times.
>
> It was not like this. When we design Axis2, we all (most of the axis devs)
> discussed the architectures for various modules such as Sandesha. Everybody
> was in agreement with the high-level details of the implementation as well.
> Chamikara and others (Sanka, me ....... (I am sorry if I miss anybody ))
> contributed to the initial code. Then Chamikara pushes it alone and later
> lot of devs joined the effort.
>
Thank you very much for the correction. I really apologize you. (Of course I
have written it under AFAIK).
> So, when there is a need people will jump in and I believe that it will the
> same for Mercury as well. As the starting point, I would like to know the
> architecture that you propose for Mercury. (This is not the simulator
> based architecture but how mercury is implemented as an Axis2 module, the
> handlers to be deployed, message receivers to be used etc...)
>
This is what I mean.
We can divide the Mercury into two parts.
1. The state machine model.
This is the part which ensure handling unreliability, proper message
flow, in order/exactly one delivery, sequence creation termination etc ...
roughly talking most of the aspects the WS-RM spec talks about. So I think
it is very easy to understand how mercury address those things in the
simulator model.
2. Implementation of this model as an Axis2 Module.
This is the part where its real implementation happens. To understand
this one should have a proper knowledge about the Axis2 Architecture and its
thread model, object model (Axiom) etc...
if you go to the module.xml file then you can understand what are the
handlers Mercury users and where each handler fit in each message flow.
(input, output and fault flows)
if you go to these handlers you can see it try to figure out the various
event receives using the action. then updates the state machine model
accordingly. First try to figure out the Duplex mode ( not anonymous). Which
is easier.
Any Axis2 module gets the messages from a handler. First Mercury try to
understand the MessageReceived using the Action. And the do the necessary
state machine updates.
There are separate set of threads called worker threads which do the
appropriate actions on the State machines according to their states.
thanks,
Amila.
>
> Thanks,
> Jaliya
>
>
> ----- Original Message -----
>
> *From:* Amila Suriarachchi <[EMAIL PROTECTED]>
> *To:* David Illsley <[EMAIL PROTECTED]>
> *Cc:* [email protected]
> *Sent:* Friday, June 13, 2008 4:04 AM
> *Subject:* Re: [DISCUSS] Mercury Proposal
>
>
>
> On Thu, Jun 12, 2008 at 9:32 PM, David Illsley <[EMAIL PROTECTED]>
> wrote:
>
>> On Thu, Jun 12, 2008 at 1:24 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
>> > Glen. I didn't think there was any consensus from the previous
>> > discussion (does the word dissensus exist?) :)
>> >
>> > I am actually pretty happy to do either, I think each approach has +s
>> and -s.
>> >
>> > On the side of starting from the Mercury codebase, Amila has got it to
>> > a point where it satisfies the 1.0 spec, including Replay.
>> > On the other hand, Mercury doesn't yet implement 1.1 or
>> > MakeConnection, and also it doesn't support transactions yet, so there
>> > are some fairly large aspects still to be coded. And starting afresh
>> > might well get more involvement from the wider community which I think
>> > has been the main pushback on this proposal so far.
>>
>> Clearly new code developed here will have far fewer legal issues (e.g.
>> the submitted Mercury has a hard LGPL dependency which would need
>> ironed out),
>
>
> definitely we have to remove the persistence module and re write it using
> direct JDBC. May be the first step to do if it going to apache. If we think
> that Mercury without that part, Then this problem is already solved.
>
> and would hopefully have a cleaner state machine model -
>> the Mercury one seems to have compromised for reasons which are pretty
>> opaque.
>>
>> > I guess one open question is - who is willing to put in the effort to
>> > work on this?! If it's just Amila, then starting afresh won't be much
>> > benefit, because he will be happier to keep working from the code he
>> > has already built.
>>
>> I'd certainly be interested in being involved in a new codebase, but
>> the amount of time I'd have to devote to it would be limited. If it's
>> just Amila, then my "Apache Way Sense" tingles to suggest that this
>> isn't really going anywhere in Apache, and probably shouldn't.
>
>
> AFAIK Sandesha2 has also started as an Axis2 module by Chamikara. Then
> people has joined and contributed to it at various times. Same thing may
> happen with the Mercury with the time. As Chamikara did with Sandesha2 I can
> initiate it with a new design. But this does not mean it will be a one man
> show for ever.
>
> thanks,
> Amila.
>
>>
>>
>> These 2 questions (legal and community) are some of the reasons why
>> the Incubator exists, and sort of points me back in that direction.
>>
>> David
>>
>> P.S. In writing this, it occurred to me that trying to write a common
>> WS-RM kernel that could be used with CXF and Axis2 might be a good
>> target, and that too, might point to the Incubator to help build a
>> broader community (not a fully formed thought though)
>>
>> P.P.S. I really like "dissensus"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
Amila Suriarachchi,
WSO2 Inc.
