On Sat, Jun 14, 2008 at 12:43 AM, Chamikara Jayalath <[EMAIL PROTECTED]>
wrote:

> We actually considered this idea in the early phases of Sandesha2. After
> some discussions we thought of going for a Axis2 based one so that we can
> use all the features that are readily available with Axis2. These included
> the context hierarchy, pause/resume functionality, Messages Receivers, AXIOM
> etc.


I  agree with Chamikara.

As I have mention earlier Mercury has two parts. The real implementation of
Mercury/Sandesha2 or any RM implementation depends lot about Axis2
architecture and all the things Chamikara has mentioned. Therefore writting
a Common implementation will be a very complex one. For an example it always
depends on the MessageContext and its properties.

However As I showed earlier, The state machine model (given in simulator)
does not depends on the Axis2. So someone can implement that on top of CXF.

thanks,
Amila.

>
>
> Chamikara
>
>
>
> On Fri, Jun 13, 2008 at 1:15 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> Just FYI:  I'm also quite interested in the idea of a "generic" RM engine
>> that could be plugged in to various stacks/providers.   Things like WSS4J
>> and Neethi have been a big help to CXF (and probably others) specifically
>> because they were "generic" enough to be used outside of Axis.     In the
>> case of WSS4J, it has actually helped the WSS4J community as developers
>> working on CXF stuff have started contributing to WSS4J as well.   Fred
>> Dushin is now a committer on WSS4J specifically due to work integrating it
>> with CXF.  Sandesha could potentially benefit similarly if it can become
>> generic enough to not be considered "just a RM plugin to Axis 2".
>> Basically, this could be an opportunity to expand the Sandesha community,
>> and that's a good thing.
>>
>> Dan
>>
>>
>>
>>
>> pzfreo wrote:
>> >
>> > David
>> >
>> > I want to make it clear that I'm *strongly* hoping that there will be
>> > greater involvement than just one person.
>> >
>> > I also *really* like the idea of building an RM implementation that
>> > has a core model that is not dependent around a specific stack (Axis2,
>> > CXF). I have always believed that there is a space for a really stable
>> > and performant WSRM messaging engine and the Sandesha model - where
>> > the stack is in control and the messaging engine is "just" a set of
>> > handlers just doesn't feel to me like it can compete with a pure
>> > messaging option like ActiveMQ or QPid. So in many ways, starting from
>> > WSRM and treating the problem as "how to build a messaging engine that
>> > also happens to be able to fit into Axis2" would be very interesting
>> > to me.
>> >
>> > I am actually not against having an incubator proposal. The only
>> > challenge with the Incubator is that:
>> > 1) the incubator is fundamentally designed to bootstrap new
>> > communities. If there is an existing community already then it doesn't
>> > necessarily work. I would rather have this discussion on sandesha-dev
>> > than have to somehow encourage everyone from sandesha-dev to start
>> > paying attention to a new list.
>> > 2) The incubator is also about how to get non-Apache members involved.
>> > So far everyone interested in this is already a committer in Apache.
>> > So in fact, labs.apache.org is more appropriate.
>> > 3) The incubator is a hassle. Its a hassle for good reasons and I
>> > strongly support it. But if you don't need that hassle, then you
>> > shouldn't take it!
>> >
>> > How would a design that works across both CXF and Axis2 work? Its an
>> > intriguing idea.
>> >
>> > Paul
>> >
>> >
>> >
>> > On Thu, Jun 12, 2008 at 5:02 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), 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.
>> >>
>> >> 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]
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Paul Fremantle
>> > Co-Founder and CTO, WSO2
>> > Apache Synapse PMC Chair
>> > OASIS WS-RX TC Co-chair
>> >
>> > blog: http://pzf.fremantle.org
>> > [EMAIL PROTECTED]
>> >
>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-DISCUSS--Mercury-Proposal-tp17790601p17828246.html
>> Sent from the Apache Sandesha mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>


-- 
Amila Suriarachchi,
WSO2 Inc.

Reply via email to