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() экземпляра.

48. Особенности реализации 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]. Термин используется в контексте поиска объектов, сущностей, ресурсов.

Данные из более общей формальной системы, описывающей заданную систему данных.

49. Технология 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-компонент на различных клиентских устройствах.

50. Технология JSF Базовые концепции технологии и функциональные возможности JSF

Функциональные возможности JavaServer Faces Процесс создания приложения (последовательность и назначение шагов создания). Жизненный цикл обработки запросов JSF. Стандартные JSF теги. Базовые теги JSF. HTML теги JSF. Атрибуты тегов. • Разработка , размещение и запуск JSF приложения.

JavaServer Faces (JSF) — это фреймворк для веб-приложений, написанный на Java. Он служит для того, чтобы облегчать разработку пользовательских интерфейсов для Java EE приложений. В отличие от прочих MVC фреймворков, которые управляются запросами, подход JSF основывается на использовании компонентов. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется. Для отображения данных обычно используется JSP.

Технология JavaServer Faces включает:

§ Набор API для представления компонент пользовательского интерфейса (UI) и управления их состоянием, обработкой событий и валидацией вводимой информации.

§ Специальная библиотека JSP тегов для выражения интерфейса JSF на JSP странице.

Процесс создания приложения:

1)Объявление описание сервлета Faces в дескрипторе Web-приложения (файле web.xml)

2)Описание местонахождения файла faces-config.xml внутри web.xml

3)Создание класса

4)Объявление класса в файле faces-config.xml в качестве объекта JavaBean

5)Создание страницы index.jsp

6)Создание страниц .jsp

Жизненный цикл обработки запроса в приложениях JSF состоит из следующих фаз:

1)Восстановление представления (запрос поступает на вход сервлета FacesServlet. Последний анализирует данные запроса и извлекает идентификатор представления, определяемый именем страницы JSP)

2)Использование параметров запроса; обработка событий (получение данных о состоянии каждого компонента)

3)Проверка данных; обработка событий (Конвертация и валидация данных, как правило, выполняются в фазе проверки данных)

4)Обновление данных модели; обработка событий (обновление данных модели путем изменения свойств серверных объектов JavaBean)

5)Вызов приложения; обработка событий (вызывает приложение для обработки данных, полученных через форму)

6)Вывод результата (вывод представления вместе со всеми его компонентами и их текущими состояниями)

JSF теги.

f:param – создает параметр компонентов.

f:actionListener – добавляет слушателя действий для компонентов.

f:attribute – добавить атрибут компонента.

f:converter – добавляет произвольный преобразователь компонент.

f:valiolator – добавляет проверки для компонента.

HTML теги.

h:form – html формы.

h:inputText – однострочный контроль ввода тега.

h:commandLink – ссылка которая работает как кнопка.

51. Spring Framework как коллекция фреймворков (фреймворков во фреймворке). Механизмы и метод конфигурирования зависимостей (dependency injection-DI или inversion of control-IoC). Использование Spring для конфигурирования модульного приложения. Основные методы и этапы разработки приложений Spring.

Spring – многоцелевая технология (фреймворк) для построения приложений. Основными функциями Spring являются поддержка IoC (инверсия контроля) и Аспектно-ориентированное программирование.Цель Spring – сделать более ясным и понятным код бизнес-логики, вынести из неё вспомогательные методы.

Spring Framework может быть рассмотрен как коллекция меньших фреймворков или фреймворков во фреймворке. Большинство этих фреймворков может работать независимо друг от друга, однако, они обеспечивают большую функциональность при совместном их использовании. Эти фреймворки делятся на структурные элементы типовых комплексных приложений:

*Inversion of Control контейнер.

*Фреймворк аспектно-ориентированного программирования.

*Фреймворк доступа к данным.

*Фреймворк управления транзакциями.

*Фреймворк Model-view-controller.

*Фреймворк удалённого доступа.

*Фреймворк аутентификации и авторизации.

*Фреймворк удалённого управления.

*Фреймворк работы с сообщениями.