问题
If a SOAP web service is working well via SoapUI (producing the correct SOAP responses), while building a web service client in Java using different APIs/frameworks to call this web service is facing different issues, is it safe to consider this web service stable and the issues are from the consumer side?
I'm asking a generic question in here, I have already asked a detailed one which is probably too long to read. I'm interested in the concept more than my actual implementation, so if you can answer my question without referring to my longer post, please do.
UPDATE: I have realized that even if the WSDL is WS-I compliant and it's functioning correctly via SoapUI, this is still not enough to conclude that the web service is not broken. As @jtahlborn said, SoapUI is very tolerant to broken web services, and it could easily trick you to believe your web service is working fine, which is what happened in my case.
I'm constructing the SOAP response in the ESB and my issue was that I used a namespace that was defined in the WSDL but not in the schema. SoapUI received the response and showed it to me (with the wrong namespace); this issue could have been avoided if I turned on the response validation option.
It's also noteworthy to mention that in the Java web service client I created to test my web service, the response could not be loaded into the output object (a NullPointerException error showed up when I tried to access the output object), this was due to the namespace issue and it started working correctly once I fixed the namespace.
回答1:
SoapUI is a fantastic product. one of the things which makes it a great product, however, is that it is very tolerant of poorly defined webservices. in our product, we deal with lots of webservices, and a frequent comment on an issue in our product is "it works fine in SoapUI". we have learned the hard way that SoapUI will tolerate all kinds of broken webservices. so, in summary, working with SoapUI is not a proof that your webservice is well-defined.
回答2:
There are WS-I testing tools to check your web service for conformance to the Web Services Interoperability profiles. If your service adheres to the WS-I basic profile, and SoapUI can call it, the issues are definitely on the consumer side.
EDIT: well, or in between the both...
SoapUI can check your wsdl for WS-I compliance, see http://www.soapui.org/SOAP-and-WSDL/working-with-wsdls.html.
回答3:
It's most likely that the consumer (client) is buggy... If the client is generated using wsdl2java it's a big chance to have bugs in it... and if you are using some special functionalities that are valid (conforming w3c) then don't be surprised... the generated clients sometimes do this... even some libraries used to generate java classes or libraries to generate the webservices are full of bugs...
A lot of things are not supported by known and frequently used libraries... (I don't want to give names -- but wsdl4java is not perfect)..
If you are using security or something ... higher chances to have bugs on both server and client side :)
maybe if you tell us what is the problem we can help you...
来源：https://stackoverflow.com/questions/15190155/soapui-vs-java-web-service-client