Ускорение проектирования и разработки корпоративных Java-приложений

В статье рассматривается применение принципов управляемой моделями архитектуры (Model Driven Architecture) для ускорения проектирования и разработки корпоративных Java-приложений, использующих массовые технологии, такие как Java Persistence API, Enterprise Java Beans и Java API for RESTful Web Services. Исследуются все этапы процесса управляемой моделями разработки начиная с моделирования предметной области и заканчивая генерированием EJB 3.0 и проектированием и реализацией JAX-RS.

Введение

Темой данной статьи является ускорение проектирования и разработки корпоративных Java-приложений, использующих базовые технологии, такие как Java Persistence API (JPA), Enterprise Java Beans (EJB) и Java API for RESTful Architecture. В соответствии с принципами RESTful-архитектуры для моделирования были выбраны ресурсы, основанные на объектах бизнес-области. В качестве промежуточного уровня используется технология Enterprise Java Beans, позволяющая использовать преимущества реализованной в ней поддержки управления транзакциями. IBM® Rational® Software Architect предлагает набор предопределенных преобразований модель-код, поддерживающих разработку корпоративных Java-приложений с использованием массовых технологий.

Из UML-модели, представляющей бизнес-область в контексте технологии JPA, можно сгенерировать Java-артефакты, содержащие объекты Java Persistence API. Кроме того, преобразование UML в EJB 3.0 генерирует компоненты Enterprise Java Beans и Java-код из элементов UML-модели, расширенных для работы с технологией EJB. Код JAX-RS Web-сервисов можно получить при помощи преобразования UML в Java и его расширения под названием UML to JAX-RS transformation extension.

Для достижения этих целей предлагается новое усовершенствование поддержки управляемой моделями архитектуры (см. рисунок 1).

Рисунок 1. Новые расширения преобразований модель-модель и модель-код

Для проектирования моделей EJB и JAX-RS мы сгенерируем два новых преобразования модель-модель:

• JPA в EJB 3.0
• EJB 3.0 в JAX-RS

Эти преобразования модель-модель реализованы в виде плагинов, расширяющих инструментальные средства Rational Software Architect.

Реализация сгенерированных JPA-операций происходит при вызове двух новых расширений преобразований для реализации методов. Этими расширениями преобразований являются:

• UML в EJB 3.0
• UML в JAX-RS

Проектирование преобразования модель-модель и определение правил

В данном разделе мы создадим JPA- и EJB 3.0-модели при помощи преобразований модель-модель, созданных в среде Model Transformation Authoring Framework (MTAF). MTAF - это инструментарий, предназначенный для реализации различных преобразований в IBM Rational Software Architect и IBM® InfoSphere Data Architect. Инфраструктура MTAF Framework позволяет определить преобразования между произвольными областями. Она также предоставляет функциональный программный интерфейс (API), поддерживающий императивное и декларативное отображения. Схема преобразования модель-модель JPA в EJB 3.0 показана на рисунке 2.

Рисунок 2. Схема преобразования модель-модель JPA в EJB 3.0

 

Основное преобразование, расширяющее класс RootTransform, состоит из набора классов UMLKindTransform. В данных примерах есть только один экземпляр класса UMLKindTransform. Он содержит набор классов правил преобразования, наследующих классу ModelRule.

Однако оба проекта (и JPA, и EJB 3.0) базируются на одних и тех же функциональных возможностях преобразования (см. таблицу 1).

Таблица 1. Функциональные возможности проектирования преобразований модель-модел

Направленность	Однонаправленное
Отношение источник-назначение	Разные исходная и целевая модели. Исходная модель может быть вложенным пакетом. Целевая модель не может быть вложенным пакетом.
Поэтапность	Использование класса Fuse Utility Class, который обращается к инфраструктуре сравнения и объединения.
Управление жизненным циклом преобразования	Управляет началом и концом преобразования путем вызова интерфейса IrunTransformationListener.
Тип отображения	Позволяет явно контролировать выполнение правил преобразования. Тип отображения - императивный.
Определение правил	Область: Meta Object Facility (MOF)
	Условия применения: реализуются в методе canAccept()
	Параметризация: обобщенные функции в качестве параметров
	Планирование правил: правила исполняются последовательн

Проектирование преобразования модель-код

IBM Software Architect включает в себя предопределенное преобразование UML в Java, которое можно расширить при помощи механизма расширений Eclipse. Автор преобразования может принять участие в этом, расширяя только ту часть преобразования, которая выполняет один или несколько элементов UML-модели. На основе этой функциональности разработаны расширения преобразований UML в EJB 3.0 и UML в JAX-RS. Оба расширения предназначены для расширения части преобразования UML в Java, преобразующей класс UML Operation в объявление метода.

Рабочий пример

В качестве источника преобразований модели в данной статье используется пример UML-модели области, показанный на рисунке 3. На основании этой модели проект и реализация EJB 3.0 и JAX-RS генерируются автоматически

Пример JPA-модел на рисунке 3 состоит из двух объектов (User и Pages) с отношением composition (композиция) между ними. Задачей данной бизнес-области является создание приложения под названием VirtualDiary , предоставляющего пользователю интерактивный дневник, состоящий из произвольного числа страниц. Каждая страница имеет заголовок, содержание и дату создания. Каждому пользователю назначается неограниченное число страниц. Профиль пользователя содержит следующую информацию

• Имя (name)
• Фамилия (surname)
• Дата рождения (date of birth)
• Имя пользователя (user name)
• Пароль (password)

Поля user name и password позволяют пользователю войти в систему, и для этой конкретной операции создается специальный именованный запрос.

Рисунок 3. Пример JPA-модели област

 

Предварительные условия

Для дальнейшей работы со статьей должны быть выполнены определенные пред- и постусловия. Этими условиями являются

Поддерживаемые среды исполнения

Разверните JPA, EJB и Web-проект, содержащий сгенерированный код, на IBM® WebSphere® Application Server или IBM® WebSphere® Liberty Profile

Применение встроенных и специализированных UML-профилей

Настройте в целевой EJB-модели следующие UML-профили:

• EJB 3.0 Transformation Profile: встроенный профиль, доступный в Rational Software Architect.
• Java Transformation Profile: встроенный профиль, доступный в Rational Software Architect.
• JPA Profile for JPA to EJB transformation: специализированный профиль, доступный в плагине com.ibm.rational.transform.demo.jpa2ejb.
• EJB Profile for JPA to EJB transformation: специализированный профиль, доступный в плагине com.ibm.rational.transform.demo.jpa2ejb.

Настройте в целевой JAX-RS-модели следующие UML-профили:

• REST: встроенный профиль, доступный в Rational Software Architect.
• JAX - RS: встроенный профиль, доступный в Rational Software Architect.
• CDI Profile for EJB to JAX-RS transformation: специализированный профиль, доступный в плагине com.ibm.rational.transform.demo.ejb2jaxrs.

Импортируемые библиотеки моделей

Импортируйте вспомогательные библиотеки J2EE, доступные в плагинах com.ibm.rational.transform.demo.jpa2ejb и com.ibm.rational.transform.demo.ejb2jaxrs, в EJB- и JAX-RS-модели назначения. Импортируйте библиотеку Java Primitive Types, доступную в Rational Software Architect, в JAX-RS-модель.

Проектирование и реализация EJB 3.0-методов

В данном разделе рассматривается генерирование EJB 3.0-модели и кода на основании JPA-модели области.

Преобразование модель-модель JPA в EJB 3.0

В качестве фасада для JPA-объектов обычно используются EJB-компоненты, поскольку они предлагают функции управления транзакциями. UML-модель JPA-объектов предоставляет источник для преобразования модель-модель JPA в EJB 3.0. Результатом преобразования является UML-модель EJB-фасадов. В данной статье приводятся правила отображения, а примеры результатов их применения демонстрируются при помощи общих имен UML-элементов.

Преобразование отображения для правила Package

Описание

