웹 응용 프로그램 메시징 프로토콜

Web Application Messaging Protocol

WAMP는 IANA에 등록된 WebSocket 하위 프로토콜로,[1] 라우팅된 RPC와 PubSub를 제공하도록 지정된다[2]. 그것의 설계 목표는[3] 애플리케이션 요소들 간의 부드러운 실시간 메시지 교환을 위한 개방형 표준을 제공하고 마이크로 서비스에 기초하여 느슨하게 결합되는 아키텍처의 생성을 용이하게 하는 것이다. 이 때문에,[4] 응답성이 높은 웹 애플리케이션을 개발하거나 IoT에서 여러 개의 연결된 장치를 조정하는 데 적합한 ESB(Enterprise Service Bus)[5]이다.

특성.

구조

WAMP는 신뢰할 수 있는 순서의 전이중 메시지 채널을 전송[6] 계층으로 필요로 하며, 기본적으로 Websocket을 사용한다. 그러나 구현은 이러한 특성에 맞는 다른 전송을 사용할 수 있으며 원시 소켓,[7] Unix 소켓 또는 HTTP 롱 폴링과 같은 WAMP와 통신할 수 있다.

메시지 일련화는 정수, 문자열 및 순서형 시퀀스 유형을 사용할 수 있다고 가정하며[8], 이를 제공하는 가장 일반적인 형식으로 JSON으로 기본 설정된다. 구현은 종종 JSON에 대한 보다 빠른 대안으로 MessagePack을 제공하지만 추가적인 의존성을 희생시킨다.[9]

원격 절차와 PubSub 주제를 충돌 없이 식별하기 위해 WAMP는 전역 할당과 해결을 허용하는 ID 공간도 필요하다. 프로토콜은 웹 네이티브(WebSocket이 선호되는 전송)이기 때문에 URI가 사용된다.

워크플로우

WAMP는 클라이언트-클라이언트 통신을 중심으로 설계되며, 중앙 소프트웨어인 라우터와 함께 이들 사이에 메시지를 전송한다. 일반적인 데이터 교환 워크플로우는 다음과 같다.[10]

  • 클라이언트는 전송을 사용하여 라우터에 연결하며 세션을 설정한다.
  • 라우터는 클라이언트를 식별하고 현재 세션에 대한 권한을 부여한다.
  • 클라이언트는 첨부된 URI를 사용하여 라우터에 메시지를 보내고 적절한 대상에 메시지를 발송한다.

고객은 RPC와 PUB/SUB라는 두 가지 상위 원시 요소를 사용하여 다음과 같은 네 가지 핵심 상호 작용을 수행하면서 이러한 메시지를 보낸다.

  • register: 고객이 원격으로 호출할 수 있는 절차를 노출한다.
  • call: 클라이언트는 라우터에 다른 클라이언트로부터 노출된 절차의 결과를 얻도록 요청한다.
  • 구독: 고객은 주제에 대한 관심을 통지한다.
  • 게시: 클라이언트가 이 항목에 대한 정보를 게시함.

이것은 기본적인 운송수단에 따라 미묘한 차이를 가질 수 있다.[11] 그러나 RPC와 PubSub라는 두 개의 높은 수준의 원시성을 가진 프로그램만 사용하는 최종 사용자에게는 구현 세부 정보가 숨겨져 있다.

보안

WAMP는 Websocket을 사용하기 때문에, 암호화를 위해 TLS로 연결을 감쌀 수 있다. 완전한 기밀성이 확립되지 않은 경우에도, 구성요소를 분리하고 중간 공격을 피하기 위해 몇 가지 메커니즘을 구현한다. 기본 구현은 이미 등록된 절차를 등록하려는 시도가 실패함을 보장한다.

