EWS:流通知与推送通知

Question

Microsoft Exchange引入了流式通知作为使用Exchange 2010的拉/推通知的替代方案.有关流式传输的基本介绍可以在这篇msdn文章和博客上找到

但是,我无法弄清楚流式传输推送通知的实际优势.博客中提到的唯一优势是"..而且您不必像推送通知那样创建一个监听器应用程序." 除此之外,还有其他优点和缺点吗？管理订阅,重新订阅逻辑,可扩展性,最大订阅数量等其他因素如何比较推送？此外,Streaming订阅的最长活动时间为30分钟,我必须每30分钟重新订阅一次？不是大量订阅的缺点(我的应用程序必须管理20K +邮箱)？

对比较因素的任何启示都会有所帮助.

Answer 1

流式传输通知(SN)的主要原因是Exchange Online.您不能让EOL打开与可能位于防火墙后面的应用程序的HTTP连接.即使在企业网络中也存在防火墙问题.我有几个案例,我的应用程序无法获得推送通知(PN),因为它自己的服务器上的防火墙.

从表面上看,SN似乎也更有效,因为每个通知都没有打开自己的TCP连接,而是在一个管道上流入.在对此进行一些Wiresharking之后,我并不是真的相信这是因为它看起来像是在进行长轮询,所以每次进入的通知都会导致新的HTTP回调到Exchange.

30分钟的最大值没什么大不了的,只需在处理程序中重新打开连接就可以了 - 你不需要实际重新订阅.事实上,我认为我想降低甚至更多说3分钟.您显然无法添加新订阅或删除旧订阅,除非在断开连接处理程序中.(试试看,你会收到错误.)

是的,您不必编写HTTP处理程序,我猜这很好.