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 > >
