Protocolo de mensajería de aplicaciones web

WAMP es un subprotocolo WebSocket registrado en la IANA,​ especificado​ para ofrecer RPC enrutado y PubSub. Su objetivo de diseño​ es proporcionar un estándar abierto para el intercambio de mensajes en tiempo real entre los componentes de la aplicación y facilitar la creación de arquitecturas ligeramente acopladas basadas en microservices. Por ello, es un bus de servicio empresarial (ESB),​ adecuado para el desarrollo de aplicaciones Web con capacidad de respuesta o para la coordinación de múltiples dispositivos conectados en el internet de las cosas.​

Características

Estructura

WAMP requiere​ un canal de mensajes dúplex completo, ordenado y fiable como capa de transporte y, por defecto utiliza Websocket. Sin embargo, las implementaciones pueden utilizar otros transportes que coincidan con estas características y comunicarse con WAMP a través de, por ejemplo, raw sockets,​ Socket Unix o encuestas de larga duración HTTP

La serialización de mensajes asume​ que los números enteros, cadenas y tipos de secuencia ordenados están disponibles, y por defecto es JSON, el formato más común que los ofrece. Las implementaciones a menudo proporcionan MessagePack como una alternativa más rápida a JSON, pero a costa de una dependencia adicional.​

Para identificar procedimientos remotos y temas PubSub sin conflictos, el WAMP también necesita un espacio de identificación que permita la asignación global y la resolución. Debido a que el protocolo es nativo de la Web - WebSocket es el medio de transporte preferido se utilizan URIs.

Flujo de trabajo

WAMP Es architectured alrededor cliente@–comunicaciones de cliente, con un software central, el router, dispatching mensajes entre ellos. El intercambio de dato típico workflow es:</ref>

• Los clientes se conectan al router usando un transporte, estableciendo una sesión.
• El enrutador identifica a los clientes y les da permisos para la sesión actual.
• Los clientes envían mensajes al enrutador que los envía a los objetivos adecuados utilizando las URIs adjuntas.

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

• Registro: un cliente expone un procedimiento para ser llamado remotamente.
• Llamada: un cliente le pide al enrutador que obtenga el resultado de un procedimiento expuesto de otro cliente. subscribe: un cliente notifica su interés en un tema.
• Suscribirse: un cliente notifica su interés en un tema.
• Publica: un cliente publica información sobre este tema.

Esto puede tener variaciones sutiles dependiendo del transporte subyacente.​ 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.

Seguridad

Como WAMP utiliza Websocket, las conexiones se pueden envolver en TLS para su encriptación. Incluso cuando no se establece la confidencialidad total, se implementan varios mecanismos para aislar los componentes y evitar los ataques del tipo "hombre en el medio". Las implementaciones predeterminadas garantizan que al intentar registrar un procedimiento ya registrado se producirá un error.

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

Algunos dominios solamente pueden unirse mediante clientes autenticados, utilizando varios métodos de autenticación como el uso de certificados TLS, cookies o un simple ticket.

ERTs enrutados

A diferencia de los RPCs tradicionales, que se dirigen directamente de la persona que llama a la entidad que ofrece el procedimiento (normalmente un backend del servidor) y son estrictamente unidireccionales (cliente a servidor), los RPCs en WAMP son enrutados por un middleware y funcionan de forma bidireccional.

El registro de los RPCs se realiza con el router WAMP, y las llamadas a los procedimientos se realizan de forma similar al router WAMP. Esto significa, en primer lugar, que un cliente puede emitir todos los RPCs a través de una única conexión al router WAMP, y no necesita tener ningún conocimiento de qué cliente está ofreciendo actualmente el procedimiento, dónde reside ese cliente o cómo abordarlo. Esto puede cambiar de una llamada a otra, abriendo la posibilidad de funciones avanzadas como el equilibrio de carga o la conmutación por error para las llamadas de procedimiento.

Además, significa que todos los clientes de WAMP son iguales en cuanto a que pueden ofrecer procedimientos de llamada. Esto evita la distinción tradicional entre clientes y backends de servidor, y permite arquitecturas donde los clientes del navegador llaman a procedimientos en otros clientes del navegador, con una API que se siente como una comunicación de par a par.

Sin embargo, incluso con arquitecturas de varios niveles, el router sigue siendo un único punto de fallo. Por esta razón, algunas hojas de ruta de implementación de routers incluyen características de clustering..​

Implementaciones

Clientes

Como los principales objetivos del WAMP son las aplicaciones Web y la Internet de los objetos, las primeras implementaciones de clientes están en lenguajes bien establecidos en estas industrias (solamente se incluyen los clientes WAMP v2): [[ Python]][[ Python]]

Biblioteca de cliente	Lenguaje
AngularWAMP	Javascript para el Framwork AngularJS
AutobahnCpp	C++ 11
AutobahnJS	Javascript (navegador y Node.js)
AutobahnPython
wampy
Neto::WAMP	Perl
backbone.WAMP	Javascript para la biblioteca Backbone.js
CppWAMP	C++ 11
Erwa	Erlang
Jawampa	Java
Loowy	Lua
MDWamp	Objetive-C
Minion	PHP
rx.wamp	Javascript para la librería React
Thruway	PHP
WAMP POCO	C++
WampSharp	C#
Wampy.js	Javascript (solo navegador)
nexus	Go

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

