Modernice su servidor SOAP legacy con Amazon API Gateway y AWS Lambda

En esta serie de publicaciones de blog, aprenderá cómo crear una solución proxy para modernizar su servidor legacy que ejecuta el protocolo SOAP, así como una solución para integrar al cliente SOAP legacy para interactuar con aplicaciones modernas mediante interfaces REST. Esta es la primera parte (de un total de tres) de esta serie.

La migración de arquitecturas legacy que utilizan soluciones monolíticas o hasta soluciones alojadas en mainframes a arquitecturas de soluciones modernas que utilizan microservicios ya está muy extendida en el mercado y está siendo adoptada por varias empresas de diversos tamaños y segmentos comerciales. Si es desarrollador, ingeniero de software o un arquitecto de soluciones que trabaja en empresas de TI, es posible que escuche frases como modernización de la arquitectura o transformación digital varias veces al día. Este blog lo ayudará a modernizar una solución legacy y le permitirá continuar su jornada de transformación digital.

Es posible que algunas empresas que están operando negocios desde la década de 1990 todavía tengan algunos sistemas legacy en ejecución en producción porque, a veces, no pueden modernizar estas soluciones debido al costo, o pueden no tener el tiempo, el conocimiento o incluso el código fuente para hacerlo.

Por lo general, estas aplicaciones legacy tienen métodos desactualizados para intercambiar datos a través de archivos o usar estándares de API antiguos (obsoletos). El concepto detrás de una API, como un gateway de acceso programable para solicitar o enviar datos a otra aplicación, existe desde los principios de la informática, comenzando con RPC (Remote Procedure Call) en 1981. Sin embargo, las formas de implementarlos han sufrido grandes transformaciones en los últimos años.

Un importante protocolo API adoptado por las empresas a principios de la década de 2000 fue SOAP (acrónimo de Simple Object Access Protocol), un protocolo basado en HTTP/HTTPS, JMS o SMTP para el intercambio de información estructurada en la implementación de servicios web en redes informáticas, utilizando el formato XML (Extensible Markup Language).

La API de SOAP se define mediante un lenguaje denominado WSDL (Web Service Description Language). Con este lenguaje, puede definir los endpoints, información obligatoria y opcional (parámetros), recibir, responder y describir todos los procesos que se pueden realizar para establecer la comunicación desde dos computadoras. Esta flexibilidad permite el uso de diferentes lenguajes de programación para enviar y recibir datos.

Cada vez más, las nuevas tecnologías, como REST, GraphQL y gRPC, están reemplazando algunos protocolos legacy, como las API de SOAP, porque son modernas, rápidas, ligeras y fáciles de mantener. ¿Qué deben hacer las empresas con sus aplicaciones legacy que siguen siendo importantes para el funcionamiento de sus negocios?

Esta publicación de blog trata de compartir una estrategia para apoyar a las empresas que aún tienen servidores o aplicaciones cliente que utilizan protocolos SOAP para el intercambio de datos mediante API REST.

La buena noticia es que la mayoría de las API de SOAP y las API de REST se basan en protocolos HTTP/HTTPS (de hecho, SOAP también puede usar SMTP, JSM y otros protocolos), y el impacto para crear interoperabilidad no es tan difícil, pero debido al hecho de que SOAP tiene métodos HTTP/HTTPS limitados (solo POST), no puede la ventaja de la más amplia gama de métodos HTTP disponibles (como GET, PUT, DELETE, HEAD y OPTIONS) y la gama completa de códigos de estado HTTP asociados a ellos.

Otra diferencia clave entre SOAP y REST es que las API de REST permiten diferentes formatos de mensaje (payloads), como texto sin formato, binario, HTML, JSON y XML. Por otro lado, el protocolo SOAP solo permite que la estructura en formato XML comparta información entre servidores y clientes.

Como ya veremos en las otras publicaciones de este blog, el formato WSDL es importante para la correcta invocación del servicio de protocolo SOAP, pero no hará ningún impacto en la solución propuesta aquí. Para reforzar, el WSDL es una notación con formato XML para describir un servicio web. Una definición de WSDL indica a un cliente cómo redactar una solicitud de servicio web y describe la interfaz que proporciona el proveedor de servicios web.

Cree un microservicio con Amazon API Gateway y AWS Lambda para servidores proxy SOAP

