本文翻译自 http://wamp-proto.org/

The Web Application Messaging Protocol

（网络程序消息协议）

WAMP is an open standard WebSocket subprotocol that provides two application messaging patterns in one unified protocol:
Remote Procedure Calls + Publish & Subscribe.

WAMP是一种开放式标准的WebSocket子协议，在一个统一协议中提供两种应用程序消息模式：远程过程调用 + 发布&订阅

WAMP provides Unified Application Routing in an open WebSocket protocol that works withdifferent languages.

WAMP在使用不同语言的开放WebSocket协议中提供统一应用程序路由。

Using WAMP you can build distributed systems out of application components which are loosely coupled and communicate in (soft) real-time.

使用WAMP，您可以用松耦合并以（软）实时通信的应用程序组件构建分布式系统

At its core, WAMP offers two communication patterns for application components to talk to each other:
Publish & Subscribe (PubSub) and Remote Procedure Calls (RPC)

WAMP的核心是为应用程序组件提供两种通信模式，以便彼此通信：发布&订阅 + 远程过程调用

We think applications often have a natural need for both forms of communication and shouldn’t be required to use different protocols/means for those. Which is why WAMP provides both.

我们认为应用程序通常对两种形式的通信都有自然的需要，并且不应该要求为这些形式使用不同的协议/手段。 这就是为什么WAMP提供这两者。

WAMP is easy to use, simple to implement and based on modern Web standards: WebSocket, JSON and URIs.

WAMP易于使用，易于实现并基于现代Web标准：WebSocket，JSON和URI。

While WAMP isn’t exactly rocket science, we believe it’s good engineering and a major step forward in practice that allows developers to create more powerful applications with less complexity and in less time.

虽然WAMP不是火箭科学，但我们相信这是一个很好的工程，在实践中向前迈出了一大步，使开发人员能够以更少的复杂性和更少的时间创建更强大的应用程序。

Unified Application Routing统一应用路由

WAMP provides what we call Unified Application Routing for applications: routing of both events (for PubSub) and routing of calls (for RPC) between applications components in one protocol.

WAMP提供了我们所谓的应用程序的统一应用路由：在一个协议中的应用组件之间路由两个事件（用于PubSub）和路由呼叫（用于RPC）。

Unified Routing is probably best explained by contrasting it with legacy approaches. Lets take the old “client-server” world. In the client-server model, a remote procedure call goes directly from theCaller to the Callee:

统一路由可能最好通过与传统方法进行对比来解释。 让我们接受旧的“客户端 - 服务器”世界。 在客户端 - 服务器模型中，远程过程调用直接从调用者到被调用者：调用者–>被调者

In the client-server model, a Caller needs to have knowledge about where the Callee resides and how to reach it. This introduces a strong coupling between Caller and Callee. Which is bad, because applications can quickly become complex and unmaintainable. We explain how WAMP fixes that in a minute.

在客户端 - 服务器模型中，Caller需要知道Callee驻留在哪里以及如何到达它。 这引入Caller和Callee之间的强耦合。 这是坏的，因为应用程序可能很快变得复杂和无法维护。 我们解释WAMP如何解决这一点。

The problems coming from strong coupling between application components were long recognized and this (besides other requirements) lead to the publish-subscribe model.

长期认识到来自应用程序组件之间的强耦合问题，这（除了其他要求）导致订阅模型的发布。

In the publish-subscribe model a Publisher submits information to an abstract “topic”, andSubscribers only receive information indirectly by announcing their interest on a respective “topic”. Both do not know about each other. They are decoupled via the “topic” and via an intermediary usually called Broker:

在发布 - 订阅模型中，发布者向抽象的“主题”提交信息，并且订阅者仅通过宣告他们对相应“主题”的兴趣而间接地接收信息。 两个人不知道彼此。 它们通过“主题”和通常称为代理的中间体解耦：发布者–>代理商–>订阅者

A Broker keeps a book of subscriptions: who is currently subscribed on which topic. When aPublisher publishes some information (“event”) to a topic, the Broker will look up who is currently subscribed on that topic: determine the set of Subscribers on the topic published to. And then forward the information (“event”) to all those Subscribers.

