Introducción
¿Cuál es la mejor forma armar una arquitectura SOA y cuál para crear Web Services abiertos a Internet?
Desde hace tiempo que vengo leyendo información sobre la exposición de Web Services en formato SOAP y REST, prestando especial atención a sus características pero también a sus objetivos.
Y en este punto es donde me voy a detener para presentar en este breve ensayo mi postura respecto de la elección de uno u otro formato a la hora de construir una arquitectura SOA o simplemente exponer servicios web
Supuestos
Para responder a las preguntas de la introducción voy a manejarme con definiciones solo conceptuales sobre cada tema sin entrar en detalles técnicos de cada uno dado que abunda la información en Internet y libros respecto de los detalles de SOAP, REST, SOA y Web Services.
En caso de no encontrarse el lector familiarizado con estos conceptos o sus pormenores dejo enlaces de interés que brindan tal información. Sin embargo aconsejo revisar múltiples fuentes de información para completar mejor el conocimiento.
Desarrollo
Es muy importante tener en claro cuáles son los fundamentos y diferencias que existen entre SOA y Web Services a la hora de decidir aplicar REST o SOAP
SOA
Como sabemos, SOA es una arquitectura de software que busca dar soluciones a los proceso de negocio de una empresa que atraviesan múltiples sistemas informáticos para su cometido.
Por ejemplo, una empresa adquiere un nuevo beneficio para sus empleados (por ejemplo, contrata los servicios de un restauran que le da 20% de descuento en los almuerzos a sus empleados). Este proceso de negocio: "adquirir beneficio corporativo" si bien generalmente es disparado por el área de RRHH tiene implicancias en otras áreas de la empresa. Por ejemplo podría afectar al área de proveedores, facturación, marketing, etc.
Y esta afectación se ve reflejada cuando cada una de estas áreas tiene que cargar en sus sistemas alguna información proveniente de esta adquisición u otras áreas.
El proceso es uno , "adquirir beneficios corporativos" y las implicancias son muchas.
Sin una arquitectura SOA la solución a esta situación son dos: empleados de diferentes áreas cargan datos en sistemas por separado (incluso a veces datos repetidos) y se mandan entre sí archivos para completar otros sistemas, o el mismo proceso pero automatizado, es decir, cada sistema prepara una "integración" con otro sistema y se ponen de acuerdo en la forma en que se trasmitirán los datos. En muchos casos esto es una solución que consiste en inventar la rueda con cada sistema nuevo a integrarse.
Con una arquitectura SOA los sistemas implicados deberían exponer como servicios bien definidos, basados en protocolos estándar (nada de cosas a medida o propietarias) aquellas funcionalidades que son importantes para la organización y ésta tendría la posibilidad de interconectar estos servicios diversos para cumplir con un proceso de negocio.
En este sentido, "adquirir beneficios corporativos" podría ejecutarse desde una interfaz gráfica centralizada ( o distribuida en varias dependiendo de la necesidad ) y detrás se encontrarían llamadas a diversos servicios expuestos por los sistemas propietarios de cada área.
Estas llamadas requieren, por supuesto, un proceso de orquestación de parte de quien los integra y esto lo podría realizar personal propio de la empresa o encargar el trabajo a alguna empresa con experiencia en este tipo de arquitecturas.
Entonces podemos comprender que SOA en realidad tiene, al menos, dos grandes desafíos:
- Hacer que los sistemas ( los más importantes de cara a la empresa) expongan su funcionalidad como servicios con protocolos estándar y bien definidos (documentados)
- Orquestar los servicios en función de los diferentes procesos de negocio que atraviesan múltiples áreas ( implica un proceso previo de relevamiento para detectar estos procesos y la prioridad de los mismos )
Web Services
Desde un punto de vista de alto nivel, los Web Services son una excelente forma de implementar llamadas a procedimientos remotos (RPC). La excelencia está dada por sus características técnicas (protocolo HTTP, independencia entre cliente y servidor, etc.) y la idea subyacente es realmente muy simple: ofrecer funcionalidad remota a quien la necesite para construir así sistemas cada vez más grandes y más desacoplados.
Supongamos este escenario: una empresa de energía utiliza un sistema de cobranzas que operan los empleados para cobrarle a los clientes. Como todo sistema, requiere algún gasto de mantenimiento y/o soporte, de manera que, en realidad, el sistema es un activo de la empresa pero que genera costo. Si se aplicare un proceso de re-ingeniería que permitiere exponer como Web Services las funcionalidades más importantes del sistema, la empresa podría ofrecer estos servicios a otras empresas y abrir así su canal de cobranza (por ejemplo, permitir que se pueda cobrar los servicios en un supermecado).
De esta forma se necesitarían menos puntos de cobranza exclusivos de la empresa y se abrirían nuevos puntos variables, generando así ahorro de gastos y hasta podría llegar a comercializar estos Web Services para obtener algún otro ingreso adicional.
Las características técnicas de los Web Services implican un desafío importante en la toma de decisiones de arquitectura porque se debe aplicar un formato de comunicación lo más estandarizado y eficiente posible.
Dado que estamos hablando de la posibilidad de hacer llamadas a procedimientos remoto basadas en estándares es natural comprender que la implementación de SOA generalmente se hace por medio de Web Services. Pero es igual de cierto que no toda implementación de Web Services es sinónimo de estar aplicando una arquitectura SOA.
SOAP y REST
¿De dónde nace entonces la dicotomía SOAP / REST?
REST es una arquitectura, no un protocolo en particular o una tecnología. Básicamente parte de una premisa fundamentalmente distinta de la de SOAP y esta más alineado con el funcionamiento ideal del protocolo HTTP.
Esta premisa supone que todo lo que existe en la web ( o intranet ) en realidad son recursos (URL) y por lo tanto podemos aplicar distintas acciones sobre ellos (verbos de HTTP).
En un nivel mayor de abstracción entonces nos encontramos que quienes pensaron el protocolo HTTP pensaron que si los recursos son sustantivos, las acciones serían verbos que se aplican sobre estos sustantivos ( ver http://blog.tordek.com.ar/2008/03/como-le-explique-rest-a-mi-esposa/ ).
Por eso la propuesta de REST es muy natural a la forma en que los humanos interactuamos con las cosas.
Los verbos Delete, Put, Get, Set, en esta perspectiva cobran sentido si pienso que al utilizarlos le estoy diciendo al servidor (borrar NNN, obtener NNN, etc.).
Sin embargo no debemos perder de vista la premisa fundamental de REST: lo que hay remoto son recursos (sustantivos), no operaciones.
SOAP es un protocolo basado en XML que sirve para el transporte de mensajes y respuestas entre cliente y servidor que, junto con WSDL, generan un contrato, una especificación que dice claramente cómo debe realizarse una llamada a un procedimiento remoto, cual será el tipo de dato devuelto y cuáles son los tipos y cantidad de parámetros a recibir.
Pero lo más importante es que parte de una premisa fundamentalmente distinta a REST: aquí el protocolo HTTP es solo un medio de transporte de mensajes.
La operación (o verbo ) no se hace explícita en la llamada HTTP, sino que se encuentra implícita dentro del procedimiento remoto que atiende la llamada.
No le digo al servidor "borrar XXX" sino "llamar a XXX y darle YYY", siendo YYY el mensaje para que XXX haga lo que tenga que hacer (por ejemplo un borrado).
La dicotomía entonces se presenta porque hay quienes argumentan la creación de Web Services en favor de uno u otro, con premisas válidas en todos los casos, pero que a mi juicio no consideran el objetivo de lo que estamos hablando.REST es una arquitectura, no un protocolo en particular o una tecnología. Básicamente parte de una premisa fundamentalmente distinta de la de SOAP y esta más alineado con el funcionamiento ideal del protocolo HTTP.
Esta premisa supone que todo lo que existe en la web ( o intranet ) en realidad son recursos (URL) y por lo tanto podemos aplicar distintas acciones sobre ellos (verbos de HTTP).
En un nivel mayor de abstracción entonces nos encontramos que quienes pensaron el protocolo HTTP pensaron que si los recursos son sustantivos, las acciones serían verbos que se aplican sobre estos sustantivos ( ver http://blog.tordek.com.ar/2008/03/como-le-explique-rest-a-mi-esposa/ ).
Por eso la propuesta de REST es muy natural a la forma en que los humanos interactuamos con las cosas.
Los verbos Delete, Put, Get, Set, en esta perspectiva cobran sentido si pienso que al utilizarlos le estoy diciendo al servidor (borrar NNN, obtener NNN, etc.).
Sin embargo no debemos perder de vista la premisa fundamental de REST: lo que hay remoto son recursos (sustantivos), no operaciones.
SOAP es un protocolo basado en XML que sirve para el transporte de mensajes y respuestas entre cliente y servidor que, junto con WSDL, generan un contrato, una especificación que dice claramente cómo debe realizarse una llamada a un procedimiento remoto, cual será el tipo de dato devuelto y cuáles son los tipos y cantidad de parámetros a recibir.
Pero lo más importante es que parte de una premisa fundamentalmente distinta a REST: aquí el protocolo HTTP es solo un medio de transporte de mensajes.
La operación (o verbo ) no se hace explícita en la llamada HTTP, sino que se encuentra implícita dentro del procedimiento remoto que atiende la llamada.
No le digo al servidor "borrar XXX" sino "llamar a XXX y darle YYY", siendo YYY el mensaje para que XXX haga lo que tenga que hacer (por ejemplo un borrado).
Generalmente el debate pasa por cuestiones técnicas: que si me ahorro más Bytes, que si tengo menor acoplamiento entre cliente y servidor, que puedo usar objetos tipados, que la seguridad, etc.
Planteada la discusión en esos términos la conclusión generalmente es que termina siendo casi una cuestión de gustos o tendencia ( me decepciona creerlo pero lo he visto, hay quienes siguen patrones o metodologías solo porque lo hace la mayoría solamente ).
No estoy planteando que hay que desconocer las tendencias, sino que hay que usar la herramienta/técnica adecuada para el problema/momento indicado, no solo porque nos gana la pereza y entonces hacemos lo que hacen todos.
Conclusión
Si nuestro objetivo es utilizar la herramienta más indicada no solo por cuestiones técnicas, podré valorar todas las opciones, reconocer las adecuadas para cada momento y aplicarlas cuando sea necesario.
En este sentido creo que si lo que necesitamos es una arquitectura SOA (es decir, darle solución de integración a sistemas para atender los procesos de negocio) la solución sería que mis sistemas ofrezcan operaciones cerradas, atómicas, bien definidas, basadas en estándares que sean fácil y seguras de interconectar. Es decir, la premisa de SOAP (exponer operaciones por medio de mensajes) se acomoda más naturalmente a la solución que necesito.
Pero si lo que estoy buscando es una arquitectura orientada a Web Services, los cuales puedan ofrecer recursos concretos (más allá de HTML incluso, por ejemplo imágenes, archivos, etc.) entonces mi enfoque se ajusta más a REST, donde puedo pensar una arquitectura basada en recursos a los cuales según mi necesidad puedo aplicarle diferentes acciones (Get, Put, etc.).
Ahora, ¿cómo decidir si necesito SOA o solo Web Services?.
A mi juicio, si la aplicación va a estar en Internet y permitirá realizar operaciones sobre diferentes recursos, donde quienes quieran consumir estos recursos deberán seguir mi estándar y documentación para interpretarlos con el formato JSON correspondiente, creo que corresponde una arquitectura orientada a Web Services en formato REST.
Pero si mi aplicación utiliza el entorno Web solo como medio de despliegue, pero en realidad es una aplicación comercial que busco poder integrarla por medio de operaciones con otras aplicaciones comerciales de manera segura, basada en estándares, entonces creo que corresponde una arquitectura orientada a SOA con Web Services en formato SOAP.
Las cuestiones técnicas y las modas/tendencias no deberían ser, a mi juicio, el factor decisivo para tomar una decisión de Arquitectura tan importante.
En este sentido creo que si lo que necesitamos es una arquitectura SOA (es decir, darle solución de integración a sistemas para atender los procesos de negocio) la solución sería que mis sistemas ofrezcan operaciones cerradas, atómicas, bien definidas, basadas en estándares que sean fácil y seguras de interconectar. Es decir, la premisa de SOAP (exponer operaciones por medio de mensajes) se acomoda más naturalmente a la solución que necesito.
Pero si lo que estoy buscando es una arquitectura orientada a Web Services, los cuales puedan ofrecer recursos concretos (más allá de HTML incluso, por ejemplo imágenes, archivos, etc.) entonces mi enfoque se ajusta más a REST, donde puedo pensar una arquitectura basada en recursos a los cuales según mi necesidad puedo aplicarle diferentes acciones (Get, Put, etc.).
Ahora, ¿cómo decidir si necesito SOA o solo Web Services?.
A mi juicio, si la aplicación va a estar en Internet y permitirá realizar operaciones sobre diferentes recursos, donde quienes quieran consumir estos recursos deberán seguir mi estándar y documentación para interpretarlos con el formato JSON correspondiente, creo que corresponde una arquitectura orientada a Web Services en formato REST.
Pero si mi aplicación utiliza el entorno Web solo como medio de despliegue, pero en realidad es una aplicación comercial que busco poder integrarla por medio de operaciones con otras aplicaciones comerciales de manera segura, basada en estándares, entonces creo que corresponde una arquitectura orientada a SOA con Web Services en formato SOAP.
Las cuestiones técnicas y las modas/tendencias no deberían ser, a mi juicio, el factor decisivo para tomar una decisión de Arquitectura tan importante.
Fuentes
Rest Vs Web Services: Rafael Navarro Marset. ELP-DSIC-UPV
Modelado, Diseño e Implementación de Servicios Web 2006-07
No hay comentarios:
Publicar un comentario