Что делает модуль / сервис / часть функциональности приложения особенно хорошим кандидатом на модуль OSGi?
Я заинтересован в использовании OSGi в своих приложениях. Мы являемся магазином Java и широко используем Spring, поэтому я склоняюсь к использованию Spring Dynamic Modules для сервисных платформ OSGi (tm) . Я ищу хороший способ включить немного OSGi в приложение в качестве пробной версии. Кто-нибудь здесь использовал эту или аналогичную технологию OSGi? Есть ли подводные камни?
@ Николас - Спасибо, я видел это. Это хороший учебник, но я больше ищу идеи о том, как сделать мой первый «настоящий» OSGi-пакет, а не пример Hello World.
@ Давид - Спасибо за ссылку! В идеале, с новым приложением, я бы хотел, чтобы все было динамичным. Однако сейчас я хочу представить его в небольшой части существующего приложения. Предполагая, что я могу выбрать любую часть приложения, какие факторы следует учитывать, чтобы сделать эту часть лучше или хуже, чем для морской свинки OSGi?
Ну, поскольку у вас не может быть одной части 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 R4 : получите PDF-файлы со спецификациями Core и Compendium, они канонические, авторитетные и очень удобочитаемые. Всегда имейте под рукой ярлык к ним, вы с ними проконсультируетесь.
- Ознакомьтесь с лучшими практиками OSGi, есть большой набор вещей, которые вы можете сделать, но несколько меньший набор вещей, которые вы должны делать, и есть некоторые вещи, которые вы никогда не должны делать (например, DynamicImport: *).
Некоторые ссылки:
- OSGi лучшие практики и использование Apache Felix
- Питер Криенс и Б.Дж. Харгрейв в Sun представили лучшие практики OSGi
- Одной из ключевых концепций OSGi являются сервисы, узнайте, почему и как они вытесняют шаблон Listener с шаблоном Whiteboard
Spring DM Google Group не очень отзывчивый и дружелюбный в моем опыте
Spring DM Google Group является не активным и переехал в Eclipse.org как Blueprint проекта Geminiкоторый имеет форума здесь .
Мне очень нравятся учебники по Apache Felix . Тем не менее, я думаю, что в целом использование OSGi в вашем приложении не является одним из тех решений «давайте использовать эту инфраструктуру, потому что это обман». Это скорее вопрос дизайна, но все, что OSGi дает вам в плане дизайна, вы можете иметь и с ванильной Java.
Что касается времени выполнения, вы не можете просто добавить существующее приложение и включить его OSGi. Это должен быть дизайн, чтобы быть динамичным. Spring DM позволяет легко скрыть это от вас, но он все еще там, и вы должны знать об этом.
Является ли ваше существующее приложение монолитным или многоуровневым в отдельных процессах / слоях?
Если многоуровневый, вы можете преобразовать средний / app-уровень для запуска в контейнере 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
Попробуйте http://neilbartlett.name/blog/osgibook/ . Книга содержит примеры с лучшими практиками OSGi.
Изучая новые технологии, богатый инструментарий поможет вам справиться с большими проблемами. На данный момент сообщество на ops4j.org предоставляет богатый набор инструментов под названием «PAX», который включает в себя:
- Pax Runner : легко бегать и переключаться между Феликсом, Равноденствием, Нопфлерфишем и Консьержем
- Pax Construct : легко и просто создавать, организовывать и создавать проекты OSGi
- Pax Drone : тестируйте свои OSGi-комплекты с помощью Junit, оставаясь независимым от фреймворка
Тогда есть много реализаций сервисов OSGi Compendium:
- Pax Logging (логирование),
- Pax Web (сервис http),
- Pax Web Extender (поддержка войны),
- Pax Coin (конфигурация),
- Pax Shell (реализация оболочки, часть следующего выпуска osgi)
- и многое другое.
... и есть полезное, независимое от фреймворка сообщество, но теперь это реклама ;-)
Этот ответ приходит спустя почти 3 года после того, как вопрос был задан, но ссылка, которую я только что нашел, действительно хороша , особенно для начинающих, использующих maven. Пошаговое объяснение.
Попробуйте http://njbartlett.name/files/osgibook_preview_20091217.pdf
ИЛИ
Вторая - это не книга, которую я прочитал сам, но я слышал о ней много хорошего.
Первый был очень полезен для меня. Сначала он проведет вас через архитектуру, а затем он перейдет к OSGi.