lunes, 31 de octubre de 2011

Patrón de Cambio Compatible

Este patrón hace referencia a la forma de modificar un contrato de servicio sin impactar a los consumidores.


Problema

Después de la implementación inicial de un servicio que hace parte de un inventario de servicio activo, sus capacidades estarán disponibles como un recurso de empresa. Por lo tanto, los consumidores estarán habilitados para invocar e interactuar con el servicio a través de su contrato con el fin de aprovechar sus capacidades a través de su consumo.

Como resultado, se genera dependencia de forma natural, entre el contrato de servicio y los programas para el consumidor. Si se requiere efectuar modificaciones al contrato, el cambio puede generar el riesgo de afectar a los consumidores existentes que fueron diseñados de acuerdo con un modelo original.


Solución

Siempre que sea posible, los cambios a los contratos de servicios establecidos deben asegurar la compatibilidad con las versiones anteriores de los contratos y con los consumidores actuales. Esto permite que el contrato de servicio pueda evolucionar de acuerdo con las necesidades, evitando el impacto negativo en las composiciones y dependencias de los programas para el consumidor.


Aplicación

Hay una variedad de técnicas mediante las cuales se puede aplicar este modelo, en función de la naturaleza del cambio requerido en el contrato. El propósito fundamental de este modelo es evitar tener que imponer cambios incompatibles de un contrato de servicios con las versiones anteriores, de las que dependen sus consumidores.

A continuación se mencionan los cambios que en general se requieren para los contratos de servicios Web y que pueden requerir compatibilidad con versiones anteriores:

• Adición de una nueva operación para una definición de WSDL
• Cambiar el nombre de una operación existente
• Extracción de una operación existente
• Cambio del MEP de una operación existente
• Adición de un mensaje de error a una operación ya existente
• Adición de un Nuevo tipo de puerto
• Adición de un elemento de mensaje nuevo esquema o atributos
• Eliminación de un elemento de mensaje de esquemas existentes o atributo
• La modificación de la restricción de un esquema de mensaje
• Adición de una nueva política
• Adición de afirmaciones políticas
• Adición de afirmaciones ignorable Política


Impacto

Cada vez que un contrato de servicio ya publicado cambia de versión, se requiere un esfuerzo adicional, para asegurar que el cambio se representa como una nueva versión del contrato, que ha sido debidamente expresado y comunicado a los consumidores actuales y futuros.

Este patrón puede eventualmente transformarse en contratos robustos que son más difíciles de mantener. Además, estas técnicas a menudo conducen a la necesidad de una notificación de terminación, lo que puede aumentar tanto el contenido del contrato y mayor trabajo para el gobierno del servicio.


Relaciones

Para aplicar este patrón consistentemente a través de múltiples servicios, se requiere la presencia de un sistema de versiones oficiales, que esté muy bien estandarizado de acuerdo con las versiones canónicas. Adicionalmente, este modelo depende de la identificación de la versión, con el fin de asegurar que los cambios estén bien expresados y podrán exigir la notificación de terminación para una transición de contenido del contrato, informando a los consumidores de las nuevas versiones.

No hay comentarios:

Publicar un comentario