- •Распределенные события:
- •4. Проектирование сложных объектов. Основные принципы проектирования. Аспекты и стадии проектирования
- •5. Развитие парадигмы программирования
- •6. Функциональное моделирование. Стандарты idef0, idef3.
- •7. Информационное моделирование. Стандарты idef1, idef1x/
- •8. Средства и элементы статистических и динамических моделей объектно-ориентированных систем (статические и динамические диаграммы uml).
- •9.Порождающие паттерны. Назначение, обобщенные свойства, применение. Пример реализации.
- •10. Структурные паттерны. Назначение, обобщенные свойства, применение. Пример реализации.
- •11.Паттерны поведения. Назначение, обобщенные свойства, применение. Пример реализации
- •12. Язык xml: средства, назначения и особенности использования. Xml и dtd.
- •13. Язык xml и схемы данных.
- •14.Методы и средства обработки xml документов с использ-ем моделей dom и sax, преимущ-ва и недостатки.
- •15.Языки Extensible Markup Language(xsl) и xsl Transformations (xslt): назначение и особенности использования.
- •16. Язык xPath и его применение для доступа к элементам xml.
- •17.Фазы, итерации и циклы разработки. Рабочие процессы, модели и артефакты.
- •18. Совместная разработка: Методы и средства тестирования и отладки программных приложений
- •19. Особенности модель распределённых объектов. Модель rpc.
- •20. Классы и интерфейсы механизма rmi . Архитектура и конфигурирование rmi
- •Разработка rmi приложений. Примеры. Соглашения о передаче данных
- •Corba, назначение, терминология. Архитектура управления объектами (ома). Объектная модель corba.
- •Основные сервисы Corba, модель организация приложений corba, примеры.
- •Orb: понятие, назначение, основные функции. Принципы организации запросов в orb. Использование стандарта iiop.
- •Объектный адаптеры boa и роа. Назначение и основные функции. Статические и динамические вызовы в corba.
- •Язык idl, основные характеристики языка, создание распределенных объектов на idl Связь rmi и corba.
- •Понятие прозрачность, серванта, использование посредников proxies в corba. Name сервис.
- •Платформа j2ee. (основные технологии). Когда следует применять Enterprise JavaBeans. Типы ejb, обобщенная архитектура, принципы функционирования и программное обеспечение.
- •Понятие, определение и использование удаленного (Remote) и локального интерфейсов. Их применение и программная реализация (примеры).
- •Понятие, определение и использование собственного (home) интерфейса. Их программная реализация (примеры)
- •Сеансовые (Session) компоненты ejb без состояния и с состоянием, их особенности и применение.
- •Общие принципы развертывание сеансовых компонентов ejb. Пример текста дескриптора поставки.
- •Организация и особенности Entity компонент с сохранением (персистентностью) управляемым контейнером (cmp).
- •Организация и особенности Entity компонент с сохранением (персистентностью) управляемым компонентом (bmp).
- •Особенности реализации (home) и (Remote) интерфейсов для Entity компонентов.
- •Контейнер ejb, понятие, назначение, основные функции.
- •Дескриптор поставки, структура и общие принципы организации кода. Пример описания на xml.
- •Jndi, структура, назначение, роль в развертывании и функционировании.
- •Архитектура совместного использования web и ejb компонентов, Ejb-транзакции.
- •Доступ к компонентам ejb из различных приложений клиента (web, Console, gui).
- •Компоненты ejb, управляемые сообщениями. Обмен сообщениями с помощью java Message Service (jms) .
- •Модели использования jms. Основные объекты и термины, их назначение (алгоритм реализации).
- •Message Driven Beans (mdb), жизненный цикл компонентов. Особенности применения и функционирования, реализующие методы (примеры).
- •Технология jsf Базовые концепции технологии и функциональные возможности jsf
- •Inversion of Control контейнер
Дескриптор поставки, структура и общие принципы организации кода. Пример описания на 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)
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. И естественно клиентское приложение, тоже ничего не почувствовало. Что же мы получаем в итоге? Мы распределили наши компоненты на разные вычислительные машины и при этом не изменили ни одной строчки кода ни в клиентском приложении ни в самих компонентах.