Message Driven Beans (mdb), жизненный цикл компонентов. Особенности применения и функционирования, реализующие методы (примеры).
Компоненты, управляемые сообщениями (Message Driven Beans, MDB),–это не имеющие состояния, серверные компоненты для обработки асинхронных сообщений JMS, поддерживающие транзакции.
Один из наиболее важных аспектов компонентов, управляемых сообщениями, состоит в том, что они могут получать и обрабатывать сообщения параллельно. Эта возможность дает им значительное преимущество перед обычными клиентами JMS, в которых управление ресурсами, транзакциями и безопасностью в многопоточном окружении должно выполняться самим клиентом.
Жизненный цикл экземпляра MDB имеет два состояния: «не существует» и «пул готовых методов». Пул готовых методов похож на пул экземпляров, исп-й для сеансовых компонентов без состояния. Как и для компонентов без состояния, для жизненных циклов MDB определен пул экземпляров.
Не существует. Когда экземпляр MDB находится в состоянии «не существует», он не является экземпляром в памяти системы. Другими словами, он еще не создан.
Пул
готовых методов Экземпляры
MDB переходят в пул готовых методов по
мере того, как они стан-тся нужны Конт-ру.
Переход в пул готовых методов Когда экземпляр перемещается из состояния «не существует» в пул готовых методов, над ним выполняются три действия. Сначала посредством метода Class.newInstance() класса MDB создается экземпляр компонента. Далее контейнер вызывает метод setMessageDrivenContext(), предоставляя экземпляру MDB ссылку на его EJBContext. Ссылка на MessageDrivenContext может быть сохранена в поле экземпляра MDB. Наконец, контейнером вызывается безаргументный метод ejbCreate() экземпляра компонента. У MDB есть только один метод ejbCreate(), не принимающий никаких параметров. Метод ejbCreate() вызывается только один раз в течение жизненного цикла MDB. MDB не являются объектами, подлежащими активации, поэтому они могут поддерживать открытые соединения с ресурсами на всем протяжении их жизненного цикла. Метод ejbRemove() должен закрывать все открытые ресурсы прежде, чем MDB будет удален из памяти в конце своего жизненного цикла.
Жизнь в пуле готовых методовЕсли экземпляр находится в пуле готовых методов, он готов к обработке входящих сообщений. Сообщение, поступающее к MDB, перенаправляется любому доступному экземпляру, находящемуся в пуле готовых методов. Пока экземпляр выполняет запрос, он не может обрабатывать другие сообщения. MDB может одновременно обрабатывать несколько сообщений, делегируя обязанность по обработке каждого сообщения другому экземпляру MDB. Когда сообщение направлено экземпляру контейнером, MessageDrivenContext экземпляра MDB изменяется, чтобы отразить новый контекст транзакции. Экземпляр, закончивший обработку, сразу же становится доступным для обработки нового сообщения.
Переход из пула готовых методов: смерть экземпляра MDB Экземпляры компонентов переводятся из пула готовых методов в состояние «не существует», когда они становятся ненужными серверу. Это происходит, когда сервер принимает решение уменьшить общий размер пула готовых методов, удаляя из памяти один или несколько экземпляров. Этот процесс нач. с вызова метода ejbRemove() экземпляра.
Особенности реализации EJB версии 3.0. Сценарии размещения в контейнерах EJB 3.0. Упрощения модели программирования EJB. Роль интерфейсов EJBHome и EJBObject. Их реализация. Метаданные их роль и использование в JEE. Применение ассоциаций в JEE и EJB в 3.0.
Спецификация EJB была рассчитана на решение таких сложных проблем как распределенные вычисления, управление транзакциями и персистентность данных.Цель EJB 3.0 — сделать начальную стадию разработки легче, а приложения — более удобными в сопровождении
1. EJB 2.0 требует написания дескрипторов развертывания (deployment descriptors), в то время как в EJB 3.0 их попросту нет.
2. В EJB 2.0 необходимо создавать Home и Remote интерфейсы, в то время как в EJB 3.0 нет необходимости этого делать.
3. В EJB 3.0 мы идентифицируем все сущности с помощью символа "@" (Использование аннотаций).
Класс компонента Stateless Session Bean в технологии EJB 3.0 должен удовлетворять следующим требованиям:
*Должен быть объявлен с аннотацией @Stateless (либо должен обозначаться в дескрипторе развертывания как stateless session bean)
*Класс компонента либо должен реализовать свой бизнес-интерфейс, либо использовать аннотацию для указания его бизнес-интерфейсов.
Компонент Stateless Session Bean должен иметь, по крайней мере, один бизнес-интерфейс. Однако их может быть и несколько. Интерфейс может быть либо локальным, либо удаленным (при этом он объявляется с аннотацией @Remote). В бизнес-интерфейсе объявляются бизнес-методы, доступные для клиента.
public interface EJBObject Создан на основе j ava. rmi . Remote.
Этот интерфейс используется при создании всех удаленных интерфейсов серверных компонентов EJB. Удаленный интерфейс позволяет клиенту "увидеть" серверный компонент EJB.
public interface EJBHome Создан на основе java.rmi.Remote. На основе этого интерфейса создаются удаленные домашние интерфейсы компонентов EJB.
EJB home, EJB object интерфейсы больше не нужны, не надо кучу кода, просто пишем в начале класса
@Stateless , @Statefull или @MessageDriven
Метаданные — это субканальная информация об используемых данных[1].
Информация о содержащейся на веб-странице информации (создателе и т. п.). Пример: Имя автора правки в тексте. Этот термин в широком смысле слова используется для любой информации о данных: именах таблиц, колонок в таблице в реляционных базах данных, номер версии в файле программы (то есть как информативная часть в бинарном файле) и т. п.
Структурированные данные, представляющие собой характеристики описываемых сущностей для целей их идентификации, поиска, оценки, управления ими[2].
набор допустимых структурированных описаний, которые доступны в явном виде и предназначение которых может помочь найти объект[3]. Термин используется в контексте поиска объектов, сущностей, ресурсов.
Данные из более общей формальной системы, описывающей заданную систему данных.
Технология JSF JSF- как реализация фреймворка MVC. Основные принципы и компоненты реализации, преимущества технологии JSF по сравнению с аналогичными технологиями разработки веб-приложений. Классы компонентов JSF. Рендеринг и библиотека JSP-тегов.
JavaServer Faces (JSF) — это фреймворк для веб-приложений, написанный на Java. Он служит для того, чтобы облегчать разработку пользовательских интерфейсов для Java EE приложений. В отличие от прочих MVC фреймворков, которые управляются запросами, подход JSF основывается на использовании компонентов. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется. Для отображения данных обычно используется JSP, но JSF можно приспособить и под другие технологии, например XUL.
Подобно Swing и AWT, JSF представляет собой каркас разработки приложений, предоставляющий набор стандартных графических компонентов для создания интерфейсов. Но при этом JSF ориентирована на создание Web-приложений и имеет следующие преимущества:
Четкое разделение бизнес-логики и интерфейса
Управление сохраняемостью на уровне компонент
Простая работа с событиями на стороне сервера
Использование простых и знакомых концепций, таких как графический интерфейс или слои в Web-приложении
Доступность нескольких реализаций от различных компаний-разработчиков
Широкая поддержка со стороны интегрированных средств разработки (IDE)
Как правило, приложение, созданное на основе JSF, состоит из следующих частей:
Объектов JavaBean, управляющих состоянием и поведением приложения
Компонентов GUI, с возможностью сохранения состояния
Классов, реализующих событийную модель, например, слушателей (listeners), аналогичных тем, что используются при традиционной разработке графических интерфейсов
Страниц, выступающих в роли представлений в парадигме Модель-Представление-Контроллер (Model-View-Controller - MVC). Подобные страницы могут обращаться к корневым узлам представления (view roots) через дерево компонентов JSF.
Технология JavaServer Faces включает:
Набор API для представления компонент пользовательского интерфейса (UI) и управления их состоянием, обработкой событий и валидацией вводимой информации, определения навигации, а также поддержку интернационализации (i18n) и доступности (accessibility).
Специальная библиотека JSP тегов для выражения интерфейса JSF на JSP странице.
Классы компонент пользовательского интерфейса, поставляемые вместе с технологией JavaServer Faces, содержат функциональность компонент, а не специфичное для клиента отображение, открывая тем самым возможность рендеринга (Ре́ндеринг - процесс получения изображения по модели с помощью компьютерной программы)JSF-компонент на различных клиентских устройствах.