Существует ли обзор терминологии OSGi, фреймворков и их взаимосвязей?

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

Например: какая связь между Apache Felix, Equinox, Karaf, Jira OSGi, Spring DM, Aries Blueprint, Gemini Blueprint, iPOJO, Camel и т. д. и т. д.

Я знаю, что Equinox основан на Felix, и что варианты Blueprint и iPOJO в некоторой степени связаны с управлением компонентами, но как насчет декларативных служб? Является ли DS альтернативой Blueprint или Blueprint является реализацией декларативных служб?

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

Кто-нибудь знает, существует ли такой обзор - возможно, графический - экосистемы OSGi?

С наилучшими пожеланиями.


jira osgi apache-felix equinox declarative-services
person Tormod Haugene    schedule 22.11.2018    source источник

Ответы (1)


arrow_upward
11
arrow_downward

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

  1. «OSGi Framework» — это реализация основной спецификации OSGi. Он должен был бы реализовать концепцию пакетов, установку и разрешение пакетов, жизненный цикл, сервисы и так далее.
  2. Apache Felix — это реализация OSGi Framework.
  3. Equinox также является реализацией OSGi Framework. Он не основан на Apache Felix, но заимствует у него небольшое количество кода. Equinox — это реализация OSGi, используемая в Eclipse и т. д.
  4. Karaf по сути является серверным продуктом приложений. Он использует Felix в качестве основной реализации OSGi Framework, а затем добавляет множество дополнительных функций сверху.
  5. Jira OSGi: не знаю. Я считаю, что Jira внутренне реализована с OSGi, но я не знаю никаких подробностей.
  6. Spring DM — устаревший/мертвый проект. Это был способ разделения графа компонента Spring на модульное приложение с использованием OSGi.
  7. Blueprint — это спецификация, опубликованная OSGi Alliance. Это одна из спецификаций Compendium, т. е. дополнений, которые не требуются в ядре. Blueprint был вдохновлен Spring-DM и стандартизирует идею связывания bean-компонентов внутри и между пакетами.
  8. Gemini Blueprint — это реализация спецификации Blueprint. Gemini начали с кода Spring-DM и развили его, чтобы он соответствовал (тогда) новой спецификации.
  9. Aries Blueprint также является реализацией Blueprint. Это «чистая комната», т.е. реализованная с нуля в соответствии со спецификацией, а не созданная из более старого кода Spring.
  10. Декларативные службы — это спецификация OSGi из Компендиума. Это альтернативный способ определить компоненты и связать их вместе с помощью сервисов в пакетах. Многие опытные разработчики OSGi, в том числе и я, считают, что Declarative Services НАМНОГО превосходят Blueprint. Я могу подробнее рассказать о причинах этого, если хотите.
  11. iPOJO — это еще один другой способ определения компонентов и их соединения друг с другом. Он не соответствует ни одной спецификации OSGi.
  12. Camel — это библиотека интеграции, в основном используемая для приложений обмена сообщениями. Он не имеет ничего общего с OSGi, за исключением того, что он может работать под OSGi.

Надеюсь, это поможет.

person Neil Bartlett    schedule 22.11.2018
comment
Это именно та информация, которая мне нужна. Большое тебе спасибо! Я был бы очень признателен за некоторые советы относительно Blueprint и DS, если у вас есть такая возможность. Я на самом деле пытаюсь выяснить, какую реализацию службы использовать, но не смог отличить концепции от фреймворков (отсюда и вопрос). Кроме того, если есть какие-то жизненно важные технологии, о которых, по вашему мнению, мне следует знать, это тоже было бы очень полезно. Я просто переформулирую вопрос, чтобы впоследствии он лучше соответствовал вашему ответу. ;-) - person Tormod Haugene; 22.11.2018