Правило Package преобразует каждый UML-пакет исходной модели в UML-пакет целевой модели. Структура пакетов сохраняется, и каждый сгенерированный пакет дополняется одним вложенным пакетом с именем ejbs.

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 4. Пример исходной JPA-модели для правила Package

Рисунок 5. Сгенерированные UML-пакеты в EJB-моде

Условие применения

Правило принимает в качестве исходного параметра исходный пакет.

Преобразование отображения для правила Entity to Bean

Описание

Объект JPA-модели отображается в Stateless (не сохраняющий состояния) или Stateful (сохраняющий состояние) bean-компонент. Если между сессионным компонентом (session bean) и интерфейсом имеется отношение имплементации, JPA-модель также отображается на один локальный и один удаленный интерфейс (не больше). Можно выбрать генерирование bean-компонента Singleton, но только в комбинации с bean-компонентами типов Stateful или Stateless. Тип bean-компонента и интерфейс указываются как параметры преобразования. Можно также выбрать типы Container или Bean Transaction Management.

• Container: при создании сессионного компонента внедряется контекст персистентности и создается новый Entity Manager.
• Stateful: контекст персистентности расширяется. Каждый сессионный компонент и интерфейс реализует следующие операции:
  • Создание логического объекта (entity).
  • Обновление логического объекта.
  • Удаление логического объекта.
  • Поиск логического объекта по идентификатору. Значение идентификатора является составным, все поля ключа передаются в операцию findById() .
• Сессионный компонент Singleton: в отличие от CRUD-операций единичные сессионные компоненты содержат три публичных метода:
  • createCache()
  • deleteCache ()
  • refreshCache()

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 6. Пример исходного JPA-объекта с одним атрибутом id

Тип bean-компонента и интерфейса

• Не сохраняющий состояния компонент управления данными с локальным и удаленным интерфейсами

Тип управления транзакциями

• Container

Рисунок 7. Сессионный компонент с двумя интерфейсами, сгенерированный в результате применения правила Entity to Bean

Условие применения

Правило принимает класс с использованием в качестве входного параметра стереотипа "Entity". Это реализовано в профиле Java Persistence API Transformation .

Преобразование отображения для правила свойства

Описание

Можно выбрать генерирование операции finder для каждого поля Entity и для каждого bean-компонента на основе значения Generate Query methods for attributes. Для Singleton-компонентов эти методы являются приватными.

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 8. Пример ввода JPA-объекта с одним id и одним не-id атрибутами

Рисунок 9. Класс сессионного компонента с созданной операцией findByAttributeName

Условие применения

Правило вызывается, если входной параметр является классом со стереотипом "Entity" и свойство преобразования Generate Query method for attributes установлено в значение true.

Преобразование отображения для правила Named query

Описание

Сессионные компоненты могут реализовывать дополнительные операции для каждого специализированного именованного запроса, определенного в исходном логическом объекте. Параметры именованного запроса становятся параметрами операции. Запрос анализируется с целью определения типа и количества параметров. Создаются также новые отношения зависимости. Первое отношение зависимости соединяет исходную операцию со стереотипом @NamedQuery, а второе - со сгенерированной операцией. Это делается с целью извлечения имени запроса на последующем шаге процесса разработки (при активизации расширения преобразования UML-в-EJB). Второе отношение создается между классом логического объекта и классом EJB-контейнера из сгенерированной операции.

Примечание.
Это отношение используется в реализации JAX-RS-методов.

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 10. Спецификация элемента именованного запроса в JPA-объекте

Строковое значение именованного запроса:

Рисунок 11. Спецификация строки специализированного именованного запроса

Рисунок 12. EJB 3.0-операция, сгенерированная из правила Named query

Условие применения

Правило принимает UML-операцию в качестве входного параметра, если:

• Применяется стереотип "NamedQuery", содержащийся в профиле Java Persistence API Transformation.
• Свойство преобразования Generate operation for custom named queries установлено в значение true.

