Legacy Wrapper

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 tecnologia uyilizada).
Esto impone las formas correspondientes de aplicación y el acoplamiento de tecnología a todos los consumidores de servicios.

 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 estandar. 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.

 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.
 Principios
\* Pérdida de acoplamiento
 Ventajas
 \*Proporciona la libertad de evolucionar o reemplazar el sistema existente con un mínimo impacto en los consumidores de servicios
\* Contrato de servicios estandarizado
\* Pérdida de acoplamiento
\* Abstracción de servicios