21. Дескриптор поставки, структура и общие принципы организации кода. Пример описания на xml.

Дескриптор Поставки служит для предоставления информации о каждом Компоненте EJB, который помещен в конкретный EJB jar-файл. Он предназначен для того, чтобы с ним работал пользователь EJB jar-файла. Создание Дескриптор Поставки - задача разработчика Компонента. Поставщик (Deployer) может изменять некоторые из атрибутов в процессе поставки. Вы также можете изменять Дескриптор Поставки после того, как он установлен в Контейнере. Информация, находящаяся в Дескрипторе Поставки, используется для задания значений атрибутов Компонентов EJB. Эти атрибуты определяют поведение Компонента при его взаимодействии с конкретной средой исполнения. Дескриптор Поставки содержит следующую информацию:

• Информацию о типах - другими словами, имена классов - для home и remote интерфейсов и класса реализации.

• JNDI-имена, включая имя, под которым зарегистрирован home-интерфейс.

• Поля, сохранением значений которых управляет Контейнер.

• Профили транзакций, которые определяют поведение Компонента при выполнении транзакции.

• Атрибуты безопасности, которые определяют права доступа к Компоненту.

Типы информации в Дескрипторе Поставки:

• Информация о структуре Компонента.

• Информация для Сборщика Приложений.

Информация о структуре. Разработчик Компонента EJB должен для каждого Компонента в файле ejb-jar определить структурную информацию для каждого Компонента. Часть этой информации является обязательной для всех Компонентов, другие части могут относиться только к session -Компонентам, entity-Компонентам или только к entity-Компонентам с СМР.Для любых Компонентов должны быть заданы: *Имя Компонента *Класс Компонента,Home-интерфейс Компонента *Remote-интерфейс Компонента,Тип Компонента *Параметры среды,Ссылки на фабрики ресурсов (если используются источники данных),Ссылки на другие Компоненты (если это необходимо), Ссылки на Роли безопасности, Для каждого session-Компонента EJB должны быть определены:

• Тип сохранения состояния Компонента

• Тип задания границ транзакций

Для каждого entity-Компонента EJB должны быть определены:

• Тип управления сохранением (persistence)

• Класс главного ключа Компонента

Для каждого session-Компонента EJB с СМР должны быть определены:• Поля, управляемые Контейнером

Создание файла Дескриптора Поставки

<enterprise-beans>

<datasource-definitions>

Пример элементов session-Компонента

<inprise-specific> <enterprise-eans> <session>

<ejb-name>sort</ejb-name>

<bean-home-name>ejb/sort</bean-home-name>

<ejb-ref>

<ejb-ref-name>ejb/sort</ejb-ref-name> <jndi-name>cosnm/mySortHome</jndi-name> </ejb-ref> </session></enterprise-beans></Inprise-pedfic>> Источники данных (DataSource)

21. Jndi, структура, назначение, роль в развертывании и функционировании.

Java Naming and Directory Interface (JNDI) это Java API, организованный в виде службы каталогов, который позволяет Java клиентам открывать и просматривать данные и объекты по их именам. API предоставляет:

механизм ассоциации(связывания) объекта с именем

интерфейс в виде директорий позволяющий общие запросы

интерфейс событий, который позволяет определить клиентам, когда элементы директории были изменены

JNDI используется в Enterprise JavaBeans в качестве службы указания имен для EJB компонент в сети и других службах контейнера, таких как транзакции. JNDI работает очень похоже с другими стандартами, такими как CORBA Naming (сервис именования), и может на самом деле быть реализован в виде надстройки над ним.

При развертывании бина имя для публикации в JNDI домашнего интерфейса EJB берется из дескриптора развертывания.

Когда клиентмкая программа хочет вызвать EJB, она должна найти EJB компонент внутри JNDI и получить ссылку на домашний интерфейс EJB компонента. Домашний интерфейс используется для создания экземпляра EJB.

Имя JNDI - это имя, которое сервер J2EE использует при поиске корпоративных бинов и ресурсов. В службе JNDI, каждому компоненту EJB сопоставляется имя, которое публикуется на дереве имен JNDI. И клиентское приложение обращается к этой службе зная имя под которым зарегистрирован EJB компонент. Обратившись к службе имен клиентское приложение получает по имени объектную ссылку (в случае удаленного взаимодействия это адрес хоста, номер порта, плюс множество служебной информации и плюс еще к тому что эта объектная ссылка уникальная и ее значение невозможно предсказать). Сервис именования JNDI позволяет по имени получить объектную ссылку компонента. Сначала запускается компонент на стороне сервера, который себя регистрирует на дереве имен JNDI под заранее оговоренным с клиентом именем, а потом клиентское приложение через сервис JNDI по имени получает объектную ссылку на этот компонент.

Преимуществом использования сервиса JNDI, кроме того, проявляется в обеспечении прозрачности размещения компонентов по отношению к размещению. Все компоненты EJB зарегистрированы на сервисе JNDI и при взаимодействии сначала ищут друг друга на JNDI. В случае когда их разместили на разных серверах приложений, компоненты даже ничего не заметили так как доступ к соседним компонентам получали через сервис JNDI. И естественно клиентское приложение, тоже ничего не почувствовало. Что же мы получаем в итоге? Мы распределили наши компоненты на разные вычислительные машины и при этом не изменили ни одной строчки кода ни в клиентском приложении ни в самих компонентах.