Я пытался понять немного больше о более широкой картине OSGi, не прочитав всю спецификацию. Как и во многих вещах, введение Serializable))?
Или автор компонента должен использовать другой механизм (предоставляемый OSGi или написанный самим) для связи между удаленными компонентами?
Любая помощь очень ценится!
Да, OSGi работает только с пакетами и службами, запущенными на одной виртуальной машине. Однако следует отметить, что это отличная особенность OSGi, которая облегчает запуск нескольких приложений (контролируемым образом и совместное использование общих модулей) на одной и той же JVM вообще.
Когда речь заходит о доступе к службам за пределами JVM клиентов, в настоящее время нет стандартизованного решения. Paremus Infiniflow и производный проект с открытым исходным кодом Newton используют подход SCA. Предстоящая версия OSGi 4.2 выпуска будет посвящена одной стороне проблемы, а именно, как использовать универсальное программное обеспечение для распространения таким образом, чтобы оно могло передавать удаленные службы в клиентскую JVM.
Как кто-то упомянул R-OSGi, этот подход также касается другой стороны проблемы, заключающейся в том, как управлять зависимостями между распределенными платформами OSGi. Поскольку R-OSGi не является общим программным обеспечением распространения, но явно рассматривает проблемы жизненного цикла и управление зависимостями пакетов OSGi.
Насколько я знаю, OSGi не решает эту проблему из коробки. Существуют OSGi-пакеты, например Удаленные OSGi, которые позволяют программисту распространять службы по сети.
Пока нет, я думаю, что это будет работать для следующего выпуска.
Но некоторые компании уже реализовали распределенные osgi. Я знаю, что это Infiniflow Паремуса (http://www.paremus.com/products/products.html). В linkedin они также работают над этим. Подробнее здесь: Строительство Linkedin следующей архитектуры gen с osgi и здесь: Мэтт-рейд: здание, связанное с архитектурой следующего поколения
Вот сводка изменений для OSGI 4.2: Некоторые соображения по проекту OSGi R4.2, Там есть раздел о RFC-119 работа с распределенными OSGi.
AFAIK, пучки работают в одном JVM, но не загружаются с использованием одного и того же загрузчика классов (поэтому вы можете одновременно использовать две разные версии одного и того же пакета).
Чтобы взаимодействовать с компонентами в другой JVM, вы должны использовать сетевой протокол, такой как rmi.
Альянс OSGi работает над стандартом для распределенных OSGi:
http://www.osgi.org/download/osgi-4.2-early-draft2.pdf
Существует даже ранняя реализация Apache этого нового стандарта:
@Patriarch24
Принятый ответ на этот вопрос, казалось бы, указывает на другое (если я не неправильно его понимаю). Также, взятый из FAQ:
Платформа OSGi Service предоставляет функции для динамического изменения композиции на устройстве различных сетей без необходимости перезапуска
(Подчеркните мое собственное). Хотя в тех же FAQ он описывает OSGi как in-VM.
Почему я так запутался в этом? Почему такой базовый вопрос о десятилетней технологии не ясен?
Исходная проблема OSGI была больше связана с распределением кода (а затем с конфигурацией пакета), чем с распределением исполнения.
Люди, которые смотрят на распределенные компоненты, скорее смотрят на SCA
Ссылка "Введение" на самом деле не является вступительным словом, это элемент часто задаваемых вопросов. Для получения дополнительной информации см. http://www.osgi.org/About/WhatIsOSGi Не сложно найти, я бы подумал.
Во всяком случае, OSGi является SOA в VM. То есть OSGi Framework - это то, что происходит внутри виртуальной машины, она обеспечивает структуру для структурирования вашего приложения внутри виртуальной машины, поэтому вы можете в значительной степени создавать ее из компонентов. Таким образом, ядро имеет nothing, чтобы делать с дистрибутивом, он совершенно не обращает внимания на то, кто реализует сервисы, он просто обеспечивает механизм для того, чтобы модули встречались друг с другом по-разному.
Тем не менее, модель μService подтверждает соединение между модулями, и оказывается, что вы можете построить поддержку поверх фреймворка, который обеспечивает распределение другим компонентам. В последних выпусках мы указали некоторые механизмы, которые делают это стандартизованным в ядре и предоставляют специальный сервис Remote Service Admin, который может управлять распределенной топологией.
Если вы ищете распределенное OSGi-ориентированное облачное исполнение - тогда эти сервисы предоставляют сервисная ткань Paremus Service (https://docs.paremus.com/display/SF16/Introduction).
Одна или несколько систем, каждая из которых состоит из нескольких сборок OSGi (Blueprint или Declarative Services), могут быть динамически развернуты и поддерживаться через совокупность рамок среды OSGi (Knopflerfish, Felix или Equinox).
Предоставляется легкая дистанционная инфраструктура RSA, которая обеспечивает обнаружение службы по умолчанию с использованием DDS (очень хорошая технология обмена промежуточными сообщениями) - (можно подумать, что ZooKeeper и другой подход могут быть использованы). В настоящее время поддерживаемые протоколы ремотирования включают RMI и Avro.
Привет
Ричард