Контейнер управляет жизнью компонента
Бизнес-компонент содержит методы, связанные с задачами приложения. Контейнер создаёт и обслуживает экземпляры, участвует в управлении транзакциями, безопасностью и зависимостями в рамках предусмотренных механизмов. Это отличается от произвольного создания обычного объекта и вызова его метода вне среды. В EJB 3.0 аннотации позволили описывать многие свойства ближе к коду и уменьшить объём обязательной инфраструктурной записи. Но удобная декларация не освобождает разработчика от понимания её значения и границ действия.
Состояние клиента определяет выбор сессионного компонента
Stateless-компонент не должен сохранять разговорное состояние определённого клиента между вызовами. Поэтому нельзя рассчитывать, что следующий запрос попадёт в тот же экземпляр с нужными значениями полей. Stateful-компонент, напротив, связан с состоянием взаимодействия конкретного клиента на протяжении нескольких обращений. Это не означает автоматического постоянного хранения в базе данных. Состояние сеанса и долговременная сохранность являются разными задачами. Для учебной архитектуры сначала определяют, какие сведения нужны между вызовами и кто ими владеет.
Обработка сообщения отличается от прямого вызова
Message-driven компонент получает работу через сообщение, а не через обычный вызов бизнес-интерфейса клиентом. Такая модель помогает отделить отправителя от момента обработки. Однако асинхронность добавляет вопросы: что делать при повторной доставке, ошибке и задержке? Получение сообщения не обязательно означает завершение всей пользовательской операции. Полезно заранее определить идентификатор действия и способ избежать нежелательных дублей. Эти вопросы относятся к устройству процесса, а не только к синтаксису аннотации.
Прикладные правила нужно сохранять явными
Предположим, компонент оформляет условную заявку. Разработчик должен определить проверки входных данных, порядок изменения состояния и поведение при сбое. Наличие контейнерной транзакции не исправляет неверное бизнес-правило. Также доступ к базе данных и объектная модель хранения требуют отдельного понимания; с поколением EJB 3.0 связан переход к упрощённой модели персистентности через Java Persistence API. При работе с историческим проектом версии спецификаций, сервера и библиотек проверяют отдельно. Старое название технологии не является готовой инструкцией установки.
Попробуйте на практике
Спроектируйте на бумаге три учебные обязанности серверного приложения без запуска сервера.
- Запишите независимую проверку заявки, многошаговый пользовательский диалог и обработку уведомления из очереди.
- Для каждой обязанности укажите, нужно ли сохранять состояние конкретного клиента между обращениями.
- Сопоставьте обязанности с общими моделями stateless, stateful и message-driven, объяснив выбор.
- Добавьте один сценарий ошибки и вопрос о том, какие гарантии даёт контейнер, а какие должен обеспечить прикладной код.
Как проверить результат. Состояние сеанса не смешано с хранением в базе, асинхронное сообщение отличено от прямого вызова, а контейнер не объявлен автоматическим решением всех ошибок.
Частые вопросы
Stateless означает, что компонент вообще не работает с данными?
Нет. Он может получать, обрабатывать и сохранять данные. Ограничение относится к ожиданию разговорного состояния конкретного клиента между вызовами.
Можно ли изучать EJB 3.0 как описание любой современной Java-среды?
Нет. Это конкретная историческая версия модели. Общие идеи полезны, но совместимость, названия пакетов и доступные возможности проверяют для выбранной среды.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.