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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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