В таблице 2 приведен список параметров преобразования, включая параметры, определенные на вкладке конфигурации, задаваемой пользователем.

Таблица 2. Параметры преобразования модель-модель JPA в EJB 3.0

Имя	Тип	Значения
Session bean type	String	Stateful, Stateless, Stateful/Singleton, Stateless/Singleton
Transaction type	String	Container, Bean
Interface Type	String	Local, Remote, LocalBean
Generate Query methods for attributes	Boolean	True, False
Generate operations from custom NamedQueries	Boolean	True, False
JPA Project Name (optional)	String

После определения бизнес-модели выполняется генерация Java-кода для JPA-объектов. Для этого вызовите предопределенное преобразование UML to JPA Transformation. Чтобы преобразование анализировало все определенные пользователем именованные запросы, необходимо реализовать логические объекты до активизации преобразования модель-модель JPA в EJB 3.0. Для получения EJB 3.0-модели выполните следующие действия.

1. Выберите File > New > Transformation Configuration.
2. Выберите JPAtoEJBTransformation в папке JPA to EJB model to model transformation.
3. Введите имя и назначение конфигурационного файла.
4. Нажмите Next.
5. Выберите исходную и целевую модели.
6. Нажмите Next.
7. На странице Extensions отобразится список доступных расширений преобразований. Отметьте флажок ID для com.ibm.rational.transform.demo.jpa2ejb.extension.GUI (см. рисунок 13).
8. Нажмите Next.

Рисунок 13. Вкладка Extensions файла конфигурации преобразования JPA в EJB 3.0

9. На рисунке 14 показан первый набор свойств преобразования
   • В поле Generate query methods for attributes установите значение свойства в true.
   • В поле Generate operations from custom NamedQueries установите значение свойства в true.
   • В поле JPA project name введите имя проекта, в котором реализуются JPA-объекты.
10. Нажмите Next.

Рисунок 14. Вкладка Properties файла конфигурации преобразования JPA в EJB 3.0

11. Для каждого объекта выберите тип bean-компонента, транзакцию и локальный интерфейс (см. рисунок 15).

Рисунок 15. Вкладка Custom с дополнительными параметрами в файле конфигурации преобразования JPA в EJB 3.0

 

12. Для запуска преобразования нажмите Finish.
13. Откройте первую страницу файла конфигурации преобразования.
14. Нажмите Run.

Итоговая EJB 3.0-модель показана на рисунке 16.

Рисунок 16. EJB 3.0-модель, полученная в результате преобразования модель-модель JPA в EJB 3.0

Ограничением преобразования модель-модель JPA в EJB 3.0 является преобразование унаследованных классов. JPA-наследование является сложным, поскольку оно может отображаться на различные структуры баз данных (Single Table, Joined или Table Per Class). Из-за своей сложности эта информация здесь не рассматривается.

Расширение преобразования модель-код UML в EJB

Для доступа к JPA-объектам необходимо в EJB-фасадах реализовать все CRUD-методы. Реализация этих методов основана на шаблонах программирования, аналогичных компонентам JPA Manager Beans, поддерживаемым системами Rational Software Architect и IBM(R) Rational(R) Application Developer. Однако в расширение преобразования модель-код UML в EJB добавляются шаблоны программирования, отражающие поведение сохраняющих состояние и единичных bean-компонентов. Эти шаблоны различаются типом управления транзакциями. Как упоминалось в разделе Преобразование модель-модель JPA в EJB 3.0, можно выбирать следующие элементы:

• Управляемую контейнером транзакцию, в которой границы транзакции устанавливает EJB-контейнер.
• Управляемую компонентом транзакцию: EJB-фасады отмечаются явно.

Используйте Entity Manager API для:

• Создания логического объекта.
• Обновления логического объекта.
• Удаления персистентных экземпляров логического объекта.
• Поиска логического объекта по первичному ключу.
• Запроса к логическому объекту.

Для управляемых контейнером транзакций Entity Manager создается контейнером, который использует информацию, содержащуюся в persistence.xml. Entity Manager внедряется в EJB-класс посредством аннотации @PersistenceContext.

