+1 to David. Apache/SOAP v2.2 is more stable and functional than Apache/ AXIS. To wit, it is more wide spread and placed in use than AXIS.
In software development process or software engineering, most of SDVs, if not all, support their existing product while they are developing the descendent product, or called new product, until their later product is ready for "prime time" -- by samelessly coping from David's mesage. A good example is the Apache/Tocmat team. While TC team were rearchitecturing the TC and developing the product for new Servlet/JSP spec, they also continusouly supported and released from the early v3.x to 3.3a during the development TC 4.x. This kinda efforts and process is we called the QUALITY-minded software engneering. If we don't catch the benefits out of this kind of process, it is indeed scary that we have those involved in the engieering process. Just because we are playing in the bleeding edge of open-source development and heading to new and emerging standards, the dev. team should not drop the existing and running product. In addition to that, the migration should not be forced to the "alpha-staged" product neither. Those decisions must be influenced by the user community and left to them to make their decision. And they will do when they feel and ready to do so bsed on the various reasons. It has been in that way and it will be so at least for a while. If you want to poll for continuously supporting the SOAP v2.2, inclduing the workarounds, patches et al, in the user community, be my guest. And you get +1 from me for sure. Pae > > The next version of Apache SOAP, i.e., Apache Axis contains this > > functionallity "built in". Under a license that you should find most > > accomodating. ;-) > > I was just told that won't work though without also going to Axis for the > SOAP implementation since Axis use JAX-RPC and SOAP 2.2 doesn't, thus > creating binding issues. I'm just not sure if Axis is "ready for prime > time" or not. I'll have to revisit it and see. We use 2.2 now, with SSL > and proxy at the same time (requiring a software patch to make that work), > and we'll just have to see how much effort/issue surrounds switching anytime > soon because of clients who use our existing SOAP apis. > > David >
