Protocolo de mensajería de aplicaciones web

WAMP es un subprotocolo WebSocket registrado en la IANA,[1]​ especificado[2]​ para ofrecer RPC enrutado y PubSub. Su objetivo de diseño[3]​ 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),[4]​ 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.[5]

Características editar

Estructura editar

WAMP requiere[6]​ 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,[7]​ Socket Unix o encuestas de larga duración HTTP

La serialización de mensajes asume[8]​ 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.[9]

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 editar

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.[10]​ 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 editar

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 editar

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..[11]

Implementaciones editar

Clientes editar

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 editar

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.[12]

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 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.[13]​ 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 editar

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.[14]​ 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.[15]​ Esto está mitigado por la existencia de polyfills[16]​ 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[17]​ 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).[18]

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 editar

WAMP se encuentra actualmente en la versión 2,[19]​ que introdujo el RPC enrutado. La versión 1 está obsoleta.[20]​ 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 editar

El sitio web del WAMP reivindica[21]​ 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[22]        

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 editar

  1. IANA protocols listing page
  2. WAMP basic profile specifications
  3. «Using WAMP you can build distributed systems out of application components which are loosely coupled and communicate in (soft) real-time.». Archivado desde el original el 5 de octubre de 2015. Consultado el 1 de octubre de 2018. 
  4. A few words about WAMP
  5. «In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developing IoT solutions». 
  6. Crossbar.io router transport
  7. «WAMP can run over Raw transports instead of WebSocket. Each message is prefixed with a uint32 (big endian) that provides the (serialized) length of the following WAMP message.». 
  8. WAMP serialization
  9. «Wampy default serializer is JSON, but it also supports msgpack as serializer, but you need to include msgpack.js as dependency». 
  10. «The Long-Poll Transport is able to transmit a WAMP session over plain old HTTP 1.0/1.1. This is realized by the Client issuing HTTP/POSTs requests, one for sending, and one for receiving». 
  11. «Crossbar node architecture». Archivado desde el original el 12 de enero de 2015. Consultado el 1 de octubre de 2018. 
  12. «Brokers and Dealers are responsible for generic call and event routing and do not run application code.». 
  13. «Crossbar.io is the name of the most full featured router». 
  14. WAMP and AngularJS
  15. «Can is use websockets ?». 
  16. Web socket polyfills
  17. «Moreover, we compared WAMP with other registered WebSocket subprotocols (MBWS, SOAP and STOMP) in terms of the related features; and with other potential protocols (CoAP and MQTT), in terms of the related practical deployments.». Archivado desde el original el 13 de mayo de 2016. Consultado el 1 de octubre de 2018. 
  18. Tessel alarm app with Crossbar.io
  19. «WAMP 2 specification menu». Archivado desde el original el 2 de octubre de 2015. Consultado el 1 de octubre de 2018. 
  20. «WAMP 1 specification overview». Archivado desde el original el 4 de octubre de 2015. Consultado el 1 de octubre de 2018. 
  21. «WAMP compared». Archivado desde el original el 4 de octubre de 2015. Consultado el 1 de octubre de 2018. 
  22. specs