Для управляемых компонентом транзакций контекст персистентности не распространяется на управляемые данными bean-компоненты, а жизненный цикл экземпляра Entity Manager управляется приложением. В этом случае приложение создает объекты Entity Manager, используя метод createEntityManager()javax.Persistence.EntityManagerFactory.

Необходимо создать новую вкладку конфигурации преобразования для генерирования EJB 3.0-кода с реализацией CRUD-методов. Создайте вкладку.

1. Выберите File > New > Transformation Configuration.
2. Выберите UML-to-EJB 3.0 в папке Java Transformations.
3. Введите имя и назначение конфигурационного файла.
4. Нажмите Next.
5. Выберите сгенерированную EJB 3.0-модель в качестве источника и EJB- или Web-проект в качестве назначения.
6. Нажмите Finish и откройте файл конфигурации преобразования.
7. На вкладке Extensions отметьте флажок идентификатора, относящегося к com.ibm.xtools.transform.uml2.ejb3.java.internal.UML2EJBTransformExtension.

Рисунок 17. Вкладка Extensions преобразования UML to EJB 3.0

 

8. Нажмите кнопку Run на первой странице файла преобразования для запуска преобразования.

Будет сгенерирован EJB 3.0-код с реализацией методов, указанных в EJB 3.0-проекте.

Генерирование JAX-RS-проекта и реализация JAX-RS-методов

В этом разделе рассматривается генерирование JAX-RS-проекта и реализация его методов с помощью преобразования модель-модель EJB 3.0 в JAX-RS. Исходной моделью для данного раздела является EJB 3.0-модель, сгенерированная в предыдущем разделе.

Преобразование модель-модель EJB в JAX-RS

Для использования в Web 2.0-приложениях EJB-фасады могут предоставляться как RESTful-ресурсы. UML-модель EJB-фасадов преобразуется в UML-модель JAX-RS-ресурса при помощи специализированного преобразования модель-модель EJB 3.0 в JAX-RS. Правила отображения определяются с использованием общих имен UML-элементов.

Преобразование отображения для Packagerule

Описание

Если назначение является моделью, в целевой модели создается новый пакет. Если назначение является пакетом, целевым пакетом должен быть root. Структура пакета исходной модели воссоздается в целевой модели, но каждый вложенный пакет ejbs в исходной модели преобразуется в пакет jaxrs.

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 18. Структура пакетов исходного элемента EJB 3.0-модели

Рисунок 19. Сгенерированная структура пакетов в JAX-RS-модели

Условие применения

Правило принимает в качестве исходного параметра исходный пакет.

Преобразование отображения для правила Application

Описание

Преобразование создает новый UML-класс. Его имя создается путем добавления к имени целевой JAX-RS-модели суффикса Application. Класс генерируется в пакете root JAX-RS-модели. В сгенерированном классе используется стереотип Application из REST-профиля.

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 20. Входной элемент EJB 3.0-модели в правиле Application

Рисунок 21. Сгенерированный элемент класса Application как результат применения правила Application

Условие применения

Правило принимает в качестве исходного параметра исходный пакет.

Преобразование отображения для правила Bean to Resource

Описание

Каждый сессионный компонент (с применением стереотипов либо Stateless, либо Singleton) однозначно отображается на один ресурс. Структура JPA-модели определяет структуру JAX-RS-модели. Поэтому важно сохранить отношения зависимости между исходным EJB-классом и соответствующим ему логическим объектом. В данном контексте UML-классы, представляющие JPA-объекты, подразделяются на две группы в зависимости от того, являются ли они частью композитной агрегации с другим классом Entity Class:

