Please be careful with how you use the phrase "JAX-RPC". JAX-RPC is a specification. You folks are referring to it as an implementation (I assume you're talking about Sun's Java Web Services Developer Pack Early Access, which complies with JAX-RPC?).
One of the goals of AXIS is to fully comply with the JAX-RPC specification. We're not there, yet. But neither is the JAX-RPC spec! It's still a moving target, version 0.8, and won't become 'official' until probably sometime this summer. Russell Butek [EMAIL PROTECTED] "Daniel F. Savarese" <[EMAIL PROTECTED]> on 03/20/2002 07:05:21 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: 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
