32
поставить реализацию OSGi платформы для всех проектов Eclipse.
Распространяется по открытой лицензии Eclipse (англ. Eclipse Public
License (EPL)) [33].
Knopflerfish – популярная и довольно зрелая реализация платформы
OSGi. Разрабатывается и поддерживается шведской компанией Makewave.
Лицензируется по лицензии схожей с программной лицензией
университета Беркли (англ. Berkeley Software Distribution license (BSD
license)). Компания Makewave также осуществляет коммерческую
поддержку проекта. На момент написания работы последняя версия была
Knopflerfish 6, которая полностью соответствовала спецификации OSGi R6
[43].
Concierge – маленькая по размерам реализация основной
спецификации OSGi R5 оптимизированная для мобильных и встроенных
устройств. Например, Concierge может быть использована в Raspberry Pi и
Beaglebone. Кроме того, данная реализация имеет поддержку работы на
виртуальной машине Android Dalvik. Размер JAR файла, который содержит
платформу, составляет всего около 250KB. Распространяется по лицензии
схожей с программной лицензией университета Беркли (англ. Berkeley
Software Distribution license (BSD license)) [32].
Felix – проект фонда Apache, разрабатываемый сообществом с целью
реализации платформы OSGi и других интересных технологий, связанных
с OSGi. Распространяется по лицензии Apache (англ. Apache License).
Среди главных особенностей проекта можно выделить малый размер
платформы и большое количество подпроектов, среди которых хотелось
бы отметить:
1. Администратор конфигурации (англ. Config Admin) – реализация
сервиса управления конфигурации для управления свойствами
конфигурации бандлов.
33
2. Менеджер зависимостей (англ. Dependency Manager) – модель
компонентов, основанная на API, которая должна упростить
разработку на основе OSGi технологии.
3. Администратор событий (англ. Event Admin) – реализация
спецификации для взаимодействия, основанном на событиях.
4. Установка файла (англ. File Install) – простой агент управления,
основанный на директории файловой системы для управления
установкой бандла.
5. Gogo – оболочка с большим количеством возможностей для
интерактивной работы с платформой OSGi.
6. HTTP сервис (англ. HTTP Service) – реализация спецификации OSGi
HTTP WhiteBoard и HTTP Service.
7. Maven плагин для создания бандлов (англ. Maven Bundle Plugin) –
плагин maven, который упрощает построение бандлов.
8. Репозиторий OSGi бандлов (англ. OSGi Bundle Repository) – сервис
репозитория бандлов, который упрощается поиск и развертывание
бандлов и их зависимостей [25].
Таким образом, проект Felix это не только сама платформа, но и
целый ряд полезных и нужных в работе с платформой OSGi инструментов
по крайне доступной лицензии. Кроме того, высокое качество данной
реализации и хорошая поддержка со стороны сообщества позволили
данному проекту стать одной из самых популярных реализаций OSGi.
Рассмотрев возможности платформы OSGi и ее самые популярные
реализации, перейдем непосредственно к модулям.
Как указывалось выше, модулем является бандл (англ. bundle)–
фундаментальный строительный блок при использовании платформы
OSGi. Именно в бандлах находится весь код приложения, которое нужно
пользователям, настройки, медиа ресурсы (изображения, звуки, шрифты и
34
т.п.). Бандл это файл, который имеет одно из двух расширений – .jar (Java
архив (англ. Java archive)) или .war (веб архив (англ. web archive)). Следует
отметить, что такие расширения могут быть и у простого архива Java,
который не является бандлом для OSGi платформы. Для того, чтобы
выяснить, является ли данный архив OSGi бандлом, необходимо
посмотреть его манифест (файл META-INF/MANIFEST.MF). Если в
манифесте присутствуют параметры, которые начинаются с "Bundle-", то
можно сделать вывод, что архив является OSGi бандлом.
Зависимости между бандлами выражаются статически в виде пакетов
(обычный Java пакет) и динамически в виде сервисов.
Если какой-то бандл зависит от внешнего класса, то этот бандл
должен импортировать пакет, который содержит этот класс. Например,
бандлу требуется класс me.pavel.temp.TempA из пакета me.pavel.temp,
тогда в манифесте этого бандла должно быть указано: "Import-Package:
me.pavel.temp".
Если бандл предоставляет какой-то класс другим бандлам, то этот
бандл должен экспортировать пакет, который содержит этот класс.
Например, бандл предоставляет класс me.pavel.api.ServiceManager из
пакета me.pavel.api, тогда в манифесте этого бандла должно быть указано:
" Export-Package: me.pavel.api" [24].
OSGi бандлы динамически устанавливаются, разрешаются, стартуют,
обновляются, останавливаются и удаляются. Платформа обеспечивает
строгие переходы между состояниями. Например, нельзя установить бандл
и перейти сразу к активному состоянию минуя состояние разрешенности и
активации. Переход между состояниями указан на рисунке 4. Далее мы
рассмотрим отдельно каждое возможное состояние бандла.
35
Рисунок 4. Жизненный цикл бандла [24].
Установлен (англ. installed). Cамое начальное состояние бандла,
когда он развертывается на платформе OSGi. Бандл в этом состоянии не
может быть сразу запущен, как видно из рисунка 4 – нет прямого перехода
из состояния установлен в состояние запуска (starting). Установленный
бандл также не является активным. Есть три возможных перехода: бандл
может быть разрешен, удален или обновлен. Установка бандла в
платформе не означает, что он готов к тому, чтобы его использовали.
Прежде всего нужно разрешить его зависимости.
Разрешен (англ. resolved). Cостояние при котором платформа
гарантирует, что все зависимости бандла обеспечиваются. Например, если
бандл А требует для своей работы бандл B, то бандл А может быть
разрешен только в том случае, если разрешен бандл B. Как только
зависимости разрешены бандл готов к тому, чтобы перейти в состояние
запуска. Разрешенный бандл может быть обновлен, что переводит бандл
обратно в состояние «установлен». Разрешенный бандл также может быть
и удален. Необходимо отметить, что разрешенный бандл не является
активным, в тоже время, он готов к активации.
update
refresh
uninstall
stop
stop
start
update
refresh
resolve
install
Installed
Resolved
Uninstalled
Starting
Active
Stopping
uninstall
36
Запущен (англ. starting). Разрешенный бандл может быть запущен.
Данное состояние переходное. Платформа осуществляет перевод бандла в
активное состояние. По факту, переход из состояния «запущен» в
состояние «активен» осуществляется неявно. Важно отметить, что когда
бандл в этом состояние происходит вызов метода start() активатора бандла.
Активен (англ. active). В этом состоянии бандл полностью разрешен,
обеспечивает и потребляет сервисы среды OSGi. Для того, чтобы
осуществлять какие-то переходы из данного состояния бандл прежде всего
должен быть остановлен.
Остановлен (англ. stopping). Переходное состояние при котором
бандл переводится из активного состояния в разрешенное состояние.
Бандл можно быть повторно запущен если он находится в разрешенном
состоянии. Важно указать, что когда бандл входит в это состояние после
вызова метода stop() активатора бандла.
Удален (англ. uninstalled). Переход в данное состояние подразумевает
удаление установленного или разрешенного бандла из среды OSGi (с
платформы OSGi) [5, с. 28-30].
Каждый бандл может также предоставлять сервисы. Сервис, подобно
бину (англ. bean) в платформах внедрения зависимостей (англ. Dependency
Injection, DI), является простым объектом Java. Он регистрируется в
реестре сервисов OSGi под именем одного или нескольких интерфейсов и
потребители сервиса, которые хотят воспользоваться им, могут найти
сервисы в реестре по имени интерфейса. Сервисы могут сами потреблять
другие сервисы, однако, они не соединяются в фиксированный граф, так
как сервисы добавляются и удаляются динамически в любое время.
Поэтому, формируются только временные связи с друг другом.
Проблема старта сервиса в этом случае легко решается – сервисы
стартуют в любом порядке. Предположим, что запускается бандл, который
37
содержит сервис B до запуска бандла, который содержит сервис А. В этом
случае, сервис B, использующий сервис А, ожидает пока сервис А не
станет доступен.
Возможно также обновлять индивидуальные компоненты без
перезагрузки всей системы. Когда обновляется сервис А, платформа OSGi
посылает события сервису B, чтобы он мог отслеживать ситуацию.
Сервисы работают согласно модели программирования, основанной
на интерфейсах. Единственное требование к сервису в том, что он должен
реализовывать интерфейс. Для этого может быть использован любой
интерфейс – или из базовой среды выполнения Java (Java Runtime
Environment (JRE)) или из любой библиотеки сторонних разработчиков.
Выбранный интерфейс или интерфейсы (объект в Java может
реализовывать N интерфейсов) формируют первичный механизм
адресации для сервиса. Таким образом, потребитель сервиса не должен
знать имени класса, который реализует сервис, а только имя интерфейса.
Это крайне важный момент, так как такая модель строго разделяет
интерфейс от реализации.
Реестр сервисов OSGi называется формой сервис-ориентированной
архитектуры (англ. Service Oriented Architecture (SOA)). Многие полагают,
что SOA связана, прежде всего с распределенными вычислениями, веб-
сервисами, SOAP и т.п. Однако, это только один из примеров SOA,
который на самом деле является лишь шаблоном или стилем архитектуры.
Заметим, что сервисы OSGi ограничены областью экземпляром одной
виртуальной машины.
В тоже время, динамические сервисы по сравнению со статическими
объектами добавляют некоторую сложность. Очевидно, что намного легче
использовать сервисы или объекты, о которых разработчик точно знает,
что они будут доступны постоянно на протяжении всей работы системы.
38
Однако, реальный мир не статичен, а, следовательно, появляется
необходимость разрабатывать системы, которые достаточно надежны,
чтобы работать с сущностями которые появляются и исчезают.
Наряду с этим, поверх реестра сервисов OSGi было разработано
несколько абстракций высокого уровня, которые в значительной мере
упрощают код, необходимый, чтобы поддерживать динамическое
поведение. Например, в платформе Spring поддержка DI достигается через
прямое использование реестра сервисов OSGi [3, с. 77-78].
В заключение, рассмотрим классический шаблон, состоящий из трех
модулей – см. рисунок 5. Бандл А содержит пакеты с API сервиса, бандл B
содержит реализацию сервиса, бандл С использует сервис, т.е. является
клиентом. В данном шаблоне наглядно представлены несколько основных
принципов использования платформы OSGi, которые видны на рисунке:
1) API отделено от реализации (Impl).
2) Клиент сервиса не владеет информацией о классе реализации, а знает
только об интерфейсе.
3) Клиент и реализация не связаны с друг другом, а взаимодействуют
через реестр сервисов.
Рисунок 5. Пример работы с сервисами OSGi.
Использует сервис
Предоставляет сервис
Бандл A (API)
Export-Package: me.pavel.api
Бандл B (Impl)
Import-Package: me.pavel.api
Бандл C (Client)
Import-Package: me.pavel.api
Реестр
сервисов
OSGi
39
2.2. Технология JPMS (Java Platform Module System)
Модульная система для платформы Java (англ. Java Platform Module
System (JPMS)) является результатом развития проекта Jigsaw, поэтому,
рассмотрим кратко основные этапы развития и цели данного проекта.
Работа над проектом Jigsaw началась в августе 2008 года. В 2014
году начинается проектирование и реализация для Java 9. В августе 2014
года создается JDK 9 сборки (англ. build) 27, который включает в себя
реорганизованный исходный код. В декабре 2014 создается JDK 9 сборки
41, который включает в себя реструктурированные образы времени
выполнения для поддержки модулей. Также, в декабре 2014
исполнительный комитет JCP (англ. Java Community Process) одобряет JSR
376 (англ. Java Specification Request) для JPMS. В апреле 2015 года
публикуется план закрытия внутреннего API. В сентябре 2015 создаются
первые сборки, содержащие прототип модульной системы. В марте 2016
года публикуется в спецификации начальный лист открытых задач (англ.
issues). Кроме того, в марте 2016 года сама модульная система,
соответствующая JSR 376, добавляется в JDK 9 сборки 111. В июле 2017
года работа над проектом Jigsaw была окончена и весь код был передан
для основного использования как часть JDK 9, который вышел 21 сентября
2017 года [52].
Считаем необходимым отметить два момента. Во-первых, модульная
система для платформы Java создавалась почти 10 лет, что свидетельствует
о большом объеме работ и высокой сложности задачи. Во-вторых, на
момент написания данной работы технология JPMS является очень новой
технологией, которая используется не более шести месяцев.
Разработчики проекта Jigsaw ставили следующие цели:
1. Упростить для разработчиков конструирование и поддержку
библиотек и больших приложений.
40
2. Улучшить безопасность и поддерживаемость платформы Java SE в
общем и JDK в частности.
3. Улучшить производительность приложений.
4. Обеспечить возможность разделения платформы Java SE и JDK на
небольшие компоненты для использования на устройствах с
ограниченными мощностями [52].
Все поставленные цели были успешно достигнуты и можно с
уверенностью сказать, что технология JPMS стала одним из сильнейших
эволюционных скачков для Java.
Приведем общие принципы использования технологии JPMS,
которые представлены на рисунке 6. Как видно на этом рисунке,
существует два типа модулей. Первый тип – стандартные модули Java SE и
JDK. Второй тип – модули приложения. Модули Java SE и JDK для версии
9 указаны на рисунке 7.
Рисунок 6. Схематичное представление использования технологии JPMS.
Аппаратное обеспечение
Драйвер
Драйвер
Драйвер
Операционная система
Среда выполнения Java SE 9
Модуль
приложения
Модуль
приложения
Модуль
приложения
Модуль
Java SE 9
Модуль
Java SE 9
Модуль
Java SE 9
41
Рисунок 7. Модули Java SE 9 и JDK 9 [51].
Из рисунка 7 видно, что при наименовании модулей применялись
определенные правила создания имен, а именно: все модули для Java SE
начинаются с "java.", все модули для JDK начинаются с "jdk." и все модули
для JavaFX начинаются с "javafx.". Кроме того, из данного рисунка видно,
что технология JavaFX, которая используется для построения
графического интерфейса пользователя, не входит в группу модулей Java
SE, а выносится отдельно. В тоже время, технологии Swing и AWT
являются частью Java SE и находятся в модуле java.desktop.
Технологию JPMS внесла изменения в библиотеки Java, в язык
программирования и среду выполнения, что свидетельствует о большом
влиянии JPMS на всю Java. В тоже время, для совместимости,
большинство существующего кода может игнорировать JPMS в Java SE 9,
что конечно очень удобно и необходимо для громадного количества
программ, разработанных для предыдущих версий Java.
Модули Java SE 9
и JDK 9
Модули Java SE:
java.activation, java.base, java.compiler, java.corba, java.datatransfer,
java.desktop, java.instrument, java.logging, java.management,
java.management.rmi, java.naming, java.prefs, java.rmi, java.scripting, java.se,
java.se.ee, java.security.jgss, java.security.sasl, java.sql, java.sql.rowset,
java.transaction, java.xml, java.xml.bind, java.xml.crypto, java.xml.ws,
java.xml.ws.annotation.
Модули JDK:
jdk.accessibility, jdk.attach, jdk.charsets, jdk.compiler, jdk.crypto.cryptoki,
jdk.crypto.ec, jdk.dynalink, jdk.editpad, jdk.hotspot.agent, jdk.httpserver,
jdk.incubator.httpclient, jdk.jartool, jdk.javadoc, jdk.jcmd, jdk.jconsole,
jdk.jdeps, jdk.jdi, jdk.jdwp.agent, jdk.jfr, jdk.jlink, jdk.jshell, jdk.jsobject,
jdk.jstatd, jdk.localedata, jdk.management, jdk.management.agent,
jdk.management.cmm, jdk.management.jfr, jdk.management.resource,
jdk.naming.dns, jdk.naming.rmi, jdk.net, jdk.pack, jdk.packager.services,
jdk.policytool, jdk.rmic, jdk.scripting.nashorn, jdk.sctp, jdk.security.auth,
jdk.security.jgss, jdk.snmp, jdk.xml.dom, jdk.zipfs.
Модули JavaFX:
javafx.base, javafx.controls, javafx.fxml,
javafx.graphics, javafx.media, javafx.swing,
javafx.web.