我正在使用Java EWS API将我的应用程序连接到MS Exchange并读取用户电子邮件请求。然后，通过系统工作流处理这些请求。一天中的电子邮件数量限制为50，因此总体积较小。但是，我正在寻找一种使用EWS API从Exchange服务器读取的高效可靠的机制。另请注意，处理完电子邮件后，我们会将其移至子文件夹，以便收件箱仅包含未处理的请求
目前我了解以下方案用于连接到Exchange服务器并对邮箱执行各种操作。
轮询 - 使用标准Exchange服务接口连接到Exchange;找到所有新电子邮件并按顺序处理它们。客户端可以更好地控制读取和移动到已处理文件夹之间的故障和同步。在不利方面，经验不是实时的，即使没有任何活动，也可以进行交流。
拉取通知 - 此方法与之前的方法几乎相同，使用间隔订阅拉取通知，并在发生计时器事件时从Inbox读取电子邮件。优点与缺点类似于方法1.
推送通知 - 此处客户端通过将自己注册到特定事件来订阅交换服务器以接收推送通知，并定义用于接收通知的回调机制（客户端Web服务）。在好的情况下，通知几乎是实时的，只有在有事件时才会建立连接。在缺点方面，我看到需要在客户端管理订阅和水印，以便不会丢失事件。不确定这是否仍然是一种可靠的方法，因为在建立订阅之前已经在收件箱中的消息会发生什么;服务器启动时会重播这些事件吗？目前尚不清楚。
流式订阅 - 客户端建立流式连接，然后使用服务器保持打开最多30分钟，在此期间，Exchange将通知任何已注册的事件。一旦连接断开，就有能力恢复它，以便订阅保持活跃状态。在我开始听到同步文件夹项目并保持同步状态的其他步骤之前，这似乎是最好的方法;需要定期，以便连接/断开连接不会遗漏事件。
查看我的需求（可靠地阅读来自Exchange服务器的电子邮件）和各种选项的分析我认为方法1简单且更可靠，因为它可以更好地控制整个过程。但与此同时，如果我对框架的利弊理解错误，我想与其他熟悉API的人一起纠正我。
我愿意接受小组提出的任何建议，以便做到更好，因为我们的目的是不要错过任何电子邮件。
答案 0 :(得分：0)
我会考虑选项1的代码简单性。如果你每分钟连接一次，那么负载非常低（只是一个FindItem调用没有返回任何内容），用户几乎可以立即体验它。
你最多只能每天处理50个，所以“瞬间”的愿望有点矛盾（如果用户只进行了很多更新，他肯定可以等一下）。