Как получить электронную почту в приложении Java EE - PullRequest
14 голосов
/ 15 апреля 2010

Очевидно, что отправлять электронные письма из приложения Java EE через JavaMail не так сложно. Что меня интересует, так это лучший шаблон для получения электронных писем (в основном, отказов уведомлений)? Меня не интересуют подходы, основанные на IMAP / POP3 (опрос входящих сообщений) - мое приложение должно реагировать на входящие электронные письма.

Один из подходов, который я мог бы придумать, был бы

  • Сохранить существующий MTA (в моем случае postfix на linux) -> ops команда уже знает, как его настроить / использовать
  • Для каждого приходящего письма порождает приложение Java, которое получает данные и отправляет их через JMS. Я мог бы сделать это с помощью записи в / etc / aliases, например myuser: "|/path/to/javahelper", при этом javahelper вызывает приложение Java, передавая STDIN.
  • MDB (часть приложения Java EE) получает сообщение JMS, анализирует его, обнаруживает сообщение о сбое и действует соответствующим образом.

Другой подход может быть

  • Откройте прослушивающий сетевой сокет на порту 25 в контейнере приложения Java EE.
  • Свяжите SessionBean с сокетом. Бин является частью приложения Java EE и может непосредственно анализировать / обнаруживать отскок / обрабатывать сообщения.
  • Сохраните существующий MTA в качестве входящего ретранслятора, выполните всю его защиту / фильтрацию спама, но перешлите электронные письма на myuser (который проходит фильтр) в контейнер приложения Java EE, порт 25.

Первый подход, который я сделал раньше (хотя и на другом языке / в настройке).

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

Какая ваша рекомендация? У вас есть детали о втором подходе?

Ответы [ 5 ]

8 голосов
/ 15 апреля 2010

Я не думаю, что второй подход "чище". Напротив, для этого требуется, чтобы вы внедрили значительную часть стандартного MTA, поэтому я бы рекомендовал против этого.

Я считаю, что опрос POP / IMAP-сервера на самом деле является самым чистым способом сделать это. Почему вы решили против этого? Если сервер POP / IMAP и ваш сервис находятся в одной локальной сети (или даже на одной и той же машине), опрос будет довольно недорогим. Вы можете делать это каждые 10-20 секунд для минимальной задержки, которая не должна вызывать проблем. Хотя это может показаться немного технически неэффективным, вы будете использовать стандартный протокол взаимодействия (POP3 / IMAP), который дает вам гибкость, избегая повторной реализации почтового сервера.

Подход порождения Java-приложения также кажется жизнеспособным, но я бы предпочел опрос, потому что:

a) Используемый вами интерфейс (POP3 / IMAP) более стандартизирован, в то время как интерфейс, который вы используете для «подключения» к почтовому серверу, будет зависеть от сервера (в Unix вы можете использовать, например, procmail, но вы все равно зависит от конкретного программного обеспечения)

b) Запуск отдельного процесса по почте, вероятно, будет иметь гораздо больше накладных расходов, чем опрос.

Между прочим: Третий подход заключается в том, чтобы каким-то образом сбросить входящие письма в виде файлов во «входящий» каталог (многие почтовые серверы могут сделать это), а затем опросить каталог. Опрос каталога будет даже дешевле, чем опрос сервера. Просто остерегайтесь проблем с синхронизацией (чтение наполовину написанной почты, несколько одновременных читателей, читающих один и тот же файл почты ...)

Мой опыт:

Я реализовал системы с использованием обоих подходов (опрос IMAP и создание отдельного процесса). Опрос проводился для довольно большого Java-приложения, которое обрабатывало данные, которые люди отправляли в почтовый ящик; У меня не возникло проблем с опросом. Нерестовый подход был для небольшого сценария Perl; Я просто сделал это, поскольку это была простая программа, которая обрабатывала только несколько писем в день, и подключиться к почтовому серверу было проще, чем выполнять IMAP в Perl.

7 голосов
/ 24 июня 2010

«Правильный» способ в соответствии с архитектурой Java EE состоит в том, чтобы иметь соединитель JCA для выполнения входящего / исходящего соединения с SMTP-сервером.

Разъем JCA может делать все что угодно, включая многопоточность и подключение к внешним системам с помощью разъемов. На самом деле JMS - это просто особый тип JCA-коннектора, который подключается к JMS-брокеру и доставляет сообщение «обычному» MDB. Затем JCA-соединитель может опросить SMTP-сервер и доставить сообщение в пользовательский MDB.

Лучшим документом о JCA является Создание адаптеров ресурсов с J2EE Connector Architecture 1.5 , и он действительно использует пример доставки электронной почты. Удачи тебе :) Предлагаю тебе взглянуть на это. Код можно найти как часть примеров Java EE и использует JavaMail, но я не знаю, готов ли он к работе.

Похожие:

4 голосов
/ 11 декабря 2011

Возможно SubEtha SMTP [править: теперь перенесено из Google Code в GitHub ] - интерес представляет библиотека Java, которая позволяет вашему приложению получать SMTP почту. Я собираюсь попробовать это.

Вот несколько связанный вопрос переполнения стека (и кто-то предлагает SubEthaSMP):
Какой самый простой способ для приложения Java получать входящую электронную почту?

3 голосов
/ 26 июля 2011

А как насчет Apache James?

он реализует весь стек и позволяет вам реагировать на входящую почту с помощью сервлет-подобного подхода; Он имеет открытый исходный код, полностью лицензирован Apache (поэтому может использоваться в коммерческих продуктах) и уже проверен годами.

2 голосов
/ 11 июля 2010

Использование ESB - автономно или встраиваемо.

"ESB привносит связанные с потоком концепции, такие как преобразование и маршрутизацию, в сервис-ориентированную архитектуру. ESB также может предоставлять абстракцию для конечных точек. Это способствует гибкости на транспортном уровне и обеспечивает слабую связь и простое соединение между службами. «

Например МУЛЬ «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"/>
...