Common Compound Design Patterns

Compound vs composite Un composite es algo que generalmente se compone de partes interconectadas. Un compound simplemente se puede considerar el resultado de combinar un conjunto específico de las cosas

Patrones compuestos y relación de patrones Los patrones que componen de un conjunto compuesto de tener una relación con el patrón compuesto. Sólo estamos interesados en los resultados de su aplicación combinada.

Joint Application vs. Coexistent Application Joint Application : Un patrón compuesto es un conjunto de patrones que son aplicadas en forma conjunta a una aplicación. Los patrones compuestos con patrones que se aplican juntos. – Official Endpoint – Federated Endpoint Layer – Three-Layer Inventory

Una aplicación de coexistencia de patrones establece un entorno de "solución" que puede ser realizado por una combinación de herramientas y tecnologías. – Orchestration – Enterprise Service Bus – Service Broker – Canonical Schema Bus

Patrones compuestos y granularidad de patrones Se debe tener en cuanta que cualquier patrón puede llegar a ser un patrón compuesto, pero que también un patrón compuesto puede ser descompuesto en un conjunto de patrones.

Orchestation Una plataforma de orquestación se dedica a un mantenimiento efectivo y ejecución de un proceso lógico de negocio padre. Está compuesto por los siguientes patrones: – Abstracción de proceso(182): responsable de separar la lógica no agnóstica de la lógica agnóstica, la cual forma la base de la composición lógica padre que reside en la plataforma y el motor. – Centralización de proceso(193): limita la distribución física de la lógica del proceso de abstracción en una o grupo de localizaciones.

Orchestation

– Estado del repositorio(242): permite a los entornos de orquestación soportar actividades de servicio de larga ejecución proveyendo un estado nativo de administración de repositorio que puede ser aprovechado como un mecanismo de aplazamiento de estado. – Servicio de Composición de Transacciones: apoya procesos de larga duración, al permitir la lógica de composición padre sea suplementada con los subprocesos de compensación que se ocupan de las condiciones de excepción.

Orchestation

Enterprise Service Bus Un ESB representa un entorno diseñado para fomentar la interconectividad sofisticada entre servicios, estableciendo una capa intermedia. Esta compuesta por los siguientes patrones núcleo: – Service Broker(707): consiste e una serie de patrones céntricos de integración usados para la traducción entre modelos de datos, formatos de datos y protocolos de comunicación incompatibles.

Enterprise Service Bus

– Cola Asíncrona(582), establece un mecanismo de queuing que permite intercambio asíncrono de mensajes e incrementa la confiabilidad de las transmisiones de mensaje cuando la disponibilidad del servicio es incierta. – Ruteo intermedio, provee opciones de ruteoo basadas en agentes inteligentes para facilitar varias condiciones de ejecución.

Enterprise Service Bus

Broker: – Funciones de conversión en tiempo de ejecución que permiten la integración entre diferentes sistemas. Service broker

Compuesto: – Transformación de Modelo de datos – Conversión de formato de datos – Protocolo puente Flexibilidad para una aplicación de arquitectura orientada a servicios. Realiza más de una función de transformación, al mismo tiempo.

Forma partes de plataformas como Enterprise Service Bus.

Enterprise Service Bus: – Proporciona una gama de funciones de mensajería centrado – Ayudan a establecer la conectividad entre los distintos servicios y recursos.

Esquema de Bus Canonico

– Contrato disociado – Contrato centralización – Esquema Canónico – EBS Datos de entrada, en la lógica, datos, y funciones que ofrece el entorno de bus de servicios Contratos de servicios estandarizados de forma independiente

Canonical esquema de bus restringe la entrada a los puntos a los contratos de servicios centralizados y canónicos y limita el uso de Service Broker. Relaciona los patrones a una intraservice de transformación de requerimientos. Permite estandarizar los contratos para cualquier servicio o programa que necesita para consumirlos. El objetivo final es estandarizar los contrato sobre un inventario de servicios.

Este modelo requiere que el acceso a la ESB sea encapsulando funciones y los recursos se limiten a los contratos de servicios estandarizados.

Official EndPoint Centralización Lógica Pregunta a los diseñadores para construir programas consumidores que solo invoquen servicios diseñados con tipos específicos de información Contrato de Centralización Pregunta a los diseñadores para construir programas consumidores que accedan a servicios solo vía contrato publico, no indica que servicios deberían ser accesados para propósitos específicos

Inventario de Tres Capas Inventario de tres capas existe por la combinación de tres patrones (Utility, Entity Process Abstraction). Y son recomendadas por las siguientes razones: Cada abstracción mejora la representación lógica. La mayoría de procesos de negocio pueden ser representados por estas tres capas.

Cada capa no se superpone, por el contrario se complementan. Los modelos de servicios son genéricos, por lo cual son personalizables.