Header Ads Widget

Ticker

6/recent/ticker-posts

Casos comunes cuando el uso de SOAP tiene sentido

 En estos días, cuando se habla de API web, generalmente se asume un enfoque RESTful. Si bien este paradigma arquitectónico moderno se usa a menudo, no siempre es el mejor tacto según el trabajo en cuestión. El hecho es que SOAP todavía se usa mucho en la actualidad. Si bien no todos los problemas pueden resolverse elegantemente con SOAP, aún puede ser la mejor opción en algunas situaciones específicas. ¿Charla loca? ¡Es verdad!

cases_soap_makes_sense

Las industrias de banca, facturación y telecomunicaciones pueden beneficiarse del uso de SOAP

En este artículo, ofrecemos diferentes escenarios en los que usar SOAP no solo tiene sentido, sino que incluso podría ser la mejor opción disponible. Las operaciones relacionadas con la facturación, el cálculo de rutas de transporte y la banca son buenos ejemplos de casos que podrían beneficiarse del uso de las funciones de SOAP.

Lo que hace que SOAP sea poderoso es que es independiente de cualquier capa de transporte específica. Esto significa que no se limita a transmitir únicamente a través de HTTP (como lo hace REST), lo que permite la comunicación con otros protocolos. El uso de SOAP sobre SMTP, por ejemplo, se presta al rápido desarrollo de una API que requiere una comunicación asíncrona a través de un canal inestable. Alternativamente, las API basadas en REST que intentan una funcionalidad similar requerirán que uno escriba mucho código e implemente mucha infraestructura.

También definiremos las operaciones sin estado y con estado y cómo SOAP puede ayudar a crear flujos de trabajo y transacciones. Comencemos por explorar cómo a veces se necesitan contratos formales legibles por máquina para garantizar que las operaciones se estén realizando como se espera, y cómo esto se puede lograr fácilmente con SOAP.

Los contratos formales dentro de SOAP reducen las malas interpretaciones

Algunas situaciones, las aplicaciones requieren un contrato formal entre el proveedor de servicios web y sus consumidores. SOAP es útil porque este proceso está claramente definido y no deja lugar a malas interpretaciones. Por lo general, se necesita un contrato formal en aplicaciones de misión crítica que se utilizan principalmente a gran escala y que afectan a una gran cantidad de consumidores. Ejemplos incluyen:

  • Facturación : los operadores de telecomunicaciones, por ejemplo, conectan numerosos sistemas para identificar el consumo de los clientes y generar información de facturación.
  • Navegación : las empresas de transporte y envío combinan información de diferentes fuentes para calcular las mejores rutas.
  • Gestión de la ciudad : cualquier cosa, desde semáforos hasta sistemas de alcantarillado, donde la interoperabilidad debe funcionar de manera predecible.
  • Transmisión de energía eléctrica: las compañías eléctricas cambian la forma en que la energía llega a los hogares al leer los datos de los sensores y cambiar de forma remota el enrutamiento de la electricidad.

SOAP tiene la capacidad de describir y hacer que los consumidores sigan contratos formales mediante el lenguaje de descripción de servicios web o, en resumen, WSDL . WSDL es un lenguaje de definición basado en XML que se utiliza para describir lo que ofrece un proveedor de servicios web y cómo debe consumirse. XML emplea las siguientes terminologías:

  • Servicio : una descripción del servicio, incluido su nombre, espacio de nombres, documentación disponible e información sobre los puntos finales existentes.
  • Punto final : información que describe un punto final, incluido su nombre, espacio de nombres, su dirección y cualquier documentación disponible. Los puntos finales también le permiten definir extensiones que brindan diferentes funcionalidades.
  • Encuadernación : descripción de cómo consumir realmente el servicio web, desde el punto de vista del mensaje y del protocolo de transmisión.
  • Interfaz : información sobre la secuencia de mensajes que un proveedor intercambia con los consumidores. Las interfaces se pueden ampliar para permitir la herencia.
  • Operación : grupo de mensajes relacionados intercambiados entre las partes. El patrón de intercambio de mensajes describe las reglas que definen cómo se transmiten los mensajes .
  • Tipo : descripción de los tipos de datos permitidos en una operación. Para evitar la escritura suave , todos los tipos de datos deben estar definidos por el contrato.

Como puede ver, todo está claramente definido por un contrato legible por máquina. No dejar lugar a malas interpretaciones significa que todas las llamadas a servicios web tienen los resultados esperados y los efectos secundarios se minimizan. Este es el escenario perfecto para situaciones en las que no puede controlar inmediatamente el resultado de una operación porque funciona de forma asincrónica.

SOAP puede manejar procesos que consumen tiempo

Los cálculos costosos, la recopilación de datos masivos y la fusión de un resultado a partir de esas partes constituyentes son procesos que requieren mucho tiempo. En lugar de mantener al usuario esperando mientras se obtiene este resultado, un enfoque asincrónico devolverá inmediatamente un resultado pendiente a la persona que llama, lo que permitirá que se activen otras operaciones en el ínterin. Esto puede ser particularmente útil en situaciones que involucran una cadena de operaciones llevada a cabo por el proveedor. Tales operaciones pueden incluir:

  • Cuentas de aprovisionamiento y desaprovisionamiento : estas operaciones suelen implicar la comunicación con una variedad de servicios que pueden tardar mucho en responder. En el mercado de las telecomunicaciones, cancelar el aprovisionamiento de una cuenta puede tardar horas o días en completarse.
  • Procesamiento de medios : este es el tipo de operación que se realiza habitualmente en la industria de los medios. La conversión de archivos de video grandes a diferentes formatos o la extracción de metadatos no se pueden lograr de forma sincrónica.
  • Cálculo de rutas de enrutamiento : debido a la gran cantidad de información, estas operaciones suelen tardar mucho en procesarse.

