I understand that WSDL 2.0 is not finished yet, I am on the working group. So is Sanjiva. But what I also know is that last call is over and we are about to enter the stage where the specification must have implementations before it can become final. I am expecting that Axis2 will be one of those ground breaking implementations. I would also note that WS-Addressing is not final either and yet we are still implementing that spec.
Adding preliminary WSDL 2.0 support give lots of people reason to start working/playing with Axis2, giving us much more valuable input on the whole system in the process. I do agree that it would be better to add this support when there is a wsdl24j library available. As far as WSDL 1.1 support, I believe this is not something we can just blow off with a "use Axis 1.x" statement. The fact of the matter is, to many users, WSDL *is* web services. If Axis2 doesn't get it at least as good as the existing Axis, this will be bad. It will be a PR nightmare if people download Axis2 1.0 and it can't even generate WSDL from their Java code, or consume the same services when presented with a WSDL. This is obviously my personal opinion, and I realize that I an unable to put code where my mouth is these days. But believe me when I say I am very hopeful and excited that Axis2 will be even more successful than Axis is. But I know our customers/users pretty well, and they are going to be confused/unhappy if Axis2 doesn't solve the same problems for them as Axis1 *plus* add something more. "Better Architecture" doesn't sell software, even open source, free software. :-) Let's frame the discussion like this: Can you describe the user/customer that will download and use Axis2 (aka "user stories")? I'll start with me: I am using Axis 1.2 embedded in my commercial product to support Web Services. From the publishing side, I create dynamic Java classes on the fly and pass them to Axis to get the WSDL for my services. I use the Provider/Handler architecture to dispatch incoming requests to services written in a custom scripting language by my users. I also support consumption of web services from my scripting language. A user passes a WSDL URL in, along with the parameters to the operation. I generate Axis stubs under the covers and invoke the Java stubs to take care of all the work on the client side, converting the results to objects in the scripting language. I hear about a new version of Axis, name Axis2. I have had some problems with the document/literal support in Axis1 and the type mapping system has been giving me trouble. I also have heard there is a support for many of the specification (Addressing, WS-Security) that my users have been asking for baked right in to Axis2, along with better performance. Also the Axis1 team doesn't seem like they will be adding support for WSDL 2.0, so I am hoping that the new version give me that too. Question: How do you sell me on Axis2? Why am I switching to it (which isn't cheap as the APIs are not compatible)? What benefits do I get? -- Tom Jordahl -----Original Message----- From: Srinath Perera [mailto:[EMAIL PROTECTED] Sent: Saturday, September 24, 2005 7:01 PM To: axis-dev@ws.apache.org Subject: Re: [Axis2] 1.0-alpha release did anybody use wsdl 2.0 for production? I know people will, but it is not a concern for the users right now. We relase for the real world .. to me holding axis2 out due to wsdl2 is unfair let us implemet the thing when spec is final, and wsdl4j equivalent comes out. I see know reason we need to dealy Axis2 for wsdl2. reagrding alpha vs .9x, alpha states that Axis2 1.0 near .. I belive features shouldnot change across alpha beta ..final ..so they are differernt from the 9.x Srinath On 9/24/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > Steve Loughran wrote: > > > Tom Jordahl wrote: > > > >> I would say that any Axis2 1.0 would have to fully support WSDL 1.1 > >> and WSDL 2.0 generation (from Java) and consumption (to Java). I > >> don't think we are there yet, particularly on the WSDL 2.0 front. > >> > >> > >> > >> I would much rather release early/often with a .92, .93, .95, etc. > > > > > > That might be a better approach. A point number to mean "ready to > > use", a value <1.0. > > I note that there is a very large number of floating point values > > between 0.92 and 1.0 > > +1 to .92 - in my interpretation, all the releases to this point have > been alpha releases. If the progressive version numbering suddenly > changes to "1.0 alpha" it's just going to confuse potential users. I'd > prefer to stick with .9X until a solid 1.0 release candidate is available. > > - Dennis >
