Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA)

Estilo arquitectónico

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.

Como se estructura una arquitectura de SOA

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.

Service-Oriented Architecture
Consumo de servicios

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.

Independiente de la tecnología

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.

tip

Nuevo concepto: Web Service

Un servicio web (en inglés, web service) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet.

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).

Protocolo SOAP
Consumo de un Web Service.

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.

Reutilización

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.

Composición de servicios SOA
Composición de servicios.

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.

Ventajas

  • Reduce el acoplamiento: La comunicación basada en contratos permite desacoplar las aplicaciones, ya que no existe referencias a la aplicación, si no a un servicio que puede estar en cualquier parte.
  • Testabilidad: Las aplicaciones basadas en SOA son muy fáciles de probar, pues es posible probar de forma individual cada servicio.
  • Reutilización: Los servicios SOA son desarrollados para hacer una sola tarea, por lo que facilita que otras aplicaciones reutilicen los servicios que existen.
  • Agilidad: Permite crear rápidamente nuevos servicios a partir de otros existentes.
  • Escalabilidad: Los servicios SOA son muy fáciles de escalar, sobre todo porque permite agregar varias instancias de un servicio y balancear la carga desde el ESB.
  • Interoperable: La interoperabilidad es uno de los factores por lo que existe esta arquitectura y es que permite que aplicaciones heterogéneas se comuniquen de forma homogénea mediante el uso de estándares abiertos.

Desventajas

  • Performance: La arquitectura SOA no se caracteriza por el performance, pues la comunicación por la red y la distribución de los servicios agregar una latencia significativa en la comunicación.
  • Volumetría: SOA no se lleva con grandes volúmenes por petición, por lo que para procesar mucha información es recomendable utilizar otras tecnologías.
  • Gobierno: Para que SOA pueda ser implementado correctamente, es necesario crear un Gobierno que ponga orden sobre el uso y la creación de nuevos servicios, lo que puede representar una carga adicional a la empresa.
  • Más puntos de falla: Debido a que SOA es una arquitectura distribuida, es necesario implementar estrategias de falla, pues se incrementa el número de puntos de falla.

Conclusiones

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.

Acerca de este libro

Introducción a la arquitectura de software

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
Todos los derechos reservados ©