Protocolo de mensajería de aplicaciones web

WAMP requiere ^{[ 6 ]} un canal de mensajes dúplex completo , ordenado y confiable como capa de transporte y, por defecto, utiliza Websocket. Sin embargo, las implementaciones pueden usar otros transportes que coincidan con estas características y comunicarse con WAMP a través de, por ejemplo, sockets sin procesar, ^{[ 7 ]} sockets Unix o sondeo largo HTTP .

La serialización de mensajes asume que ^{[ 8 ]} están disponibles los tipos de enteros, cadenas y secuencias ordenadas, y utiliza JSON por defecto como el formato más común que los ofrece. Las implementaciones suelen proporcionar MessagePack como una alternativa más rápida a JSON a costa de una dependencia adicional. ^{[ 9 ]}

WAMP está diseñado en torno a comunicaciones cliente-cliente con un software central, el enrutador, que distribuye mensajes entre ellos. El flujo de trabajo típico de intercambio de datos es: ^{[ 10 ]}

• Los clientes se conectan al enrutador mediante un protocolo de transporte, estableciendo así una sesión.
• El enrutador identifica a los clientes y les otorga permisos para la sesión actual.
• Los clientes envían mensajes al enrutador, que los distribuye a los destinos adecuados utilizando las URI adjuntas.

Los clientes envían estos mensajes utilizando las dos primitivas de alto nivel que son RPC y PUB/SUB, realizando cuatro interacciones principales:

• registro : un cliente expone un procedimiento para ser llamado de forma remota.
• llamada : un cliente le pide al enrutador que obtenga el resultado de un procedimiento expuesto de otro cliente.
• suscribirse : un cliente notifica su interés en un tema.
• publicar : un cliente publica información sobre este tema.

Esto puede tener variaciones sutiles dependiendo del transporte subyacente. ^{[ 11 ]} Sin embargo, los detalles de implementación están ocultos para el usuario final que solo programa con las dos primitivas de alto nivel que son RPC y PubSub.

Dado que WAMP utiliza WebSocket, las conexiones se pueden cifrar mediante TLS . Incluso cuando no se garantiza la confidencialidad total, se implementan varios mecanismos para aislar los componentes y evitar ataques de intermediario . Las implementaciones predeterminadas aseguran que intentar registrar un procedimiento ya registrado resultará en un error.

Los enrutadores pueden definir dominios administrativos, y los clientes deben especificar a qué dominio desean unirse al conectarse. Una vez unidos, el dominio actuará como un espacio de nombres , impidiendo que los clientes conectados a él utilicen identificadores definidos en otro para RPC y PubSub. Los dominios también tienen permisos asociados y pueden limitar a los clientes a un subconjunto de las acciones REGISTER/CALL/PubSub disponibles.

A algunos dominios solo pueden acceder clientes autenticados, utilizando diversos métodos de autenticación, como certificados TLS , cookies o un simple ticket.

A diferencia de las llamadas RPC tradicionales, que se dirigen directamente desde el emisor a la entidad que ofrece el procedimiento (normalmente un servidor backend) y son estrictamente unidireccionales (de cliente a servidor), las llamadas RPC en WAMP son enrutadas por un middleware y funcionan bidireccionalmente.

El registro de las llamadas a procedimiento remoto (RPC) se realiza en el enrutador WAMP, y las llamadas a los procedimientos se emiten de forma similar a este enrutador. Esto significa, en primer lugar, que un cliente puede emitir todas las RPC a través de una única conexión con el enrutador WAMP, sin necesidad de saber qué cliente está ofreciendo el procedimiento, dónde se encuentra ni cómo acceder a él. De hecho, esta situación puede variar entre llamadas, lo que abre la posibilidad de implementar funciones avanzadas como el balanceo de carga o la conmutación por error para las llamadas a procedimientos.

Además, esto significa que todos los clientes de WAMP son iguales, ya que pueden ofrecer procedimientos para realizar llamadas. Esto evita la distinción tradicional entre clientes y servidores backend, y permite arquitecturas donde los clientes del navegador llaman a procedimientos en otros clientes del navegador, con una API que se asemeja a la comunicación entre pares.

Sin embargo, incluso con arquitecturas de múltiples niveles, el enrutador sigue siendo un único punto de fallo. Por esta razón, algunas hojas de ruta de implementación de enrutadores incluyen funciones de agrupación. ^{[ 12 ]}

Dado que los principales objetivos de WAMP son las aplicaciones web y el Internet de las cosas, las primeras implementaciones de clientes están en lenguajes bien establecidos en estas industrias (solo se incluyen clientes WAMP v2):

Los requisitos mínimos para crear un cliente WAMP son la capacidad de usar sockets y serializar a JSON. Por lo tanto, muchos lenguajes modernos ya cumplen con estos requisitos gracias a su biblioteca estándar. Las funciones adicionales que generarían dependencias, como el cifrado TLS o la serialización MessagePack, son opcionales.

Sin embargo, la naturaleza persistente de las conexiones WebSocket requiere el uso de bibliotecas no bloqueantes y API asíncronas . En lenguajes con un mecanismo oficial, como JavaScript, Erlang o Go, esto no representa un problema. Pero para lenguajes con varias soluciones competitivas para la programación asíncrona, como Python o PHP, obliga al desarrollador del cliente a comprometerse con una parte específica del ecosistema.

Por la misma razón, la integración de proyectos heredados también puede requerir trabajo. Por ejemplo, la mayoría de los frameworks web de Python más populares utilizan WSGI , una API síncrona, y ejecutar un cliente WAMP dentro de un proceso WSGI requiere adaptadores manuales como crochet.

Aunque técnicamente los enrutadores pueden integrarse directamente en el código de la aplicación y algunas bibliotecas cliente también proporcionan un enrutador, esta arquitectura no es recomendable según la especificación. ^{[ 13 ]}

Dado que el enrutador es una pieza móvil, lo mejor es utilizarlo como una caja negra intercambiable, al igual que se consideraría Apache o Nginx para HTTP :

Tavendo , la empresa que originó el protocolo, también es la autora de Crossbar.io , que se promociona como la implementación de enrutador de facto. ^{[ 14 ]} Dado que promueven arquitecturas basadas en microservicios, Crossbar.io incorpora un administrador de servicios para alojar y monitorear componentes de aplicaciones WAMP, un servidor web de archivos estáticos y un contenedor WSGI. Al estar escrito con la biblioteca Twisted , es una de las implementaciones que se pueden configurar en producción sin un proxy, con el objetivo de reemplazar pilas como Nginx asociadas con Supervisor y Gunicorn .