Recently I was working on a client that calls a webservice. I had done it before and thought it was easy. However, some problems I encountered during the process made me realize that I still knew too little.
The server side of webservice requires certificate authentication. The certificate has been sent to me in cer format. After using the Java keytool tool to extract the certificate, execute the following statement when calling webservice:
System.setProperty("javax.net.ssl.trustStore", "xxxx.truststore");
Tell the server that my client has a certificate, and so far there is no problem.
Next, I used axis2's wsdl2java to generate the client code, but the following error occurred as soon as it was executed:
org.apache.axis2.AxisFault: [ISS.0088.9125] SOAP request does not conform to the SOAP message model
This error was found in the soap development document because the requested soap message format is wrong. The document address is: http://documentation.softwareag.com/webmethods/wmsuite7/Developer/Guides/7-1-1_SOAP_Developers_Guide.pdf (89 Page)
At this time, the other party asked me to send the soap request message. I was only at the stage of using webservice. I could use tools such as axis and xfire to write the server and client, but I only knew a little about soap. I looked for information on the Internet and asked Colleague, after struggling for a long time, I finally found the request message. The method given by colleagues is to use tools such as tcp monitor, but the webservice is in https format and cannot be used. Later, I typed SOAPEnvelope.toString() in the generated client code to get it, as follows:
<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ ">
<soapenv:Body>
<ns1:UPLGenerate xmlns:ns1=" http://www.alcatel-lucent.com/webService/WS_UPL ">
<OperationCode>1 </OperationCode>
<Plant>2 </Plant>
<QuoteNumber>3 </QuoteNumber>
<UserID>4 </UserID>
<IncludePriceType>5 </IncludePriceType>
</ns1:UPLGenerate>
</soapenv:Body>
</soapenv:Envelope>
In fact, the reason for this problem is that the default transfer-encoding of the axis2 client is chunked, so there will be two numbers at the beginning and end of the body of the soap request message. You can use tcpmon to test it. .net or some other servers do not support this mode. Yes, just set it in the code, as follows:
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED, false);
I researched it over the weekend. I consulted a senior in the company to check it for me and gave me some suggestions. Thank you very much to him!
There should be no problem with the execution now. I thought, but there is another problem.
Exception in thread "main" org.apache.axis2.AxisFault: org.apache.axis2.databinding.ADBException: Unexpected subelement xxxxResponse
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
This problem has been bothering me for three days. I found a lot on the Internet. Some said to use wstx-asl-3.2.1.jar, etc., but I tried them all and it didn't work. At least it's not because of this error on my side. I'm very urgent. I didn't have a clue. Later, I accidentally printed out org.apache.axiom.soap.SOAPEnvelope _returnEnv in the stub, which is _returnEnv.toString(). I found that the result returned by soapUI was different because the webservice was https, so it couldn't be used. Using tcpmon, I understand now, because the following elements in the returned response are not always there, but they are not defined in the wsdl definition, that is, minOccurs="0" is not written. As a result, if the client code generated by this wsdl does not fetch If you find those elements that are not returned, an error will naturally be reported. Add minOccurs="0" to the wsdl, regenerate the client code, test, and pass.
In the last step, after deploying to websphere, an error occurred when executing the webservice call:
java.net.SocketException: Unconnected sockets not implemented
It was a certificate problem. It took several days, and then it was repeated. It was because the parent certificate of this certificate was missing. In short, if you cannot get all the certificates through host and port in websphere, including the certificates used directly to the certificate authority. For certificates, the only way is to import the .cer file. The root of the problem is here: the certificate! ! !
The problems I encountered were annoying, but the rewards were not small. In just a few days, I have deepened my understanding of webservice. I am ashamed to say that in the past, I only knew how to use axis to write the server, and then use wsdl to generate the client. I don't know if wsdl can be used to generate server side. Fortunately, given this opportunity, I have made progress, and everyone can encourage me.
-