Composición de los Servicios

por

 

Principio SOA 8 – Los Servicios participan eficazmente en la composicion de servicios, independientemente del tamaño y complejidad de la composicion

 

Composición de servicios.

Completamos esta serie de entradas dedicadas a los principios SOA con este octavo y último principio: la composición de servicios.

 

Como hemos venido comentando en esta serie, la mayoría de los principios SOA están estrechamente relacionados entre sí, y a menudo se necesitan mutuamente para poder implementarse. Este es de nuevo el caso con el principio de composición de servicios.

 

Lo que este servicio viene a subrayar es un principio de diseño que no siempre es inmediato de ver, y que de no tenerse en cuenta puede acarrear una importante cantidad de esfuerzo para rediseñar lo que ya se creía estable.

 

A menudo los primeros servicios de una implantación de una estrategia SOA vendrán de abajo arriba, es decir, partirán de las soluciones de integración existentes en los sistemas heredados.

Tras alguna labor de abstracción y estandarización se identificarán los servicios SOA que pueden cubrir las necesidades existentes en un nivel de orientación a servicios superior.

Habitualmente esas necesidades son tareas sencillas, sin apenas reglas de negocio ni eventos complejos que orquestar.

 

Otras veces, nuestros servicios vendrán del análisis de procesos de negocio más o menos complejos. Primero analizaremos procesos más simples, con pocos actores, reglas de negocio de baja complejidad, etc.

Este camino de arriba abajo nos dará servicios generalmente con un nivel de abstracción alto, y a menudo encontraremos en nuestra mesa de diseño servicios con vocación de resolver problemas complejos. Estos problemas pueden explotarse en otros más sencillos, que podrían dar lugar a servicios más granulados, reglas más detalladas, etc.

 

Pues bien, el reto que se nos presenta aquí es lograr que en ambas aproximaciones, los servicios sean diseñados pensando en que además de resolver la necesidad o la tarea que estamos analizando, debe ser capaz de combinarse con otros servicios para resolver procesos más complejos, servicios compuestos.

 

Podríamos pensar que esto no requiere de un principio SOA. Al fin y al cabo al estar usando estándares para el diseño de los servicios siempre podremos combinarlos.

 

Pero no es suficiente.

 

Pensemos por ejemplo en el escenario de arriba abajo que hemos planteado: analizamos un proceso de negocio determinado, e identificamos un posible servicio a incluir en el catálogo.

 

Bien, podemos tratar de resolver ese subproceso o conjunto de subprocesos mediante un único servicio, o bien podemos descomponerlo en tareas cada vez más sencillas, y que sean éstas tareas más sencillas las que tengan cada una su propio servicio estándar.

 

¿Para qué? ¿Por qué aumentar así el número de servicios a diseñar, construir y mantener?

 

Fácil: para tener más piezas del lego.

 

Para poder contar en próximos casos de uso con suficientes servicios estándar como para poder seleccionar algunas de esas piezas y poder componer otros servicios de orden superior a base únicamente de ensamblar estos servicios.

 

 

El símil del juego de lego es muy útil.

 

Lograr tener un conjunto de servicios estándar, orientados por eventos de negocio, orquestados por las reglas de negocio, y que puedan ser autónomos y al mismo tiempo componer entre sí servicios de mayor orden, nos proporciona una tremenda potencia y flexibilidad a la hora de maximizar el impacto y el beneficio de toda la estrategia SOA.

 

Es como tener una caja de piezas de lego de distintas formas y colores.

 

Es mucho mejor que tener piezas grandes, ensambladas de forma específica para alguna necesidad concreta. Eso reduciría nuestra capacidad de reutilizar esa pieza, para empezar. Y muy probablemente incluirá detalles que se nos presentarán en otros modelos, y que por tanto tendremos que volver a incluir.

 

Si en vez de eso descomponemos todas las piezas lego, tendremos mucha más facilidad y flexibilidad a la hora de componer cualquier forma, sin preocuparnos de retocar ni rediseñar nada, ni de estar repitiendo nada ya existente.

 

Pensemos también en el mantenimiento del catálogo.

 

Si nuestros servicios tienen la granularidad adecuada que les permita componer servicios de orden superior, el mantenimiento se facilita y agiliza clarísimamente. Cualquier error que surja, o cambios que tengamos que añadir a nuestros servicios, afectarán a muchos menos servicios del catálogo, puesto que todos sus usos (autónomos o compuestos) se verán inmediatamente actualizados por la nueva versión del servicio corregido o evolucionado.

 

Como podéis ver, tener en mente el principio de composición de servicios a la hora de identificar, analizar y diseñar nuestros servicios SOA, arroja importantes ventajas para nuestro futuro, y potencia enormemente el impacto y la razón de ser de toda la estrategia SOA para la organización.

 

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This