Состояние службы администрирования развертывания OSGi

Question

Приложения OSGi состоят из модулей, называемых пакетами. Проблема в том, что любое приложение с разумным размером будет иметь большое количество пакетов (может быть легко сотен, просто посмотрите на каталог плагинов вашей Eclipse IDE), чтобы вы захотели получить более крупную детализацию, чем отдельные пакеты при управлении или развертывании приложения.

В состав спецификации OSGi Compendium Spec входит служба администрирования развертывания, в которой определены пакеты развертывания в виде набора пакетов и других артефактов (таких как конфигурация), которые могут быть развернуты, обновлены, удалены и т. Д. Как единое целое.

К сожалению, я не смог найти много информации о реализации, инструментах или пользователях развертывания администратора развертывания.

Каков статус этой услуги? Есть ли у кого-нибудь опыт, мнение или рекомендации относительно администратора развертывания?

Кроме того, Spring dm-server имеет концепцию набора пакетов приложений (файлы PAR) и Eclipse Equinox работает над вложенными фреймами для решения проблемы, я думаю. Как эти подходы относятся к администратору развертывания?

Answer 1

Администратор развертывания является одним из тех сервисов OSGi, которые, как представляется, привлекают относительно мало внимания. Очевидно, что существует спецификация и, следовательно, предположительно эталонная реализация и тесты соответствия. Реализация была внесена в проект Apache Felix, но, похоже, практически полностью потоплена.

Я изучил администратор развертывания при разработке поддержки файла PAR в SpringSource dm Server, но модель была неприемлема для наших случаев использования. В частности, пакет с заданным символическим именем (и любой версией) может не находиться в двух разных пакетах развертывания, которые установлены в одной и той же инфраструктуре OSGi.

Напротив, два файла PAR, установленные в одном экземпляре сервера dm, могут содержать набор с указанным символическим именем пакета (и той же или другой версией пучка). Мы рассматриваем это как требование масштабирования приложения: мы не хотели, чтобы крупные приложения «сталкивались» просто потому, что их разработчикам приходилось упаковывать один и тот же пакет. Услуги также доступны в файлах PAR.

В dm Server 2.0 мы обобщили концепцию PAR в «планах», которые являются файлами, ссылающимися на имя и версию типа, на артефакты, которые должны быть установлены. План может быть ограничен (например, PAR) или не обладать полномочиями и может быть атомарным (это означает, что жизненный цикл его содержимого привязан атомарно к жизненному циклу плана, например PAR) или неатомному.

Вложенные фреймворки также исследуются как возможный будущий стандарт OSGi для удовлетворения требований к области применения приложений, но с довольно разной точкой проектирования для областей сервера dm. Вложенная структура не может автоматически видеть пакеты и службы в своей родительской структуре. Таким образом, модель по умолчанию является изолированной, независимо от того, является ли это изоляцией дочерних инфраструктур друг от друга или изолированием дочерних и родительских фреймворков. dm Области сервера преднамеренно изолируют детей друг от друга, но изолируют ребенка от родителя в одном направлении: ребенок может видеть все пакеты и службы своего родителя.

Answer 2

Возможно, вам будет интересно узнать, что Apache Ace (который в настоящее время находится в стадии инкубации и наращивания) может динамически генерировать пакеты развертывания для администратора развертывания и использует (по умолчанию при инициализации целевой OSGi) администратор развертывания Felix.

Поскольку сайт находится в стадии разработки: Apache Ace - это система распространения программного обеспечения, которая позволяет централизованно управлять и распространять программные компоненты, данные конфигурации и другие артефакты для целевых систем. Он построен с использованием OSGi, а может быть развернут в разных топологиях. Целевые системы обычно также основаны на OSGi, но не обязательно.