代理商保留一本订阅：谁目前订阅了哪个主题。 当发布者向主题发布一些信息（“事件”）时，代理将查找当前对该主题订阅的用户：确定发布到的主题上的订阅者集合。 然后将信息（“事件”）转发给所有这些订阅者。

The act of determining receivers of information (independently of the information submitted) and forwarding the information to receivers is called routing.

确定信息接收者（独立于提交的信息）和将信息转发到接收者的行为被称为路由。

Now, WAMP translates the benefits of loose coupling to RPC. Different from the client-server model, WAMP also decouples Callers and Callees by introducing an intermediary - the Dealer:

现在，WAMP将松耦合的好处转化为RPC。 与客户端 - 服务器模型不同，WAMP还通过引入中介 - 经销商来解除Caller和Callees的联系：调用者–>经销商–>被调者

Similar to a Broker’s role with PubSub, the Dealer is responsible for routing a call originating from the Caller to the Callee and route back results or errors vice-versa. Both do not know about each other: where the peer resides and how to reach it. This knowledge is encapsulated in the Dealer

类似于Broker在PubSub中的作用，经销商负责将来自Caller的呼叫路由到被叫方，并路由回结果或错误，反之亦然。 两者不知道彼此：对等体驻留在哪里以及如何到达它。 这些知识被封装在经销商。

With WAMP, a Callee registers a procedure at a Dealer under an abstract name: an URI identifying the procedure. When a Caller wants to call a remote procedure, it talks to the Dealer and only provides the URI of the procedure to be called plus any call arguments. The Dealer will look up the procedure to be invoked in his book of registered procedures. The information from the book includes where the Callee implementing the procedure resides, and how to reach it.

使用WAMP，被叫方在经销商处以抽象名称注册过程：标识过程的URI。 当调用者想要调用远程过程时，它与经销商谈话，并且仅提供要调用的过程的URI加上任何调用参数。 经销商将在他的注册程序书中查找要援引的程序。 书中的信息包括执行程序的Callee所在的位置，以及如何到达它。

In effect, Callers and Callees are decoupled, and applications can use RPC and still benefit from loose coupling.

实际上，Caller和Callees是分离的，应用程序可以使用RPC并仍然受益于松耦合。

What if you combine both? Routed RPC and PubSub? When you combine a Broker and a Dealer you get what WAMP calls a Router:

如果你结合两个？ 路由RPC和PubSub？ 当你结合经纪人和经销商，你得到什么WAMP调用路由器：路由 = 代理商 + 经销商

A Router is capable of routing both calls and events, and hence can support flexible, decoupled architectures that use both RPC and PubSub. We think this is new. And a good thing.

路由器能够路由呼叫和事件，因此可以支持使用RPC和PubSub的灵活的解耦架构。 我们认为这是新的， 一个好东西。

Here is an example. Imagine you have a small embedded device like an Arduino Yun with sensors (like a temperature sensor) and actuators (like a light or motor) connected. And you want to integrate the device into an overall system with user facing frontend to control the actuators, and continuously process sensor values in a backend component.

这里是一个例子。 想象一下，你有一个像Arduino Yun这样的小型嵌入式设备，具有传感器（如温度传感器）和致动器（如灯或电机）连接。 您希望将设备集成到整个系统中，用户面向前端以控制执行器，并连续处理后端组件中的传感器值。

Using WAMP, you can have a browser-based UI, the embedded device and your backend talk to each other in real-time:

使用WAMP，您可以有一个基于浏览器的UI，嵌入式设备和您的后端实时交谈

Switching on a light on the device from the browser-based UI is naturally done by calling a remote procedure on the device (1). And the sensor values generated by the device continuously are naturally transmitted to the backend component (and possibly others) via publish & subscribe (2).

从基于浏览器的UI打开设备上的灯自然通过在设备（1）上调用远程过程来完成。 并且由设备连续生成的传感器值通过发布和订阅（2）自然地传输到后端组件（并且可能是其他组件）。

“Moving onto the part of Internet of Things, we integrated a sensor (light sensor) and an actuator (light switch/dimmer) into a web application. The major feature of the sensor (sending data) and that of the actuator (commanding and configuration) perfectly match the messaging patterns, Pub/Sub and RPC, which WAMP provides.”
From: Web Technologies for the Internet of Things, Master thesis, July 2013, Huang F.

