Как получать электронную почту в приложении Java EE
Очевидно, что не так сложно отправлять электронные письма из приложения Java EE через JavaMail. Меня интересует лучшая модель для получения электронных писем (в основном, отскакивание уведомлений)? Меня не интересуют подходы, основанные на IMAP/POP3 (опрос почтовых ящиков) - мое приложение будет реагировать на входящие письма.
Один из подходов, о котором я мог думать, будет
- Сохранять существующий MTA (постфикс на linux в моем случае) → команда ops уже знает, как настроить/управлять им.
- Для каждой полученной почты создайте приложение Java, которое получает данные и отправляет его через JMS. Я мог бы сделать это через запись в /etc/aliases вроде
myuser: "|/path/to/javahelper"
с javahelper, вызывающим Java-приложение, передавая STDIN вместе.
- MDB (часть приложения Java EE) получает сообщение JMS, анализирует его, обнаруживает сообщение отказов и действует соответствующим образом.
Другим подходом может быть
- Откройте сетевой разъем прослушивания на порту 25 в контейнере приложений Java EE.
- Свяжите SessionBean с сокетом. Bean является частью приложения Java EE и может анализировать/обнаруживать отказы/обрабатывать сообщения напрямую.
- Сохранять существующий MTA в качестве входящего реле, выполнять всю его фильтрацию защиты/спама, но пересылать письма на
myuser
(которые проходят фильтр) в контейнер приложения Java EE, порт 25.
Первый подход, который я сделал раньше (хотя и на другом языке/настройке).
С точки зрения производительности и (воспринимаемой) чистоты, я думаю, что второй подход лучше, но мне потребовалось бы обеспечить надлежащую реализацию транспорта SMTP. Кроме того, я не знаю, можно ли вообще подключить сетевой сокет с помощью bean...
Какова ваша рекомендация? У вас есть детали о втором подходе?
Ответы
Ответ 1
Я не думаю, что второй подход "чище". Напротив, он требует, чтобы вы реализовали значительную часть стандартного MTA, поэтому я бы рекомендовал против него.
Я считаю, что опрос сервера POP/IMAP на самом деле является самым чистым способом сделать это. Почему вы решили против этого? Если сервер POP/IMAP и ваша служба находятся в одной и той же локальной сети (или даже при одной и той же обработке), опрос будет довольно недорогим. Вы можете делать это каждые 10-20 с за минимальную задержку, что не должно вызывать проблем. Хотя это может выглядеть немного технически неэлегантно, вы будете использовать стандартный протокол взаимодействия (POP3/IMAP), который дает вам гибкость, избегая повторной реализации почтового сервера.
Подход к созданию Java-приложения также кажется жизнеспособным, но я бы предпочел опрос, потому что:
a) Используемый вами интерфейс (POP3/IMAP) более стандартизирован, а интерфейс, который вы используете для "подключения" к почтовому серверу, зависит от сервера (в Unix вы можете использовать, например, procmail, но вы все равно зависят от конкретного программного обеспечения)
b) Запуск отдельного процесса на почту, вероятно, будет намного больше накладных расходов, чем опрос.
Кстати. Третий подход состоял бы в том, чтобы каким-то образом выгрузить входящие письма как файлы в "входящий" каталог (многие почтовые серверы могут это сделать), а затем опросить каталог. Опрос каталога будет еще менее дорогим, чем опрос сервера. Просто остерегайтесь проблем синхронизации (чтение полузаписей почты, нескольких одновременных читателей, читающих один и тот же почтовый файл...)
Мой опыт:
Я реализовал системы с использованием обоих подходов (опрос IMAP и создание отдельного процесса). Опрос был для достаточно большого приложения Java, которое обрабатывало данные, отправленные людьми в почтовый ящик; У меня не возникало проблем с опросом. Подход нереста был для небольшого Perl script; Я просто сделал это, потому что это была простая программа, которая обрабатывала только несколько писем в день, а подключаться к почтовому серверу было проще, чем делать IMAP в Perl.
Ответ 2
"Правильный" способ в соответствии с архитектурой Java EE должен состоять в том, чтобы соединитель JCA выполнял входящее/исходящее соединение с SMTP-сервером.
Разъем JCA может делать все, что вам нужно, включая потоки и подключение к внешним системам с разъемами. На самом деле JMS - это особый вид JCA-коннектора, который подключается к JMS-брокеру и доставляет сообщение в "обычный" MDB. Разъем JCA затем может опросить SMTP-сервер и доставляет сообщение в пользовательский MDB.
Лучший документ о JCA Создание адаптеров ресурсов с J2EE Connector Architecture 1.5, и на самом деле он использует пример доставки электронной почты. Удачи вам. Я предлагаю вам взглянуть на него. Код может быть найден как часть образцов Java EE и использует JavaMail, но я не знаю, готова ли его подготовка.
Связанный:
Ответ 3
Возможно SubEtha SMTP [edit: теперь переведен из Google Code в GitHub] - это библиотека Java, которая позволяет вашему приложению получать почту SMTP. Я собираюсь попробовать.
Вот несколько связанных вопросов (и кто-то предлагает SubEthaSMP):
Какой самый простой способ для приложения Java получать входящую электронную почту?
Ответ 4
А как насчет Апача Джеймса?
он реализует весь стек и позволяет вам реагировать на входящую почту с помощью сервлет-подобного подхода; он с открытым исходным кодом, полностью лицензированный apache (поэтому его можно использовать в коммерческих продуктах) и уже тестировался в течение многих лет.
Ответ 5
Использование ESB - автономного или встроенного.
"ESB предоставляет концепции, связанные с потоком, такие как преобразование и маршрутизация в сервис-ориентированную архитектуру. ESB также может обеспечивать абстракцию для конечных точек, что способствует гибкости в транспортном уровне и обеспечивает свободное соединение и простое соединение между службами."
Например MULE
"Mule ESB является наиболее широко используемым ESB с открытым исходным кодом. Легкая платформа интеграции и контейнер обслуживания Mule ESB предоставляет функции для веб-сервисов, маршрутизации сообщений, медиации, трансформации и управления транзакциями, помогая разработчикам интегрировать свои приложения в часы, а не в недели"
Как получать письма через мул
http://books.dzone.com/articles/mule-messaging-chapter?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fsoa+(SOA+Zone)
Ниже приведена просто конфигурация, отправляющая сообщение JMS как реакция на полученное сообщение (это все, что вам нужно) - определить входящий (imap/pop3/etc) - определить исходящий.
<imap:inbound-endpoint user="bob" password="password" host="localhost" port="65433" checkFrequency="3000"/>
<jms:outbound-endpoint queue="my.destination" connector-ref="jmsQueueConnector"/>