Mostrando entradas con la etiqueta Patrones de Gobierno de Servicio. Mostrar todas las entradas
Mostrando entradas con la etiqueta Patrones de Gobierno de Servicio. Mostrar todas las entradas

lunes, 31 de octubre de 2011

Patrón de Identificación de Versión

Este patrón hace referencia a la forma en que los consumidores pueden estar notificados de las actualizaciones de versión del contrato de servicio.


Problema

Si un contrato, que por lo general ya ha sido publicado, está sujeto a la compatibilidad o a cambios incompatibles, cualquier modificación a su contenido, justifica una nueva versión del contrato. Sin un medio de asociación entre versiones que han generado cambios que afectan la compatibilidad entre un servicio y sus consumidores actuales y nuevos, se genera un riesgo permanente, dado que el servicio se vuelve menos detectable a los diseñadores de los consumidores, de modo que el diseño del servicio incrementa la dificultad para su gobernabilidad y evolución.


Solución

El contrato de servicio puede ser diseñado para expresar los identificadores de versión, que permite al consumidor determinar con seguridad si se trata de una versión compatible con el servicio. El uso de los identificadores de versión apoya aún más, la simultaneidad de contratos a fin de manejar el control de versiones, lo que permite a un consumidor elegir el contrato correcto, basado en su versión expresa.


Aplicación

Las versiones se suelen identificar de forma numérica, a través de valores que se incorporan al contrato de servicio, ya sea como anotaciones legibles o como una extensión efectiva de la operación técnica de contenido. La versión más común es a través del formato numérico con decimal, donde el primer dígito representa el número de versión principal, y los dígitos siguientes al punto decimal representan menores números de versión.

El significado de los números de versión realmente depende de los convenios celebrados por una estrategia global de versiones. A continuación se relacionan dos enfoques comunes:

• La cantidad de trabajo: Los números de versión mayor y menor se utilizan para indicar la cantidad de esfuerzo requerido en cada cambio. El incremento de un número mayor representa una cantidad importante de trabajo, mientras que el menor aumento de los números de versión representan mejoras de menor importancia.

• Garantía de compatibilidad: Números de versión mayor y menor se utilizan para expresar compatibilidad. El sistema más común se basa en que un aumento en el número de versión principal se traducirá en un contrato que no es compatible con versiones anteriores, mientras que los incrementos en el número de versión menor son compatibles con versiones anteriores. Como resultado de ello, no se espera que los incrementos de versión secundaria afecten a los consumidores existentes.

Se debe tener en cuenta que estos dos sistemas de identificación pueden ser combinados de manera que el número de versión incremental continúe indicando los cambios compatibles o incompatibles, al tiempo que representa la cantidad de trabajo que entró en los cambios.


Impacto

Los sistemas de identificación de versión y las convenciones suelen ser específicos para un inventario de servicios determinado y por lo general parte de una estrategia de versiones estandarizadas, según versiones canónicas. Como resultado, ellos no están estandarizados a nivel de la industria y por lo tanto, cuando se expresadan como parte del contrato técnico, imponen la necesidad constante de diseñar el servicio para que los consumidores puedan comprender el significado de los identificadores de versión y la programación de quienes consumen, según se requiera.

Cuando los servicios están expuestos a nuevos consumidores o a nivel externo, aplican los mismos requisitos, pero la aplicación necesaria de las normas puede ser más difícil de lograr.


Relaciones

Este patrón se aplica comúnmente como resultado del manejo de Versiones canónicas, y contempla una parte esencial en el proceso de generar un Cambio Compatible. La identificación de la versión hace referencia principalmente a otros modelos de contrato de control de versiones.

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.