• Логический JPA-объект не "содержится" ни в каком другом логическом JPA-объекте - соответствующий элемент EJB Class преобразуется в JAX-RS Root Resource. Между Root Resource и классом Application создается новое отношение зависимости с именем "{name}/{entity name}". К зависимости применяется стереотип "Path". В класс resource добавляется новый атрибут типа соответствующего сессионного компонента путем применения стереотипа "Inject". Этот стереотип доступен в специализированном CDI-профиле.
• Логический JPA-объект "содержится" в другом логическом JPA-объекте - соответствующий элемент EJB Class преобразуется в JAX-RS Sub-resource. Между элементом Sub-resource и его ресурсом container создается новое отношение зависимости. Поскольку элемент Sub-resources доступен только из своего предка, в контейнер ресурсов добавляется операция locator нового Sub-resource. URI-имя отношения между root и Sub-resource - "/{entity name}/{id attribute}". Также добавляется новый атрибут типа соответствующего сессионного компонента. Найдите bean-компонент, используя Java Naming and Directory Interface (JNDI).

Другим важным аспектом этого правила является область видимости сгенерированных ресурсов. Единичный bean-компонент отображается на ресурс со стереотипом "ApplicationScoped", тогда как не сохраняющий состояние bean-компонент отображается на ресурс со стереотипом "RequestScoped".

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 22. Исходный компонент управления данными, сгенерированный из логического объекта, который не "содержится" в каком-либо другом логическом JPA-объекте

Рисунок 23. Сгенерированный элемент класса Root Resource с отношением зависимости к классу Application

Условие применения

Правило принимает элемент UML-класса с применением одного из стереотипов "Stateless" или "Singleton".

Преобразование отображения для правила Operation

Описание

Для каждой операции сессионного компонента создается новая операция в JAX-RS Resources с именем и параметрами как у порождающего метода. К каждому из сгенерированных методов применяется стереотип, который указывает обозначение метода запроса. В таблице 4 продемонстрировано применение этих стереотипов.

Элементы

• JPA-элемент
• Результаты преобразования

Диаграммы

Рисунок 24. Операции сессионного компонента как исходные данные для Operation Rule

Рисунок 25. Сгенерированные операции POST, PUT и DELETE в классе Resource и две операции GET со значениями path

Условие применения

Правило в качестве исходных элементов принимает UML-операции, содержащиеся в UML-классе со стереотипами "Stateless" или "Singleton". Кроме того, контейнер должен иметь отношение зависимости с логическим JPA-объектом, и операция должна быть публичной.

К каждому из сгенерированных методов применяется стереотип, который указывает обозначение метода запроса (см. таблицу 4).

Таблица 4. Применение стереотипов, указывающих обозначение HTTP-метода на JAX-RS-методах

Тип операции	Стереотип, указывающий обозначение метода	Значение Path
создать	"POST"	не определено
обновить	"PUT"	не определено
удалить	"DELETE"	не определено
найти по идентификатору	"GET"	" /{id}"
другие операции поиска	"GET"	" /" плюс имя операции

Параметры преобразования, включая указанные во вкладке определяемой пользователем конфигурации, приведены в таблице 5.

Таблица 5. Параметры преобразования модель-модель EJB 3.0 в JAX-RS

Имя	Тип	Значения
Consume media types for create, update and delete type of methods	String	JSON, XML, JSON (XML)
Allowed combination of consume media type and annotation applied on input parameters for custom finder methods	String	@FormParam/FORM_URLENCODED /JSON /XML /JSON(XML) @QueryParam/
Produces media types	String	JSON, XML, JSON (XML)

Сгенерированные методы могут использовать и генерировать сообщения в JSON- и XML-формате. Предполагается, что получаемый JAX-RS API используется главным образом со средами WebSphere Application Server или WebSphere Liberty Profile. Однако эти среды поддерживают сериализацию и десериализацию форматов JSON и XML.

Сгенерируйте JAX-RS-проект из ранее сгенерированной EJB 3.0-модели.

1. Выберите File > New > Transformation Configuration.
2. Выберите EJB-to-JAX-RSTransformation.
3. Укажите имя и назначение конфигурационного файла и нажмите Next.
4. Выберите ранее сгенерированную EJB 3.0-модель в качестве исходной модели.
5. Выберите целевую модель.
6. Нажмите Next.
7. Откроется страница, содержащая список доступных расширений преобразований. Отметьте флажок ID для com.ibm.rational.transform.demo.ejb2jaxrs.extension.GUI (см. рисунок 26).
8. Нажмите Next.

