Hace cercas de 20 años cuando todavía no existían tantos productos de software comerciales para gestionar las diferentes áreas de una compañía, las empresas por lo general construían sus propios sistemas adecuados para satisfacer sus necesidades específicas, por lo que casi toda la información residía en un solo punto, lo que hacía que las necesidades de integrar información entre diferentes sistemas eran casi nulas.
Sin embargo, con el paso de los años, empezaron a salir sistemas especializados que ayudaban a gestionar diferentes áreas de la compañía de una forma más eficiente y con un costo mucho menor que desarrollarlos por ellos mismo, como es el caso de los sistemas de nómina, inventarios, distribución, contabilidad, almacenes, ERP, CRM, CMS, etc. Aunado a esto, todos estos productos eran desarrollados por empresa y tecnologías diferentes, lo que hacía que enviar o consultar información de un sistema a otro era un verdadero dolor de cabeza.
Una de las problemáticas más importantes para la transferencia de información de un sistema a otra era la tecnología por sí misma, ya que una aplicación desarrollada en C no se podía comunicar naturalmente con una en Java, o una aplicación de Visual Basic, esto provocaba que los desarrolladores buscaran alternativas para la transmisión de información, la cual consistía en intercambiar archivos de texto plano o compartir una base de datos desde la cual leyeran y escribieran información, que como veremos más adelante, era otro problema.
Para solventar esta problemática salieron tecnologías como DCOM (Distributed Component Object Model) y CORBA (Common Object Request Broker Architecture) los cuales buscaban resolver los problemas de comunicación entre las diferentes tecnologías, y lo lograron, sin embargo, son hasta la fecha, tecnologías sumamente complejas. DCOM se implementa mediante la creación RPC (Remote Procedure Call – “Llamada a procedimientos remotos”) el cual consiste en crear procedimientos expuestos por un servidor que pueden ser ejecutados por otra aplicación, con la limitante que solo soporta parámetros básicos, es decir, no soporta estructuras u objetos. Por otra parte, CORBA, si permite en envío de mensajes completos u objetos, sin embargo, CORBA requiere de la definición de cada objeto en un lenguaje descriptor de interfaz (IDL) y la creación de Stubs, los cuales son representaciones de los objetos y operaciones remotos del lado del consumidor del servicio.
Debido a toda esta problemática, nace la arquitectura SOA (Service-Oriented Architecture), la cual incentiva a que las empresas creen servicios interoperables que puedan ser aprovechados por toda la organización. Dichos servicios deben de ser construidos utilizando estándares abiertos, lo que permita que pueden ser consumidos por cualquier aplicación sin importar en que tecnología esté desarrollada.
SOA solo promueva la creación de servicios para lograr la integración de aplicaciones, por lo que se podría decir que CORBA es el precursor de SOA, aunque al momento de crear CORBA no existía el término de SOA. Por su parte, el nacimiento de SOA como arquitectura no solo trae el concepto de crear servicios si no un nuevo paradigma que revoluciono la forma en que construimos software de hoy en día.
Lo primero que tenemos que entender al momento de implementar una arquitectura SOA es que, todas las aplicaciones que construimos están diseñadas para ser integradas con otras aplicaciones, por lo que deben de exponer como servicios todas las operaciones necesarias para que otras aplicaciones pueden interactuar con ella.
En la imagen anterior podemos ver como las aplicaciones del lado izquierdo (A, B, C) exponen una serie de servicios que estarán disponibles por la red, los cuales son consumidos por las aplicaciones del lado derecho (X, Y, Z), aun que podrían ser consumidos por cualquier otra aplicación que este dentro de la misma red, o en su defecto, por internet.
La idea central de construir servicios va más allá de solventar la problemática de la integración con aplicaciones heterogéneas, si no que brinda una serie de ventajas que ayudan a la reutilización de los servicios, encapsulamiento de las aplicaciones, seguridad, una larga lista de características.
Lo primero que debemos de analizar es que, los servicios deben ser construidos con estándares abiertos, lo que quiere decir que es independiente del sistema operativo o del lenguaje de programación. Hoy en día conocemos a estos servicios como Web Services.
Nuevo concepto: Web Service
Para que un servicio sea considerado un Web Service, debe de publicar un WSDL (Web Services Description Language), el cual es un contrato que describe las operaciones que expone el servicio, los tipos de datos esperados en formato XSD (XML Schema).
Este contrato (WSDL) será utilizado por el consumidor para crear mensajes en formato XML para enviar la información, los cuales deberán de cumplir al pie de la letra la estructura definida en el contrato.
Si bien el protocolo HTTP es el más utilizado para la transmisión de los datos, no es la única forma, como muchos creen, pues en realidad SOA no define los protocolos a utilizar, es por ello que es posible transmitir los mensajes por protocolos como FTP o SMTP, lo importante es que el mensaje (XML) cumpla con el contrato (WSDL). Finalmente, el mensaje es envuelto en el protocolo SOAP (Simple Object Access Protocol), el cual es otro protocolo estándar que divide el mensaje en dos secciones, el header y el payload, el primero son una serie de parámetros de cabecera de control, que ayudan a los sistemas a entender el payload, por otra parte, el payload es el mensaje transmitido como tal (XML).
La utilización de todos estos estandartes y protocolos como HTTP, SOAP, WSDL, XML, XSD hacen que las aplicaciones se puedan comunicar de una forma totalmente homogénea, pues ya no importa en qué tecnología este desarrollado el sistema, sino más bien, cumplir con el formato del mensaje, el cual está perfectamente definido en el WSDL.
Cuando nació DCOM y CORBA no existía una cultura de reutilización, por lo que lo que se exponía eran por lo general operaciones de negocio complejas que realizaban varios pasos, lo que hacía muy difícil que una operación se pudiera ser reutilizada por otras aplicaciones, en este sentido, una operación era construida específicamente para una integración especifica.
Por el contrario, SOA promueve la construcción de servicios que hagan una sola tarea, lo que hace que en lugar de tener 1 servicio que haga 10 cosas, mejor hacemos 10 servicios que hagan 1 cosas. En principio se puede escuchar estúpido tener que crear más servicios, sin embargo, al construir servicios que hagan una sola tarea los hace mucho más reutilizables, por otra parte, es posible crear nuevos servicios basado en los anteriores, lo que conocemos como servicios compuestos
Cabe mencionar que SOA pone foco en la flexibilidad por encima de la optimización, lo que quiere decir que esta arquitectura no es especialmente rápida con respecto a otras, ya que en ocasiones un servicios tiene que consumir a otros para completar un proceso de negocio, lo que hace que cada brinco a otro servicio provoque una pequeña latencia, además, los servicios por lo general son distribuidos, lo que quiere decir que los diferentes servicios pueden estar en diferentes redes o regiones geográficas, sin embargo, esta arquitectura se caracteriza por su flexibilidad, ya que permite la construcción de nuevos servicios utilizando la infraestructura de servicios existentes.
En la imagen anterior podemos ver claramente como nuevos servicios se van construyendo a partir de los servicios existentes, pero al mismo tiempo, a la vez que vamos subiendo en el nivel de composición, los servicios se van haciendo de más alto nivel, es decir, puede que el primer nivel sean servicios básicos de CRUD (Altas, Bajas, Cambios, Borrado) y los servicios de más nivel son operaciones completas como reservar un vuelo con hospedaje y la renta de un carro, al mismo tiempo que a más alto nivel, diferentes aplicaciones pueden ser impactadas en una sola ejecución.
Como hemos podido analizar en este capítulo, SOA es una arquitectura muy flexible que permite la interoperabilidad entre las diferentes aplicaciones empresariales, ya que utiliza una serie de estándares abiertos que permite que sean independientes de la tecnología o la plataforma, sin embargo, SOA es uno de los estilos arquitectónicos más complejos por la cantidad de componentes que interviene, el gobierno y toda una serie de lineamientos que se deben de cumplir para implementarla correctamente, por lo que te sugiero que si quieres aprender SOA de lleno, busques una literatura especializada en el tema, ya que este arquitectura tiene libros completos sobre cómo implementarla, que hacen que sea imposible de cubrir en este libro.
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:
Ver libro
© 2021, Copyright - Oscar Blancarte. All rights reserved.
