Web Application Messaging Protocol

WAMP är ett WebSocket- underprotokoll registrerat hos IANA , specificerat för att erbjuda routad RPC och PubSub . Dess designmål är att tillhandahålla en öppen standard för mjukt meddelandeutbyte i realtid mellan applikationskomponenter och underlätta skapandet av löst kopplade arkitekturer baserade på mikrotjänster . På grund av detta är det en lämplig Enterprise Service Bus (ESB), lämplig för att utveckla responsiva [[Web]]-applikationer eller för att koordinera flera anslutna enheter i IoT .

Egenskaper

Strukturera

WAMP kräver en pålitlig, ordnad, full-duplex meddelandekanal som transportlager och använder som standard Websocket. Implementeringar kan dock använda andra transporter som matchar dessa egenskaper och kommunicera med WAMP via t.ex. råa sockets, Unix-sockets eller HTTP long poll .

Meddelandeserialisering förutsätter att heltal, strängar och sorterade sekvenstyper är tillgängliga, och standardinställningen är JSON som det vanligaste formatet som erbjuder dessa. Implementeringar ger ofta MessagePack som ett snabbare alternativ till JSON, men till priset av ett ytterligare beroende.

För att identifiera fjärrprocedurer och PubSub-ämnen utan konflikter behöver WAMP också ett ID-utrymme som tillåter global tilldelning och lösning. Eftersom protokollet är webbinbyggt - WebSocket är den föredragna transporten - används URI :er.

Arbetsflöde

WAMP är uppbyggd kring klient-klientkommunikation, med en central programvara, routern, som skickar meddelanden mellan dem. Det typiska arbetsflödet för datautbyte är:

  • Klienter ansluter till routern med hjälp av en transport och upprättar en session.
  • Routern identifierar klienterna och ger dem behörighet för den aktuella sessionen.
  • Klienter skickar meddelanden till routern som skickar dem till rätt mål med hjälp av de bifogade URI:erna.

Klienterna skickar dessa meddelanden med hjälp av de två primitiva på hög nivå som är RPC och PUB/SUB, och gör fyra kärninteraktioner:

  • register : en klient avslöjar en procedur som ska anropas på distans.
  • samtal : en klient ber routern att få resultatet av en exponerad procedur från en annan klient.
  • prenumerera : en kund anmäler sitt intresse för ett ämne.
  • publicera : en klient publicerar information om detta ämne.

Detta kan ha subtila variationer beroende på den underliggande transporten. Emellertid är implementeringsdetaljer dolda för slutanvändaren som bara programmerar med de två primitiva på hög nivå som är RPC och PubSub.

säkerhet

Eftersom WAMP använder Websocket kan anslutningar lindas in i TLS för kryptering. Även när full konfidentialitet inte är etablerad, implementeras flera mekanismer för att isolera komponenter och undvika man-in-the-middle-attacker . Standardimplementationer säkerställer att försök att registrera en redan registrerad procedur misslyckas.

Routrar kan definiera sfärer som administrativa domäner, och klienter måste ange vilken sfär de vill ansluta sig till vid anslutning. När den väl har anslutits kommer sfären att fungera som ett namnområde , vilket förhindrar klienter som är anslutna till en sfär från att använda ID:n definierade i en annan för RPC och PubSub. Realms har också behörigheter kopplade och kan begränsa klienterna till en delmängd av de tillgängliga REGISTER/CALL/PubSub-åtgärderna.

Vissa sfärer kan endast anslutas av autentiserade klienter, med hjälp av olika autentiseringsmetoder som att använda TLS-certifikat , cookies eller en enkel biljett.

Routerade RPC:er

Till skillnad från traditionella RPC:er, som adresseras direkt från en uppringare till den enhet som erbjuder proceduren (vanligtvis en serverbackend) och är strikt enkelriktade (klient-till-server), dirigeras RPC:er i WAMP av en mellanprogramvara och fungerar dubbelriktat.

