In message <94F890AC98E9AF478F08FEFAC7467C7C095168@riker01>, Taras Shkvarchuk w rites: >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.
This is true, but some of the comments went deeper than you suggest and it doesn't take away from the fact that JAXM does not meet many developer's needs, even if it meets yours. >JAMX is the ONLY decent API for java to manipulate SOAP messages. I was under the impression that Apache SOAP wasn't too shabby. >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. I never claimed JAXM was designed for anything other than SOAP messaging. >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. Either I didn't express myself well, or you haven't used the JAXM reference implementation. If you want to send an asynchronous message you must use an Endpoint. An Endpoint is a URI. The mapping of the Endpoint to a URL must be defined at service deployment time or through an admin tool. This does not address the needs of developers who require messaging to arbitrary dynamically determined endpoints. I'm talking about asynchronous messaging, not the synchronous calls that use a URLEndpoint. Furthermore, the support of profiles is severely flawed. For example, if you want to use a profile, you have to know about the implementation-specific profile classes. Take soaprp in the reference implementation. You have to cast a SOAPMessage to com.sun.xml.messaging.soaprp.SOAPRPMessageImpl and use setTo() and setFrom() to make your message go anywhere. This is flat out a bad design. At the very least, profiles should be supported through profile-specific generic interfaces (perhaps the subject of separate JSRs) and you shouldn't be forced to use a specific profile to send an asynchronous message through a provider. Please show me how you can send an arbitrary SOAP message asynchronously to an arbitrary endpoint without using a profile? The answer is that you can't because ProviderConnection.send() accepts only a SOAPMessage as an argument and expects the message to contain profile-specific routing information. So your assertion that JAXM "in NO WAY restricts you" is misinformed. Rather than spend my time critiquing JAXM, I have opted to use and eventually contribute to Axis. It took time trying to get work done with the JAXM reference implementation and the limited APIs provided by the JAXM specification to make this decision. I only wanted to save someone else with more than the most basic application development needs the hardship. Many people will be happy with JAXM, but it is also inadequate for many. >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. But you missed the point of my comment. It's not that I have to use a Source, it's that I have to set the entire content and can't do any fine-grained manipulation that leverages pre-existing DOM code. Axis recognizes this in its implementation (see org.apache.axis.message package) because it is at least a major flaw and developers need more. I think we should kill this thread here because it's turned into advocacy (probably my fault) and this mailing list is about using Axis. daniel
