используя объект сообщения java между веб-приложениями - PullRequest
Новая
       9

используя объект сообщения java между веб-приложениями

0 голосов
/ 30 июня 2009

Я занимаюсь разработкой веб-приложения, которое выступает в качестве почтового клиента для мобильных устройств. В этом приложении пользователь может войти в систему и предоставить многочисленные идентификаторы электронной почты для мониторинга. В веб-приложении есть два основных класса. 1.MailGetter 2.MailFormatter

Поведение класса MailGetter:

  1. Запущена временная задача, которая будет выполняться каждые 10 минут
  2. Получает многочисленные идентификаторы электронной почты из базы данных, которые предоставляются для мониторинга
  3. устанавливает соединение с почтовым сервером для первого идентификатора электронной почты и получает недавно прибывший объект сообщения электронной почты
  4. передает объект сообщения классу MailFormatter

Поведение класса MailFormatter:

  1. разбирает объект сообщения электронной почты
  2. различные рекурсивные вызовы, если в сообщении есть многократный порядок для разбора частей по одной
  3. загружает также вложения вместе с этим сообщением
  4. возвращает строку xml в класс MailGetter, который будет храниться в виде простого текстового файла со следующим содержимым:

Пример: 

<mail>
<from>FromEmailID</from>
<to>ToEmailID</to>
<subject>Subject</subject>
<body>Email Body</body>
<attachments>
  attachment
</attachments>
</mail>

MobileResponderServlet: в веб-приложении также закодирован отдельный сервлет, который будет читать простой текстовый файл xml и отправлять прочитанное содержимое на мобильный телефон

Основным недостатком этого приложения может быть то, что класс «MailGetter» будет ожидать, пока все функции (включая рекурсивные вызовы) класса «MailFormatter» не завершат выполнение. Как только элемент управления возвращается из класса «MailFormatter» в класс «MailGetter» , он получит следующий почтовый объект с почтового сервера и передаст его классу «MailFormatter». Так что оповещение о новых электронных письмах мобильному пользователю требует времени. Даже когда класс «MailFormatter» реализован в виде отдельного потока, рассмотрим случай, если в одной папке входящих сообщений (для одного и того же почтового ящика) есть 1000 новых писем, которые будут вызывать 1000 потоков «MailFormatter», что сделает процесс более ресурсоемким интенсивный.

Так что я решил отключить «MailFormatter» от «MailGetter». «MailGetter» будет работать как отдельное веб-приложение на одном сервере, тогда как «MailFormatter» будет работать как отдельное веб-приложение на другом сервере. После получения последнего объекта сообщения электронной почты веб-приложение «MailGetter» сохраняет (через message.writeTo (FileOutputstream)) объект сообщения в месте, которое также является общим для «MailFormatter». Класс «MailFormatter» затем считывает (через конструктор MimeMessage (Session, InputStream)) и анализирует объект сообщения один за другим, а затем сохраняет «содержимое XML» в другом месте, которое будет прочитано «MobileResponderServlet» и отправлено на мобильный.

Будет ли этот процесс эффективным в реальном времени? Будут ли возникать проблемы, особенно при совместном использовании объектов сообщений между веб-приложениями «MailGetter» и «MailFormatter»? Пожалуйста, дайте мне знать, если есть какие-либо другие способы. Это веб-приложение будет обрабатывать более 5000 пользователей (минимум), которые предоставили многочисленные идентификаторы электронной почты для мониторинга.

1 Ответ

0 голосов
/ 30 июня 2009

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

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

Было бы неплохо сделать это повторяемым и последовательным, чтобы, реализовав свое реальное решение, вы могли изучать, становится ли оно медленнее, и / или тестировать и последовательно измерять.

...