WAMP ต้องการ^{[ 6 ]} ช่องทางการส่งข้อความ แบบฟูลดูเพล็กซ์ที่เชื่อถือได้และเรียง ลำดับ เป็นเลเยอร์การขนส่งและโดยค่าเริ่มต้นจะใช้ WebSocket อย่างไรก็ตาม การใช้งานสามารถใช้การขนส่งอื่นๆ ที่ตรงกับคุณลักษณะเหล่านี้และสื่อสารกับ WAMP ผ่านซ็อกเก็ตดิบ^{[ 7 ]}ซ็อกเก็ต UnixหรือHTTP long poll

การแปลงข้อความ เป็นอนุกรม ถือว่า^{[ 8 ]}มีจำนวนเต็ม สตริง และประเภทลำดับที่เรียงลำดับพร้อมใช้งาน และค่าเริ่มต้นคือJSONเนื่องจากเป็นรูปแบบที่พบได้บ่อยที่สุดที่นำเสนอสิ่งเหล่านี้ การใช้งานมักจะจัดเตรียมMessagePackเป็นทางเลือกที่เร็วกว่า JSON โดยแลกกับการพึ่งพาเพิ่มเติม^{[ 9 ]}

WAMP ได้รับการออกแบบทางสถาปัตยกรรมโดยเน้นการสื่อสารระหว่างไคลเอ็นต์กับไคลเอ็นต์ โดยมีซอฟต์แวร์ส่วนกลางคือเราเตอร์ ทำหน้าที่ส่งข้อความระหว่างไคลเอ็นต์ ขั้นตอนการแลกเปลี่ยนข้อมูลโดยทั่วไปมีดังนี้: ^{[ 10 ]}

• ไคลเอนต์เชื่อมต่อกับเราเตอร์โดยใช้ช่องทางการสื่อสารเพื่อสร้างเซสชัน
• เราเตอร์จะระบุตัวตนของไคลเอ็นต์และให้สิทธิ์แก่ไคลเอ็นต์เหล่านั้นสำหรับเซสชันปัจจุบัน
• ไคลเอนต์ส่งข้อความไปยังเราเตอร์ ซึ่งเราเตอร์จะส่งต่อข้อความเหล่านั้นไปยังปลายทางที่ถูกต้องโดยใช้ URI ที่แนบมาด้วย

ไคลเอนต์ส่งข้อความเหล่านี้โดยใช้สองฟังก์ชันพื้นฐานระดับสูง ได้แก่ RPC และ PUB/SUB ซึ่งมีการโต้ตอบหลักสี่อย่าง:

• register : ไคลเอนต์จะเปิดเผยขั้นตอนการทำงานเพื่อให้สามารถเรียกใช้จากระยะไกลได้
• การเรียกใช้ : ไคลเอนต์ขอให้เราเตอร์รับผลลัพธ์ของกระบวนการที่เปิดเผยจากไคลเอนต์อื่น
• สมัครรับข้อมูล : ลูกค้าแจ้งความสนใจในหัวข้อใดหัวข้อหนึ่ง
• เผยแพร่ : ลูกค้าเผยแพร่ข้อมูลเกี่ยวกับหัวข้อนี้

สิ่งนี้อาจมีความแตกต่างเล็กน้อยขึ้นอยู่กับการขนส่งพื้นฐาน^{[ 11 ]}อย่างไรก็ตาม รายละเอียดการใช้งานจะถูกซ่อนไว้จากผู้ใช้ปลายทางซึ่งเขียนโปรแกรมด้วยสองฟังก์ชันพื้นฐานระดับสูงเท่านั้น ได้แก่ RPC และ PubSub

เนื่องจาก WAMP ใช้ WebSocket การเชื่อมต่อจึงสามารถเข้ารหัสด้วยTLSได้ แม้ว่าจะไม่ได้มีการรักษาความลับ อย่างสมบูรณ์ แต่ก็มีการนำกลไกหลายอย่างมาใช้เพื่อแยกส่วนประกอบและหลีกเลี่ยง การโจมตีแบบคนกลาง (man-in-the-middle attacks ) การใช้งานเริ่มต้นจะทำให้การพยายามลงทะเบียนขั้นตอนที่ลงทะเบียนไว้แล้วล้มเหลว

