Recientemente estuve trabajando en un cliente que llama a un servicio web. Lo había hecho antes y pensé que era fácil. Sin embargo, algunos problemas que encontré durante el proceso me hicieron darme cuenta de que todavía sabía muy poco.
El lado del servidor del servicio web requiere autenticación de certificado. El certificado me fue enviado en formato cer. Después de usar la herramienta Java keytool para extraer el certificado, ejecute la siguiente declaración al llamar al servicio web.
System.setProperty("javax.net.ssl.trustStore", "xxxx.truststore");
Dígale al servidor que mi cliente tiene un certificado y hasta el momento no hay ningún problema.
A continuación, utilicé wsdl2java de axis2 para generar el código del cliente, pero se produjo el siguiente error tan pronto como se ejecutó:
org.apache.axis2.AxisFault: [ISS.0088.9125] La solicitud SOAP no se ajusta al modelo de mensaje SOAP
Este error se encontró en el documento de desarrollo de SOAP porque el formato del mensaje de SOAP solicitado es incorrecto. La dirección del documento es: http://documentation.softwareag.com/webmethods/wmsuite7/Developer/Guides/7-1-1_SOAP_Developers_Guide.pdf (89). Página)
En ese momento, la otra parte me pidió que enviara el mensaje de solicitud de SOAP. Solo estaba en la etapa de usar el servicio web. Podía usar herramientas como axis y xfire para escribir el servidor y el cliente, pero solo sabía un poco sobre SOAP. Busqué información en Internet y le pregunté a un colega. Después de luchar durante mucho tiempo, finalmente encontré el mensaje de solicitud. El método dado por mis colegas es usar herramientas como tcp monitor, pero el servicio web está en formato https y no se puede usar. Más tarde, escribí SOAPEnvelope.toString () en el código del cliente generado para obtenerlo, de la siguiente manera:
<?xml version='1.0' codificación='utf-8'?>
<soapenv:Sobre xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ ">
<soapenv:Cuerpo>
<ns1:UPLGenerate xmlns:ns1=" http://www.alcatel-lucent.com/webService/WS_UPL ">
<CódigoOperación>1 </CódigoOperación>
<Planta>2 </Planta>
<QuoteNumber>3 </QuoteNumber>
<ID de usuario>4 </ID de usuario>
<IncludePriceType>5 </IncludePriceType>
</ns1:UPLGenerar>
</soapenv:Cuerpo>
</soapenv:Sobre>
De hecho, la razón de este problema es que la codificación de transferencia predeterminada del cliente axis2 está fragmentada, por lo que habrá dos números al principio y al final del cuerpo del mensaje de solicitud de SOAP. Puede usar tcpmon para probarlo. .net u otros servidores no admiten este modo. Sí, simplemente configúrelo en el código, de la siguiente manera:
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED, falso);
Lo investigué durante el fin de semana. Consulté a un senior de la empresa para que lo comprobara y me dio algunas sugerencias.
No debería haber ningún problema con la ejecución ahora, pensé, pero hay otro problema.
Excepción en el hilo "principal" org.apache.axis2.AxisFault: org.apache.axis2.databinding.ADBException: subelemento inesperado xxxxResponse
en org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
Este problema me ha estado molestando durante tres días. Encontré muchos en Internet. Algunos decían que usara wstx-asl-3.2.1.jar, etc., pero los probé todos y no funcionó. No por este error de mi parte. Soy muy urgente. No tenía ni idea. Más tarde, imprimí accidentalmente org.apache.axiom.soap.SOAPEnvelope _returnEnv en el código auxiliar, que es _returnEnv.toString(). Descubrí que el resultado devuelto por SOAPUI era diferente porque el servicio web era https, por lo que no se podía usar. Ahora lo entiendo, porque los siguientes elementos en la respuesta devuelta no siempre están ahí, pero no están definidos. en la definición de wsdl, es decir, minOccurs = "0" no está escrito. Como resultado, si el código de cliente generado por este wsdl no recupera los elementos que no se devuelven, naturalmente se informará un error. minOccurs="0" al wsdl, regenerar el código del cliente, probarlo y aprobarlo.
En el último paso, después de implementar en websphere, se produjo un error al ejecutar la llamada al servicio web:
java.net.SocketException: sockets no conectados no implementados
Fue un problema de certificado. Tomó varios días y luego se repitió. Fue porque faltaba el certificado principal de este certificado. En resumen, si no puede obtener todos los certificados a través del host y el puerto en websphere, incluidos los certificados utilizados. directamente a la autoridad certificadora Para los certificados, la única forma es importar el archivo .cer. La raíz del problema está aquí: ¡el certificado! ! !
Los problemas que encontré fueron molestos, pero las recompensas no fueron pequeñas. En solo unos días, profundicé mi comprensión del servicio web. Me avergüenza decir que en el pasado solo sabía cómo usar axis para escribir el servidor. y luego use wsdl para generar el cliente. No sé si wsdl se puede usar para generar el lado del servidor. Afortunadamente, dada esta oportunidad, he progresado y todos pueden alentarme.
-