El Protocolo Canónico es un patrón de diseño aplicado dentro del paradigma de diseño orientado a servicios , que intenta hacer que los servicios , dentro de un inventario de servicios, [1] sean interoperables entre sí mediante la estandarización de los protocolos de comunicación utilizados por los servicios. Esto elimina la necesidad de puentear los protocolos de comunicación cuando los servicios utilizan diferentes protocolos de comunicación. [2]
Los servicios desarrollados por diferentes equipos de proyecto pueden basarse en diferentes mecanismos de comunicación. Como resultado, un inventario de servicios puede terminar teniendo diferentes conjuntos de servicios, cada uno de los cuales se ajusta a un conjunto diferente de protocolos. Cuando se trata de reutilizar servicios que tienen diferentes protocolos de comunicación, se requiere algún tipo de mecanismo de puente de comunicación. Por ejemplo, los servicios desarrollados utilizando el protocolo de mensajería JMS son incompatibles con los servicios que utilizan .NET Remoting , por lo que para hacer uso de estos dos tipos de servicios, es necesario implementar alguna tecnología de middleware que supere la disparidad del protocolo de comunicación. Además de incurrir en costos adicionales, el uso de dicha tecnología de puente agrega latencia y sobrecarga de comunicación. Esto hace que el servicio sea menos reutilizable y recomponible [3] y va en contra de las pautas del principio de diseño de Composabilidad de Servicios .
Para diseñar un inventario de servicios en el que todos los servicios sean interoperables entre sí y puedan ser compuestos en diferentes soluciones, la aplicación del patrón de Protocolo Canónico dicta la estandarización de los protocolos de comunicación utilizados por los servicios. Cuando todos los servicios utilizan el mismo protocolo de comunicación, se elimina la necesidad de una tecnología de puente y la comunicación entre servicios se simplifica. [4]
La aplicación de este patrón de diseño requiere la elección de una arquitectura tecnológica que proporcione un marco de comunicación común para que todos los servicios de un inventario puedan comunicarse entre sí utilizando el mismo protocolo de comunicación. Esto depende de cómo se vayan a utilizar los servicios dentro de un inventario de servicios. Si los servicios sólo van a ser parte de composiciones de servicios que siempre utilizan un protocolo de comunicación particular (por razones de eficiencia y seguridad), entonces todos los servicios dentro de ese inventario de servicios pueden construirse sobre dicho protocolo de comunicación, incluso si no es el protocolo más utilizado.
El patrón de protocolo canónico de Thomas Erl responde a la pregunta: "¿Cómo se pueden diseñar los servicios para evitar la interconexión de protocolos?" [5] El problema es que los servicios que admiten diferentes tecnologías de comunicación comprometen la interoperabilidad, limitan la cantidad de consumidores potenciales e introducen la necesidad de medidas de interconexión de protocolos no deseadas. La solución es que la arquitectura establezca una única tecnología de comunicaciones como el único o principal medio mediante el cual los servicios pueden interactuar. Por lo tanto, los protocolos de comunicación (incluidas las versiones de protocolo) utilizados dentro de un límite de inventario de servicios están estandarizados para todos los servicios (véase el diagrama).
Uno de los mecanismos de comunicación más maduros y utilizados es el que proporciona el marco de servicios web. Además de elegir un marco de comunicación, también es necesario estandarizar los protocolos de mensajes reales. Por ejemplo, si los servicios web se crean utilizando SOAP sobre HTTP o simplemente utilizando servicios RESTful . De manera similar, al estandarizar los servicios web basados en SOAP, también es necesario acordar la versión específica del protocolo SOAP, es decir, SOAP v 1.1 o SOAP v 1.2.
Para estandarizar un protocolo de comunicación, es necesario comparar las características del protocolo con los requisitos de interacción del servicio, como la seguridad, la eficiencia y el soporte de transacciones. En el caso de los servicios web, por ejemplo, si una composición de servicio requiere soporte explícito de transacciones, SOAP sobre HTTP sería una mejor opción que usar servicios RESTful.
En algunos casos, dependiendo de la tecnología utilizada para crear el servicio, puede ser posible admitir dos conjuntos diferentes de protocolos para que el servicio sea accesible a diferentes tipos de consumidores de servicios (patrón de diseño de protocolos duales [6] ). Por ejemplo, utilizando WCF , el mismo servicio se puede configurar para utilizar los protocolos HTTP y TCP/IP al mismo tiempo.
Al elegir un marco de comunicación, se deben tener en cuenta la madurez, la escalabilidad y los costos de licencia, ya que crear servicios utilizando un protocolo que quedará obsoleto en el futuro cercano afectará la reutilización de dichos servicios y requerirá mucho tiempo y esfuerzo para rediseñar el servicio.