Recentemente eu estava trabalhando em um cliente que chama um webservice. Já tinha feito isso antes e achei que era fácil. Porém, alguns problemas que encontrei durante o processo me fizeram perceber que ainda sabia muito pouco.
O lado do servidor do webservice requer autenticação de certificado. O certificado foi enviado para mim no formato cer. Depois de usar a ferramenta Java keytool para extrair o certificado, execute a seguinte instrução ao chamar o webservice.
System.setProperty("javax.net.ssl.trustStore", "xxxx.truststore");
Avise ao servidor que meu cliente possui um certificado e até o momento não há problema.
Em seguida, usei o wsdl2java do axis2 para gerar o código do cliente, mas ocorreu o seguinte erro assim que ele foi executado:
org.apache.axis2.AxisFault: [ISS.0088.9125] A solicitação SOAP não está em conformidade com o modelo de mensagem SOAP
Este erro foi encontrado no documento de desenvolvimento do Soap porque o formato da mensagem do Soap solicitado está errado. O endereço do documento é: http://documentation.softwareag.com/webmethods/wmsuite7/Developer/Guides/7-1-1_SOAP_Developers_Guide.pdf (89). Página)
Nesse momento, a outra parte me pediu para enviar a mensagem de solicitação do soap. Eu estava apenas na fase de uso do webservice e sabia usar ferramentas como axis e xfire para escrever o servidor e o cliente, mas só sabia um pouco sobre o soap. Procurei informações na Internet e perguntei ao Colega, depois de muito lutar, finalmente encontrei a mensagem de solicitação. O método fornecido pelos colegas é usar ferramentas como tcp monitor, mas o webservice está no formato https e não pode ser usado. Posteriormente, digitei SOAPEnvelope.toString() no código do cliente gerado para obtê-lo, da seguinte forma:
<?xml versão='1.0' codificação='utf-8'?>
<soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ ">
<soapenv:Corpo>
<ns1:UPLGerar xmlns:ns1=" http://www.alcatel-lucent.com/webService/WS_UPL ">
<OperationCode>1 </OperationCode>
<Planta>2 </Planta>
<QuoteNumber>3</QuoteNumber>
<UserID>4</UserID>
<IncludePriceType>5 </IncludePriceType>
</ns1:UPLGenerate>
</soapenv:Body>
</soapenv:Envelope>
Na verdade, a razão para esse problema é que a codificação de transferência padrão do cliente axis2 é fragmentada, portanto, haverá dois números no início e no final do corpo da mensagem de solicitação de sabão. Você pode usar o tcpmon para testá-lo. .net ou alguns outros servidores não suportam este modo. Sim, basta configurá-lo no código, da seguinte forma:
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED, false);
Pesquisei no fim de semana, consultei um veterano da empresa para verificar para mim e me deu algumas sugestões.
Não deveria haver nenhum problema com a execução agora, pensei, mas há outro problema.
Exceção no thread "principal" org.apache.axis2.AxisFault: org.apache.axis2.databinding.ADBException: subelemento inesperado xxxxResponse
emorg.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
Esse problema está me incomodando há três dias. Encontrei muita coisa na Internet. Alguns disseram para usar wstx-asl-3.2.1.jar, etc., mas tentei todos e não funcionou. não por causa desse erro da minha parte. Sou muito urgente, não tinha a menor ideia. Mais tarde, imprimi acidentalmente org.apache.axiom.soap.SOAPEnvelope _returnEnv no stub, que é _returnEnv.toString(). Descobri que o resultado retornado pelo soapUI era diferente porque o webservice era https, então não poderia ser usado usando tcpmon, entendi agora, porque os seguintes elementos na resposta retornada nem sempre estão lá, mas não estão definidos. na definição wsdl, ou seja, minOccurs="0" não é escrito. Como resultado, se o código do cliente gerado por este wsdl não for buscado, um erro será naturalmente relatado. minOccurs="0" para o wsdl, gere novamente o código do cliente, teste e passe.
Na última etapa, após a implantação no websphere, ocorreu um erro ao executar a chamada do webservice:
java.net.SocketException: Soquetes não conectados não implementados
Foi um problema de certificado. Demorou vários dias e depois foi repetido porque o certificado pai deste certificado estava faltando. Resumindo, se você não conseguir obter todos os certificados por meio do host e da porta no websphere, incluindo os certificados usados. diretamente para a autoridade certificadora. Para certificados, a única maneira é importar o arquivo .cer. A raiz do problema está aqui: o certificado! ! !
Os problemas que encontrei foram irritantes, mas as recompensas não foram pequenas. Em apenas alguns dias, aprofundei meu conhecimento sobre webservice, tenho vergonha de dizer que no passado eu só sabia usar o axis para escrever o servidor. e depois usar wsdl para gerar o cliente. Não sei se o wsdl pode ser usado para gerar o lado do servidor. Felizmente, tendo esta oportunidade, fiz progressos e todos podem me encorajar.
-