Registrering av RPC:er sker med WAMP-routern, och anrop till procedurer utfärdas på liknande sätt till WAMP-routern. Detta innebär först och främst att en klient kan utfärda alla RPC:er via den enda anslutningen till WAMP-routern, och behöver inte ha någon kunskap om vilken klient som för närvarande erbjuder proceduren, var den klienten finns eller hur den ska åtgärdas. Detta kan verkligen ändras mellan samtal, vilket öppnar möjligheten för avancerade funktioner såsom lastbalansering eller fail-over för procedursamtal.

Det betyder dessutom att alla WAMP-klienter är lika genom att de kan erbjuda procedurer för att ringa. Detta undviker den traditionella skillnaden mellan klienter och serverbackends och tillåter arkitekturer där webbläsarklienter anropar procedurer på andra webbläsarklienter, med ett API som känns som peer-to-peer-kommunikation.

Men även med flerskiktsarkitekturer är routern fortfarande ett enda fel. Av denna anledning inkluderar vissa färdplaner för routerimplementering klustringsfunktioner.

Genomföranden

Kunder

Eftersom WAMPs huvudmål är webbapplikationer och Internet of Things, är de första klientimplementeringarna på språk som är väletablerade i dessa branscher (endast WAMP v2-klienter listade):

Klientbibliotek Språk
AngularWAMP JavaScript för ramverket AngularJS
AutobahnCpp C++ 11
wamplv LabVIEW (G)
AutobahnJS JavaScript ( webbläsare och Node.js )
Autobahn Python Pytonorm
mumsig Pytonorm
Net::WAMP Perl
ryggrad.WAMP JavaScript för Backbone.js -biblioteket
CppWAMP C++ 11
Erwa Erlang
Jawampa Java
Loowy Lua
MDWamp Mål-C
Gunstling PHP
rx.wamp JavaScript för React -biblioteket
Thruway PHP
WAMP POCO C++
wampcc C++
WampSharp C#
Wampy.js JavaScript (endast webbläsare)
nexus

Minimikraven för att bygga en WAMP-klient är förmågan att använda sockets och att serialisera till JSON. Således uppfyller många moderna språk redan dessa krav med sitt standardbibliotek. Ytterligare funktioner som skulle lägga till beroenden, såsom TLS-krypteringar eller MessagePack-serialisering, är valfria.

Den beständiga karaktären hos WebSocket-anslutningar kräver dock användning av icke-blockerande bibliotek och asynkrona API :er . På språk med en officiell mekanism som JavaScript, Erlang eller Go är detta inget problem. Men för språk med flera konkurrerande lösningar för asynkron programmering, som Python eller PHP, tvingar det klientens författare att engagera sig i en specifik del av ekosystemet.

Av samma anledning kan det också kräva arbete att integrera äldre projekt. Som ett exempel använder de mest populära Web Python-ramverken WSGI , ett synkront API, och att köra en WAMP-klient inuti en WSGI-arbetare behöver manuella adaptrar såsom crochet .

Routrar

Även om routrar tekniskt sett kan bäddas in direkt i applikationskoden och vissa klientbibliotek också tillhandahåller en router, avskräcks denna arkitektur av specifikationen.

Eftersom routern är en rörlig del är den bäst att använda [ enligt vem? ] som en utbytbar svart låda precis som man skulle överväga Apache eller Nginx för HTTP :

Router Språk
Bondy Erlang
Crossbar.io Python (CPython och PyPy )
Erwa Erlang
wampcc C++
Jawampa Java
Thruway PHP
wamp.rt JavaScript (endast Node.js)
WampSharp C#
Wiola Lua
Nattliv-kanin JavaScript (endast Node.js)
nexus

Tavendo, företaget från vilket protokollet har sitt ursprung, är också författare till Crossbar.io, som marknadsför sig som de facto-routerimplementeringen. Eftersom de marknadsför mikrotjänstbaserade arkitekturer, bäddar Crossbar.io in en servicehanterare för värd och övervakning av WAMP-appkomponenter, en statisk filwebbserver och en WSGI-behållare. Eftersom det är skrivet med Twisted- biblioteket är det en av de implementeringar som kan ställas in i produktion utan proxy, som syftar till att ersätta stackar som Nginx associerade med Supervisor och Gunicorn .

