Entendiendo SOA desde cero

¡Hola una vez más!

El tema de hoy es fundamental para quienes estamos involucrados o interesados en el desarrollo de aplicaciones con arquitectura SOA. Y es necesario entenderlo ya que muchas veces nos dedicamos exclusivamente a programar, a hacer servicios y usar las herramientas, pero no nos tomamos el tiempo de analizar el panorama completo, o al menos más amplio, de lo que estamos generando y por que.

Me gustaría comenzar por dar una explicación del concepto de SOA, será breve puesto que en internet podemos encontrar mucha información al respecto, lo que me parece mejor idea y en lo que me estaré enfocando, será en ejemplificar esta arquitectura partiendo de elementos con los que estamos un poco más familiarizados y trasladarlos a este "nuevo" concepto.

Las siglas SOA significan Service Oriented Architecture. Tal como su nombre lo dice, se refiere a las Arquitecturas Orientadas a Servicios, en palabras más mundanas y en el estricto sentido del término, no es más que una forma de estructurar aplicaciones usando Servicios como eje central.

Este paradigma no es nuevo y tampoco es una solución adecuada a todos los problemas. Como cualquier otra arquitectura, es una forma de diseñar aplicaciones y por ende tiene sus ventajas y desventajas. No creas que por estar de moda o por que el nombre apantalle, significa que será la salvación a todos sus problemas técnicos y de negocio.

Usar Servicios como base de una aplicación significa que es necesario cambiar de fondo la forma en la que creamos nuestros desarrollos y que requerimos ciertos elementos específicos para integrar y coordinar los componentes.

Vayamos poniendo un ejemplo de base, que para muchos de nosotros es bien conocido, una aplicación Web JAVA. La estructura más básica y a grandes rasgos sería algo como esto:



Un cliente web (llámese PC para este ejemplo) realiza peticiones a un servidor de aplicaciones por medio de internet. En el servidor existe una aplicación web (empaquetada) lista para ejecutar las acciones requeridas por los clientes, exponiendo formularios web que consumen sus propios servicios de negocio (en este caso, Alta, Baja y Consulta de Clientes), vamos a llamarles, locales, que accesan a una Base de Datos.

En este escenario simple, la solución es idónea para cubrir la necesidad. Pero ¿qué pasa cuando el panorama se complica un poco más?

Resulta que nuestro Cliente (empresa que nos contrata para realizar el desarrollo) tiene otra aplicación enfocada a la administración de un sector diferente de sus propios clientes, desarrollada en .NET y desea unificar ambos repositorios.



Como podemos observar en el diagrama, ambas aplicaciones realizan operaciones muy similares, es decir, comparten cierta funcionalidad pero distintas bases de datos. La idea es unificar estos repositorios y estándarizar ambas aplicaciones a una misma estructura de datos. Para resolver este problema tenemos varias opciones, una de ellas es modificar las dos aplicaciones, simplemente apuntar al nuevo repositorio y hacer los cambios pertinentes en cada sevicio local. Esta solución parace ser buena siempre y cuando la funcionalidad y la estructura de datos no cambie constantemente, por que de no ser así, cada vez que se requiera un cambio, tendría que hacerse en ambas aplicaciones. Imagínense que no fueran solo dos, si no 10 o 20 aplicaciones, ya no suena tan viable ¿cierto?

Una segunda opción es modificar y centralizar los servicios comunes para que las dos aplicaciones hagan uso de ellos. Aquí es donde entra la definición de Servicios Web.



En la imagen se ilustra como el Servicio Web concentra y encapsula toda la lógica de negocio de ambas aplicaciones y la expone en métodos a través de una red. Los que antes eran servicios locales, ahora se vuelven clientes consumidores de servicios web. Esta solución es más apropiada para fomentar la reutilización y facilita el mantenimiento, ya que si es requerido hacer cambios, sólo se realizarán una vez y en un solo lugar.

En este momento podríamos pensar que tenemos una arquitectura orientada a servicios, sin embargo, va mucho más allá de solo usar servicios web, implica poner en práctica varios patrones de diseño adicionales, que en otro momento me daré la tarea de explicar, entre otras cosas. Lo importante por ahora es identificar los elementos principales.

El siguiente elemento en nuestra arquitectura es una capa intermedia entre los consumidores y los servicios, que se encargue de hacer la tan famosa Mediación de Servicios, que más adelante explicaré. Este elemento es un Enterprise Service Bus, para nuestro caso Oracle Service Bus (OSB).

Esta nueva capa es una aplicación que se ejecuta en un servidor weblogic, misma que actua como un  Proxy de nuestros servicios. Como nota cultural, este es uno de los patrones de diseño que se usan en esta arquitectura y significa anteponer un elemento intermediario de un objeto con la finalidad de mantener control sobre los accesos al mismo. Este elemento es, a su vez, otro servicio.



Si observamos la imagen, podemos identificar que en esta nueva capa existen dos elementos, el Proxy Service y el Business Service. Este último es una especie de Wrapper o Envoltorio del servicio web de Clientes, mientras que el Proxy es la interfaz común que quedará expuesta a los clientes que deseen consumir el servicio web de Clientes.

Ahora bien, ustedes se preguntarán ¿para qué poner una capa intermedia que solo sirva como control de accesos? Pues la respuesta es simple, no solo sirve para eso, sino que además provee una serie de opciones a realizar con diferentes elementos, aqui es donde entra el concepto de Mediación de Servicios y voy a tratar de explicarlo agregando un poco más de complejidad a nuestro ejemplo. Vamos a suponer que el registro de un cliente, además de darlo de alta en la base de datos, requiere enviarle un correo electrónico a éste para notificarle que su alta fue exitosa y además verificar si el tipo de cliente que se dio de alta es un proveedor, y si es así, darlo de alta en la base de datos de Proveedores. Basándonos en lo que ya mencionamos sobre como diseñar aplicaciones SOA, tendríamos un conjunto de tres servicios web, uno de Clientes, otro de Email y otro de Proveedores.



Esta lógica adicional requiere coordinar las invocaciones a cada uno de los 3 servicios y realizar la validación pertinente. Nuevamente nos enfrentamos al mismo problema de antes, agregarla en cada una de las dos aplicaciones y repetir la misma funcionalidad, o centralizarla en un solo lugar para que ambas aplicaciones simplemente la consuman. Como lo hicimos antes, nos vamos a ir por la segunda opción en pro de la reutilización y para ello usaremos nuestro Servicio Proxy. Aquí es donde vamos a agregar este flujo, tal como lo ilustra la imagen, el recuadro amarillo contiene dicha lógica.



Este es un ejemplo básico de la funcionalidad de un Service Bus y de SOA, sin embargo, hay una gran cantidad de recursos disponibles que pueden hacer de nuestra orquestación, un elemento muy robusto y de gran utilidad, siempre y cuando, esté bien diseñado y aplicado.

Recordemos que el objetivo principal de los sistemas es cumplir los requerimientos del negocio para que le sean de utilidad, y para lograrlo hay que diseñarlos de manera flexible tratando de adaptarse a entornos cambiantes. Si generamos aplicaciones demasiado rígidas y estáticas, estan destinadas al fracaso, en cambio, si diseñamos sistemas capaces de ser modificados con menor esfuerzo e implicaciones, no solo estaremos promoviendo las buenas prácticas, sino estaremos cumpliendo la meta por más tiempo.

Espero que este ejemplo les haya dado un poco más de claridad en su camino al entendimiento del SOA.

¡Nos leemos la próxima vez!



Sandy
Compartamos para trascender.