“移动到物联网的一部分，我们将传感器（光传感器）和执行器（光开关/调光器）集成到Web应用中。传感器（发送数据）和执行器的主要特征（命令和 配置）完全匹配WAMP提供的消息模式，Pub / Sub和RPC。来自：物联网的Web技术，硕士论文，2013年7月，黄福

Polyglot多语言化

WAMP was designed with first-class support for different languages in mind (*). Nothing in WAMP is specific to a single programming language. As soon as a programming language has a WAMP implementation, it can talk to application components written in any other language with WAMP support. Transparently.

WAMP设计有一流的支持，支持不同的语言（*）。 WAMP中没有什么特定于单个编程语言。 只要编程语言具有WAMP实现，它就可以与使用WAMP支持的任何其他语言编写的应用程序组件通信。 透明。

*: WAMP has facilities for first-class support of many common and less common language features. E.g. WAMP can transmit both positional and keyword based call arguments, so that languages which natively support keyword arguments in functions (e.g. Python) can be naturally mapped. WAMP even supports multi-positional and keywords based return values for calls. E.g. the PostgreSQL pgPL/SQL or Oracle PL/SQL languages support this. Means that most PL/SQL functions can be naturally exposed via WAMP.

*：WAMP拥有许多常见和不常用语言功能的一流支持。 例如。 WAMP可以传输基于位置和基于关键字的调用参数，以便本机支持函数中的关键字参数（例如Python）的语言可以自然映射。 WAMP甚至支持基于多位置和基于关键字的调用返回值。 例如。 PostgreSQL的pgPL / SQL或Oracle PL / SQL语言支持这一点。 意味着大多数PL / SQL函数可以通过WAMP自然暴露。

The ability to create a system from application components written in different languages is a big advantage. You can write your frontend in JavaScript to run in the browser, but still write backend components in Python or Java. If you recognize a performance bottleneck in a component, you can rewrite that component in a faster language - without changing a single line of code in other components.

从以不同语言编写的应用程序组件创建系统的能力是一个很大的优势。 您可以使用JavaScript编写前端以在浏览器中运行，但仍然使用Python或Java编写后端组件。 如果您认识到组件中的性能瓶颈，您可以使用更快的语言重写该组件，而无需更改其他组件中的单行代码。

All developers in your team can become productive, since they are not tied to a “least common denominator”, but can write components in the language they prefer, or which is ideal for the specific components at hand. Need some fancy numerical code which is only available in C++ and needs to run with maximum performance? No problem. Have the functionality isolated in an application component written in C++, and integrate this with components written in your “standard” language.

您团队中的所有开发人员都可以变得高效，因为它们不受“最小公分母”的束缚，而是可以使用他们喜欢的语言编写组件，或者是手头特定组件的理想选择。 需要一些花哨的数字代码，这只是在C ++中可用，并需要运行最大的性能？ 没问题。 将功能分离在用C ++编写的应用程序组件中，并将其与用“标准”语言编写的组件集成。

What this means is: plug-and-play your app components - no matter what language.

这意味着：即插即用您的应用程序组件 - 无论使用什么语言。

So here you have it: one protocol fulfilling “all” application communication needs.

所以这里你有它：一个协议满足“所有”应用程序通信需求。

What is RPC?

Remote Procedure Call (RPC) is a messaging pattern involving peers of three roles:
Caller
Callee
Dealer
A Caller issues calls to remote procedures by providing the procedure URI and any arguments for the call. The Callee will execute the procedure using the supplied arguments to the call and return the result of the call to the Caller.
Callees register procedures they provide with Dealers. Callers initiate procedure calls first to Dealers.Dealers route calls incoming from Callers to Callees implementing the procedure called, and route call results back from Callees to Callers.
The Caller and Callee will usually run application code, while the Dealer works as a generic router for remote procedure calls decoupling Callers and Callees.
Up

远程过程调用（RPC）是一种涉及三个角色的同级的消息模式：

呼叫者
Callee
经销商
调用者通过提供过程URI和调用的任何参数来向远程过程发出调用。 Callee将使用提供的调用参数执行该过程，并将调用结果返回给调用者。