Sin embargo, la naturaleza persistente de las conexiones WebSocket requiere el uso de bibliotecas que no bloquean y APIs asíncronas. En lenguajes con un mecanismo oficial como JavaScript, Erlang o Go, esto no es un problema. Pero para lenguajes con varias soluciones que compiten por la programación asíncrona, como Python o PHP, obliga al autor 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. Como ejemplo, los frameworks más populares de Web Python están usando WSGI, una API síncrona, y ejecutar un cliente WAMP dentro de un trabajador de WSGI necesita adaptadores manuales como crochet.

Routers

Aunque los enrutadores se pueden integrar técnicamente directamente en el código de la aplicación y algunas bibliotecas de clientes también proporcionan un enrutador, esta arquitectura no se ve favorecida por la especificación.​

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

Router	Lengua
Crossbar.io Archivado el 12 de enero de 2015 en Wayback Machine.	Python (CPython y PyPy)
Erwa	Erlang
Jawampa	Java
Thruway	PHP
wamp.rt	Javascript (Node.js solo)
WampSharp	C#
Wiola	Lua
Nightlife-Conejo	Javascript (Node.js solo)
nexus	Go

Tavendo, la empresa que originó el protocolo, es también el autor de Crossbar.io, que se promociona como la implementación de facto del router.​ Al promover arquitecturas basadas en micro-servicios, 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 librería 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 a Supervisor y Gunicorn.

Casos de uso

Al ser un subprotocolo WebSocket, WAMP se adapta de forma natural a cualquier lugar en el que se utilicen sockets web en bruto, como una forma de sincronizar clientes como los navegadores Web, enviarles notificaciones y permitir la colaboración en tiempo real entre usuarios.​ También tiene las mismas limitaciones, requiriendo soporte al cliente, que falta para las versiones de Internet Explorer de más de 10 años de antigüedad.​ Esto está mitigado por la existencia de polyfills​ que utilizan tecnologías más portátiles como Flash o el uso de HTTP Longpoll como respaldo. En ese sentido, el WAMP es un competidor del DDP de Meteor.

WAMP también se dirige a la IOT, donde se utiliza de la misma manera que el MQTT​ como un medio ligero y eficiente para orquestar grupos de objetos conectados. Las implementaciones en varios lenguajes lo hacen adecuado para controlar y monitorizar pequeños dispositivos como el Raspberry Pi (en Python) o el Tessel (en JavaScript).​

Y por último, pero no por ello menos importante, el WAMP puede actuar como un bus de servicios empresariales, sirviendo de enlace entre microservicios como lo haría con Corba, ZeroMQ, Apache Thrift, SOAP o AMQP.

Evolución

WAMP se encuentra actualmente en la versión 2,​ que introdujo el RPC enrutado. La versión 1 está obsoleta.​ A partir de ahora, todos los routers son compatibles con la versión 2. Algunos clientes siguen sin ser reportados: Wamp.io, AutobahnAndroid y cljWAMP.

La versión 2 de la especificación se divide en dos partes: el perfil básico, incluyendo el router RPC y Pub/Sub, y el perfil avanzado, con niveles de confianza, correspondencia de patrones URI y listado de clientes. El perfil básico se considera estable y es lo que las bibliotecas actuales están implementando mientras que el perfil avanzado aún está en evolución.

Comparación

El sitio web del WAMP reivindica​ los siguientes puntos de venta para la tecnología:

• Nativo de PubSub: soporta Publish & Subscribe out of the box (no requiere extensión).
• RPC: soporta Remote Procedure Calls out of the box (no requiere extensión).
• Enruta RPC: soporta llamadas remotas de procedimiento enrutado (no solamente punto a punto).
• Web nativa: se ejecuta de forma nativa en la Web (sin túneles ni puentes).
• Lenguaje cruzado: trabaja en y entre diferentes lenguajes de programación y tiempos de ejecución.
• Estándar abierto: Es una especificación abierta y oficial implementada por diferentes proveedores.

Por otro lado, el WAMP no intenta alcanzar algunos de los objetivos de otros protocolos:

• Objeto completo pasando como CORBA.
• Sincronización de datos como DDP.
• Comunicación entre pares como ZeroMQ.
• Transmisión de secuencias multimedia como WebRTC.
• Transferencia de archivos grandes como HTTP.

Sin embargo, numerosos protocolos comparten algunas características con el WAMP:

Tecnología	PubSub	RPC	Routed RPC	Indígena de web	Cross Lengua	Estándar abierto
WAMP
AJAX	style="background: #D2FFD2; color: black; vertical-align: middle; text-align: center; " class="table-yes2" |
AMQP
Apache Thrift
Capn'n'Proto
Cometa
OMG DDS
D-Autobús
CORBA
DCOM
Java JMS
Java RMI
JSON-RPC
MQTT
RESTO
JABÓN
Socket.io
SockJS
STOMP
XML-RPC
XMPP
ZeroMQ
DDP​

Aunque, es importante notar que mientras DDP hace Pub/Sub bajo el capó para sincronizar los conjuntos de datos, no expone las primitivas de PubSub. También es una especificación abierta con varias implementaciones, pero no registrada como estándar.

Referencias

• Datos: Q19862448