Как лучше всего начать работу с OSGI?

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

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

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

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

Ответов (8)

Решение

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

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

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

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

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

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

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

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

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

ИЛИ

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

Вторую книгу я не читал сам, но слышал о ней хорошие отзывы.

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

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

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

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

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

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

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

Если вы начинаете с OSGi, следует помнить о нескольких вещах.

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

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

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

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

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

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

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

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

Затем существует множество реализаций служб компендиума OSGi:

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

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

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