>Why Axis? Because it is good implementation of JAXM and JAX-RPC APIs. Not all the interfaces are implemented, but you will find APIs very close. If you are doing Attachments, you will be pleased to know that Axis is not using JavaMail for MIME parsing.
*** RE: JAXM *** > 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). The vote was not on quality of the design, it was much more on the need of JAXM as a standard. People argued that it came too close to being JMS using SOAP. > 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. JAXM does what it has been designed to do and does it well. JAMX is the ONLY decent API for java to manipulate SOAP messages. It also in NO WAY restricts you from using async messages. In fact JAXM was designed to be used for SOAP messaging(not RPC calls) sending and receiving plain SOAP documents. If you look at ProviderConnection class, you will notice that it has been designed with async messages in mind. SOAPConnection.call() takes a URL for "on the fly" definition of the end point. When using async messaging, you usually want functionality that does some sort of request->response correlation. Therefore, sending a one way message requires you to create a new instance of your ProviderConnection. > 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. I would have to agree with you on this one. Having to use Source is an inconvenience that I think is unneeded. But it is not a fatal flaw. -Taras > -----Original Message----- > From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 21, 2002 11:00 AM > To: [EMAIL PROTECTED] > Subject: Re: why Axis? > > > > In message > <[EMAIL PROTECTED]>, "Russell > Butek" writes: > >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?). > > Not sure that I referred to it only as an implementation. You have my > apologies if I misled. Before anyone thinks I'm lambasting everyting > coming out of the JCP, let me clarify. My negative comments > were aimed > only at JAXM, both spec and implementation, specifically if > you're interested > in doing asynchronous document-oriented SOAP messaging or > more than the most > basic SOAP message manipulation. Axis will provide more in > these areas > because the project and to boot, you can contribute in small > or big ways. > You can already see how the org.apache.axis.message package > is more useful > than javax.xml.soap alone, even though it is careful to implement > javax.xml.soap interfaces (for implementing JAX-RPC since > JAX-RPC makes use > of JAXM's javax.xml.soap). > > >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. > > Yes, but the lastest draft is a proposed final draft, which > implies that > the amount of change probably (but not definitely) won't be so great. > > daniel > >
