Modernize seu servidor SOAP legado usando o Amazon API Gateway e o AWS Lambda

Por Daniel Abib, Enterprise Solution Architect, FSI – LATAM

Nesta série de blog posts, você aprenderá a construir uma solução de proxy para modernizar um servidor legado executando o protocolo SOAP, bem como uma solução para integrar seu cliente SOAP legado para interagir com aplicativos modernos usando interfaces REST. Esta é a primeira parte (num total de três) da série de blog posts.

A migração de arquiteturas legadas utilizando soluções monolíticas ou mesmo soluções hospedadas em mainframes para arquiteturas de soluções modernas que utilizam microsserviços já é difundida no mercado e está sendo adotada por diversas empresas de diversos portes e segmentos de negócios. Se você é um desenvolvedor, um engenheiro de software ou um arquiteto de soluções que trabalha em empresas de TI, pode ouvir frases como modernização de arquitetura ou transformação digital várias vezes ao dia. Este blog ajudará você a modernizar uma solução legado e permitirá que você continue em sua jornada de transformação digital.

Algumas empresas que administravam negócios desde os anos 90 ainda podem ter alguns sistemas legados rodando em produção porque, às vezes, não conseguem modernizar essas soluções devido aos custos, ou talvez não tenham tempo, conhecimento ou mesmo o código-fonte para isso.

Normalmente, esses aplicativos legados têm métodos obsoletos para trocar dados por meio de arquivos ou usando padrões de APIs antigos (descontinuados). O conceito por trás de uma API, como um gateway de acesso programável para solicitar ou enviar dados para outra aplicação, existe desde os primórdios da ciência da computação, começando com RPC (Remote Procedure Call) em 1981. No entanto, as formas de implementá-las passaram grandes transformações nos últimos anos.

Um importante protocolo de API adotado pelas empresas no início dos anos 2000 foi o SOAP (sigla para Simple Object Access Protocol), um protocolo baseado em HTTP/HTTPS, JMS ou SMTP para troca de informações estruturadas na implementação de serviços web em redes de computadores, utilizando o formato de XML (Extensible Markup Language).

A API SOAP é definida por uma linguagem chamada WSDL (Web Service Description Language). Usando esta linguagem, você pode definir os endpoints, as informações obrigatórias e opcionais (parâmetros), receber, responder e descrever todos os processos que podem ser realizados para estabelecer a comunicação de dois computadores. Essa flexibilidade permite a utilização de diferentes linguagens de programação para enviar e receber dados.

Cada vez mais, novas tecnologias como REST, GraphQL e gRPC estão substituindo alguns protocolos legados como APIs SOAP por serem modernas, rápidas, leves e fáceis de manter. O que as empresas devem fazer com seus aplicativos legados que ainda são importantes para administrar seus negócios?

Este blog post é sobre o compartilhamento de uma estratégia de suporte à empresas que ainda possuem servidores ou aplicativos de clientes usando protocolos SOAP para troca de dados usando APIs REST.

A boa notícia é que a maioria das APIs SOAP e APIs REST são baseadas em protocolos HTTP/HTTPS (na verdade, SOAP também pode usar SMTP, JSM e outros protocolos), e o impacto para criar a interoperabilidade não é tão desafiador, mas devido ao fato de que o SOAP tem métodos HTTP/HTTPS limitados (somente POST), ele não consegue obter o benefício da maior variedade de métodos HTTP disponíveis (como GET, PUT, DELETE, HEAD e OPTIONS) e toda a gama de status HTTP códigos associados a eles.

Outra diferença principal entre SOAP e REST é que as APIs REST permitem diferentes formatos de mensagens (payloads), como texto simples, binário, HTML, JSON e XML. Por outro lado, o protocolo SOAP apenas permite que a estrutura no formato XML para compartilhar informações entre servidores e clientes.

Como será visto nas outras publicações deste blog, o formato do WSDL é importante para a correta invocação do serviço do protocolo SOAP, mas não terá impacto na solução aqui proposta. Apenas para reforçar, o WSDL é uma notação em formato XML para descrever um serviço da web. Uma definição WSDL indica a um cliente como compor uma solicitação de serviço da web e descreve a interface que é fornecida pelo provedor de serviços da web.