Independientemente de si su empresa tiene un servidor local o en la nube y esta solución legacy solo permite el intercambio de datos mediante SOAP, en caso de que sea necesario exponer estos servicios a través de un estándar de API moderno, como REST, podemos usar Amazon API Gateway y funciones en AWS Lambda para ayudarlo en este camino.

El siguiente diagrama describe la arquitectura de un servidor proxy SOAP que utiliza los servicios de AWS.

En este escenario, queremos exponer las API del servidor SOAP (a la derecha de la imagen). Como se mencionó anteriormente, el protocolo SOAP utiliza principalmente HTTP/HTTPS para transportar los datos en formato XML y encapsular su payload (datos). Sin embargo, debes tener en cuenta:

• El HTTP/HTTPS Header Content-Type (que se utiliza para indicar el tipo de medio del recurso) debe establecerse en «text/xml; charset=UTF-8»;
• Los datos (payload) deben estar en formato XML;
• La solicitud de datos debe seguir el formato WSDL definido por el servidor.

A continuación, mostramos un nuevo escenario de una arquitectura donde lo que nos gustaría modernizar es una aplicación cliente, actualmente preparada para realizar llamadas de servicio utilizando el protocolo SOAP para los servicios que se implementan en un servidor, expuestos a través del protocolo REST.

En las dos soluciones propuestas que figuran en la parte 2 y la parte 3 del blog, la función de AWS Lambda es responsable de convertir la carga JSON de entrada en XML para poder enviarla al servidor. Posteriormente, la función necesita convertir el XML recibido del servidor al formato JSON para responder a la aplicación que realiza la llamada.

Observarás que utilizamos Amazon API Gateway, que es capaz de recibir cualquier tipo de payload (XML, JSON, binario, etc.), por lo que no existe limitación en el uso de este servicio para resolver este escenario, pero compruebe las cuotas de servicio definidas en la siguiente página:https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html

También utilizaremos AWS Lambda, como componente informático para realizar la transformación de headers, cambiar la estructura de los datos solicitados y también como orquestración de las llamadas de servicio.

Conclusión

Este primer artículo se creó para presentar los conceptos de los protocolos y también presentar los desafíos que enfrentan las empresas al mantener los sistemas legacy, tanto en el lado del servidor (servidor SOAP legacy) como en el lado del cliente (cliente SOAP legacy).

En la parte 2 del blog, detallaremos una posible alternativa de implementación que ayudará a nuestros clientes a crear un Proxy para el servidor SOAP legacy, convertir el header de content-type de «Texto/XML» a « Application /JSON» y también realizar la conversión de la payload de XML a JSON.

En la parte 3 del blog, se presentará una solución para mantener la aplicación cliente SOAP legacy, utilizando una arquitectura similar para la conversión del header del content-type del payload, pero en un contexto opuesto a ese presentado en la parte 2.

Si sigue estos pasos detallados en las partes 2 y 3 del blog, podrá crear un servicio REST para hacer proxy de un servidor SOAP legacy, así como de un cliente SOAP legacy, utilizando Amazon API Gateway y AWS Lambda. Esta API REST expone un endpoint que acepta el payload JSON y transforma esos datos en formato XML. Luego invocamos un servidor legacy utilizando su estándar WSDL y, finalmente, con la respuesta del servidor, nuestra función tuvo que transformarse de XML a JSON y respondió el resultado a la aplicación cliente.

Hubo algunos desafíos, como se mencionó anteriormente:

1) Se requiere que la API REST tenga el header Content-Type de «Application/JSON»;

2) El servidor SOAP debe tener un header Content-Type de «text/xml»;

3) Además, la conversión de JSON a XML y posteriormente de XML a JSON es obligatoria.

Puede usar esta solución y los servicios de AWS para seguir trabajando con su software legacy y seguir el proceso de modernización de su empresa mediante una interfaz de programación de aplicaciones (API) moderna y más escalable.

Si tiene otros casos de uso para modernizar arquitecturas SOAP legacy y quiere compartirlo conmigo, póngase en contacto conmigo en LinkedIn e intentaré ayudarlo. https://www.linkedin.com/in/danielabib/

Acerca el autor

Daniel Abib es Arquitecto de Soluciones empresariales en AWS, con más de 25 años trabajando en gestión de proyectos, arquitecturas de soluciones escalables, desarrollo de sistemas y CI/CD, microservicios, serverless y seguridad.  Trabaja apoyando a los clientes corporativos, ayudándolos en su jornada a la nube.