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

Tagged: