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.




Comentarios

  1. muy bueno.... excelente..

    ResponderBorrar
  2. Excelente me gusta tu manera de explicar. Gracias

    ResponderBorrar
  3. Muy bueno tu aporte para el entendimiento de Soa.

    ResponderBorrar
  4. facil y bonito, muchas gracias :D

    ResponderBorrar
    Respuestas
    1. Muchísimas gracias, que bueno es saber que les ha servido para entender un poco más. Saludos!

      Borrar
  5. Hola, me gustaría saber si puedes recomendar algún libro en español para aprender de SOA para un desconocedor absoluto del tema.

    ResponderBorrar
    Respuestas
    1. Hola! Ufff me la pones muy difícil, creo que nunca he leído un libro en español de SOA, perdoname creo que te voy a quedar super mal con eso, trataré de averiguar con mis compañeros si alguien sabe de alguno y con gusto te lo comparto.

      Saludos.

      Borrar
  6. porfin alguien que explique bien gracias :D muy buen blog para poder entender todo esto!!

    ResponderBorrar
    Respuestas
    1. Gracias Cristian, me da gusto saber que te ha servido.

      Recibe un saludo!

      Borrar
  7. Excelente aporte. Claro y conciso. Muchas gracias ;)

    ResponderBorrar
  8. Me gusta la manera en la que trasmites tu conocimiento. Es un buen material y muy útil para iniciar en el mundo de SOA y OSB. Saludos.

    ResponderBorrar
    Respuestas
    1. Muchísimas gracias Marcos, me da gusto que te haya servido!

      Recibe un saludo.

      Borrar
  9. Gracias por este post, muy bueno y muy concreto en los conceptos

    ResponderBorrar
  10. muchas gracias, excelente post !!

    ResponderBorrar
    Respuestas
    1. Gracias a ti Marcos por leerme y aportar tus comentarios.

      Saludos!

      Borrar
  11. Una consulta, a que le llamas repositorio, cuando dices modificar las 2 aplicaciones y apuntar al nuevo repositorio ??
    Osea las 2 aplicaciones estarian en un mismo servidor de aplicaciones ??
    modificamos ambas y unificamos la base de datos??

    ResponderBorrar
    Respuestas
    1. Hola Alejandro, me refería a reposiorios de datos, es decir, a la base de datos. Respecto a las aplicaciones, en el ejemplo están desarrolladas en diferentes lenguajes y desplegadas en diferentes servidores.

      Saludos!

      Borrar
  12. Bravo!! genial aporte, haces que parezca fácil y eso es lo díficil. Enhorabuena

    ResponderBorrar
    Respuestas
    1. Muchas gracias!

      Que gusto saber que te ha servido un poco para entender esta arquitectura.

      Saludos!

      Borrar
  13. Excelente post como todos los demás, felicitaciones Sandy, saludos desde Chile!

    ResponderBorrar
  14. Muchas gracias, excelente explicación.

    ResponderBorrar
  15. Gracias Sandy, excelente resumen.

    ResponderBorrar
  16. Parece fácil pero diste una explicación muy sencilla y precisa de lo que es un Proxy, las veces que he leído una definición de Proxy pocas veces me había quedado tan claro. Con respecto al tema global que es SOA, muy entendible y bien explicado, como mujer mi admiración y respeto. Saludos.

    ResponderBorrar
  17. Muy buen artículo, ojala puedas mas adelante postear uno donde pueda apreciarse la descomposición de procesos en servicios.

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Conceptos básicos de Servicios Web SOAP, WSDL y XSD

OWSM and WS-Security: Username Token Authentication for SOAP and REST Services in OSB 12c.

Conversión de servicios SOAP a REST/JSON usando OSB 11g