เราเตอร์สามารถกำหนดรีล์มเป็นโดเมนการบริหารได้ และไคลเอ็นต์ต้องระบุว่าต้องการเข้าร่วมรีล์มใดเมื่อเชื่อมต่อ เมื่อเข้าร่วมแล้ว รีล์มจะทำหน้าที่เป็นเนมสเปซป้องกันไม่ให้ไคลเอ็นต์ที่เชื่อมต่อกับรีล์มหนึ่งใช้ ID ที่กำหนดไว้ในรีล์มอื่นสำหรับ RPC และ PubSub นอกจากนี้ รีล์มยังมีสิทธิ์ที่แนบมาด้วย และสามารถจำกัดไคลเอ็นต์ให้ใช้ได้เฉพาะชุดย่อยของแอ็กชัน REGISTER/CALL/PubSub ที่มีอยู่เท่านั้น

บางโดเมนสามารถเข้าร่วมได้เฉพาะไคลเอ็นต์ที่ผ่านการตรวจสอบสิทธิ์แล้วเท่านั้น โดยใช้วิธีการตรวจสอบสิทธิ์ต่างๆ เช่น การใช้ใบรับรอง TLS , คุกกี้หรือตั๋วแบบง่ายๆ

แตกต่างจาก RPC แบบดั้งเดิม ซึ่งผู้เรียกจะส่งคำขอไปยังหน่วยงานที่ให้บริการกระบวนการโดยตรง (โดยทั่วไปคือเซิร์ฟเวอร์แบ็กเอนด์) และเป็นแบบทิศทางเดียวอย่างเคร่งครัด (จากไคลเอ็นต์ไปยังเซิร์ฟเวอร์) แต่ RPC ใน WAMP จะถูกส่งผ่านมิดเดิลแวร์และทำงานได้แบบสองทิศทาง

การลงทะเบียน RPC จะทำผ่านเราเตอร์ WAMP และการเรียกใช้โปรซีเดอร์ก็ทำผ่านเราเตอร์ WAMP เช่นกัน นั่นหมายความว่า ลูกค้าสามารถส่ง RPC ทั้งหมดผ่านการเชื่อมต่อเดียวกับเราเตอร์ WAMP ได้ และไม่จำเป็นต้องรู้ว่าลูกค้ารายใดกำลังให้บริการโปรซีเดอร์อยู่ ลูกค้ารายนั้นอยู่ที่ใด หรือจะระบุที่อยู่ได้อย่างไร ซึ่งสามารถเปลี่ยนแปลงได้ระหว่างการเรียกใช้ ทำให้สามารถใช้งานฟีเจอร์ขั้นสูง เช่นการกระจายโหลดหรือการสำรองข้อมูลเมื่อเกิดข้อผิดพลาด สำหรับการเรียกใช้โปร ซีเดอร์ได้

นอกจากนี้ยังหมายความว่าไคลเอ็นต์ WAMP ทั้งหมดมีความเท่าเทียมกันในแง่ที่ว่าพวกเขาสามารถนำเสนอขั้นตอนการเรียกใช้งานได้ ซึ่งช่วยหลีกเลี่ยงความแตกต่างแบบดั้งเดิมระหว่างไคลเอ็นต์และแบ็กเอนด์เซิร์ฟเวอร์ และช่วยให้สถาปัตยกรรมที่ไคลเอ็นต์เบราว์เซอร์เรียกใช้ขั้นตอนบนไคลเอ็นต์เบราว์เซอร์อื่น ๆ เป็นไปได้ ด้วย API ที่ให้ความรู้สึกเหมือนการสื่อสารแบบ peer-to-peer

อย่างไรก็ตาม แม้จะมีสถาปัตยกรรมแบบหลายระดับ เราเตอร์ก็ยังคงเป็นจุดเดียวที่อาจเกิดความล้มเหลวได้ ด้วยเหตุนี้ แผนงานการใช้งานเราเตอร์บางส่วนจึงรวมคุณสมบัติการจัดกลุ่มไว้ด้วย^{[ 12 ]}

