Существует ли обзор терминов OSGi, структур и их отношений? - PullRequest
Новая
       84

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

0 голосов
/ 22 ноября 2018

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

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

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

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

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

С уважением.

1 Ответ

0 голосов
/ 22 ноября 2018

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

  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 - устаревший / мертвый проект.Это был способ разделения графа bean-компонента Spring на модульное приложение с использованием OSGi.
  7. Blueprint - это спецификация, опубликованная OSGi Alliance.Это одна из спецификаций Компендиума, то есть дополнения, которые не требуются в Core.Проект Blueprint был вдохновлен Spring-DM и стандартизирует идею соединения компонентов внутри и между пакетами.
  8. Gemini Blueprint является реализацией спецификации Blueprint.Gemini начал с кода Spring-DM и усовершенствовал его для соответствия (тогда) новой спецификации.
  9. Aries Blueprint также является реализацией Blueprint.Это «чистая комната», то есть реализованная с нуля в соответствии со спецификацией, а не развитая из более старого кода Spring.
  10. Декларативные службы - это спецификация OSGi из Компендиума.Это альтернативный способ определить компоненты и связать их вместе, используя сервисы между пакетами.Многие опытные разработчики OSGi, в том числе и я, считают, что декларативные сервисы намного лучше, чем Blueprint.Я могу подробнее рассказать о причинах этого, если хотите.
  11. iPOJO - это еще один другой способ определения компонентов и их соединения.Он не соответствует какой-либо спецификации OSGi.
  12. Camel - это библиотека интеграции, в основном используемая для приложений обмена сообщениями.Он не имеет ничего общего с OSGi, за исключением того, что он может работать под OSGi.

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

...