Какой лучший способ начать работу с OSGI?

Что делает функциональность модуля/службы/бит приложения особенно хорошим кандидатом для модуля OSGi?

Я заинтересован в использовании OSGi в моих приложениях. Мы являемся магазином Java, и мы довольно широко используем Spring, поэтому я склоняюсь к использованию Spring Динамические модули для платформ OSGi (tm). Я ищу хороший способ включить немного OSGi в приложение в качестве пробной версии. Кто-нибудь здесь использовал эту или аналогичную технологию OSGi? Есть ли подводные камни?

@Николас - Спасибо, я видел это. Это хороший учебник, но я больше ищу идеи о том, как сделать свой первый "настоящий" пакет OSGi, в отличие от примера Hello World.

@david - Спасибо за ссылку! В идеале, с помощью нового приложения, я бы разработал все, чтобы быть динамичным. Тем не менее, я ищу сейчас, чтобы представить его в небольшом фрагменте существующего приложения. Предполагая, что я могу выбрать любую часть приложения, каковы некоторые факторы, которые могли бы сделать этот кусок лучше или хуже, чем морская свинка OSGi?

Ответ 1

Ну, так как у вас не может быть одной части OSGi и одной части, отличной от OSGi, вам нужно будет сделать все приложение OSGi. В своей простейшей форме вы делаете один комплект OSGi из своего приложения. Очевидно, что это не самая лучшая практика, но может быть полезно почувствовать развертывание пакета в контейнере OSGi (Equinox, Felix, Knoplerfish и т.д.).

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

Некоторая помощь может быть получена из таких инструментов, как JDepend, который может показать вам соединение пакетов Java с другими пакетами/классами в вашей системе. Пакет с низкой эфферентной муфтой должен быть легче извлекать в пучок OSGi, чем один с высокой эфферентной муфтой. Еще больше архитектурной проницательности можно получить с помощью таких инструментов, как Structure 101.

Чисто на техническом уровне, ежедневно работая с приложением, состоящим из 160 пакетов OSGi и используя Spring DM, я могу подтвердить, что переход от "нормального" Spring к Spring DM в значительной степени обезболивает. Дополнительное пространство имен и тот факт, что вы можете (и должны) изолировать вашу специфическую конфигурацию OSGi Spring в отдельных файлах, упрощает работу как с сценариями развертывания OSGi, так и без них.

OSGi - это глубокая и широкая модель компонентов, документация, которую я рекомендую:

Спецификация OSGi R4: получить PDF файлы спецификации Core и Compendium, они являются каноническими, авторитетными и очень читабельными. Имейте ярлык для них в любое время, вы обратитесь к ним.
Читайте в лучших примерах OSGi, есть большой набор вещей, которые вы можете делать, но несколько меньший набор вещей, которые вы должны делать, и есть некоторые вещи, которые вы должен никогда не делать (DynamicImport: * например).

Некоторые ссылки:

лучшие практики OSGi и использование Apache Felix
Peter Kriens и BJ Hargrave в презентации Sun о лучших практиках OSGi
одна из основных концепций OSGi - это службы, узнайте, почему и как они вытесняют шаблон Listener с планшетной доски
~~Spring Группа Google DM > очень отзывчива и дружелюбна в моем опыте~~
Spring Группа Google DM больше не активна и перешел на Eclipse.org в качестве проекта Gemini Blueprint, в котором есть форум здесь.

Ответ 2

Когда вы изучаете новую технологию, богатую инструментами, вы попадаете в вещи без больших головных болей. На данный момент сообщество ops4j.org предоставляет богатый набор инструментов под названием "PAX", который включает в себя:

Pax Runner. Запустите и переключайтесь между Felix, Equinox, Knopflerfish и Concierge легко.
Pax Construct: создавать, организовывать и создавать проекты OSGi с помощью maven легко
Pax Drone. Проверьте свои пакеты OSGi с помощью Junit, будучи независимыми от структуры (использует PaxRunner).

Тогда существует множество реализаций сервисов compigium OSGi:

Запись в Pax (ведение журнала),
Pax Web (служба http),
Расширитель веб-страниц Pax (поддержка войны),
Pax Coin (конфигурация),
Pax Shell (реализация оболочки, часть следующего выпуска osgi)
и многое другое.

.. и есть полезное, независимое от платформы сообщество, - но теперь это реклама;-)

Ответ 3

Этот ответ наступает через 3 года после того, как был задан вопрос, но ссылка которую я только что нашел, действительно хороша, особенно для стартеров, использующих maven. Пошаговое объяснение.

Ответ 4

Попробуйте http://neilbartlett.name/blog/osgibook/. В книге есть примеры с примерами OSGi.

Ответ 5

Попробуйте http://njbartlett.name/files/osgibook_preview_20091217.pdf

ИЛИ

http://www.manning.com/hall/

Вторая - это не книга, которую я прочитал сам, но я слышал хорошие вещи об этом.

Первое было очень полезно для меня. Сначала он берет вас через архитектуру, а затем берется за OSGi.

Ответ 6

Является ли ваше существующее приложение монолитным или многоуровневым в отдельных процессах/слоях?

Если многоуровневый, вы можете преобразовать средний/уровень приложения для работы в контейнере OSGi.

В моем опыте команды мы обнаружили, что пытались сделать веб-материал в OSGi болезненным. Другими причинами боли являются Hibernate и Jakarta Commons Logging.

Я нахожу спецификации OSGi довольно читаемыми, и я рекомендую вам распечатать блок-схему, которая показывает алгоритм загрузки классов. Я гарантирую, что у вас будут моменты, "почему я получаю NoClassDefFoundError?": Блок-схема подскажет вам, почему.

Ответ 7

Есть несколько соображений, которые следует иметь в виду, если вы начинаете с OSGi.

Как уже упоминалось в этом разделе, знание о загрузке классов действительно важно. По моему опыту, все рано или поздно сталкиваются с проблемами.

Еще одна важная вещь, которую нужно помнить: никогда не держите ссылки! Посмотрите на шаблон доски, на котором строится концепция OSGi (см. Ссылку в одном из других ответов).

По моему опыту вы не должны пытаться преобразовать монолитное приложение в OSGi-based. Это обычно приводит к плохому и неуправляемому беспорядку. Начните заново.

Загрузите одну из свободно доступных автономных реализаций oSGi. Я нашел Knopflerfish довольно хорошим и стабильным (я использую его во многих проектах). Он также поставляется с большим количеством исходного кода. Вы можете найти его здесь: http://www.knopflerfish.org

Еще один хороший учебник можно найти здесь. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

Питер Криенс из Альянса OSGi дал хорошее интервью: http://www.infoq.com/interviews/osgi-peter-kriens. Его домашнюю страницу и блог (который всегда хорошо читается, можно найти здесь: http://www.aqute.biz

Ответ 8

Мне очень нравится Учебники Apache Felix. Тем не менее, я думаю, что в целом использование OSGi в вашем приложении не является одним из тех, "допустивших использование этой структуры, потому что это реклама". Это скорее вопрос дизайна, но затем все, что OSGi дает вам с точки зрения дизайна, вы можете иметь и с ванильной Java.

Что касается среды выполнения, вы не можете просто добавить существующее приложение и включить его OSGi. Он должен быть динамичным. Spring DM позволяет легко скрыть это от вас, но он все еще существует, и вам нужно знать об этом.