El bus de servicios en SOA


Este escrito es sobre el porque del uso de un bus de servicios en donde se tienen varios servicios SOA interconectados. Muestra gráficamente como sería una arquitectura sin este bus de servicio y con el bus. De esa forma se evidencian sus ventajas y desventajas.

Ya les he hablado de SOA en el artículo Conceptos clave de SOA, pero hoy les quiero hablar de algo que no está en esos conceptos básicos, el bus de servicios. Para entender su necesidad primero imagine que tiene una organización en donde muchos de los sistemas de información se comunican entre si mediante SOA y además son fuertemente dependientes unos de otros. La situación se se vería gráficamente de la siguiente manera.

 

Varios servicios interconectados sin bus de servicios

Varios servicios interconectados todos contra todos sin bus de servicios. Arquitectura punto a punto

En el gráfico se tienen solo ocho servicios, lo cual es muy poco para una organización que utilice juiciosamente SOA. Además en el gráfico es la situación en donde todos están conectados con todos. En éste, el número de conexiones máximas posibles  es de n * (n-1) ¡del orden de n2! Imagine por un momento sino son ocho, sino veinte, lo cual no es raro en una organización, se tendría un máximo de 20 * (20-1) = 380 conexiones, y para treinta servicios ¡30 * (30-1) =  870 conexiones! crece de manera cuadrática.

Esta complejidad puede tener muchas consecuencias, por ejemplo: Un aumento en la dificultad de la administración del sistema. También puede ser fuente de agujeros de seguridad. Y en general, a medida que aumenta la complejidad se pierde el control. Y podrían mencionarse muchas más, que en últimas redunda en altos costos para la organización.

En cambio, si tenemos los mismos servicios conectados a un bus se servicios se vería como lo siguiente.

Varios servicios conectados mediante un bus de servicios

Varios servicios SOA conectados mediante un bus de servicios

Tal vez no sea tan bonito como la anterior arquitectura (que parecía una joya facetada), pero es una arquitectura mucho más sencilla.Para ocho servicios solo se tienen ocho conexiones, y en general para n servicios se tienen n conexiones. Para el caso más extremo que calculamos, para 30 servicios solo se tendrían 30 conexiones que son mucho menos que las 870 que se necesitarían con la arquitectura punto a punto.

También tiene las ventajas que tiene toda intermediación, esto es, se tiene una capa software  entre los diversos servicios que aísla a éstos entre si. Por ejemplo, este aislamiento permite que los sistemas de información sean más fácilmente reemplazables puesto que la intermediación hace opaco este reemplazo. Esto puede servir, además,  para hacer traducciones entre diversos protocolos SOA, sin que los servicios involucrados se den cuenta. En este mismo orden de ideas, es mucho más fácil conectar una aplicación legada, una que no está hecha siguiendo los estándares SOA, mediante adaptadores que se conectan al bus de servicios, y el día de mañana cuando esa aplicación se migre las demás que consumen servicios de ella no se darían ni cuenta del cambio.

Claro, no todo son ventajas, la arquitectura de bus de servicios también tiene algunas desventajas. La que me parece más grave es que es un único punto de fallo. El día en el cual el hardware o el software que soportan el bus de servicios falle, toda la organización queda sin funcionar. Pero esto se puede solucionar montando el bus en un esquema de alta disponibilidad.

En general, como con cualquier sistema tecnológico lo que hay es que poner en una balanza cuyo fiel es la relación costo-beneficio. Y es de enfatizar que esta evaluación debe hacerse lo más objetiva posible. Me he encontrado muchas organizaciones en que las decisiones de TI se toman en base a lo que se conoce, o de lo que se ha oído hablar, o peor, en base a lo que dicen los proveedores de TI y no en base a lo que es mejor para la organización. Y en una decisión tan crítica no se puede dejar en manos de las opiniones y los opinadores.

Si quieres seguir leyendo sobre SOA, he publicado otro artículo sobre el tema que es:

Comments
One Response to “El bus de servicios en SOA”
Trackbacks
Check out what others are saying...
  1. […] Este es una primera aproximación al Modelo de Referencia SOA de OASIS, digamos que es un primer nivel, y muy superficial, de este denso documento que es el Modelo de Referencia SOA de OASIS [1], pero sirve como introducción a los conceptos clave de SOA. Tal vez en un futuro aborde una descripción más profunda de este documento que realmente lo merece, así implique mucho tiempo. O tal vez algún lector ya lo ha hecho y pueda compartirnos su escrito en los comentarios. Por ahora les dejo otro de los artículos sobre SOA que tengo en este blog: El bus de servicios en SOA. […]



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: