GeDOS : Contratos de servicio y estandarizació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

Modelos de servicio (según Thomas Erl)

En la página 43 del libro "SOA: Principles of Service Design" (y también en el anterior "Service-Oriented Architecture (SOA): Concepts, Technology, and Design"), Thomas Erl presenta una clasificación de servicios que creo bastante útil:

• servicios de entidad (entity services)
• servicios de tarea (task services)
• servicios de utilidad (utility services)

Estos servicios se dispondrían por capas o niveles (layers), estando los de tarea más cerca de las aplicaciones y los de utilidad más cerca de los sistemas externos.


Servicios de entidad

Su ámbito funcional se circunscribe a una o más entidades de negocio, p.ej. Cliente, Empleado, etc. Se consideran servicios muy reusables porque se diseñan agnósticos de la mayoría de los procesos de negocio en los que puedan participar.

Ejemplo:

Employee

• GetWeeklyHoursLimit
• UpdateWeeklyHoursLimit
• GetHistory
• UpdateHistory
• DeleteHistory
• AddProfile
• GetProfile
• UpdateProfile
• DeleteProfile

Sus operaciones pueden ser parecidas al CRUD.

También llamados "business entity services" o "entity-centric business services".


Servicios de tarea

Su ámbito funcional está directamente asociado a una tarea o proceso de negocio. Este tipo de servicio tiende a ser menos reusable que los servicios de entidad. Normalmente se comporta como el controlador de una composición de servicios (quizás estos más agnósticos).

Ejemplo:

RevenueAnalysis

• Submit

Dependiendo de la tecnología empleada, este tipo de servicios pueden ser implementados con un WebService o con una plataforma de orquestación de servicios (definido el proceso de negocio con BPEL, p.ej).

También llamados "business process services" o "task-centric business services".


Servicios de utilidad

Los anteriores se centran en el negocio, éstos se centran en la tecnología.

En la capa de servicios de utilidad agrupamos servicios reusables, transversales e idealmente agnósticos de la aplicación que lo puede consumir.

Ejemplo:

Transform

• APImport
• APExport
• ARImport
• ARExport

También llamados "application services", "infrastructure services" o "technology services".

Probar un objeto que instancia a sus propios colaboradores

Esta semana pasada he tenido el siguiente problema:

Queremos probar una clase (Flow) que implementa un flujo de llamadas a otros objetos (Tasks) que representan tareas.

En principio, parece un enunciado bastante simple, pero la dificultad radica en que no es posible sustituir las tareas por dobles (mocks) porque son instanciadas dentro del propio flujo. ¿Qué estrategia de prueba podemos seguir entonces?

Inicialmente lo hemos resuelto teniendo una TaskFactory que inyectamos al flujo, de tal modo que podamos hacer un doble de ésta (con EasyMock).

Pero este fin de semana, con algo más de tranquilidad, he estado reflexionando y me he dado cuenta de que realmente no estábamos siguiendo una buena estrategia, puesto que habíamos hecho un diseño contraintuitivo simplemente porque no éramos capaces de hacer pruebas unitarias del objeto Flow. Es más, en mi opinión, lo que estábamos probando era que habíamos escrito el código que estaba ya escrito... es decir, no estábamos realmente probando ni el resultado final ni las colaboraciones con objetos externos al propio SUT (System Under Test, que dice la bibliografía más reconocida). Estábamos probando que se ejecutaban las diferentes líneas del algoritmo. Mmmm... me parece que eso no es una prueba unitaria...

Pues bien, dándole vueltas al tema he llegado a la conclusión de que:

• las tareas son parte del flujo, e.d., son parte del SUT
  
• nuestra intención era probar las salidas indirectas del flujo
• deberíamos comprobar las llamadas a sistemas externos que puedan hacer las tareas, e.d. necesitamos puntos de observación para esas llamadas
• también puedo probar es el estado final del SUT, lo cuál me ha dado la pista de que puedo pasar un contexto (FlowContext) al flujo, de tal modo que cada una de las tareas pueda modificarlo y yo comprobar al final de cada prueba el resultado final (esto me viene bien, por cierto, para otros requisitos que tengo más adelante...)

Primera sesión del GeDOS

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í.

La importancia del kick-off

Estas últimas semanas estamos dándole una vuelta de tuerca a nuestra propia interpretación del agilismo y hemos impuesto lo que conocemos internamente como "iteración extrema", que consiste (simplificando mucho) en planificar iteraciones de una semana. Sí, sí, de una semana. Bueno, realmente lo que estamos haciendo es aplicar muchas técnicas de SCRUM, pero adaptando todo a nuestro propia idiosincrasia.

En este contexto, el pasado lunes hicimos en mi proyecto el kick-off de la iteración correspondiente a esta semana; pero lo hicimos tan mal que nuestro coach, Xavi Gost, nos hizo repetirlo: no habíamos definido claramente las historias de usuario, ni estimado tareas...aunque eso sí, nos habíamos puesto fechas (pero ni una estimación en base a tareas). Total, que había sido un desastre. De hecho, la mayoría del equipo no tenía demasiado claro qué tenía que hacer.

Afortunadamente, en la repetición estuvimos asesorados y puedo asegurar que es una experiencia muy gratificante salir de una reunión como ésta porque lo haces perfectamente enfocado y con una gran seguridad en ti mismo y en tus propias posibilidades de éxito: sabes que los objetivos que te has marcado son factibles, lo cuál no es ninguna tontería..

Libros

Mi último pedido a Amazon ha llegado:

• Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) [Hardcover]
  By: Erich Gamma (Author), et al
• Domain-Driven Design: Tackling Complexity in the Heart of Software [Hardcover]
  By: Eric Evans (Author)
• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency [Paperback]
  By: Tom DeMarco (Author)
• Model-Driven Design Using Business Patterns [Hardcover]
  By: Pavel Hruby (Author)

Mucho para leer y poco tiempo...

GeDOS

En DEGESYS hemos lanzado una iniciativa formativa poco frecuente. Se trata de un Grupo de Estudio formado por voluntarios en el marco del cuál, todas las semanas, se estudia un tema (alguien se lo prepara especialmente) y se hace una puesta en común con el objetivo de asegurar una mejor comprensión de los conceptos. Para esto nos hemos basado principalmente en el trabajo de Joshua Kerievski titulado “Knowledge Hydrant: A Pattern Language for Study Groups”, donde se explica cómo organizar con éxito un Grupo de Estudio.

Lo hemos nombrado GeDOS (Grupo de Estudios "Diseño Orientado a Servicios") porque justamente queremos centrarnos en aumentar nuestro conocimiento sobre este tema en particular y tratar de cubrir así nuestras necesidades de formación en este terreno dado que no encontramos nada en España ni fuera de España (a un precio razonable, claro).

El primer material de estudio que hemos decidido (y que ahora mismo debería estar yo estudiando, puesto que soy el ponente de la primera sesión) es el capítulo 4 del libro de Thomas Erl "SOA: Principles of Service Design", titulado "Service Orientation" y que, para que os hagáis una idea, son apenas 30 páginas y es básicamente una introducción al paradigma SOA y a los retos que hay que enfrentarse cuando se diseña en base a este modelo. El próximo jueves nos reuniremos en un VIPS cerca de la oficina, mientras tomamos un café y pondremos en común las conclusiones que cada uno haya sacado del estudio. Espero que el fin de semana pueda haceros partícipes de esas mismas conclusiones porque la idea es publicarlas también en nuestro wiki, con lo que no me debería costar nada ponerlo en el blog porque lo difícil ya estaría hecho. :-)

Lógicamente, no descartamos poder abrir el Grupo de Estudio a personas fuera de DEGESYS, con todas las ventajas que eso supondría para la compañía (darse a conocer a profesionales cualificados del sector) y para los propios miembros del Grupo de Estudio (ampliar la red de contactos y enriquecerse con conocimientos y puntos de vista “extramuros”), pero de momento vamos a rodar la iniciativa y ya iremos sacando conclusiones de esta experiencia. También estamos pensando en organizar otros Grupos de Estudios sobre otros temas, pero "piano, piano si va lontano"...

Por cierto, quería aprovechar para saludar a Jose Moreno, que ha dejado Cap Gemini para unirse a nuestro Departamento de Desarrollo como arquitecto. Estoy seguro de que vamos a aprender mucho juntos. De momento ya le he enredado para que se una al GeDOS.