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.