Java EE и серверы приложений - что я могу сделать?

Question

Я решил, что мне пора копаться во всем, что касается Java EE. Я использую некоторые методы EE в Java SE, такие как JPA или JMS, но я все еще возиться с Java SE, и я верю, что Java EE и сервер приложений решат некоторые из моих проблем.

НО: у меня все еще есть вопросы после прочтения некоторых статей в Интернете.

1-й: ограничен ли я приложениями запрос-ответ? У меня есть приложение, которое обслуживает документы XML через HTTP. Все доставленные объекты добавляются в очередь, которая будет отправлена ​​в другом потоке. Для этого объекта была проведена некоторая проверка, в том числе открытие сокетов на удаленной машине (я слышал, что EJ-компонентам не разрешается делать это, правда?). Итак, возможно ли сделать это на сервере приложений?

2-й: я знаю, что есть объекты, управляемые сообщениями, возможно ли отправлять сообщения JMS на MDB извне сервера приложений? У меня есть служба, которая отправляет сообщения JMS, но работает как устаревшая система, а не на одном сервере приложений.

3-й: Как системный администратор или пользователь могут настроить мое приложение? Я знаю, что некоторые вещи, такие как соединения с базой данных, настроены на сервере приложений, и мое приложение может искать их через JNDI или получать их через DI. Но как насчет конкретной конфигурации приложения?

Да, это довольно нудистские вопросы, но, возможно, у кого-то есть время, чтобы объяснить мне, как все это работает. :)

С уважением, Posix

PS:

4-е: кажется, что EJB-компонентам не разрешено ничего делать с файлами, поэтому Java EE, похоже, не подходит для Службы, которая получает файлы, передает их в другие системы и хочет, чтобы они записывали в Socket (см. Вопрос 1). )

Answer 1

Я могу сказать, что Java EE может использоваться без каких-либо сомнений в вашем случае. Позвольте мне подробнее рассказать о ваших конкретных вопросах:

1. Вы можете открыть сокетное соединение с вашего EJB. Ничто не мешает вам сделать это. Однако этот вид операций не рекомендуется для приложений Java EE. На мой взгляд, лучшим вариантом является реализация Java EE Connector (JCA), который бы управлял пулом соединений сокетов с вашей проприетарной системой. Это модельный способ реализации такой интеграции в соответствии со спецификацией.

2. Да! Вполне возможно получать сообщения, отправленные из внешнего приложения / системы (вне AS). Это основная идея интеграции с использованием обмена сообщениями :) Во многих случаях ваше приложение, являющееся приложением Java EE, получает сообщения через MDB из канала JMS, но JMS является только API и может быть реализовано любой системой обмена сообщениями, например, IBM MQ. В этой архитектуре внешняя система помещает сообщение MQ в очередь, а ваше приложение Java EE, которое прослушивает саму очередь, получает сообщение через JMS API!

3. Вообще говоря, Application Server предоставляет Администратору отличные инструменты для управления ресурсами Java EE, такими как источники данных, фабрики соединений JMS, места назначения JMS, диспетчер транзакций JTA и т. Д. Если вам требуется возможность изменить ваше конкретное приложение Java EE, Лучшие варианты, кажется, JMX. Просто внедрите несколько MBean-компонентов, экспортируйте их на сервер JMX, встроенный в ваш сервер приложений, и все готово. Эта задача действительно тривиальна, скажем, в JBoss, но большинство современных серверов приложений в настоящее время предлагают широкие возможности JMX.

4. На первый взгляд EJB не кажется лучшим для работы с файлами. Но помните, что реализация ваших EJB-компонентов все еще написана на чистом Java, поэтому ничто не мешает вам читать / передавать файлы и так далее. У меня есть опыт работы с большими приложениями Java EE, которые обрабатывают большие файлы как входные файлы и могут заверить вас, что Java EE - хороший выбор технологии:)

Answer 2

1. На сервере приложений, таком как Tomcat (возможно, и другие, но я никогда с ними не работал), вы можете не только выполнять действия при получении запроса, но и выполнять какие-либо действия (включая запуск долго работающих потоков) при запуске сервера. По сути, вы можете делать все, что можете с «нормальной» Java. Фактически, вы можете поместить обычное Java-приложение на сервер приложений, если просто включите фрагмент кода, который вызывает соответствующий метод main () при запуске сервера.

Answer 3

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

1. В контексте EE вы добавляете сообщения в очередь JMS, в которой есть MDB, которые будут выполнять фактическую обработку. Что касается управления жизненным циклом HTTP-запросов / ответов, вы бы управляли этим так же, как сейчас, или использовали бы существующую библиотеку, если это для вас. Перейдя на сервер приложений EE, вы позволите серверу приложений управлять потоками, транзакциями и т. Д. Вместо того, чтобы управлять им вручную.

2. Как указано Даффимо, MDB отвечают за прием сообщений, им все равно, откуда пришло сообщение.

3. Системный администратор может настроить сервер приложений, как указано в duffymo. Кроме того, вы можете предоставлять компоненты JMX другим системам или конечному пользователю, чтобы они могли настраивать службы по вашему желанию.

Answer 4

4. Это нарушение спецификации EE, что-либо делать с файлами (чтобы приложение EE было переносимым и распространяемым). Однако, поскольку это всего лишь простой Java-код, yopu может делать все, что угодно. Пока вы знаете, как выглядит ваша целевая среда (например, система предназначена для внутреннего использования), я бы не колебался при изменении файлов только потому, что в спецификации так сказано.

Answer 5

Здесь - ограничения по спецификации EJB 1.1.

Вот мой ответ на ваши вопросы:

1. Я полагаю, что EJB может открыть сокет на удаленной машине, но я бы сказал, что открытие сокетов - это слишком низкая операция. Я бы подумал о том, чтобы показать, что этот сокет делает для тебя, как другой EJB.
2. MDB - это просто слушатель, зарегистрированный в определенной теме или очереди. Это ничего не говорит об отправке. Если ваш клиент знает, как доставить сообщение в очередь, это возможно. Они просто должны знать URL-адрес очереди и иметь возможность создать соединение.
3. Администратор устанавливает пулы соединений, имена JNDI и т. Д. - все. Они делают это, используя консоль администратора для сервера приложений.