Java EWS API - Прочтите письмо из обмена - Сравнимые параметры

Question

Я использую Java EWS API для подключения своего приложения к MS Exchange и чтения запросов электронной почты пользователей. Эти запросы затем обрабатываются через рабочий процесс системы. Количество писем в день ограничено 50, поэтому общий объем меньше. Однако я рассматриваю эффективный и надежный механизм для чтения с сервера Exchange с использованием EWS API. Также обратите внимание, что после обработки электронной почты мы перемещаем его в подпапки, поэтому Inbox имеет только необработанные запросы

В настоящее время, насколько я понимаю, для подключения к серверу Exchange и выполнения различных операций с почтовым ящиком используются следующие схемы.

1. Опрос - подключение к Exchange с использованием стандартного интерфейса Exchange Service; найти все новые письма и обработать их в последовательности. Клиент лучше контролирует сбои и синхронизацию между чтениями и переходом на обработанные папки. С другой стороны, опыт не в режиме реального времени, а связи используются для обмена, даже если нет никакой активности.

2. Pull Notifications - этот метод почти идентичен предыдущему, подпишитесь на получение уведомлений с использованием интервала и прочитайте электронные письма из папки «Входящие» всякий раз, когда происходит событие таймера. Плюсы и минусы сходны с подходом 1.

3. Push Notifications - здесь клиенты подписываются на сервер обмена для получения push-уведомлений, регистрируясь на определенные события и определяя механизм обратного вызова (Клиентский веб-сервис) для получения уведомлений. В верхней части уведомления находятся в режиме реального времени, а соединения выполняются только при наличии событий. С другой стороны, я вижу, что подписи и водяные знаки необходимо управлять на стороне клиента, чтобы события не были потеряны. Не уверен, что это по-прежнему надежный подход, как то, что происходит с сообщениями, которые уже находятся в папке «Входящие», прежде чем устанавливать подписку; будут ли эти события воспроизводиться при запуске сервера? Не ясно.

4. Потоковая подписка. Клиенты устанавливают потоковое соединение, а затем сохраняют его открытым в течение максимум 30 минут с сервером, и в течение этого времени обмен будет уведомлять о любых зарегистрированных событиях. Как только соединение умирает, есть возможность восстановить его, чтобы подписка оставалась живой. Это было похоже на лучший подход, пока я не начал слышать, что дополнительные шаги для синхронизации элементов папок и поддержания состояния синхронизации; требуется через равные промежутки времени, чтобы события не пропускались от соединения/разъединения.

Глядя на моих потребностях (читать электронную почту от сервера обмена надежно) и анализ различных вариантов я считаю, что подход 1 является простым и более надежным, поскольку это дает лучший контроль над всем процессом. Но в то же время я хотел пообщаться с другими, которые знакомы с API, чтобы исправить меня, если мое понимание структуры с точки зрения плюсов и минусов неверно.

Я открыт для любых предложений группы, чтобы сделать это лучше, поскольку цель состоит в том, чтобы не пропустить ни одного письма.

Answer 1

Я бы выбрал код простоты варианта 1. Если вы подключаетесь один раз в минуту, загрузка очень низкая (просто вызов FindItem не возвращает ничего), и пользователи испытывают это как почти мгновенное.

Вы обрабатываете максимум 50 дней в день, поэтому желание быть «мгновенным» является немного противоречивым (если пользователь делает только это много обновлений, он наверняка может подождать минуту).