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 modelado y diseño.
Blog de Andrés Hevia 
29/06/2015 at 19:36
Todos estos patrones son efectivamente un requisito básico para entender el Analisis orientado a servicios, y hasta cierto punto también, el diseño. Sin embargo, en cierto casos, particularmente con e-Gob., hace falta un patrón adicional, que sería el del Inventario mixto, que combina el inventario transversal con el inventario de dominio. eGob en particular, presenta el caso particular que una gran cantidad de servicios debe ser compartida entre todas las instituciones del Estado, y por lo tanto, tendrán sus estándares propios de diseño, plataforma común de desarrollo para un juego consistente de WS-*, ws-Policy comunes, esquemas XML centralizados, etc. mientras los dominios del gobierno (ministerios y entes descentralizados) tendrán una parte de sus servicios con estándares y plataformas propias, que no necesitarán ser compartidos. Esto forma la base para este patrón mixto candidato. El trabajo de gobernanza de este inventario híbrido, será en gran parte el de definir con las instituciones, cuales servicios van al inventario transversal y cuales se quedan locales.
Por ejemplo, los servicios de tarea orquestada que representan los procesos administrativos, son candidatos para ir al inventario transversal porque, a pesar que los servicios de tarea son non-agnósticos, en el ambiente del eGob un proceso administrativo debería poder consumer otro proceso administrativo. De la misma manera, los servicios de catálogos y los servicios que administran los registros públicos tambien deben ser parte del inventario transversal.
Por lo menos, esto es MI modelo de eGob y «acepto opiniones en lo contrario» como dicen los abogados. Saludos. Yves Chaix.
29/06/2015 at 19:45
Interesante aportación. Según la leo, se me viene a la cabeza una especie de «herencia» de inventarios, al estilo de la herencia de orientación a objetos. Es decir, el inventario transversal (el común) sería el inventario padre y los «locales» serían los hijos que heredan sus atributos y comportamientos y añaden luego su propia funcionalidad. Siguiendo con el simil, los servicios del padre los pondría como «final» para que no puedan ser modificados por los hijos.
Claro que a los inventarios hijos habría que imponerles ciertas restricciones para mantener la compatiblidad con el padre. Es decir, que no sean necesarias excesivas transformaciones para invocar desde un servicio del hijo al del padre (más bien ninguna transformación).
En fin, un debate interesante como digo… 😉
07/10/2015 at 18:32
En realidad, Andrés, no estoy seguro que haya efectivamente herencia, puesto que el inventario de dominio de cada institución va a tener especificaciones propias y si acaso tiene características idénticas al del inventario transversal padre, será por casualidad solamente, no por diseño. Las instituciones accederán a los servicios de su dominio con sus especificaciones (estándares, plataforma de ejecución, esquemas XML, etc.) para crear servicios para su propio uso solamente, y crear aquellas aplicaciones SOA propias del dominio. Cuando tenga que recurrir (consumir) servicios del inventario transversal, tendrán que adecuarse a sus especificaciones. De hecho, en términos de gobernanza, visualizo que habrá – con el pasar del tiempo – dos niveles de madurez de las instituciones. Un nivel inicial, gobernando por la SGPO central, con solo acceso al inventario central, y un nivel de madurez avanzado, donde la institución podrá adoptar una SGPO federada local, con un inventario de dominio para uso local exclusivamente.
Saludos cordiales.
30/07/2015 at 06:50
En sí el tener un buen inventario de servicios es un paso super importante durante la implantación de un proyecto SOA, independientemente del tipo que sea (Dominio o Empresa) de acuerda a la magnitud de servicios que se tenga, lo resaltante como dices es no tener la lógica duplicada ya que así se pierde algo fundamental que es que cada servicio debe tener un objetivo de negocio funcional diferente esto para que sea correctamente reutilizado. Muchos desarrolladores no entienden este punto, ya que simplemente se enfocan al desarrollo lo más rápido que sea, pero esto es un problema que si se pasa por algo irá creciendo y creciendo a medida que el inventario aumente, debido a ello la importancia de seguir correctamente estos patrones.
Saludos.
30/07/2015 at 08:21
Pues sí, aunque no sólo es que algunos no lo entiendan. Muchas veces, con los plazos tan ajustados, lo único que cuenta es acabar tu proyecto «como sea» y haces los servicios que necesitas sin pensar en el resto de la empresa ni que sean reutilizables.
Hay que luchar contra las dos cosas: el desconocimiento y el «cortoplacismo» de los proyectos…
07/10/2015 at 18:43
Ambos comentarios apuntan al tema de la Gobernanza SOA. ES el papel de la SGPO asegurar que se cumplan con los preceptos que regulan la implementación de los principios y patrones de diseño SOA (en particular del inventario). La calidad del inventario ES el resultado de la aplicación de mecanismos estrictos de gobernanza SOA. Parece haber un consenso creciente de que la carencia de un mecanismo formal de gobernanza es la causa principal de fracaso de los proyectos SOA.
Pero Andrés tiene mucha razón: la gobernanza SOA se enfrenta directamente con los mecanismos corrientes de contratación y de gerencia de los proyectos. Mientras los criterios gerenciales sean la productividad, la reducción del monto de las inversiones – aunque se traduzcan por costos de mantenimiento y gobernanza mayores a largo plazo – y los plazos de entrega, la gobernanza va a tener que librar una batalla cuesta-arriba. La única manera de contrarrestar esto es incluyéndo el nivel de los esfuerzos de gobernanza dentro del presupuesto de cualquier proyecto SOA Y tomar en cuenta en el costo de posesión, los costos de mantenimiento y gobernanza, lo que implica una visión estratégica y no táctica.
Cordialmente.
07/10/2015 at 18:52
Interesante reflexión. Quizás ahora que tenemos más experiencia tras haber pasado por varios proyectos podamos hacer ver, con pruebas, que hacer las cosas de cualquier manera es más caro que hacerlas bien… y podamos convencer a los que ponen el dinero de la importancia de una buena gobernanza, que realmente es sembrar hoy para recoger mañana.