Dual Protocols

Dos niveles de servicios se prestan en el mismo inventario:
• un nivel primario basado en el protocolo preferido
• un nivel secundario basado en un protocolo alternativo
 Un ejemplo popular de una combinación de los protocolos de transporte, además de mensajería que se elige para la normalización, a parte de una plataforma tecnológica que puede no ser adecuado para todos los tipos de servicios es SOAP a través de HTTP. A pesar de que los servicios construidos como servicios Web pueden establecer un marco de comunicaciones estandarizado basado en estas tecnologías, esta elección puede plantear algunas cuestiones.
Por ejemplo:
• SOAP introduce sobrecarga de procesamiento del mensaje que puede ser razonable en las capacidades del servicio que necesitan intercambiar cantidades granulares de datos o que necesitan ser invocados varias veces por el mismo consumidor durante el mismo proceso de negocio.
• El procesamiento de mensajería adicional puede ser considerado inapropiado para los servicios que físicamente coexisten en el mismo servidor y que no requieren control remoto de la comunicación.
• El servicio puede requerir una característica especial que no puede ser acomodada por la plataforma de tecnología de servicios Web, debido a la ausencia de soporte del proveedor o de un vacío o deficiencia en un estándar de servicios web compatible.
Por lo tanto, Dual Protocols ofrece una solución de compromiso que se basa esencialmente en la estandarización de los dos Canonical Protocols . Por ejemplo, al aplicar este modelo a un inventario de servicios basados en servicios web, se clasifican normalmente como el nivel de servicio primario debido a que el uso de los servicios web es compatible con varios otros beneficios de diseño y los patrones que aprovechan sus estándares de la industria.
Sin embargo, para los casos en que los servicios Web no representan una opción de la aplicación adecuada de los servicios, un protocolo secundario se elige. Por lo general, este protocolo alternativo se basa en una plataforma particular (Java o .NET).
En este caso, los componentes están diseñados como servicios autónomos sujetos a todo el conjunto de principios de diseño de servicios de orientación (incluyendo la estandarización de la interfaz de componente mediante el principio Estandarizado contrato de servicio). Tanto los niveles de servicio primario y secundario representan puntos finales oficiales como parte de una capa de punto final de servicio.
Existen riesgos significativos al aplicar este patrón se recomiendan las siguientes pautas para disminuir los riesgos:
• Contract Centralization siempre debe ser respetado, lo que significa que se debe tener acceso al servicio basado en el protocolo primario a través del protocolo primario cuando se invoca por los servicios secundarios. En el caso de los servicios Web, esto requiere que los servicios basados en componentes no accedan directamente a los componentes subyacentes o recursos de los servicios basados en servicios web.
• Considere algunos o todos los servicios en el nivel secundario como candidatos de transición. Si este patrón fue elegido debido a la falta de madurez en el protocolo primario, servicios secundarios pueden ser destinados a una mejora a nivel primario una vez que la tecnología ha evolucionado lo suficiente.
• Durante un período transitorio, utilice Concurrent Contracts para permitir que un servicio sea accesible a través de cualquiera de los protocolos. De esta manera, se puede comenzar a interoperar usando el protocolo primario sin dejar de apoyar a los consumidores que se basan en el protocolo secundario.
• Aplicar Redundant Implementation siempre que sea posible en apoyo de los servicios secundarios. Esto es especialmente relevante cuando los servicios secundarios basados en componentes están compuestos principalmente por la lógica del servicio básico basado en servicios web para evitar la comunicación a distancia.

\* Pérdida de acoplamiento
\* Abstracción de servicios
\* Autonomía de servicios
 Ventajas
 \*Contrato estandarizado de servicios
\* Pérdida de acoplamiento
\* Abstracción de servicios
\* Autonimía de servicios
\* Composición de servicios
\* Interoperabilidad
\* Puede generar mayor esfuerzo de gobierno y gastos.
\* Cuando se aplica mal, puede haber una dependencia malsana de Protocol Bridging.