简单协议（如 twisted.pb）与消息传递（AMQP/JMS）与web服务（REST/SOAP）
我现在在用Python的Twisted库里的Perspective Broker（视角代理），之前考虑过换成RabbitMQ，但不太确定它能否完全替代pb，感觉这就像在比较苹果和橙子一样。
最近我在研究REST和SOAP之间的争论，这让我开始关注一些“企业级”的网络服务，比如SOA。
我有一个即将到来的项目，需要在网络和桌面上实现一些类似ERP的功能，所以我在考虑用什么方法或技术来实现服务器和客户端之间的通信。不过，我也想尽可能多地了解这些内容，所以我不仅仅想解决这个特定的问题。
你们在服务器和客户端之间用什么进行通信呢？
我知道像Perspective Broker这样的Python特定协议可能会限制我的互操作性，但我是否可以认为某种AMQP协议可以替代它呢？
如果我没记错的话，Twisted的pb和AMQP都使用一种始终保持连接的方式，并且协议开销非常小。但一方面，保持大量客户端一直连接可能会是个问题；另一方面，即使使用HTTP的保持连接和其他技巧，序列化部分在网络服务中仍然会是个问题。
如果我有任何错误的假设，希望有人能指引我更深入地了解这些内容。
1 个回答
和往常一样，“这要看情况”。首先，我们来澄清一些术语。
Twisted的Perspective Broker基本上是一个系统，当你可以控制分布式操作的两端（客户端和服务器端）时，可以使用它。它提供了一种将对象从一端复制到另一端的方法，并可以在远程对象上调用方法。复制的过程涉及将对象转换成适合网络传输的格式，然后使用Twisted自己的传输协议进行传输。这在两端都能使用Twisted的情况下非常有用，而且你不需要和非Twisted系统进行交互。
一般来说，Web Services是依赖HTTP进行通信的客户端-服务器应用程序。客户端使用HTTP向服务器发送请求，服务器则返回结果。参数可以通过例如GET或POST请求进行编码，或者在POST请求中使用数据部分发送，例如一个描述要执行的操作的XML格式文档。
REST是一种架构思想，认为系统暴露的所有资源和对资源的操作都应该可以直接访问。简单来说，这意味着用于访问或操作资源的URI包含资源名称和要执行的操作。REST通常是通过HTTP实现的Web服务。
SOAP是一种消息交换协议。它由两个部分组成：几种传输方法的选择，以及一种基于XML的消息格式。传输方法可以是HTTP，这使得SOAP适合用于实现Web服务。消息格式则规定了请求的操作和操作结果的所有细节。
JMS是一个针对基于Java的消息系统的API标准。它定义了一些消息的语义（比如一对一或一对多），并包括用于寻址、创建消息、填充参数和数据、发送、接收和解码消息的方法。这个API确保理论上你可以更换底层的消息系统实现，而不需要重写所有代码。不过，消息系统的实现不需要和其他JMS支持的消息系统兼容。因此，拥有一个JMS系统并不意味着你可以和另一个JMS系统交换消息。你可能需要建立某种桥接服务来实现这一点，这在寻址方面尤其具有挑战性。
AMQP试图通过定义一个消息系统必须遵循的协议来改善这种情况。这意味着来自不同厂商的消息系统可以互相交换消息。
最后，SOA是一种架构概念，将应用程序拆分为可重用的服务。这些服务再被组合（“编排”）以实现应用程序。每当创建一个新应用时，都有机会重用现有的服务。SOA还需要非技术支持活动，以确保真正实现重用，并且服务设计得足够通用。此外，SOA也是将旧系统中的功能打包成一个有意义的整体的一种方式，这样就可以使用更现代的技术进行扩展和开发。SOA可以通过多种技术实现，例如Web服务、消息系统或企业服务总线。
你考虑了每个请求一个连接和保持连接以处理多个请求之间的权衡。这取决于可用资源、消息模式和数据大小。如果传入的消息流始终保持不变，那么保持连接开放可能是合适的，因为连接的数量不会有太大变化。另一方面，如果来自多个系统的消息突然增多，那么释放资源而不让连接保持太久可能会更有用。此外，如果每个连接传输大量数据，那么打开和关闭连接的开销相对于总交易时间来说是很小的。相反，如果你传输的是大量非常小的消息，那么保持连接开放可能会更有利。使用你特定的参数进行基准测试是确保这一点的唯一方法。
AMQP确实可以替代Twisted特定的协议。这将允许与非Twisted系统进行交互。
希望这些对你有帮助。如果你还有其他疑问（我想你肯定还有，因为这是一个很大的领域），我建议把问题拆分成更小的部分，单独提问。这样回答会更准确。