Callees注册他们向经销商提供的程序。 呼叫者首先向经销商发起程序呼叫。 经销商将来自呼叫者的呼叫路由到实现所调用的过程的Callees，并将呼叫结果从Callees路由回到呼叫者。

Caller和Callee通常运行应用程序代码，而经销商作为一个通用路由器，用于远程过程调用解耦Caller和Callees。

What is PubSub?
Publish & Subscribe (PubSub) is a messaging pattern involving peers of three roles:
Publisher
Subscriber
Broker
A Publishers publishes events to topics by providing the topic URI and any payload for the event.Subscribers of the topic will receive the event together with the event payload.
Subscribers subscribe to topics they are interested in with Brokers. Publishers initiate publication first at Brokers. Brokers route events incoming from Publishers to Subscribers that are subscribed to respective topics.
The Publisher and Subscriber will usually run application code, while the Broker works as a generic router for events decoupling Publishers from Subscribers.
Read more: Publish / Subscribe Systems: Design and Principles, by Sasu Tarkoma.
发布和订阅（PubSub）是一种包含三个角色的同行的消息模式：

发布商
订户
经纪人
发布者通过提供主题URI和事件的任何有效内容将主题发布到主题。 主题的订阅者将与事件有效内容一起接收事件。

订阅者订阅他们对Brokers感兴趣的主题。 发布商首先在Brokers发布发布。 代理将从发布者传入的事件路由到订阅相应主题的订阅者。

发布者和订阅者通常运行应用程序代码，而代理作为通用路由器用于将发布者与订阅者分离的事件。

阅读更多：发布/订阅系统：设计和原则，由Sasu Tarkoma。

Why RPC and PubSub in one protocol?
Imagine the following situation: an application frontend wants to perform some action on an application backend. The frontend also wants to get notified when another frontend performs the respective action on the backend.
For example, in a Web application for managing service tickets, a frontend might perform the action “create new ticket”, and get notified via events of “new ticket created”.
A natural approach to realize above would use RPC for performing actions, and PubSub for notifications.
With the service ticket Web app, the frontend would subscribe to the topic “OnTicketCreated”, and perform it’s actions by calling “createTicket”. The backends implementation of “createTicket” would not only perform the action of creating a new ticket, but also publish a event on the topic “OnTicketCreated” with the details of the new ticket.
Now, a protocol suitable for realizing above will naturally need to provide both RPC and PubSub messaging patterns. WAMP was designed exactly with above in mind, so it provides you with a unified protocol for both RPC and PubSub.
For more about the reasoning behind WAMP, see this explanation.

想象以下情况：应用程序前端希望对应用程序后端执行某些操作。前端还希望在另一个前端在后端执行相应操作时获得通知。

例如，在用于管理服务票证的Web应用程序中，前端可以执行动作“创建新票据”，并且通过“新票据创建”的事件来通知。

上面实现的自然方法将使用RPC来执行动作，而PubSub用于通知。
使用服务票Web应用程序，前端将订阅主题“OnTicketCreated”，并通过调用“createTicket”执行它的操作。 “createTicket”的后端实现不仅执行创建新票据的操作，而且还发布关于主题“OnTicketCreated”的事件以及新票据的细节。

现在，适合于实现上述的协议自然需要提供RPC和PubSub消息模式。 WAMP的设计完全符合上述要求，因此它为RPC和PubSub提供了一个统一的协议。

有关WAMP背后的原因的更多信息，请参阅此解释。

Why is it called WAMP and how do I use it?
WAMP is an acronym, and the term “Web Application Messaging Protocol” is a quite precise description of what the protocol provides.
WAMP is pronounced /wa:mp/, as in swamp or chomp.
Note that there is another technology also abbreviated WAMP: the Web technology stack “Windows + Apache + MySQL + PHP”. I.e. Wikipedia has a corresponding disambiguation page.
Because of this potential ambiguity, here is what we recommend for authors/implementors:
Use “WAMP” in text and speech
The first occurrence in text should read: “WAMP (Web Application Messaging Protocol)”
Add the hashtag/keyword “wampws” to the contents metadata
And here is what we recommend for users:
Use the terms “wamp” and “protocol” combined when using Web search engines
Use the hashtag/keyword “wampws” when search on Web platform like Twitter orStackOverflow