Las operaciones asincrónicas requieren más que HTTP

El protocolo HTTP no es adecuado para situaciones asincrónicas porque no puede interactuar fácilmente con el procesamiento del lado del cliente manejado por las partes que realizan la operación. El uso de HTTP implica sondeos en el lado del proveedor o del consumidor, lo que puede retrasar el proceso aún más cuando las personas que llaman están detrás de firewalls o sin conectividad constante. Anticipándose a estos escenarios, es mejor utilizar protocolos de comunicación que se adapten a esta realidad. Resulta que SOAP admite diferentes protocolos de comunicación:

  • SMTP : SOAP puede funcionar fácilmente con SMTP, el protocolo responsable de manejar todas las comunicaciones por correo electrónico. SMTP es, por naturaleza, un protocolo totalmente asincrónico con un sistema integrado de notificación de reintento y entrega. La compatibilidad con SOAP SMTP funciona simplemente incrustando sobres SOAP dentro de los mensajes SMTP.
  • XMPP : otra opción adecuada para arquitecturas de suscriptor-editor es usar SOAP sobre XMPP . El Protocolo de presencia y mensajería extensible, o XMPP, es bien conocido por su uso en sistemas de chat, pero a menudo se elige en situaciones en las que hay muchas entidades interesadas en recibir notificaciones sobre el resultado de una sola operación.

En resumen, las operaciones asincrónicas están presentes en más situaciones de las que uno podría haber pensado en un principio. Al utilizar SOAP además de los protocolos de comunicación asíncronos probados, los desarrolladores pueden gestionar de forma eficaz la comunicación del servicio web cuando no hay una respuesta disponible. Sin embargo, para manejar operaciones complejas y encadenadas, la asincronía no es suficiente. Para eso, deberá realizar un seguimiento de un conjunto de operaciones y agruparlas en una transacción.

SOAP admite operaciones con estado

Los servicios web más recientes siguen el estándar sin estado , lo que significa que a los clientes no les importa el estado de las operaciones entre las diferentes llamadas al servidor. Sin embargo, las situaciones que involucran múltiples operaciones encadenadas aún requieren operaciones con estado para que toda la transacción actúe como una. Algunos casos requieren replicar transacciones e incluso realizar una reversión si es necesario:

  • Transferencias bancarias : estas operaciones suelen requerir la comunicación entre múltiples bancos o sucursales, lo que implica muchas llamadas a varios servicios web. Este proceso se facilita con un coordinador para realizar un seguimiento de su estado. La industria bancaria generalmente agrupa todas estas operaciones en transacciones.
  • Reservar un vuelo : nuevamente, es necesario llamar a diferentes entidades y servicios web para verificar la disponibilidad y la información de precios. Cuando la información final vuelve al usuario, es posible que ya esté desactualizada, por lo que se necesita una transacción con una vida útil específica.

Afortunadamente, SOAP admite operaciones con estado Esto significa que un grupo de operaciones se puede controlar fácilmente mediante la ejecución de un conjunto de reglas predefinidas. El estado se transfiere entre operaciones para que cada parte involucrada siempre sepa cómo actuar sin realizar llamadas adicionales. SOAP implementa esto con la ayuda de Web Services Extension Specification, o en resumen, WS. Hay muchas extensiones WS disponibles que le permiten definir diferentes aspectos relacionados con cómo se transfieren los mensajes:

  • WS-Addressing : una forma estándar de agregar información de enrutamiento de mensajes a los encabezados SOAP. Ser capaz de definir el enrutamiento de mensajes de forma dinámica es importante porque la calidad de la comunicación puede cambiar mientras se ejecuta el servicio web.
  • WS-ReliableMessaging : garantiza que los mensajes SOAP siempre se entreguen, incluso cuando hay una falla en la comunicación de red o en un componente de software. Entre otras cosas, esta extensión le permite decir que los mensajes deben llegar en un orden determinado, lo cual es importante en una cadena de eventos.
  • WS-Coordination : le permite definir un flujo de trabajo que deben ejecutar todas las partes involucradas en las llamadas al servicio web.
  • WS-Policy : permite que un servicio web anuncie sus políticas de trabajo, que incluyen la calidad de servicio, los tiempos de respuesta esperados y la seguridad.
  • WS-Security : especifica cómo se aplica la integridad y la confidencialidad a los mensajes. En particular, le permite utilizar diferentes tipos de cifrado de mensajes, como certificados X.509, credenciales de usuario y contraseña y aserciones SAML.

Hay muchas más extensiones de WS que abordan diferentes necesidades. Los desarrolladores pueden incluso crear los suyos propios si es necesario. Esta personalización es una de las razones por las que SOAP se vuelve atractivo cuando se dan las condiciones adecuadas.

Conclusión

A pesar de todos los rumores, SOAP sigue vivo y coleando. Esto no significa que deba usarlo en todas las situaciones. Al analizar cuidadosamente el problema que está tratando de resolver, podrá comprender si SOAP es la combinación adecuada para su API. SOAP es particularmente útil en situaciones que involucran contratos formales, legibles por máquina, donde necesita asegurarse de que todas las partes se comporten exactamente como se diseñaron. Las operaciones asincrónicas y con estado son otros dos escenarios en los que SOAP sobresale. Debido a que SOAP no está vinculado a un protocolo de comunicación en particular, es fácil hacer que funcione de forma asincrónica. La creación de un servicio web con estado no debería ser demasiado difícil porque SOAP se puede ampliar fácilmente y el estado de funcionamiento se puede mantener entre llamadas.

¿Estás usando SOAP? ¿Cómo? ¡Deja un comentario aquí o ponte en contacto para discutir este tema!

Publicar un comentario

0 Comentarios