Kürzlich habe ich an einem Client gearbeitet, der einen Webservice aufruft, und dachte, es sei einfach. Allerdings wurde mir aufgrund einiger Probleme klar, dass ich immer noch zu wenig wusste.
Die Serverseite des Webservice erfordert eine Zertifikatauthentifizierung. Das Zertifikat wurde mir im CER-Format gesendet. Nachdem Sie das Zertifikat mit dem Java-Keytool-Tool extrahiert haben, führen Sie beim Aufruf des Webservice die folgende Anweisung aus:
System.setProperty("javax.net.ssl.trustStore", "xxxx.truststore");
Teilen Sie dem Server mit, dass mein Client über ein Zertifikat verfügt und bisher kein Problem vorliegt.
Als nächstes habe ich wsdl2java von axis2 verwendet, um den Client-Code zu generieren, aber der folgende Fehler trat sofort nach der Ausführung auf:
org.apache.axis2.AxisFault: [ISS.0088.9125] SOAP-Anfrage entspricht nicht dem SOAP-Nachrichtenmodell
Dieser Fehler wurde im Soap-Entwicklungsdokument gefunden, weil das angeforderte Soap-Nachrichtenformat falsch ist. Die Dokumentadresse lautet: http://documentation.softwareag.com/webmethods/wmsuite7/Developer/Guides/7-1-1_SOAP_Developers_Guide.pdf (89 Seite)
Zu diesem Zeitpunkt bat mich die andere Partei, die Soap-Anforderungsnachricht zu senden. Ich konnte Tools wie Axis und Xfire zum Schreiben des Servers und des Clients verwenden, wusste aber nur wenig über Soap Ich suchte im Internet nach Informationen und fragte den Kollegen. Nach langem Ringen fand ich schließlich die Anforderungsnachricht. Die von Kollegen angegebene Methode besteht darin, Tools wie TCP-Monitor zu verwenden, aber der Webservice liegt im https-Format vor und kann nicht verwendet werden. Später habe ich SOAPEnvelope.toString() wie folgt in den generierten Client-Code eingegeben, um ihn abzurufen:
<?xml version='1.0'kodierung='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>
<Anlage>2 </Anlage>
<QuoteNumber>3 </QuoteNumber>
<BenutzerID>4 </BenutzerID>
<IncludePriceType>5 </IncludePriceType>
</ns1:UPLGenerate>
</soapenv:Body>
</soapenv:Envelope>
Tatsächlich liegt der Grund für dieses Problem darin, dass die Standardübertragungscodierung des axis2-Clients fragmentiert ist, sodass am Anfang und am Ende des Hauptteils der SOAP-Anforderungsnachricht zwei Zahlen stehen. Sie können tcpmon zum Testen verwenden. .net oder einige andere Server unterstützen diesen Modus nicht. Ja, legen Sie ihn einfach wie folgt im Code fest:
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED, false);
Ich habe es am Wochenende recherchiert, einen Vorgesetzten im Unternehmen konsultiert, um es für mich zu überprüfen, und ihm einige Vorschläge gemacht.
Ich dachte, es sollte jetzt kein Problem mit der Ausführung geben, aber es gibt noch ein anderes Problem.
Ausnahme im Thread „main“ org.apache.axis2.AxisFault: org.apache.axis2.databinding.ADBException: Unerwartetes Unterelement xxxxResponse
unter org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
Dieses Problem beschäftigt mich seit drei Tagen. Einige sagten, ich solle wstx-asl-3.2.1.jar usw. verwenden, aber es hat zumindest nicht funktioniert Nicht wegen dieses Fehlers auf meiner Seite. Ich hatte keine Ahnung. Später habe ich versehentlich org.apache.axiom.soap.SOAPEnvelope im Stub ausgedruckt, was _returnEnv.toString() ist. Ich habe festgestellt, dass das von SoapUI zurückgegebene Ergebnis unterschiedlich war, da der Webservice https war und daher nicht mit tcpmon verwendet werden konnte, da die folgenden Elemente in der zurückgegebenen Antwort nicht immer vorhanden sind, aber nicht definiert sind In der WSDL-Definition wird also minOccurs="0" nicht geschrieben. Wenn der von dieser WSDL generierte Client-Code nicht abgerufen wird, wird natürlich ein Fehler gemeldet minOccurs="0" in die WSDL einfügen, den Clientcode neu generieren, testen und bestehen.
Im letzten Schritt, nach der Bereitstellung auf Websphere, ist beim Ausführen des Webservice-Aufrufs ein Fehler aufgetreten:
java.net.SocketException: Nicht verbundene Sockets nicht implementiert
Es handelte sich um ein Zertifikatsproblem, das mehrere Tage dauerte und sich dann wiederholte. Es lag daran, dass das übergeordnete Zertifikat dieses Zertifikats fehlte. Kurz gesagt, Sie konnten nicht alle Zertifikate über den Host und den Port abrufen, einschließlich der verwendeten Zertifikate Bei Zertifikaten besteht die einzige Möglichkeit darin, die .cer-Datei zu importieren. Die Ursache des Problems liegt hier: das Zertifikat! ! !
Die Probleme, auf die ich gestoßen bin, waren zwar ärgerlich, aber die Belohnungen waren nicht gering. In nur wenigen Tagen habe ich mein Verständnis von Webservices vertieft. Ich muss zugeben, dass ich in der Vergangenheit nur wusste, wie man Axis zum Schreiben des Servers verwendet. und dann wsdl zum Generieren des Clients verwenden. Ich weiß nicht, ob wsdl zum Generieren auf der Serverseite verwendet werden kann. Glücklicherweise habe ich dank dieser Gelegenheit Fortschritte gemacht und jeder kann mich ermutigen.
-