라우터는 realms를 관리 도메인으로 정의할 수 있으며, 클라이언트는 연결 시 가입하고자 하는 영역을 지정해야 한다. 일단 가입되면 영역은 네임스페이스의 역할을 하게 되어 영역에 연결된 클라이언트가 RPC와 PubSub에 대해 다른 영역에 정의된 ID를 사용하지 못하게 된다. Realms는 또한 권한을 첨부하고 있으며 클라이언트를 사용 가능한 RERGER/Call/PubSub 동작 중 하나의 하위 집합으로 제한할 수 있다.

일부 영역은 TLS 인증서, 쿠키 또는 단순 티켓 사용과 같은 다양한 인증 방법을 사용하여 인증된 클라이언트만 가입할 수 있다.

라우팅된 RPC

호출자에서 절차를 제공하는 실체(일반적으로 서버 백엔드)로 직접 어드레싱되고 엄격히 단방향(클라이언트 대 서버)인 기존 RPC와는 달리 WAMP의 RPC는 미들웨어에 의해 라우팅되어 양방향으로 작동한다.

RPC의 등록은 WAMP 라우터에 있으며, 절차에 대한 호출은 WAMP 라우터와 유사하게 발행된다. 이는 무엇보다도 클라이언트가 WAMP 라우터에 대한 단일 연결을 통해 모든 RPC를 발급할 수 있다는 것을 의미하며, 클라이언트가 현재 절차를 제공하고 있는 것, 클라이언트가 상주하는 위치 또는 처리 방법을 알 필요가 없다. 이는 실제로 통화 간에 변경될 수 있으며, 로드 밸런싱 또는 절차 호출의 페일오버와 같은 고급 기능에 대한 가능성을 열 수 있다.

그것은 또한 모든 WAMP 고객들은 그들이 전화할 수 있는 절차를 제공할 수 있다는 점에서 동등하다는 것을 의미한다. 이것은 클라이언트와 서버 백업 간의 전통적인 구분을 피하고, 피어 투 피어 통신처럼 느껴지는 API를 통해 브라우저 클라이언트가 다른 브라우저 클라이언트에서 프로시저를 호출하는 아키텍처를 허용한다.

그러나, 멀티티어 아키텍처에서도, 라우터는 여전히 단일 장애 지점이다. 이러한 이유로, 일부 라우터 구현 로드맵에는 클러스터링 기능이 포함되어 있다.[12]

구현

클라이언트

WAMP의 주요 대상은 웹 애플리케이션과 사물 인터넷(Internet of Things)이므로, 첫 번째 클라이언트 구현은 이러한 산업에서 잘 확립된 언어(WAMP v2 클라이언트만 나열됨):

클라이언트 라이브러리 언어
각도WAMP 각도를 위한 자바스크립트JS 프레임워크
아우토반캅 C++ 11
아우토반JS JavaScript(브라우저 및 Node.js)
아우토반피톤 파이톤
왁자지껄한 파이톤
네트:WAMP 펄
줏대 있는WAMP Backback.js 라이브러리용 JavaScript
CppWAMP C++ 11
에르와 얼랑
자와파 자바
루위 루아
MDWamp 목표-C
미니언 PHP
rx.wamp 반응 라이브러리용 JavaScript
스루웨이 PHP
WAMP POCO C++
ampSharp C#
Wampy.js JavaScript(브라우저만 해당)
넥서스 가다

WAMP 클라이언트를 구축하기 위한 최소 요구사항은 소켓 사용 및 JSON에 직렬화하는 기능이다. 그러므로, 많은 현대 언어들은 그들의 표준 라이브러리로 이미 이러한 요건을 충족시키고 있다. TLS 암호화 또는 MessagePack 직렬화와 같이 종속성을 추가하는 추가 기능은 선택 사항이다.

그러나 WebSocket 연결의 지속적인 특성 때문에 차단되지 않는 라이브러리와 비동기 API를 사용해야 한다. 자바스크립트, 얼랑 또는 바둑과 같은 하나의 공식 메커니즘을 가진 언어에서 이것은 문제가 되지 않는다. 그러나 Python이나 PHP와 같이 비동기 프로그래밍을 위한 여러 경쟁 솔루션을 가진 언어의 경우, 그것은 고객 작성자가 생태계의 특정 부분에 전념하도록 강요한다.

