axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taras Shkvarchuk <tar...@grandcentral.com>
Subject RE: why Axis?
Date Fri, 22 Mar 2002 01:39:00 GMT
> >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.
No product out there is going to meet everyone's needs.
People did find use for JAXM, didn't they? :)

> >JAXM is the ONLY decent API for java to manipulate SOAP messages.
> I was under the impression that Apache SOAP wasn't too shabby.
Apache SOAP was for RPC wasn't it? :)
There are plenty of reasons Axis got started and we don't have newer
versions of Apache SOAP.

> Please show me how you can send an arbitrary SOAP message
> asynchronously to an arbitrary endpoint without using a profile?
This is in case the whole provider framework is not something you care
about.
If you don't need error handling, or some smart transport logic...
A) just write message to a stream
	URLConnection conn;
	OutputStream out=conn.getOutputStream();
	SOAPMessage msg;
	msg.writeTo(out);
B) Use SOAPConnection, and ignore whatever response/exception you get.

Conclusion: JAXM provides SOAP message packaging for SOAP messaging. Expect
nothing more.
Use Axis, it provides the functionality JAXM defines.

-Taras

> -----Original Message-----
> From: Daniel F. Savarese [mailto:dfs@savarese.org]
> Sent: Thursday, March 21, 2002 1:37 PM
> To: axis-user@xml.apache.org
> Subject: Re: why Axis? 
> 
> 
> 
> 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
> 
> 

Mime
View raw message