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
Estructura
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
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
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..[11]
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 |
| Javascript (navegador y Node.js) | |
| 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.[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:Plantilla:According to whom
| 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
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
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
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-yes" | | |||||
| 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
- IANA protocols listing page
- WAMP basic profile specifications
- . Archivado desde el original el 5 de octubre de 2015. Consultado el 1 de octubre de 2018.
- A few words about WAMP
- «In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developing IoT solutions».
- Crossbar.io router transport
- «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.».
- WAMP serialization
- «Wampy default serializer is JSON, but it also supports msgpack as serializer, but you need to include msgpack.js as dependency».
- «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».
- . Archivado desde el original el 12 de enero de 2015. Consultado el 1 de octubre de 2018.
- «Brokers and Dealers are responsible for generic call and event routing and do not run application code.».
- «Crossbar.io is the name of the most full featured router».
- WAMP and AngularJS
- «Can is use websockets ?».
- Web socket polyfills
- . Archivado desde el original el 13 de mayo de 2016. Consultado el 1 de octubre de 2018.
- Tessel alarm app with Crossbar.io
- . Archivado desde el original el 2 de octubre de 2015. Consultado el 1 de octubre de 2018.
- . Archivado desde el original el 4 de octubre de 2015. Consultado el 1 de octubre de 2018.
- . Archivado desde el original el 4 de octubre de 2015. Consultado el 1 de octubre de 2018.
- specs