我正在为一个个人项目做一些关于 SOAP 的研究，我遇到了一个网站，上面列出了使用 SOAP 的优缺点，我理解其中大多数的意思，除了这个缺点：
在利用 HTTP 进行传输时，SOAP 通常仅限于池，而不是事件通知。更重要的是，典型情况下只有一个客户端可以使用一台服务器的服务。
根据我对池的理解，池化 SOAP 对象以实现可重用性应该没有问题。池化只是一种反复使用相同资源的方法，例如与数据库的连接。也不完全确定事件通知的上下文。
所以我的两个问题是，上面的块引用文本实际上是什么意思，这些信息是否正确？
【问题讨论】：
标签： web-services soap
SOAP 是RPC，在 RPC 中，一些本地客户端调用某个远程目标上的方法并接收结果。它就是这样工作的，所以 SOAP 也是这样工作的。客户端调用服务请求某些东西，而服务只是响应。
如果您希望在这种类型的通信中使用“事件”，最简单的方法是更频繁地调用服务（即轮询）。这样做的好处是服务器或客户端没有任何变化。这是相同的 RPC 调用，但执行的频率更高。
如今，每个人都连接到网络，每个人都订阅了各种服务。他们希望在他们周围的世界发生任何事情时立即得到通知。在这片用户和服务的海洋中，池化变得低效，因为你在浪费资源。您可能会为了获得一个通知而轮询服务一百次。出于这个原因，技术正在不断发展，以便最大限度地减少资源使用。而这个方向是推送服务。
现在几乎所有事情都发生在浏览器中。每个浏览器制造商都急于实施最新的技术变化和 HTML5 规范。这意味着向用户推送通知而不是使用 Ajax、comet 等伪造通知的实际页面。
SOAP 早在 1998 年就出现了，它的发展速度并没有 Web 的其他部分那么快，主要是因为 SOAP 主要是一个企业参与者，而且它是一个协议。因为它是一个协议，所以您必须在不破坏该协议的情况下为其提供新技术。事情进展缓慢，因此人们放弃了 SOAP，转而采用其他方式进行服务器-客户端通信。
SOAP 通常仅限于池化，而不是事件通知...
没错。但请注意，“通常”并不意味着“总是”。
您可以举办活动，但这更难。它涉及使用WS-* specifications，如WS-Eventing 和WS-Addressing。这是 SOAP 客户端操作方式的一个变化，因为客户端现在也变成了某种服务，因为它也需要接收调用，而不仅仅是启动它们。如果您的技术堆栈实现了这些规范，那么对您有好处，但如果没有，那么您必须自己构建它，这真的很痛苦。
因此，由于这些原因，如果您没有阻塞性能或资源使用问题，您“通常”选择使用 SOAP 而不是事件通知进行轮询。
【讨论】：