Hi Dug, This sounds like a major re-arch of Axis 1.x. Do you see this being part of Axis 1.(x+1) or more say Axis1 2.0?
>From a project perspective, its perfectly fine and healthy to have multiple versions of a major project going (proof: HTTPD and Tomcat) but it does require a serious committment to keep this going. I'm curious whether the other regulars also feel this is the right thing to do: Glen/Dims/Tom/Steve/?. Of course, as a committer you are free to do this and push things out, but you'd have to be in it for the long run to make it work .. I guess that's more a PMC issue than anything else. Sanjiva. On Mon, 2006-01-23 at 07:18 -0500, Doug Davis wrote: > > Yes - I basically took the engine (client and server) and allowed each > side (send/receive) to be called independently. And it also includes > an async listener. It will also include the correct plug-points for > RM and security. From what little I've seen (at previous RM interops) > the current RM code had a lot of troubles and I think some of the > reorganization I've done will help that. > -Doug > > > > "Jaliya Ekanayake" > <[EMAIL PROTECTED]> > > 01/22/2006 10:05 PM > Please respond to > axis-dev > > > > > To > <[email protected]> > cc > > Subject > Re: integrating > wsa into core > axis > > > > > > > > > Hi Dug, > > When we design Axis2 we consider these two problems (WS-Addressing and > Async Support) as core problems in Axis and the solution we came up > was to split the send and receive paths in a message flow. This > mechanism works fine and Axis2 is able to support all the messaging > scenarios including fully asynchronous case (where a separate listener > is required in the client side) > > So just wanted to know, whether the changes you mentioned are similar > to the above for Axis? > > Thanks, > > Jaliya > ----- Original Message ----- > From: Doug Davis > To: [email protected] > Sent: Sunday, January 22, 2006 2:01 PM > Subject: integrating wsa into core axis > > > axis-dev'ers - I'd like take some axis changes I have and commit them. > The > first round of stuff focuses on splitting the axis engines so that it > can > more easily deal with async messages. In particular, in the stuff > I'd > like to commit soon (asap) it splits the client-side engine apart so > that > the two sides of the chains can be invoked separately. This, in > conjunction with moving WS-Addressing logic in the base Axis code, > allows > a client to more easily send and receive async messages. It also > allows > for other technologies, like WS-RM and WS-Security, to be more easily > plugged-in. The next set of changes (asap too :-) would do the same > thing on the server. One of axis's biggest flaws is its lack of > support > for async messaging - I think these changes will go a long way > towards > fixing that. Most of the changes don't actually involved new code - > rather simply moving things around since we still need to do the same > things, just in a slightly more modular way. Anyway, I've > discussed > this, off-line, with a couple of axis-dev'ers already and they were > in > favor of it but before I actually did it I wanted to make sure there > wasn't any huge objection to it. For the most part, if you don't turn > on > the WS-Addr support then nothing should really change - and there's > no > harm - but if you believe WS-Addr will be core to soap (as I do) then > having native support for it will benefit axis's customers. > thanks, > -Doug
