Введение в J2EE. Что такое платформа Java 2 Enterprise Edition. Краткая история J2EE. Зачем нужна J2EE, страница 5

Компоненты EJB

Спецификация EJB находится в самом сердце платформы J2EE. Она определяет обширную модель компонентов для построения масштабируемых, распределенных серверных компонентов для программных систем предприятия на Java. Существует три типа компонентов EJB.

·  Сеансовые компоненты (session beans) лучше всего применять для переходных функций. Эти компоненты не сохраняются долго и часто образуют большую часть логики приложения в программной системе предприятия на языке Java. Сеансовые компоненты могут поддерживать состояния (stateful) — это означает, что они сохраняют соединение с клиентом в перерывах между последовательными транзакциями. Компоненты другого типа не имеют состояний (stateless). В последнем случае каждое последующее обращение сеансового компонента к тому же клиенту рассматривается как новая, не связанная с другими операция.

·  Компоненты-сущности (entity beans) инкапсулируют постоянные данные в хранилище данных, которое обычно представляет собой полную или частичную запись базы данных. Они имеют автоматизированные функции обеспечения синхронности объектного представления этих постоянно хранимых данных с фактическими данными в базе. Компоненты-сущности также часто применяются для форматирования постоянно хранимых данных, либо для содействия логике приложения, либо для подготовки данных для отображения на Web-странице. Например, в таблице базы данных сотрудников каждая запись может отображаться на экземпляр компонента-сущности.

·  Компоненты, управляемые сообщениями (message-driven beans) разработаны как удобные в использовании приемники асинхронных сообщений Java Message Service (JMS). В отличие от сеансовых компонентов и компонентов-сущностей, компоненты, управляемые сообщениями, не имеют открытых интерфейсов. Они работают анонимно и скрыто. Управляемые сообщениями компоненты не имеют состояний и представляют собой новый тип компонентов, впервые определенный в J2EE 1.3.

Для понимания взаимоотношений и взаимодействия этих разных технологий J2EE может пригодиться архитектура "модель-вид-контроллер" (Model-View-Controller — MVC), которая когда-то использовалась в языке программирования Smalltalk. Для тех, кто незнаком с архитектурой MVC, достаточно знать, что ее главная идея состоит в том, чтобы свести к минимуму связи между объектами системы путем их классификации по определенным наборам обязанностей. Такие обязанности связаны с тремя областями: постоянно хранимых данных и правил доступа к ним (модель), представления (вид) и логики I приложения (контроллер). Этот подход показан на рис. 2.4.

Модель отвечает за сохранение состояния и данных приложения. Она может получать запросы от вида и отвечать на них, а также сообщать виду об изменениях в своем состоянии.

Контроллер обновляет модель, руководствуясь логикой приложения и в ответ на действия пользователя (например, нажатие кнопок диалога, отправку формы и т.д.). Он также | сообщает виду, что именно надо отобразить в ответ на действия пользователя.

Вид отвечает фактическое отображение данных, предоставленных контроллером.

Для примера рассмотрим простое приложение-часы, разработанное с использованием I архитектуры MVC. Модель в этом случае отвечает за измерение времени. Некоторые I встроенные механизмы модели автоматически обновляют значение времени через зара-1 нее заданные интервалы (микросекунду, миллисекунду или другой период). Кроме того, I модель имеет функцию, которая сообщает текущее время в ответ на запросы других объектов, но сама модель не занимается отображением времени и не знает, как это делается.

Обязанность по отображению времени лежит на виде; в то же время вид может принимать различные формы. Например, время может отображаться на аналоговом циферблате с помощью двух или трех стрелок. Также время может быть представлено в виде отдельных цифр. Когда значение времени изменяется, модель сообщает об этом виду, и вид соответственно изменяет отображение.