He estado bastante liadillo estas últimas semanas y no he tenido apenas tiempo de nada. Sin embargo, y no sólo porque tengo como objetivo semestral (en mi empresa) liderar esta iniciativa, hemos tenido un par de sesiones más del Grupo de Estudio “GeDOS”. Hemos cambiado un poco el formato porque no estabamos consiguiendo avances prácticos: nos quedábamos la mayoría de las ocasiones en temas demasiado teóricos.

Hemos pasado a estudiar directamente los Principios de Diseño que explica Thomas Erl en cada capítulo de su libro. Vamos sesión por sesión, capítulo por capítulo. La verdad es que ahora estamos bastante más enfocados que antes y eso se nota. Es como si hubiéramos pasado una barrera que nos impedía hablar de Diseño de Servicios (en mayúscula); quizás la decisión de no hablar de tecnologías, frameworks, etc. haya ayudado en esto.

La siguiente sesión (a la vuelta del puente) será la del capítulo 8 (Abstracción de servicios).

La semana pasada celebramos una reunión más del Grupo de Estudio “Diseño Orientado a Servicios” en DEGESYS. Parece que, por fin, nos estamos centrando ya y comenzamos a avanzar.

Os hago un extracto del acta de esa reunión por si alguien tiene curiosidad y/o quiere comentar algo.

Parece que no había quedado bien claro cuál era el tema a tratar, pero JRR abrió la discusión tratando sobre “¿alguien se acuerda cuál fue la pregunta inicial?”.

La conversación derivó rápidamente a discutir sobre la clasificación que hace T. Erl de servicios de entidad, de actividad o de utilidad. Discutimos sobre si los servicios son fundamentalmente de entidad (CRUD-like) en vez de principalmente de actividad (process-like). JRR hizo una anotación interesante: “la diferencia entre un task service y un entity service no es si está componiendo un proceso en base a otros servicios o no, sino en su naturaleza”. Y, ciertamente, Erl nunca hace esa simplificación sino que, en el ejemplo de la pág.45 compara el servicio “Factura” y su operación “Añadir” (claramente centrada en el dominio funcional de las facturas) con el servicio “Consolidación de Facturas de un Cliente” (que manipula un conjunto de facturas para un cliente dado y que no parece claramente centrado en el dominio funcional de las facturas ni tampoco de los clientes). Si este último caso resulta implementado como un proceso de negocio orquestando a otros servicios de grano más fino, hablaríamos de un orchestrated task service. Por último, Erl concluye en esta misma página que reconoce el punto de confusión y establece que la “capa de servicios de actividad” no concentra toda la lógica de procesos de negocio sino que se centra en aquella lógica no-agnóstica.

Iván apuntó la diferencia entre la clasificación de servicios por su modelo de análisis frente al diseño de capas de orquestación, de servicios de negocio y de servicios técnicos, donde esta clasificación de servicios de Erl encajaría enteramente en la capa de servicios de negocio. (Me atrevería a afirmar que Iván estaba pensando en este artículo de IBM cuando decía esto)

También discutimos sobre el peligro de centrar el esfuerzo de análisis/diseño en las entidades (porque eso nos hace derivar peligrosamente hacia servicios CRUD-like que ofrecen al exterior el modelo de datos) en vez de trabajar desde los procesos de negocio (desde donde irían surgiendo los servicios y, de ahí, las entidades). En varias ocasiones tratamos de ejemplificar esta orientación a servicios centrada en los requisitos de negocio en vez de centrada en los datos y parece que un ejemplo sacado del proyecto SGC aclaró un poco las ideas:

El proceso de contratación de un nuevo servicio para un cliente dado consiste en:

• formalizar el contrato con el cliente (persistir los datos de la contratación del servicio)
  
• iniciar la provisión de ese servicio (que debe asíncrona porque puede demorarse en el tiempo incluso días, o no acabar nunca…), devolviendo al cliente un “ticket”

Aunque no nos pusimos de acuerdo sobre si debía ser un “task service” o un “proceso orquestador de entity services”, la discusión parece que fue bastante enriquecedora porque durante ella se dijeron frases como:

