arrows-765153_640

Como citaba esta semana en twitter

un patrón de diseño es una solución probada que se puede aplicar a un problema común

Como no podía ser menos, SOA tiene unos cuantos patrones ya probados que merece la pena conocer.

Quizás unos de los menos conocidos son los que se refieren al inventario de servicios. ¿Cómo definimos y organizamos los servicios dentro de este inventario de la mejor manera posible?.

En primer lugar, debemos de tener en cuenta dos patrones que nos ayudan a definir y mantener los servicios dentro de un mismo inventario: normalización de servicios y centralización de la lógica.

Normalización de servicios

A medida que el número de servicios va aumentando y se les va añadiendo más complejidad y funcionalidad, uno de los riesgos en los que caemos (con toda seguridad) es el solapamiento funcional de los servicios. Es decir, una misma lógica de negocio está implementada en más de un servicio.

Cuando esto aparece, se nos viene encima el consiguiente problema  ya que necesitamos mantener lo mismo más de una vez, puede no ser coherente entre varios servicios, no estar actualizada a la vez, etc. etc. En resumen, un problema del que conviene huir.

Como consecuencia de este overlap de la funcionalidad, tenemos que los servicios se vuelven más difíciles de reutilizar. Y por supuesto, aparece la tentación de volver a duplicar la lógica con tal de conseguir los objetivos a corto plazo del proyecto.

El patrón de Service Normalization establece el requerimiento que cualquier servicio dentro del mismo inventario tiene un contexto funcional distinto y disjunto del resto y que por lo tanto no se solapa con ningún otro. Cuando el inventario alcanza este estado se dice que está normalizado.

Centralización de la lógica

Este patrón viene a decir que una lógica de negocio sólo está en un sitio, en un servicio. Y además, para acceder a esa lógica, la única forma de hacerlo es a través de este servicio.

En el pasado he tenido algunas discusiones sobre este tema en particular con los equipos de desarrollo. Como decía es mucha la presión que puede haber en un desarrollo, y el camino más corto en SOA no es la línea recta, es la duplicación de la funcionalidad.

Hacer las cosas bien, e invocar al servicio que contiene esea lógica en lugar de duplicarla acarrea varios potenciales problemas como pueden ser el rendimiento, el coste, el plazo, etc. Aunque pueda parecer paradójico, muchas veces es más barato volver a implementar una lógica que llamar a la que hay.

Este patrón de Logic Centralization aboga por supuesto por la composición de servicios y es muy relevante durante las fases de modeladodiseño.

 

Anuncios