เนื่องจากเป้าหมายหลักของ WAMP คือแอปพลิเคชันบนเว็บและอินเทอร์เน็ตของสรรพสิ่ง (IoT) การใช้งานไคลเอ็นต์รุ่นแรกจึงใช้ภาษาที่ได้รับการยอมรับอย่างดีในอุตสาหกรรมเหล่านี้ (แสดงเฉพาะไคลเอ็นต์ WAMP v2 เท่านั้น):

ข้อกำหนดขั้นต่ำในการสร้างไคลเอ็นต์ WAMP คือความสามารถในการใช้ซ็อกเก็ตและการแปลงข้อมูลเป็น JSON ดังนั้น ภาษาโปรแกรมสมัยใหม่หลายภาษาจึงมีคุณสมบัติตรงตามข้อกำหนดเหล่านี้อยู่แล้วในไลบรารีมาตรฐานของตน คุณสมบัติเพิ่มเติมที่จะเพิ่มการพึ่งพา เช่น การเข้ารหัส TLS หรือการแปลงข้อมูลเป็น JSON ด้วย MessagePack นั้นเป็นตัวเลือกเสริม

อย่างไรก็ตาม ลักษณะการเชื่อมต่อแบบต่อเนื่องของ WebSocket จำเป็นต้องใช้ไลบรารีแบบไม่บล็อกและAPI แบบอะซิงโครนัส ในภาษาที่มีกลไกอย่างเป็นทางการเพียงกลไกเดียว เช่น JavaScript, Erlang หรือ Go จะไม่มีปัญหา แต่สำหรับภาษาที่มีโซลูชันที่แข่งขันกันหลายอย่างสำหรับการเขียนโปรแกรมแบบอะซิงโครนัส เช่น Python หรือ PHP จะบังคับให้ผู้เขียนฝั่งไคลเอ็นต์ต้องเลือกใช้ส่วนใดส่วนหนึ่งของระบบนิเวศนั้น

ด้วยเหตุผลเดียวกัน การผสานรวมโปรเจกต์เก่าๆ ก็อาจต้องใช้ความพยายามเช่นกัน ตัวอย่างเช่น เฟรมเวิร์ก Python สำหรับเว็บส่วนใหญ่ใช้WSGIซึ่งเป็น API แบบซิงโครนัส และการเรียกใช้ไคลเอ็นต์ WAMP ภายในเวิร์กเกอร์ WSGI จำเป็นต้องใช้อะแดปเตอร์แบบแมนนวล เช่น crochet

แม้ว่าเราเตอร์จะสามารถฝังลงในโค้ดแอปพลิเคชันได้โดยตรงในทางเทคนิค และไลบรารีไคลเอ็นต์บางตัวก็มีเราเตอร์ให้ด้วย แต่สถาปัตยกรรมนี้ไม่แนะนำตามข้อกำหนด^{[ 13 ]}

เนื่องจากเราเตอร์เป็นชิ้นส่วนที่เคลื่อนไหวได้ จึงควรใช้มันเป็นกล่องดำที่สามารถเปลี่ยนได้ เหมือนกับที่เราพิจารณาใช้ApacheหรือNginxสำหรับHTTP :

Tavendoบริษัทที่เป็นผู้ริเริ่มโปรโตคอลนี้ ยังเป็นผู้เขียนCrossbar.ioซึ่งโปรโมตตัวเองว่าเป็นการใช้งานเราเตอร์มาตรฐาน^{[ 14 ]}เนื่องจากพวกเขาสนับสนุนสถาปัตยกรรมแบบไมโครเซอร์วิส Crossbar.io จึงฝังตัวจัดการบริการสำหรับการโฮสต์และตรวจสอบส่วนประกอบแอป WAMP เซิร์ฟเวอร์เว็บไฟล์คงที่ และคอนเทนเนอร์ WSGI ไว้ด้วย การเขียนด้วย ไลบรารี Twistedทำให้เป็นหนึ่งในการใช้งานที่สามารถตั้งค่าในสภาพแวดล้อมการผลิตได้โดยไม่ต้องใช้พร็อกซี โดยมีเป้าหมายเพื่อทดแทนสแต็กต่างๆ เช่น Nginx ที่เกี่ยวข้องกับSupervisorและGunicorn