简单协议（如twisted.pb）与消息传递（AMQP/JMS）与Web服务（REST/SOAP）

Question

我目前在python上使用了扭曲的透视代理，而且我曾考虑切换到RabbitMQ之类的东西，我不确定它可以取代pb--我觉得我可能会在这里比较苹果和橘子。 最近我一直在阅读很多关于REST的文章，并且与SOAP进行了不可避免的争论，这让我读到了像SOA这样的“企业级”web服务。

我有一个项目即将到来，我需要在Web和桌面上实现一些类似于erp的功能，所以我正在考虑使用哪种方法/技术来在服务器和客户端之间进行通信。但我也想尽可能多地学习所有这些，所以我不想仅仅解决这个特定的问题。

你对服务器和客户端之间的通信有什么用？

我知道像透视经纪人这样的python特定协议会限制我的互操作性，但我是否有权假定某些AMQP协议可以取代它？

如果我没有弄错，twisted.pb和amqp都使用一个永远在线的连接和一个非常低的开销协议。但一方面，保持大量客户端连接始终可能成为问题，另一方面，即使使用http保持活动，以及使用序列化部分的任何技巧仍然是Web服务的问题。

如果我在我的任何假设中错了，我会很感激，如果有人能指出我在正确的方向了解更多。

Answer 1

一如既往，“它取决于”。首先，让我们澄清术语。

Twisted的视角经纪人基本上是一个系统，您可以使用时，您可以控制分布式操作（客户端和服务器端）的两端。它提供了一种将对象从一端复制到另一端并调用远程对象上的方法的方法。复制涉及将对象序列化为适合网络传输的格式，然后使用Twisted自己的传输协议传输它。这在两端都可以使用Twisted时非常有用，而且您不需要与非Twisted系统进行交互。

一般来说，Web服务是依赖HTTP进行通信的客户端服务器应用程序。客户端使用HTTP向服务器发出请求，返回结果。参数可以编码在例如。 GET或POST请求或使用POST请求中的数据部分发送描述要采取的操作的XML格式的文档。

REST是一种架构思想，系统所暴露资源的所有资源和操作都应该是可直接寻址的。简而言之，这意味着用于访问或操作资源的URI包含资源名称和对其执行的操作。 REST可以并且通常作为使用HTTP的Web服务来实现。

SOAP是用于消息交换的协议。它由两部分组成：几种传输方法的选择和一种基于XML的消息格式。传输方法可以是例如HTTP，这使得SOAP成为实现Wed服务的候选者。消息格式指定了有关请求的操作和操作结果的所有细节。

JMS是基于Java的消息传递系统的API标准。它定义了消息的一些语义（如一对一或一对多），并且包括寻址，创建消息，使用参数和数据填充它们，发送它们以及接收和解码它们的方法。该API确保理论上可以更改底层的消息传递系统实现，而无需重写所有代码。但是，消息系统实现不需要与另一个启用JMS的消息传递系统协议兼容。因此，拥有一个JMS系统并不意味着您可以与另一个JMS系统交换消息。您可能需要为此开展某种桥梁服务工作，特别是在解决问题时，这将是一项重大挑战。

AMQP尝试通过定义消息系统必须遵守的有线协议来改善情况。这意味着来自不同供应商的消息系统可以交换消息。

最后，SOA是一种架构概念，应用程序被分解为可重用的服务。然后将这些服务组合（“编排”）以实施该应用程序。每次创建新应用程序时，都有可能重用现有服务。 SOA也是需要非技术支持活动的事情，以便真正实现重用并且服务设计得足够通用。此外，SOA是开始将遗留系统中的功能打包成一个有意义的整体的一种方式，然后可以使用更现代的技术进一步扩展和开发。可以使用各种技术实现SOA，例如Web服务，消息传递系统或企业服务总线。

您考虑了每个请求的一个连接与多个请求的连接保持打开的权衡。这取决于可用资源，消息传递模式和数据大小。如果传入的消息流持续不变，那么让连接保持开放状态可能没有问题，因为它们的数量不会有太大变化。另一方面，如果有来自多个系统的消息的突发，则释放资源并且不会让连接持续太久会很有用。而且，如果每个连接传输大量数据，则与总事务长度相比，打开和关闭连接的开销较小。另一方面，如果你传输很多非常小的消息，那么保持连接打开可能是有益的。使用您的特定参数进行基准对比是唯一确定的方法。

AMQP确实可以替代Twisted特定的协议。这将允许与非Twisted系统进行交互。

我希望这证明对您有用。如果你还在想某些事情（我认为你是，因为这是一个很大的领域），那么我会建议将事情分解成更小的问题并单独发布。答案可以更精确。