Användningsfall

Eftersom WAMP är ett WebSocket-underprotokoll passar WAMP naturligt var som helst där man skulle använda råa webbsockets, som ett sätt att synkronisera klienter som webbläsare, push-meddelanden till dem och tillåta mjukt realtidssamarbete mellan användare. Den har också samma begränsningar, som kräver klientstöd, vilket saknas för Internet Explorer- versioner äldre än 10. Detta mildras av förekomsten av polyfills som använder mer bärbara teknologier som Flash eller användningen av HTTP Longpoll som reserv. I den meningen är WAMP en konkurrent till Meteors DDP .

WAMP riktar sig också mot IoT, där det används på samma sätt som MQTT som ett lätt och effektivt medium för att orkestrera kluster av anslutna objekt. Implementeringarna på olika språk gör det lämpligt att styra och övervaka små enheter som Raspberry Pi (i Python) eller Tessel (i JavaScript).

Och sist men inte minst kan WAMP fungera som en företagsservicebuss, som fungerar som länken mellan mikrotjänster som man skulle göra med CORBA , ZeroMQ , Apache Thrift , SOAP eller AMQP .

Evolution

WAMP är för närvarande i version 2 som introducerade routed RPC. Från och med nu är alla routrar kompatibla med version 2. Vissa klienter förblir opporterade: Wamp.io, AutobahnAndroid och cljWAMP.

Version 2 av specifikationen är uppdelad i två delar: den grundläggande profilen, inklusive routerns RPC och Pub/Sub, och den avancerade profilen, med förtroendenivåer, URI-mönstermatchning och klientlistning. Den grundläggande profilen anses vara stabil och är vad nuvarande bibliotek implementerar medan den avancerade profilen fortfarande är under utveckling.

Jämförelse

WAMP-webbplatsen hävdar följande försäljningsargument för tekniken:

  • Native PubSub : stöder Publicera och prenumerera direkt (ingen förlängning krävs).
  • RPC : stöder fjärranrop ur lådan (ingen anknytning krävs).
  • Routed RPC : stöder dirigerade (inte bara punkt-till-punkt) fjärranrop.
  • Web native : körs inbyggt på webben (utan tunnling eller bryggning).
  • Cross Language : fungerar på och mellan olika programmeringsspråk och körtider.
  • Öppen standard : Är en öppen, officiell specifikation implementerad av olika leverantörer.

Å andra sidan försöker WAMP inte uppnå vissa mål för andra protokoll:

  • Helt föremål som passerar som CORBA .
  • Datasynkronisering som DDP.
  • Peer-to-peer-kommunikation som ZeroMQ .
  • Multimediastreaming som WebRTC .
  • Stor filöverföring som HTTP.

Ändå delar många protokoll vissa egenskaper med WAMP:

Teknologi PubSub RPC Routerad RPC Webbensinfödd Cross Language Öppen standard
WAMP Yes Yes Yes Yes Yes Yes
AJAX Yes Yes Yes
AMQP Yes Yes Yes Yes
Apache Thrift Yes Yes
Capn'n'Proto Yes Yes
Comet Yes Yes
OMG DDS Yes Yes Yes
D-Bus Yes
CORBA Yes Yes Yes Yes
DCOM Yes Yes Yes
Java JMS Yes Yes
Java RMI Yes Yes
JSON-RPC Yes Yes Yes Yes
MQTT Yes Yes Yes Yes
REST Yes Yes Yes
SOAP Yes Yes Yes Yes
Socket.io Yes Yes
SockJS Yes Yes
STOMP Yes Yes Yes Yes
XML-RPC Yes Yes Yes Yes
XMPP Yes Yes Yes Yes Yes
ZeroMQ Yes Yes
DDP Yes Yes Yes Yes

Även om det är viktigt att notera att medan DDP gör Pub/Sub under huven för att synkronisera datamängder, exponerar det inte PubSub-primitiver. Det är också en öppen specifikation med flera implementeringar, men inte registrerad som standard.