• “Demandar al consumidor un alto nivel de conocimiento sobre mi negocio es malo”.
• “El Diseño Orientado a Servicios comienza por el servicio, no por los datos”.
• “Es más interesante enfocar el modelado desde el punto de vista de las actividades-procesos porque de ellas se podrán deducir más fácilmente las entidades” (También se escuchó la afirmación contraria)
• Para iniciar un diseño SOA tenemos que conocer los procesos de negocio, caso contrario no podremos hacer SOA.

Finalmente, acordamos (a propuesta de JRR) que en la siguiente sesión (la semana que viene) trataremos sobre la cualidad de “distribuibilidad” de un diseño para ser considerado Orientado a Servicios. La idea de fondo es validar la afirmación “una arquitectura basada en un contenedor OSGi, pero que no se puede hacer distribuida (e.d. ejecutada en varios contenedores separados físicamente), es SOA”. No hemos planteado un material específico porque entendemos que en el capítulo 3 da suficientes pistas, sin embargo, quedamos abiertos a alguna aportación que pueda ser de ayuda para esta discusión.

Bueno, pues esta semana que termina hemos dado el siguiente paso en el Grupo de Estudio. No es que haya sido un “Gran Paso para la Humanidad” pero un paso tras otro es como se anda.

ESTADO

• Planificada para el día 14/Feb/2008
• Pospuesta a la semana siguiente: J-21/Feb/2008 18:30
• Reunión realizada
• En fase de discusión

TEMA

• Contratos de servicio y estandarización

MATERIAL

• SOA. Principles of service design. Ch 6. Service contracts.pdf

ORDEN DEL DÍA

• La sesión la moderará JMB.
• Dado que no hemos participado mucho en las preguntas planteadas en la sesión anterior, propongo que no concluyamos nada y que pasemos directamente al tema del día: “Service Contracts”
• La pregunta inicial la hará Xavi G.
• Duración: 30 minutos
• Es importante (lo ha pedido Iván) que tratemos el tema de discutir sobre los contratos de DEAS-SALES, así que deberíamos dar tiempo a esta discusión para poder sacar conclusiones.
• Jose M. explicará los contratos de DEAS-SALES y discutiremos sobre ellos.
• Duración: 30 minutos
• Conclusiones y a casa.

PONENTE

Xavi G.

MODERADOR

JMB

ASISTENTES

• Iván H.
• Xavier G.
• Jose Manuel B.
• Jose M.
• Alfredo R.

DURACIÓN

Comenzamos a las 18:40 (otra vez un poco de retraso) y terminamos a las 20:05 (previsto a las 19:30)

RESUMEN

Xavi G. comenzó haciendo un resumen de lo más relevante (para él) del capítulo y así introdujo la discusión sobre la estandarización de los mensajes.

Xavi G. resaltó algunas frases y conceptos que le parecieron especialmente interesantes:

• Los contratos deben resistir el paso del tiempo.
• Los contratos deben expresar el dominio de su ámbito.
• Es interesante que los mensajes sigan un estándar conocido lo más universalmente posible para así no cerrar las posibilidades de interoperabilidad.
• Los contratos de servicios deben ser descubribles.

Alfredo R. aprovechó que el tema de esta sesión estaba centrada en los contratos para preguntar sobre cómo deberíamos (en DEGESYS) construir nuestros contratos:

• métodos con campos de tipo String (y que luego se parsean en el servicio para comprobar su conformidad al XSD correspondiente)
• métodos con campos de tipo ObjetoComplejo (y que sea JAXB y el wsgen el que construya el XSD)

Esta pregunta tiene más que ver con la discusión Contract-First vs Contract-Last y, aunque parece que todos teníamos mucha más simpatía por Contract-First, tanto Alfredo como JMB explicaron por qué estamos usando ahora mismo JAXB (e.d. Contract-Last) y reclamaron una manera diferente de hacer.

También estudiamos los contratos de DEAS-SALES y vimos que no parecía buena idea el seguir el patrón Request/Response puesto que:

