SOAP com TypeScript em pleno 2023

Soap soup

TL;DR: blablabla tive que fazer um parsing XML e depois descobri que ia conseguir usar o WSDL. Se no quiser ler o texto, vai pro prximo tpico sobre como eu resolvi primeiro o parsing XML.

O ano 2023. Estamos falando em gRPC, tRPC, Rest, GraphQL blablabla. Pois eis que do nada surge uma integrao que precisa ser feita via SOAP e XML. Sim... voc no entendeu errado... um Web Service... SOAP... com direito a XML.. e tudo mais.

Pois . Fui transportado no tempo e automaticamente me lembrei de quando eu estava na faculdade, nos idos de 2009. Quando em uma cadeira de Java ns falvamos de JAX-WS e de como poderamos gerar classes stubs pelo Eclipse. Meu Deus... aqui a nostalgia no vem acompanhada de saudade. Tambm impossvel no lembrar dos trocadilhos com sabo, sopa ou coisas que tem sonoridade parecida. Inclusive a capa desse artigo uma Sopa de Sabo que eu pedi pro Midjourney gerar pra mim haha.

Mas bem. Estamos em 2023 e hoje eu estou construindo solues em JavaScript... ou melhor: em TypeScript. E tenho como fiel companheiro o Fastify para que as coisas fiquem menos dolorosas.

Mas quem foi que disse que a vida simples? Pois . Eu contava que eu teria o WSDL pra facilitar minha vida e, em um primeiro momento eu tive uma negativa em relao a isso.

Dessa forma eu teria que fazer o parsing do XML... na mo. Dando um spoiler, depois eu consegui o WSDL e a vida vai ficar mais fcil, mas eu j tinha feito uma PoC de como eu faria o parsing desse XML na mo ento vai ser a primeira parte dessa sequncia de posts. Espero que voc no tenha que precisar usa-los, mas se precisar, espero que sejam teis hehe.

Alinhando os patos

Antes de irmos pro primeiro texto vamos alinhar alguns conceitos para quem no souber do que eu estou falando consiga ficar na mesma pgina.

WebService, SOAP, SOA e at mesmo REST

Talvez o termo menos problemtico aqui seja WebService. Vamos defini-lo como "uma aplicao distribuda cujos componentes podem ser aplicados e executados em dispositivos distintos." -- Martin Kalim.

Provavelmente voc pensou em APIs Rest. E no est de todo errado. Inclusive h anos atrs, bibliografias dividiam WebServices em dois grupos: baseados em SOAP e de "estilo" REST. Inclusive considerando SOAP uma espcie de caso especial do REST. Muito disso tem relao com o fato de ambos rodarem em cima do protocolo HTTP.

Outro ponto que ajuda a confundir as definies quando entra a definio de SOA no meio. Originalmente SOAP significa Simple Object Access Protocol enquanto SOA significa Service Oriented Architecture. Ento como podemos ver pelos prprios nomes, SOA um estilo arquitetural enquanto SOAP um dialeto XML.

Aqui vale frisar que nosso foco no SOA, ento paramos por aqui em relao a esse termo e que, SOAP e SOA so conceitos que podem ser utilizados de forma totalmente independente entre si.

Se voc quiser uma visualizao simples de como funciona um WebService SOAP, abra seu postman e chame o seguinte servio (exatamente da mesma forma que voc faria com um endpoint Restful).

POST /webservicesserver/NumberConversion.wso HTTP/1.1Host: www.dataaccess.comContent-Type: text/xmlContent-Length: 276<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  <soap:Body>    <NumberToWords xmlns="http://www.dataaccess.com/webservicesserver/">      <ubiNum>500</ubiNum>    </NumberToWords>  </soap:Body></soap:Envelope>

Esse WebService traduz um nmero inteiro para sua representao por extenso. E o retorno dele ser.

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">    <soap:Body>        <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">            <m:NumberToWordsResult>five hundred </m:NumberToWordsResult>        </m:NumberToWordsResponse>    </soap:Body></soap:Envelope>

const axios = require('axios');let data = '<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <NumberToWords xmlns="http://www.dataaccess.com/webservicesserver/">
      <ubiNum>500</ubiNum>
    </NumberToWords>
  </soap:Body>
</soap:Envelope>';let config = {  method: 'post',  maxBodyLength: Infinity,  url: 'https://www.dataaccess.com/webservicesserver/NumberConversion.wso',  headers: {     'Content-Type': 'text/xml'  },  data : data};axios.request(config).then((response) => {  console.log(JSON.stringify(response.data));}).catch((error) => {  console.log(error);});

Perceba que ele um XML bem diferento, mas ainda um XML. E como sua requisio usa como base o protocolo HTTP, fica muito fcil fazer uma requisio dessa forma.

O problema que os servios dificilmente so simples dessa forma. E se precisarmos integrar com um WebService que tenha uma quantidade grande de mtodos ou a informao tenha uma estrutura mais complexa, fazer a requisio dessa forma ser bem mais complicado. E veremos isso nos prximos dois artigos dessa srie.

O WSDL

Eu comentei que dependendo do que tivermos no nosso WebService, essa integrao pode ser bem complexa. Existe uma forma de tentar fazer com que isso seja menos problemtico?

A resposta sim. No bonito, mas torna a vida mais simples.

L pra 2010 quando eu estava ainda na faculdade, eu tive uma cadeira sobre isso e por mais que eu lembre de poucas coisas da poca, uma coisa ficou na minha cabea: os stubs que eram gerados via Eclipse por meio de um arquivo chamado WSDL.

O WSDL significa WebService Description Language e tambm baseado em XML. Ele vai servir justamente pra definir a interface dos servios SOAP e nele estaro coisas como o formato de entrada e de sada, os tipos que precisam ser passados, quais mtodos esto disponveis etc.

<wsdl:definitions  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"  xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"  xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"  xmlns:tns="http://tempuri.org/"  xmlns:s="http://www.w3.org/2001/XMLSchema"  xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"  xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"  targetNamespace="http://tempuri.org/"> <wsdl:types>  <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">  <s:element name="Add">    <s:complexType>      <s:sequence>        <s:element minOccurs="1" maxOccurs="1" name="intA" type="s:int"/>        <s:element minOccurs="1" maxOccurs="1" name="intB" type="s:int"/>      </s:sequence>    </s:complexType></s:element><s:element name="AddResponse">  <s:complexType>    <s:sequence>      <s:element minOccurs="1" maxOccurs="1" name="AddResult" type="s:int"/>    </s:sequence>  </s:complexType></s:element>...

Repare que tambm um XML, mas diferente. Nele voc encontra o nome dos parametros, os tipos aceitos e o nome dos mtodos. Assim como o padro de suas respostas.

Com essa documento a vida fica consideravelmente mais simples, pois muitas tecnologias oferecem ferramentas para que voc crie o cdigo que ser usado pra integrar com o WebService por meio desse documento.

Em Java por exemplo, existe o wsimport que vai escrever quase que completamente um cliente que ser usado para consumir o servio disponibilizado.

Concluso

Esse texto inicial pra dar o termmetro do que precisaremos fazer e tambm serve como alinhamento de entendimento de alguns termos que por muito se confundem entre si.

Pros prximos passos, vamos ver as duas maneiras de fazer uma integrao com um WebService SOAP. Primeiro vamos fazer um parsing direto do XML e depois vamos usar libs que entendem o padro WSDL para que nossas vidas sejam mais fceis.

At l :)