我正在做一些关于SOAP的研究，对于个人项目，我遇到了一个网站，其中列出了使用SOAP的优缺点，我理解其中大部分含义，除了这个缺点：< / p>
当利用HTTP进行传输时，SOAP通常仅限于池，而不是事件通知。而且，在典型情况下，只有一个客户端可以使用一台服务器的服务。
根据我对池的理解，应该没有问题汇集SOAP对象以实现可用性。池化只是一种反复使用相同资源的方式，例如与数据库的连接。在事件通知的上下文中也不完全确定。
所以我的两个问题是，上面的块引用文本实际意味着什么，这个信息是否正确？
答案 0 :(得分：1)
SOAP是RPC，在RPC中，一些本地客户端在某个远程目标上调用方法并接收结果。这就是它的工作原理，所以SOAP也是如此。客户端调用服务请求某些内容，服务只响应。
如果您想在此类通信中使用“事件”，最简单的方法是更频繁地调用服务（即轮询）。这样做的好处是服务器或客户端没有任何变化。它是相同的RPC调用，但更频繁地完成。
现在每个人都与网络连接，每个人都订阅了各种服务。他们希望在周围世界发生某些事情时立即得到通知。在这个用户和服务的海洋中，池化效率低下，因为您浪费资源。您可以轮询一百次服务，只是为了取回一个通知。出于这个原因，技术正在发展，以便最大限度地减少资源使用。而这个转变的方向是推送服务。
现在几乎所有事情都发生在浏览器中。每个浏览器制造商都急于实施最新的技术变更和HTML5规范。这意味着将通知推送给用户而不是使用Ajax，comet等伪装的实际页面。
SOAP自1998年以来一直存在，它的移动速度不如网络的其他部分，主要是因为SOAP主要是企业级播放器，因为它是一种协议。因为它是一种协议，所以你必须在不违反协议的情况下使用新技术。事情进展缓慢，因此人们放弃了SOAP，转而采用其他方式进行服务器 - 客户端通信。
SOAP通常仅限于池化，而不是事件通知......
这是正确的。但要注意“通常”并不意味着“永远”。
你可以举办活动，但这更难。它涉及使用WS-* specifications和WS-Eventing等WS-Addressing。这是SOAP客户端运行方式的变化，因为客户端现在也成为某种服务，因为它也需要接收呼叫，而不仅仅是启动它们。如果你的技术堆栈实现了这些规范然后对你有好处，但如果没有，那么你必须自己构建它并且这是一个真正的痛苦。
因此，出于这些原因，如果您没有阻塞性能或资源使用问题，则“通常”选择使用SOAP进行轮询而不是事件通知。