Criar um microsserviço usando o Amazon API Gateway e AWS Lambda para servidores Proxy SOAP

Independentemente de sua empresa ter um servidor on-premise ou na nuvem e essa solução legada apenas permitir a troca de dados usando SOAP, caso seja necessário expor esses serviços sobre um padrão de API moderno como REST, podemos usar o Amazon API Gateway e o funções em AWS Lambda para ajudá-lo nesta jornada.

O diagrama a seguir representa a arquitetura para um SOAP Proxy Server usando os serviços da AWS.

Neste cenário, queremos expor as APIs do servidor SOAP (à direita da imagem). Como mencionado anteriormente, o protocolo SOAP usa principalmente HTTP/HTTPS para transportar os dados no formato XML para encapsular seu playload (dados). No entanto, há considerações a serem feitas:

• O HTTP/HTTPS Header Content-Type (que é usado para indicar o tipo de mídia do recurso) deve ser definido como “text/xml; conjunto de caracteres=UTF-8”;
• Os dados (payload) deve estar no formato XML;
• A requisição e dados devem seguir o formato WSDL definido pelo servidor.

A seguir, mostramos um novo cenário de uma arquitetura aonde o que gostaríamos de modernizar é uma aplicação cliente, atualmente preparada para fazer chamadas de serviços usando o protocolo SOAP para serviços que estão implementados em um servidor, expostos através do protocolo REST.

Nas duas soluções propostas contidas nas parte 2 e parte 3 do blog, a função AWS Lambda tem a responsabilidade de converter o payload JSON de entrada em XML para poder enviar ao servidor. Posteriormente, a função precisa converter o XML recebido do servidor no formato JSON para responder ao aplicativo de chamada.

Vocês irão perceber que utilizamos o Amazon API Gateway, que é capaz de receber qualquer tipo de payload (XML, JSON, binário etc.), portanto, não há limitação de uso desse serviço para solucionar esse cenário, mas verifique as cotas de serviço definidas na página a seguir: https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html

Também utilizaremos o AWS Lambda, como o componente de computação para realizar a transformação de headers, mudança de estrutura dos dados solicitados e também como orquestração das chamadas de serviços.

Conclusão

Este primeiro artigo foi criado para apresentar os conceitos dos protocolos e também introduzir os desafios que as empresas possuem ao manter sistemas legados, tanto na parte do servidor (legacy SOAP server) quanto na parte cliente (legacy SOAP cliente).

Na parte 2 do blog, vamos detalhar uma possível alternativa de implementação que auxiliará os nossos clientes na criação de um Proxy para o servidor SOAP legado, fazendo a conversão de header do content-type de “Text/XML” para “Applicartion/json” e também realizando a conversão do payload de XML para JSON.

Na parte 3 do blog, será apresentada uma solução para manter a aplicação SOAP cliente legada, usando uma arquitetura similar para a conversão do header de contente-type e do payload, mas num contexto oposto ao apresentado na parte 2.

Seguindo essas poucas etapas detalhadas na parte 2 e 3 do blog, vocês conseguirão criar um serviço REST para fazer proxy de um servidor SOAP legado bem como de um cliente SOAP legado, usando o Amazon API Gateway e o AWS Lambda. Essa API REST expõe um endpoint que aceita carga JSON e transforma esses dados em formato XML. Em seguida, invocamos um servidor legado usando seu padrão WSDL e por fim, com a resposta do servidor, nossa função teve que transformar de XML para JSON e respondeu o resultado para a aplicação cliente.

Houve alguns desafios, como mencionado anteriormente:

1) A API REST é obrigada a ter o cabeçalho Content-Type de “Application/json”;

2) O Servidor SOAP deve possuir cabeçalho Content-Type de “text/xml”;

3) Além disso, a conversão de JSON para XML e posteriormente XML para JSON é obrigatória.

Você pode usar esta solução e os serviços da AWS para continuar trabalhando com seu software legado e seguir na jornada de modernização de sua empresa usando uma interface de programação de aplicativos (API) moderna e mais escalável.

Se você tiver outros casos de uso para modernizar arquiteturas legadas SOAP e quiser compartilhá-lo comigo, entre em contato comigo no LinkedIn e tentarei ajudar. https://www.linkedin.com/in/danielabib/

Sobre o autor

Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, Serverless e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.