Рисунок 26. Вкладка Extension файла конфигурации преобразования EJB 3.0 to JAX-RS

9. На последней странице мастера Transformation properties выберите тип метода и тип, который этот метод потребляет и генерирует (столбцы Consumes и Produces).
10. Выберите тип аннотации для применения с параметрами некоторых методов.
11. Нажмите Finish. На рисунке 27 показана завершающая страница.

Рисунок 27. Параметры файла конфигурации преобразования EJB 3.0 в JAX-RS

12. Откройте первую страницу файла конфигурации преобразования. Для запуска преобразования нажмите Run.

На рисунке 28 показана сгенерированная JAX-RS-модель.

Рисунок 28. JAX-RS-модель как результат преобразования модель-модель EJB 3.0 в JAX-RS

 

Расширение преобразования модель-модель UML в JAX-RS

Шаблон программирования для генерирования реализации JAX-RS-методов зависит от типа ресурсов. Класс JAX-RS-ресурса root получает ссылку на экземпляр корпоративного bean-компонента через механизм внедрения зависимостей контекста (context dependency injection - CDI). Это означает, что ссылка на корпоративный bean-компонент в ресурсе root снабжается аннотацией @Inject. Однако субресурс получает ссылку на корпоративный bean-компонент посредством JNDI-поиска с использованием синтаксиса Java Naming and Directory Interface. Согласно спецификации JAX-RS, субресурс не может быть представлен как bean-компонент CDI. В этом преобразовании в качестве переносимого способа поиска корпоративных bean-компонентов посредством операций JNDI-поиска используется пространство JNDI-имен java:global. JNDI-адрес формируется согласно следующему шаблону:

java:global[/имя приложения]/имя модуля/имя корпоративного bean-компонента

Имя приложения является необязательным и требуется только если приложение помещается в EAR-архив. Его можно указать в параметре преобразования во вкладке конфигурации расширения.

Если имя приложения определено, оно включается в поисковую строку. Имя модуля проверяется в любом из следующих файлов:

• Файл ejb-jar.xml. Используется, когда именем является имя EJB-проекта и реализуются сессионные компоненты.
• Дескриптор web.xml. Если имя пользовательского модуля не указано, преобразование берет имя модуля по умолчанию в адресной строке JNDI.

Каждая операция JAX-RS вызывает соответствующий EJB-метод.

Для генерирования кода JAX-RS выполните следующие действия:

1. Выберите File > New > Transformation Configuration.
2. Выберите UML to Java из папки Java Transformations.
3. Введите имя и назначение конфигурационного файла.
4. Нажмите Next.
5. Выберите сгенерированную EJB 3.0-модель в качестве источника и Web-проект в качестве цели.
6. Нажмите Finish.
7. На вкладке Extensions отметьте флажки возле идентификаторов com.ibm.xtools.transform.uml2.jaxrs и com.ibm.xtools.uml2jaxrsExtension.

Рисунок 29. Вкладка Extensions преобразования UML в Jav

 

8. Для запуска преобразования нажмите Run на главной странице файла конфигурации преобразования.

Заключение

В статье было представлено первоначальное решение, реализуемое вручную. Время реализации и количество учитываемых деталей такого ручного решения существенно возрастают по мере увеличения сложности JPA-модели области.

Поэтому было предложено полностью автоматизированное решение для генерирования EJB- и JAX-RS-моделей и кода. Этот процесс занимает несколько часов независимо от сложности исходной JPA-модели.

Также в данной статье были рассмотрены варианты связывания. Они важны для обеспечения предсказуемости получаемого JAX-RS API, что является еще одним важным аспектом эффективности разработки.

Следование проверенным практикой стандартам и форматам, передовым методикам и вариантам, представленным в данной статье, позволяет получить целостный, простой для понимания и предсказуемый API.