같은 이유로, 레거시 프로젝트를 통합하는 것 역시 작업이 필요할 수 있다. 예를 들어, 대부분의 인기 있는 Web Python 프레임워크는 동기식 API인 WSGI를 사용하고 있으며, WSGI 작업자 내부에서 WAMP 클라이언트를 실행하려면 크로셰와 같은 수동 어댑터가 필요하다.

라우터

라우터가 기술적으로 애플리케이션 코드에 직접 내장될 수 있고 일부 클라이언트 라이브러리도 라우터를 제공하는 반면, 이 아키텍처는 규격에 의해 억제된다.[13]

라우터는 움직이는 부분이기 때문에 HTTP를 위해 Apache나 Nginx를 고려하는 것처럼 스왑이 가능한 블랙박스로 가장 잘 사용된다[according to whom?].

라우터 언어
본디 얼랑
크로스바.이오 파이톤(CPython 및 PyPy)
에르와 얼랑
자와파 자바
스루웨이 PHP
쾅.rt JavaScript(Node.js만 해당)
ampSharp C#
위올라 루아
나이트라이프-라빗 JavaScript(Node.js만 해당)
넥서스 가다

프로토콜의 발원지인 타벤도(Tavendo)도 사실상의 라우터 구현이라고 홍보하는 Crossbar.io의 저자다.[14] 마이크로 서비스 기반 아키텍처를 추진하면서 아마존닷컴은 WAMP 앱 컴포넌트, 정적 파일 웹 서버, WSGI 컨테이너 호스팅 및 모니터링을 위한 서비스 매니저를 내장하고 있다. 트위스트 라이브러리와 함께 작성되어, 감독자, 구니콘과 연관된 Nginx와 같은 스택을 대체하는 것을 목표로, 대리 없이 프로덕션에서 설정할 수 있는 구현의 하나이다.

사용 사례

WebSocket 하위 프로토콜인 WAMP는 웹 브라우저와 같은 클라이언트를 동기화하고 알림을 푸시하며 사용자 간에 부드러운 실시간 협업을 허용하는 방법으로 원시 웹 소켓을 사용하는 모든 곳에 자연스럽게 적합하다.[15] 또한 10년 이상 된 Internet Explorer 버전에 대해서는 누락된 클라이언트 지원이 필요한 동일한 제한을 가지고 있다.[16] 이는 플래시 등 더 많은 휴대용 기술을 사용하는 폴리필드의[17] 존재나 HTTP 롱폴을 폴백으로 사용함으로써 완화된다. 그런 의미에서 WAMP는 운석의 DDP의 경쟁자다.

WAMP는 또한 IoT를 대상으로 하며, 이 IoT는 연결된 객체의 클러스터를 조정하기 위한 가볍고 효율적인 매체로서 MQTT와[18] 동일한 방식으로 사용된다. 다양한 언어로 구현되어 라즈베리파이(Python)나 테셀[19](JavaScript)과 같은 작은 장치를 제어하고 모니터링하기에 적합하다.

마지막으로 중요한 것은 WAMP가 기업용 서비스 버스로서, CORBA, ZeroMQ, Apache Saleft, SOAP 또는 AMQP와 같은 마이크로 서비스 간의 연결고리 역할을 하는 것이다.

진화

WAMP는 현재 라우팅된 RPC를 도입한 버전 2에[20] 있다. 현재, 모든 라우터는 버전 2와 호환된다. 일부 클라이언트는 보고되지 않은 상태로 유지됨: Wamp.io, AutobanAndroid 및 cljWAMP.

규격의 버전 2는 라우터 RPC와 Pub/Sub를 포함한 기본 프로필과 신뢰 수준, URI 패턴 매칭, 클라이언트 목록 등 두 부분으로 나뉜다. 기본 프로파일은 안정적인 것으로 간주되며, 고급 프로파일이 아직 진화 중인 동안 현재 도서관이 구현하고 있는 것이다.

