Как OSGi управляет взаимодействием компонентов, работающих в отдельных JVM? - PullRequest
13 голосов
/ 17 декабря 2008

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

Глядя на пример Феликса DictionaryService, я не совсем понимаю, что происходит. Является ли OSGi отдельным экземпляром JVM, в который вы загружаете пакеты, которые затем могут найти друг друга?

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

В этом последнем случае, как компонент, работающий в одной JVM, взаимодействует с другим компонентом в отдельной JVM? Могут ли два компонента «использовать» друг друга так, как если бы они работали в одной и той же JVM (то есть с помощью локальных вызовов методов), и как OSGi управляет распределением данных по сети (например, нужно ли использовать Serializable) ?

Или автор компонента должен использовать какой-то другой особый механизм (предоставляемый OSGi или написанный самим) для связи между удаленными компонентами?

Любая помощь высоко ценится!

Ответы [ 9 ]

6 голосов
/ 16 января 2009

Да, OSGi работает только с пакетами и службами, работающими на одной и той же виртуальной машине. Однако следует отметить, что отличительной особенностью OSGi является то, что она облегчает запуск нескольких приложений (контролируемым образом и совместное использование общих модулей) на одной и той же JVM.

Когда речь идет о доступе к службам вне клиентской JVM, в настоящее время не существует стандартизированного решения. Paremus Infiniflow и производный проект с открытым исходным кодом Newton используют SCA-подход. В следующем выпуске 4.2 спецификаций OSGi будет решена одна сторона проблемы, а именно, как использовать универсальное программное обеспечение для распространения таким образом, чтобы оно могло приносить удаленные сервисы в JVM клиента.

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

4 голосов
/ 19 декабря 2008

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

3 голосов
/ 28 декабря 2008

Пока нет, я думаю, что над ним готовятся к следующему выпуску.

Но некоторые компании уже внедрили распределенные ОСГИ. Один из тех, кого я знаю, это Infiniflow от Paremus (http://www.paremus.com/products/products.html).. В linkedin они также работают над этим. Подробнее здесь: Создание архитектуры следующего поколения Linkedin с osgi и здесь: Matt raible: строительная архитектура следующего поколения

Вот краткий обзор изменений для OSGI 4.2: Некоторые соображения по поводу черновика OSGi R4.2 , В RFC-119 есть раздел, посвященный распределенной OSGi.

2 голосов
/ 18 марта 2009

Альянс OSGi работает над стандартом для распределенной OSGi:

http://www.osgi.org/download/osgi-4.2-early-draft2.pdf


Существует даже ранняя реализация Apache этого нового стандарта:

http://cxf.apache.org/distributed-osgi.html

2 голосов
/ 18 декабря 2008

AFAIK, пакеты работают в одной и той же JVM, но не загружаются с использованием одного загрузчика классов (поэтому вы можете использовать две разные версии одного и того же пакета одновременно).

Для взаимодействия с компонентами в другой JVM вы должны использовать сетевой протокол, такой как rmi.

1 голос
/ 10 июня 2011

Ссылка "введение" на самом деле не вступление, а запись в FAQ. Для получения дополнительной информации см. http://www.osgi.org/About/WhatIsOSGi Не трудно найти, я бы подумал.

В любом случае, OSGi - это SOA, встроенная в VM. То есть OSGi Framework - это то, что происходит внутри виртуальной машины, она предоставляет структуру для структурирования вашего приложения внутри виртуальной машины, поэтому вы можете создавать ее слишком сильно из компонентов. Таким образом, ядро ​​не имеет ничего общего с дистрибуцией , оно полностью не замечает, кто реализует сервисы, оно просто обеспечивает механизм для модулей, чтобы встретиться друг с другом в слабосвязанной форме.

Тем не менее, модель µService упрощает соединения между модулями, и оказывается, что вы можете создать поддержку поверх платформы, которая обеспечивает распределение для других компонентов. В последних выпусках мы указали некоторые механизмы, которые делают это стандартизированным в ядре и предоставляют специальный сервис Remote Service Admin, который может управлять распределенной топологией.

1 голос
/ 20 февраля 2009

Первоначальная проблема OSGI была больше связана с распространением кода (а затем с настройкой пакета), чем с распространением исполнения.

Люди, которые смотрят на распределенные компоненты, скорее смотрят на SCA

1 голос
/ 18 декабря 2008

@ Patriarch24

Принятый ответ на этот вопрос , похоже, указывает на иное (если я не читаю его). Также взято из FAQ:

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

(Подчеркну мое). Хотя в том же FAQ он описывает OSGi как in-VM .

Почему я так растерялся по этому поводу? Почему такой основной вопрос о десятилетней технологии неясен?

0 голосов
/ 27 июля 2011

Если вы ищете распределенную среду выполнения OSGi Cloud, то Paremus Service Fabric (https://docs.paremus.com/display/SF16/Introduction) предоставляет эти возможности.

Одна или несколько систем, каждая из которых состоит из нескольких сборок OSGi (Blueprint или декларативные службы), могут быть динамически развернуты и поддерживаться в совокупности сред выполнения OSGi (Knopflerfish, Felix или Equinox).

Предоставляется облегченный удаленный каркас RSA, который обеспечивает обнаружение служб по умолчанию с использованием DDS (очень хорошая технология обмена сообщениями промежуточного программного обеспечения) - (возможно, будет использован ZooKeeper и другой подход). В настоящее время поддерживаются следующие протоколы удаленного подключения: RMI и Avro.

Привет

Richard

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...