Я разрабатываю семантическое приложение поиска в java. Чтобы сделать приложение модульным, я думал использовать архитектуру osgi. Но поскольку я новичок в osgi, я понятия не имею о плюсах и минусах использования. Может ли кто-нибудь объяснить преимущества/недостатки использования osgi и какое приложение будет полезно при использовании osgi/то, что приложение получит, сделав это?
Спасибо!
В нескольких словах OSGi - это стандарт, используемый для создания модульных приложений. Он добавляет новый уровень модульности - пакеты (например, компоненты, модули). В каждом пакете содержатся классы и интерфейсы, и что самое главное, он должен явно указывать:
С технической точки зрения пачки представляют собой файлы jar, которые имеют бит расширенного файла META-INF/MANIFEST.MF. Вся вышеупомянутая информация сохраняется в файле MANIFEST.MF.
С практической точки зрения эта очевидность имеет как преимущества, так и недостатки. Для меня самым большим преимуществом является то, что вы вынуждены думать о своей архитектуре, модулях и взаимодействии между ними больше, чем в стандартных приложениях. Это может создать лучшую архитектуру, где каждый модуль отвечает за четко определенные задачи и модули могут быть повторно использованы. Если дело доходит до недостатков, создание множества модулей иногда может быть болезненным. Достаточно легко иметь много модулей, и если у вас их действительно много, может быть сложно поддерживать все зависимости между модулями (циклы зависимостей весьма болезненны).
OSGi - это не только стандарт построения только модульных приложений. Он также определяет среду, в которой существуют и выполняются пакеты. Об этом вам следует знать - при использовании OSGi вы должны запустить приложение в специальной среде. Эта среда (например Eclipse Equinox) отвечает за запуск вашего приложения. Это дает некоторые причудливые возможности. Например, вы можете добавить пакет в уже запущенное приложение без необходимости останавливать это приложение - это может быть очень важным элементом в некоторых типах приложений (но IMHO там не так много приложений, которые действительно понадобятся).
Что действительно важно, так это факт, что некоторые библиотеки с открытым исходным кодом могут быть не полностью совместимы с инфраструктурой OSGi, и может быть трудно использовать их из коробки, как и в стандартных приложениях Java (помните, что в OSGi все должен быть связкой). Однако множество популярных библиотек были объединены в пакеты - например, Spring предоставляет пакет репозитория, который содержит много популярных библиотек (но не все).
OSGi довольно сложный и трудно описать его и его возможности в нескольких словах. Я написал только самые важные (IMO) элементы OSGi. Но OSGI намного больше, например. связки могут отправлять события друг другу, они могут предоставлять услуги друг другу. Если вас интересует более подробная информация, я предлагаю пройти учебник. Я могу рекомендовать этот в Java World. После этого вы можете взглянуть на эту бесплатную электронную книгу об OSGi (она содержит много деталей). Все подробности об OSGi можно найти в официальных спецификациях, но я бы не сказал, что их легко читать (по крайней мере в начале) - вы можете найти их здесь (перед загрузкой вам придется принять лицензию и некоторые юридические уведомления).
Подводя итог, я думаю, что OSGi полезен при создании модульных приложений, но это точно не бесплатно. Это довольно тяжелый стандарт, который может запретить вам делать что-то и заставлять вас делать то, что делает OSGi.
Некоторые связанные вопросы SO:
Мой личный (2 года) опыт работы с OSGI заключается в том, что технический законопроект превосходит функциональные преимущества на порядок.
Я столкнулся с ситуациями: вам нужно было бы создать/отредактировать 25 + pom файлы, чтобы реализовать один макет линейки!
Дизайн играет большую роль, но я нахожу, что это вызывает беспокойство, что разработчики становятся экспертами по темам (например, maven), которые не влияют на ценность для клиента.
Кроме того, этот подход не очень хорошо справляется с Agile. Фактически, это было бы отлично подходит для... Waterfall
Все это касается вашего основного внимания ИМХО. Конечные результаты против шаблонов строительства.
Короче говоря, OSGI не злой, но он не подходит для небольших команд и быстрого выхода на рынок.
Вам нужно будет написать книгу, чтобы правильно ответить на этот вопрос. На самом деле на эту тему написано много книг. Если вы действительно хотите узнать об OSGi, я рекомендую искать такую книгу.
OSGi - это модуль модульности Java. У этого нет никакой надежной конкуренции в этой области. Любое приложение может быть более модульным, но модульность не бесплатна. Легче бросить все в один гигантский загрузчик классов и не слишком задумываться о взаимоотношениях ваших компонентов. Если вы решите дать OSGi попробовать, отличная утилита PDE, часть Eclipse поддерживает разработку OSGi, ориентированную не на Eclipse, и упрощает работу с OSGi.
Мое личное мнение заключается в том, что OSGi приносит больше боли, чем пользы. Если вам действительно нужно приложение с подключаемым модулем, вы можете начать использовать OSGi, но вам нужно написать код подключаемым способом, что не так просто (даже при установке плагина в eclipse рекомендуется перезапустить eclipse, не знаю, почему он использует OSGi)
Я разработал два проекта на работе с помощью OSGi, это очень медленно в начале проекта, потому что вам нужно обернуть множество публичных библиотек, и не все из них можно обернуть, потому что вы можете столкнуться с классом ClassNotDefoundError при запуске из-за проблем с загрузкой классов при работе с прокси-объектами.
Вся модульность, которую мы имеем в проектах, использующих OSGi, может быть достигнута с использованием только maven, при работе с OSGi никто не принуждает вас писать много мелкозернистых пакетов, если вы хотите, чтобы вы могли написать приложение с отверстиями в одном большом комплекте,
Если мы говорим о потере связи между компонентами, это может быть достигнуто с помощью автоматической проводки из spring -коррекции или схемы вложения зависимостей google-guice.