• no era propio del modelo de dominio, sino más bien una necesidad tecnológica (distinguir entre los mensajes de ida y los de vuelta)
• no era necesario puesto que ya SOAP hace ese encapsulamiento

Revisitamos otra vez la discusión Contract-First vs Contract-Last y parece imponerse la necesidad de un prototipo.

Antes de terminar, JMB preguntó a todos si compartían/conocían la clasificación de tipos de servicio que proponía Thomas Erl en sus libros (entity, task y utility services). Así, propuso el material para la siguiente sesión.

SIGUIENTE SESIÓN

Fecha: 28/Feb/08
Tema: La granularidad de los servicios
Material de Estudio: SOA. Principles of service design. Ch 3. Service-oriented computing and SOA.pdf

Más vale tarde que nunca… hace más de una semana adelanté que habíamos creado un Grupo de Estudio sobre “Diseño Orientado a Servicios” y que iba a tratar de publicar los resultados de la primera reunión. Pues bien, aunque esta semana íbamos a celebrar la segunda reunión y hemos tenido que posponerla, ya tengo el resumen de la primera reunión y quería compartirlo.

ESTADO

• Planificada para el día 07/Feb/2008
• Reunión realizada
• En fase de discusión

MATERIAL

• “SOA Principles of Service Design” Capítulo 4 : Service-Orientation

PONENTE

• Jose Manuel Beas

MODERADOR

• No se eligió previamente, pero JMB intentó actuar como tal.

ASISTENTES

• Iván H.
• Xavier G.
• JMB
• Jose M.
• Marco F.
• JRR
• Alfredo R.

DURACIÓN

• Comenzamos a las 18:40 (un poco de retraso) y terminamos a las 19:50 (previsto a las 19:30)

PRIMERA IMPRESIÓN

• Comenzamos comentando el material que se había elegido.
• JMBeas apuntó hacia el concepto de interoperabilidad, que es uno de los 8 conceptos de diseño que se identifican en el material bajo estudio.
• La discusión rápidamente se desplazó a temas generales y JoseRamon volvió al foco planteando una pregunta acerca de si un servicio era necesariamente distribuido.
• Ante la discusión generalizada se decidió ir repasando cada uno de los 8 conceptos y en el primero y al hilo del significado de “Standardized Service Contract” volvió a desviarse hacia temas generales.
• La reunión, a partir de ese punto, se desenfoca y acabamos planteando temas demasiado abstractos para ser objeto de estudio. Hablamos de qué es un servicio, de dónde parte, de la importancia del contrato y de cómo es un contrato propiamente dicho.
• El tiempo avanza y decidimos cerrar la sesión no sin antes tomar algunas decisiones. Se decide que el tema de estudio para la siguiente reunión es el capítulo del mismo libro dedicado a los contratos. Se formulan tres líneas de debate:
• ¿El significado de “Standardized Service Contract” es el de generar un estándar propio de la empresa o de acercarse a estándares de la industria?
• ¿Es necesariamente distribuido un servicio? ¿y distribuible?
• Definir el ámbito de discusión y de aplicación de SOA para este grupo… todos estamos de acuerdo en que es Degesys y por lo tanto los escenarios en los que nos movamos deberían estar incluidos en este ámbito.
• Planteamos también el escribir para la próxima sesión un contrato tal como lo entendemos cada uno para poder, por síntesis, encontrar un punto de partida común para la siguiente sesión.

CONCLUSIONES FINALES

• N/A

SIGUIENTE SESIÓN

• Fecha: 14/Feb/2008 (San Valentín)
• Material de Estudio: “SOA Principles of Service Design” Capítulo 6 : Service Contracts (Standardization and Design)

Hemos creado un grupo en GoogleGroups para ver qué tal se nos da. Si vemos que la cosa funciona (y hay petición popular), abriremos la participación al público en general. De momento, a medida que vaya pudiendo extraer alguna conclusión suficientemente interesante, trataré de conseguir permiso para publicarla aquí.