一如既往，“这取决于”。首先，让我们理清术语。
Twisted 的Perspective Broker基本上是一个您可以在控制分布式操作的两端（客户端和服务器端）时使用的系统。它提供了一种将对象从一端复制到另一端并在远程对象上调用方法的方法。复制涉及将对象序列化为适合网络传输的格式，然后使用 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 could indeed replace the Twisted-specific protocol. This would allow interacting with a non-Twisted system.
I hope this proves useful to you. If you're still wondering about something (and I think you are, since this is such a large area) then I would suggest splitting things into smaller questions and posting them individually. The answers can then be more precise.