The other reason of course is that Axis is very easy to use. I haven't used JAXM or JAX-RPC so I can't compare, but we are doing interoperability testing between different SOAP implementations (mainly .Net so far), and have found it to be great. An example. If a .Net service is developed I can just point the WSDL2Java at the .Net wsdl url, and hey presto I have a working client. I can also have a working server as well (if I choose that option), and I only have to do the business logic part of the program as all the SOAP message handling is done for me.
Basically, given a WSDL file, you can get both a client and a server written and deployed in approx 5 mins. (This time obviously depends upon the complexity of the business logic as stated previously) That's why I'm using it anyway. Peter ----- Original Message ----- From: "Stan Jordan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Daniel Savarese" <[EMAIL PROTECTED]> Sent: Thursday, March 21, 2002 1:55 AM Subject: Re: why Axis? > Daniel... > Hoo-ahh. Bravo. You have shed very much light, and I am very much obliged. > Thank you, thank you, thank you! > Stan > > ----- Original Message ----- > From: "Daniel F. Savarese" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, March 20, 2002 6:05 PM > Subject: Re: why Axis? > > > > > > In message <003601c1d060$d5c3c7a0$9f05560c@DELL850>, "Stan Jordan" writes: > > >Every time I pick up a magazine, I see an article advising Java > programmers > > >to build Web Services via JAX-RPC and JAXM APIs. The articles are > complete > > >with lotsa examples (but do not mention Axis). > > > > As someone who wrote about JAXM and has been writing about XML/Web > services > > APIs, I'll make a few comments. First, so-called "standard" APIs > > coming out of the Java Community Process are subjects editors like to > > see articles about, so you'll tend to see a lot of them. Axis only > > recently entered beta and editors don't like to publish material that > > becomes outdated in the two months it takes for a submission to be > > published, so that's why it probably hasn't been covered. Now that Axis > > is in beta, I plan to write my next column (won't be published until July) > > on Axis because ... after having used JAXM extensively, I can certify that > > JAXM is an absolute piece of garbage that should never have passed muster > > (it barely did with a 7-6 vote). > > > > >Where does Axis fit into this picture? I don't want to sound rude, but > why > > >would I program with Axis, rather than using the JAX-RPC and JAXM APIs? > > > > One big reason to use Axis is that as you encounter deficiencies in design > > or functionality, you can bring them to light, discuss them, and submit > > patches. You can't do this with JAXM or JAX-RPC because not even the > > source code is available to you. JAX-RPC is much better designed than > > JAXM, but it is oriented strictly at RPC functionality and doesn't provide > > document-oriented SOAP manipulation functionality like JAXM's > javax.xml.soap > > package. Axis doesn't (or eventually won't) limit you to any one model. > > I'll let others go into more detail, but Axis is simply a more complete > > solution. JAXM should be avoided at all costs if you want to do > > asynchronous messaging (e.g., asynchronous messaging endpoints must be > > preconfigured before use; you cannot message to an arbitrary URL on the > > fly, only predefined URI to URL mappings) or manipulate SOAP messages > > on a fine-grained level. javax.xml.soap does not interoperate with DOM > > (which you need if you have a bunch of pre-existing DOM-based code) > > beyond allowing you the entire content of a message to be set from > > a javax.xml.transform.Source. The only piecemeal message modification > > supported is with the javax.xml.soap.Node derived classes. > > > > >speculate beyond JAX-RPC and JAXM (to say, JAXB) that would be very cool. > > > > Regarding JAXB, many people (including myself) have found that it's too > > early to use it even though it looks very good so far (it's not expected > > to be finalized until Q3 or Q4). Forget about trying to make JAX-RPC or > > JAXM play well with JAXB (eventually they'll have to play well together, > > but I doubt they will until sometime in 2003). Castor is a much more > > productive investment of your time. > > > > I haven't really justified my statements, but they come from the school > > of hard knocks: trying to use the so-called standards and abandoning them > > because of their inability to meet my application development > requirements. > > > > daniel > > > > > >
