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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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