WAMP是首字母缩略词，术语“Web应用消息协议”是对协议提供的内容的非常精确的描述。

WAMP发音为/ wa：mp /，如在沼泽或chomp中。

注意还有另一种技术也简称为WAMP：Web技术栈“Windows + Apache + MySQL + PHP”。 也就是说 维基百科有一个相应的消歧页面。

由于这种潜在的模糊性，这里是我们建议作者/实施者：

在文本和语音中使用“WAMP”
文本中的第一次出现应该是：“WAMP（Web应用程序消息传递协议）”
将hashtag /关键字“wampws”添加到内容元数据
这里是我们推荐给用户：

在使用Web搜索引擎时，请使用术语“wamp”和“protocol”
在Twitter或StackOverflow等Web平台上搜索时，请使用hashtag /关键字“wampws”

What is WebSocket?

WebSocket is a protocol providing full-dupley communcations channels over a single TCP connection. It started out in the Web world, where it was created to replace things like Comet, and to allow true bi-directional, low-latency connections between browser and server. It’s standardized by the IETF and the W3C. Usage is not limited to the browser, with implementations available for all major programming languages. For more details see this introductory blog post.

WebSocket是一种通过单个TCP连接提供全双工通信信道的协议。 它开始于Web世界，在那里它被创建来替换彗星，并允许浏览器和服务器之间的真正双向，低延迟连接。 它由IETF和W3C标准化。 用法不限于浏览器，实施可用于所有主要的编程语言。 有关更多详细信息，请参阅此介绍性博客文章。

Is WebSocket necessary for WAMP?
WAMP started out as the WebSocket Application Messaging Protocol. WebSocket is still the preferred transport in many cases, but the transport layer is fully decoupled. Any bi-directional, reliable, message-based and ordered transport works. Transports like Unix Domain Sockets or Unix Pipes are being used in implementations.
Additionally, a transport for WAMP transports can be implemented on top of other transports which lack some of the requirements, e.g. using longpoll bi-directionality can be built on top of HTTP.

WAMP开始作为WebSocket应用消息协议。 WebSocket在许多情况下仍然是首选传输，但传输层完全解耦。 任何双向，可靠，基于消息和有序运输工程。 在实现中使用像Unix Domain Sockets或Unix Pipes这样的传输。

另外，用于WAMP传输的传输可以在没有一些要求的其它传输的顶部实现，例如。 使用longpoll双向性可以建立在HTTP之上。

Legal
What is the legal status of WAMP?
WAMP is free - both as in beer and as in speech. Do with it what you like. If WAMP fills your needs as it is, then the easiest thing is to just use it without any changes. The more compatible implementations, the better for interoperability. If your needs require modifications, or you want to start your own development based on WAMP, then you are also free to do so.
Whatever you do with WAMP - an announcement on the mailing list is always welcome.

WAMP是免费的 - 无论是在啤酒和语音。 做它你喜欢什么。 如果WAMP满足你的需要，那么最简单的方法是只使用它而没有任何改变。 更兼容的实现，更好的互操作性。 如果你的需求需要修改，或者你想根据WAMP开始自己的开发，那么你也可以这样做。

无论你如何使用WAMP - 在邮件列表上的公告总是欢迎。

Are there any requirements if I use WAMP for my project?
WAMP is free to use for anybody, be it as part of an open source or a commercial project. There are no strings attached here, no licenses to pay, and no known other intellectual property (such as patents).
If you do use WAMP for your project, then both a mention of this somewhere in your project, and an announcement on the mailing list would be welcome.

WAMP可以为任何人免费使用，无论是作为开源或商业项目的一部分。 这里没有字符串，没有许可证支付，没有已知的其他知识产权（如专利）。

如果你使用WAMP为你的项目，那么在项目的某个地方提及，并在邮件列表上的公告将欢迎。

最后

以上就是淡然黑夜为你收集整理的WAMP知识一览The Web Application Messaging Protocol（网络程序消息协议）的全部内容，希望文章能够帮你解决WAMP知识一览The Web Application Messaging Protocol（网络程序消息协议）所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。