Hello Daniel, Thank for your review, it saved my time by not learning "garbage" standarts. As for JAXB, I'd add that it would be possibly helpful if it'd supports XML Schema - Beans mapping.
-- Best regards, Alex mailto:[EMAIL PROTECTED] > 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 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
