LEGACY WRAPPER

Problema

Los sistemas heredados a menudo deben ser encapsulados por los servicios establecidos por la
API de componentes patentados o productos de adaptadores de servicios Web. La interfaz
técnica resultante se fija con frecuencia y no personalizable. Debido a que el contrato es
predeterminado por el proveedor del producto o limitada por las API del legado de componentes
que no cumple con las normas de diseño del contrato aplicados a un inventario de servicios dado.
Por otra parte, la naturaleza de la API y de servicios Web del adaptador suele ser tal que
contienen incrustados detalles específica de la aplicación (dependiendo de la tecnología
utilizada).

Esto impone las formas correspondientes de aplicación y el acoplamiento de tecnología a todos

los consumidores de servicios.

SOLUCIÓN

Aunque una API del sistema legado o un adaptador de servicio Web expondrán un punto de
entrada oficial, en la lógica del sistema legado, a menudo es aconsejable para clasificar un punto
final, como un miembro oficial de un inventario de servicios. En cambio, puede ser más seguro
para ver APIs heredadas y los adaptadores de servicios Web como extensiones del entorno
heredado proporcionando sólo otra interfaz propietaria que está disponible para la encapsulación
de servicio.
Esta perspectiva permite la creación de un servicio de envoltorio legado estandarizada que
expresa la función de herencia de una manera estándar. El resultado es un diseño que permite
la extracción completa de características heredadas de propiedad, que proporciona la libertad de
evolucionar o reemplazar el sistema existente con un mínimo impacto en los consumidores de
servicios existentes.
APLICACIÓN

La aplicación de este patrón se asocia típicamente con la introducción de un nuevo contrato de

servicio. Sin embargo, cuando se envuelven sólo las partes de un recurso legado que caen dentro
de un límite de servicio predefinido, este patrón puede resultar en sólo la adición de una nueva
capacidad de un contrato de servicio existente.
De cualquier manera, el servicio de envoltura (o capacidad) contendrá típicamente lógica que
realiza la transformación de entre su contrato estandarizado y la interfaz de legado nativo. A
menudo, esta forma de transformación se lleva a cabo mediante la eliminación y encapsular la
información técnica, de la siguiente manera:

• La eliminación de Información Técnica - A menudo, los datos de entrada y salida contienen

altamente características propias, tales como ID de mensaje de correlación, los códigos de error,
la información de auditoría, etc. Muchos de estos detalles pueden ser retirados del contrato
envoltorio través de la transformación interna adicional. Por ejemplo, los códigos de error pueden
ser traducidos a errores de SOAP, y los ID de mensaje de correlación se pueden generar dentro
de la implementación del servicio de envoltura. En este último caso, los consumidores pueden
comunicarse con el servicio de envoltura sobre un protocolo de comunicación de bloqueo como
HTTP y por lo tanto no se necesita saber acerca de los identificadores de correlación.

• Encapsular Información Técnica - Cuando los consumidores de servicios todavía tienen que
transmitir datos heredados específicos (como la información relacionada con las auditorías) el
mensaje intercambiado por el contrato envoltorio puede ser diseñado para dividir los datos de
negocio estandarizados de datos heredados de propiedad en el cuerpo y las cabeceras de las
secciones, respectivamente. En este caso, tanto el servicio de envoltura y su consumo tendrán
que llevar a cabo un procesamiento adicional de montar y extraer los datos de las secciones de
encabezado y el cuerpo de los mensajes entrantes y salientes.

El primer enfoque general resulta en un servicio de utilidad, mientras que la última opción tenderá
que añadir la lógica envoltorio como una extensión de un servicio de negocio. Puede ser
beneficioso para establecer un único servicio de envoltura de utilidad para un sistema legado, de
modo que toda la lógica de transformación requerida este centralizada dentro de la lógica
subyacente de ese servicio. Si las capacidades de múltiples servicios para acceder a las API
nativas o interfaces adaptadores de servicios web, necesitará la lógica necesaria de
transformación para ser distribuidos (descentralizado). Si un punto en el tiempo llega donde el
sistema legado se sustituye con la tecnología más reciente, que tendrá un impacto múltiples
servicios.