IX Международная студенческая научная конференция Студенческий научный форум - 2017

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

Целями данной статьи являются автоматическое проектирование и реализация EJB – компонентов и JAX – RS – сервисов с применением специализированных преобразований модели (начиная с JPA – модели предметной области), а также повышение скорости и эффективности проектирования и разработки корпоративных 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. Новые расширения преобразований модель – модель и модель – код

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

• JPA в EJB 3.0

• EJB 3.0 в JAX – RS

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

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

• UML в EJB 3.0

• UML в JAX – RS

•  
  1. ПРОЕКТИРОВАНИЕ ПРЕОБРАЗОВАНИЯ МОДЕЛЬ – МОДЕЛЬ И ОПРЕДЕЛЕНИЕ ПРАВИЛ

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

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

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

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

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

•  
  1. ПРОЕКТИРОВАНИЕ ПРЕОБРАЗОВАНИЯ МОДЕЛЬ – КОД

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

•  
  1. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ EJB 3.0 – МЕТОДОВ

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

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

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

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

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

3.1.2 Преобразование отображения для правила 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()

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

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

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

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

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

Правило принимает 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.

Ограничением преобразования модель – модель JPA в EJB 3.0 является преобразование унаследованных классов. JPA – наследование является сложным, поскольку оно может отображаться на различные структуры баз данных (Single Table, Joined или Table Per Class) [1].

•  
  1. РАСШИРЕНИЕ ПРЕОБРАЗОВАНИЯ МОДЕЛЬ – КОД 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 [2].

•  
  1. ГЕНЕРИРОВАНИЕ JAX – RS – ПРОЕКТА И РЕАЛИЗАЦИЯ JAX – RS – МЕТОДОВ

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

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

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

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

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

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

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

5.1.3 Преобразование отображения для правила 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» [3].

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

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

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

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

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

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

Таблица 4. Параметры преобразования модель – модель 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 [4].

•  
  1. РАСШИРЕНИЕ ПРЕОБРАЗОВАНИЯ МОДЕЛЬ – МОДЕЛЬ 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 [3].

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

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

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

• Файл ejb – jar.xml. Используется, когда именем является имя EJB – проекта и реализуются сессионные компоненты.

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Полищук А.П., Семерико С.А. Программирование в X Window средствами Free Pascal / А.П. Полищук, С.А. Семерико. – Кривой Рог: КГПУ, 2003г.

2. Фленов М. Е. Библия для программиста в среде Delphi / М.Е. Фленов – Copyright, 2002г.

3. Википедия – свободная энциклопедия [Электронный ресурс]. – http://wikipedia.org . – (дата обращения: 01.12.2016)

4. Books.google.ru. – библиотека Google [Электронный ресурс]. – books.google.ru – (дата обращения: 01.12.2016)

Код для цитирования: Скопировать