비교

WAMP 웹사이트는 이 기술에 대해 다음과 같은 판매 포인트를 주장한다[21].

  • Native PubSub: 즉시 게시 및 구독 지원(연장 필요 없음)
  • RPC: 즉시 원격 프로시저 호출 지원(연장 필요 없음)
  • 라우팅된 RPC: 라우팅된 원격 프로시저 호출(점 대 점뿐 아니라)을 지원한다.
  • 웹 네이티브: 터널링 또는 브리징 없이 웹에서 기본적으로 실행됨.
  • 크로스 랭귀지: 다른 프로그래밍 언어와 런타임 사이에서 작동한다.
  • 개방형 표준: 여러 공급업체에 의해 구현되는 공개 공식 규격이다.

반면에 WAMP는 다른 프로토콜의 일부 목표를 달성하려고 시도하지 않는다.

  • CORBA처럼 지나가는 풀 오브젝트.
  • DDP와 같은 데이터 동기화.
  • ZeroMQ와 같은 피어 투 피어 통신.
  • WebRTC와 같은 멀티미디어 스트리밍.
  • HTTP와 같은 대용량 파일 전송.

그럼에도 불구하고, 수많은 프로토콜은 WAMP와 몇 가지 특성을 공유한다.

기술 펍섭 RPC 라우팅된 RPC 웹 네이티브 크로스 언어 오픈 스탠더드
WAMP Yes Yes Yes Yes Yes Yes
아약스 Yes Yes Yes
AMQP Yes Yes Yes Yes
아파치 레프트 Yes Yes
캡앤프로토 Yes Yes
혜성 Yes Yes
OMG DDS Yes Yes Yes
D-버스 Yes
코르바 Yes Yes Yes Yes
DCOM Yes Yes Yes
자바 JMS Yes Yes
자바 RMI Yes Yes
JSON-RPC Yes Yes Yes Yes
MQTT Yes Yes Yes Yes
쉬다 Yes Yes Yes
비누 Yes Yes Yes Yes
Socket.io Yes Yes
SockJS Yes Yes
쿵쿵거리며 걷다 Yes Yes Yes Yes
XML-RPC Yes Yes Yes Yes
XMPP Yes Yes Yes Yes Yes
제로엠큐 Yes Yes
DDP[22] Yes Yes Yes Yes

그러나 DDP는 데이터 세트를 동기화하기 위해 후드 아래에서 Pub/Sub를 수행하지만 PubSub 원시 요소를 노출하지는 않는다는 점에 유의해야 한다. 또한 여러 가지 구현이 가능한 개방형 규격이지만 표준으로 등록되지는 않았다.

참조

  1. ^ IANA 프로토콜 목록 페이지
  2. ^ WAMP 기본 프로필 사양
  3. ^ "Using WAMP you can build distributed systems out of application components which are loosely coupled and communicate in (soft) real-time".
  4. ^ WAMP에 대한 몇 마디
  5. ^ Bahga, Arshdeep; Madisetti, Vijay (9 August 2014). In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developing IoT solutions. ISBN 9780996025515.
  6. ^ Crossbar.io 라우터 전송
  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 직렬화
  9. ^ "Wampy default serializer is JSON, but it also supports msgpack as a serializer, but you need to include msgpack.js as dependency".
  10. ^ WAMP 내부 조류 보기 다이어그램
  11. ^ "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".
  12. ^ 크로스바 노드 아키텍처
  13. ^ "Brokers and Dealers are responsible for generic call and event routing and do not run application code".
  14. ^ "Crossbar.io is the name of the most full-featured router".
  15. ^ WAMP 및 각도JS
  16. ^ "Can is use websockets ?".
  17. ^ 웹 소켓 폴리필즈
  18. ^ "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" (PDF).
  19. ^ 크로스바와 함께 테셀 알람 앱.이오
  20. ^ WAMP 2 사양 메뉴
  21. ^ WAMP 비교
  22. ^ DDP 사양