Web services 发布/订阅/请求交换大型、复杂和机密数据？

我正在从事一个项目，在这个项目中，网站需要与其他系统交换复杂的、机密的、加密的数据。数据包括个人信息、技术图纸、公共文件等

我们希望避免依赖系统的请求-应答模式，因为依赖系统很多，因为这会产生大量的空流量

另一方面，我不确定纯粹的发布者/订阅者模式是否合适——主要是因为要交换的数据复杂而庞大

因此，我们讨论了发布/订阅/请求解决方案的可能性。发布/订阅部分将向相关系统发布一条消息，表明已准备好接收某些内容。然后，实际内容由旧式请求-响应操作提取

你觉得这个怎么样

问候,，

---

Morten

如果相关系统始终在线，则此方法有效-您无法向晚上/周末关闭的PC发送消息

因此，如果客户机是全天候运行的服务器，那么这是可行的。否则，请尝试以下方法：

让客户自己注册 当新文档出现时，添加一个条目客户端X需要在数据库中看到它 当客户端连接时，向它们发送所有条目。 当客户端成功下载文档时，删除客户端X需要查看此条目。这使得工作台很小。 这有几个优点：

客户不需要全天候运行 只有在客户端看到文档后，才会删除该标志，因此不会丢失任何更新。 你可以在一个地方看到哪个客户从未提取过它的文档。一个简单的选择客户机，count*group by client，count*>10，告诉您有关问题。 大多数客户机将及时获取数据，因此工作表将保持较小。这意味着，当您必须收集what's now数据时，开销很小。

---

编辑离线订阅者的问题是他们不知道他们错过了什么。因此，发送端需要跟踪失败的推/拉请求。这意味着您必须实现我建议的伪代码，以确保断开的连接可以恢复。

如果系统始终在线，听起来不错

您可能需要查看，因为： 1.不要解决已经解决的问题。它是可伸缩的，代表了良好的关注点分离

它涉及三方：

出版东西的出版商 对某些出版物感兴趣的订阅者 调解并消除“投票”的中心 其工作方式如下：

订阅者，向中心注册他们对URL的兴趣，并提供回调URL。 发布者在发布内容时通知中心。 集线器获取“增量”并将其推送到感兴趣的订阅者。 协议本身是Atom的扩展，但它似乎符合您的要求，例如，新Atom“内容”可以是一个包含新发布文档URL的项目，然后可以单独下载

---

新建/修改的文档=>提要中包含获取它们的URL的新建/修改的项目=>Hub=>Subscribers=>Pull documents from Publisher

我对此没有很好的经验，但消息队列应该可以帮助您完成所需的任务。我使用这样一个系统，同时管理从后端向多个前端客户端发布数据

---

如果客户机处于关闭状态，则数据不会被消耗，服务器也不会收到任何关于正在恢复数据的确认。一旦客户机重新联机，他将使用数据并继续侦听更多消息，队列将清除。而ofc则是发布者接收到一个正在使用的数据的ack。通过这种方式，我们可以识别并通知接收端有问题的人员，作为奖励。在您的情况下，这可以做到吗？

因此，订阅者会轮询中央消息存储，查看是否有自己的消息？如果有，他们会请求吗？@henginy，没有。订阅者从商店收到一条消息，说可以取东西。这样可以避免所有的空轮询。@Aron，我假设我描述的解决方案应该支持离线订户。怎么不呢？：-MortenLike我刚刚写信给Aron：我假设我描述的解决方案应该支持离线订户。怎么不呢？：-MortenSo，在您描述的设计中，如果订阅服务器关闭，发布通知会发生什么情况？我猜计划是：发布者每隔一段时间重试失败的通知？这与反过来的“轮询”几乎相同。所以不用投票的优势已经消失了，对吧？因此，除非所涉及的服务通常都是“上升”的，否则这种方法就失去了它的优势。确切地说：-所有服务通常应该上升95%以上。但我不能百分之百地假设。那么这是一个合理的设计。如果消息失败，您将重试，因为通常服务已启动，f

---

疾病并不常见，所以重试也可以。在我看来，一切都是平静而美好的。所以不管怎样，我的回答只是想建议一种合理的标准方式来做你所做的事情，而不是从头开始设计。事实上，所涉及的服务总是在线的，这就是为什么我觉得它最适合您的要求。我们谈论的不是服务器对pc，而是服务器对服务器的通信。