SOAP Pooling的优点/缺点

Question

我正在做一些关于SOAP的研究，对于一个个人项目，我遇到了一个网站，列出了使用SOAP的优缺点，我明白了其中大部分意思，除了这个一个处于劣势：

当利用HTTP进行传输时，SOAP通常仅限于池化，而不是事件通知。更重要的是，在典型情况下，只有一个客户端可以使用一台服务器的服务。

根据我对池的理解，应该没有问题汇集SOAP对象的可用性。池化只是反复使用相同资源的一种方式，就像连接数据库一样。在事件通知的上下文中也不完全确定。

所以我的两个问题是，上面的块引用文本实际上是什么意思，并且这个信息是正确的？

网站：http://searchsoa.techtarget.com/definition/SOAP

Answer 1

SOAP是RPC，并且在某些RPC本地客户机调用某些远程目标的方法和接收的结果。这就是它的工作原理，所以SOAP也是如此。一个客户调用一个服务请求一些东西，这个服务只是响应。

如果你想在这种类型的通信中使用“事件”，最简单的方法就是经常调用服务（即轮询）。这具有服务器或客户端没有任何变化的优点。这是相同的RPC调用，但更频繁地完成。

现在每个人都连接到网络，每个人都订阅了各种服务。他们希望在周围的世界发生一些事情时立即得到通知。在用户和服务的海洋中，共享池变得效率低下，因为您正在浪费资源。您可能需要百次查询服务才能获取一个通知。出于这个原因，技术正在不断发展，使资源使用最小化。而这个转向的方向是推送服务。

现在几乎所有事情都发生在浏览器中。每个浏览器制造商都急于实施最新的技术变更和HTML5规范。这意味着将通知推送给用户的实际页面，而不是用Ajax，彗星等伪造它。

SOAP自1998年以来一直存在，其速度并未像网络其他部分那样快，主要因为SOAP主要是企业播放器，因为它是一个协议。因为这是一个协议，你必须在不违反协议的情况下使新技术可用。事情发展缓慢，因此人们放弃了SOAP，转而采用其他方式进行服务器 - 客户端通信。

SOAP一般仅限于池，而不是事件通知...

这是正确的。但请注意，“典型”并不意味着“永远”。

你可以有事件，但它很难。它涉及使用WS-* specifications，如WS-Eventing和WS-Addressing。这是SOAP客户端操作方式的改变，因为客户端现在也变成某种服务，因为它也需要接收调用，而不仅仅是启动它们。如果你的技术堆栈实现了这些规范，那么对你来说很好，但如果它没有，那么你必须自己构建它，这是一个真正的痛苦。

因此，出于这些原因，如果您没有阻止性能或资源使用问题，您“通常”选择使用SOAP进行轮询而不是事件通知。