Refactorización de servicios

Dentro del paradigma de diseño orientado a servicios , la refactorización de servicios es un patrón de diseño que se aplica a un servicio existente ^{[ 1 ]} de manera que se pueda cambiar la lógica del servicio o su implementación sin afectar a los consumidores del servicio.

Es natural que un servicio experimente cambios por diversas razones. El cambio podría ser necesario porque la implementación subyacente (por ejemplo, bases de datos, sistemas heredados , etc.) necesita actualizarse o simplemente porque la lógica original del servicio no hacía un uso eficiente de la memoria. En otros casos, el cambio podría ser iniciado por los propios consumidores del servicio. Por ejemplo, con un uso concurrente limitado, el servicio funciona según lo estipulado en su SLA ; sin embargo, con un aumento en su uso concurrente, el servicio no puede cumplir con su SLA y, en consecuencia, necesita responder a las crecientes demandas de rendimiento de sus consumidores. ^{[ 2 ]}

Es necesario abordar esta situación de manera que se mejore el servicio sin perjudicar a los consumidores que ya dependen de él. Si bien podría argumentarse que responder a cualquiera de los requisitos mencionados no debería ser problemático siempre que el servicio cumpla con su contrato, nos preocupa tanto el resultado de la ejecución de las funcionalidades del servicio ^{[ 3 ]} como su comportamiento y fiabilidad. El patrón de diseño de refactorización de servicios proporciona una estrategia para garantizar que un servicio pueda evolucionar sin afectar negativamente a sus consumidores ^{[ 4 ] .}

La aplicación de este patrón de diseño aboga por el uso de técnicas tradicionales de refactorización de software . El enfoque está en refactorizar el servicio en pasos más pequeños para que el impacto de cada paso sea mínimo y pueda revertirse fácilmente si afecta negativamente a los consumidores del servicio. En segundo lugar, para garantizar que el contrato de servicio no se vea afectado por cambios en la lógica o la implementación, el contrato de servicio debe desacoplarse lo máximo posible. ^{[ 5 ]} Esto puede hacerse introduciendo un componente de fachada ^{[ 6 ]} entre el contrato de servicio y la lógica del servicio. Sin embargo, esto solo es posible si el contrato de servicio está físicamente desacoplado de su implementación en primer lugar, lo que podría lograrse mediante la aplicación del patrón de diseño Contrato Desacoplado ^{[ 7 ]} . Esto podría reforzarse aún más mediante la aplicación del patrón de diseño Centralización de Contratos ^{[ 8 ]} que aboga por establecer el contrato del servicio como el único punto de entrada oficial al servicio.

Por otro lado, para aislar la lógica del servicio de los efectos negativos derivados de los cambios en la implementación del servicio, se podría volver a aplicar el patrón de diseño Fachada de Servicio para introducir otro componente de fachada entre la implementación del servicio y la lógica del servicio. La aplicación del principio de Abstracción de Servicio puede contribuir aún más a reducir las posibilidades de cualquier efecto perjudicial causado por la aplicación de este patrón de diseño. ^{[ 9 ]}

La aplicación del patrón de diseño de refactorización de servicios requiere pruebas exhaustivas para garantizar que un servicio fiable y probado, aunque ineficiente, mantenga el mismo nivel de estabilidad y fiabilidad. Esto podría incrementar los costes del proyecto y requeriría procedimientos adicionales de control de calidad y una gobernanza estricta.

Por otro lado, su aplicación podría implicar un cambio en los niveles de abstracción actuales del servicio, lo que a su vez requeriría la reaplicación del principio de diseño de Abstracción de Servicio para garantizar que el servicio mantenga el nivel de abstracción adecuado. En algunas situaciones, podría ser imposible limitar el efecto de los cambios en la lógica o la implementación del servicio, y, por consiguiente, sería necesario actualizar el contrato de servicio. En este caso, se podría aplicar el patrón de diseño Contratos Concurrentes ^{[ 10 ]} , permitiendo que el servicio continúe prestando soporte a los consumidores que dependen del contrato anterior, al tiempo que ofrece un contrato actualizado que se ajusta a la nueva lógica o implementación del servicio.

• Erl et al., (2009). Patrones de diseño SOA . Prentice Hall. ISBN 0-13-613516-1.
• Mauro et al. Integración de dispositivos orientada a servicios: un análisis de patrones de diseño SOA. [En línea], págs.  1-10, 43.ª Conferencia Internacional de Hawái sobre Ciencias de Sistemas, 2010. Fecha de acceso: 5 de abril de 2010.

• Conceptos de SOA
• Glosario de términos de SOA
• patrones SOA