Каковы основные различия между OSGi и Java EE?
Итак, я занял некоторое время сегодня днем, чтобы наконец сесть и начать читать таинственные и неуловимые "OSGi" и его так называемые пакеты.
Хорошо, поэтому я думаю, что понял. OSGi "bundle" - это в основном JAR с дополнительной информацией манифеста. И вместо того, чтобы развертывать его на обычном сервере приложений (или другом контейнере), вы развертываете его на сервере OSGi, таком как Apache Felix. Он запускается, а затем предоставляет услуги пользователям/клиентам.
Как это отличается от обычного EAR, развернутого на сервере приложений?
OSGi, похоже, растет (я все время сталкиваюсь с этим!), но для жизни меня не понимаю, что он предлагает (по функциональности) по всему, что вы можете сделать с сервером реального бизнеса, например GlassFish или Spring.
Я знаю, что мир не сошел с ума, поэтому я, очевидно, что-то пропустил. Просто не смог понять, что. Спасибо за любую помощь или прозрение!
Ответы
Ответ 1
Комплект OSGi - это скорее "программный модуль", чем "баннер", "война" или "ухо". Пакеты OSGi редко предоставляют преимущества, если они объединяют все приложение; однако они очень полезны для автоматизации и правильной обработки подключения к большому количеству библиотек.
Итак, рассмотрим проблему, которую пыталась решить OSGi, и вы лучше поймете, где она подходит. Это Java-эквивалент шаблона "наследование алмаза" из С++. Вы включаете две библиотеки, каждая из которых нуждается в общей библиотеке ведения журнала, но в этом случае она не из-за множественного наследования, а из-за множества включенных операторов.
Если две библиотеки работают с одной и той же версией общей библиотеки журналов, вам повезло. Если они этого не делают, то для того, чтобы каждая библиотека работала правильно независимо, вам нужно загрузить две копии одной и той же библиотеки, каждая из которых, вероятно, использует те же пространства имен (и часто те же имена классов).
OSGi - это средство объединения, которое позволяет загружать две версии одной и той же библиотеки, которые используют одни и те же пространства имен, одни и те же имена классов, но были созданы в разное время. Он также подключает "правильную" версию к "правильному" пакету OSGi, не позволяя пакету использовать "неправильную" версию "правой" библиотеки.
Java EE делает много, но это не то, что Java EE даже адреса. В лучшем случае проект Jigsaw работал над той же проблемой. Когда путаница Java EE/OSGi вступает в игру, так это то, что большинство ранних последователей OSGi-комплектации были теми, кто реализовывал функциональность, аналогичную некоторым библиотекам, предлагаемым в Java EE. Тем не менее, фактическая инфраструктура контейнерного соединения (OSGi) не имеет ничего общего с функциональными возможностями (хотя некоторые из них были структурно модифицированы, чтобы соответствовать требованиям привязки OSGi).
Ответ 2
Сравнение Java EE с OSGi - это сравнение яблок и апельсинов с дополнительным бонусом, не зная, что это такое.
Java EE focus - это масштабируемые многоуровневые бизнес-приложения в гетерогенных средах и интеграция информационных систем на уровне предприятия.
OSGi запущен в другом углу, объединив несколько независимых кодовых баз в одну JVM (пожалуйста, извините меня за то, что я очень кратко).
Конечно, некоторые проблемы (например, горячее развертывание) являются общими для обеих сред, но в различной степени.
Конечно, вы можете обновить, понизить и скрестить друг друга, и они будут встречаться где-то посередине.
Поэтому вопрос не должен быть "Какая польза от A over B", но что-то вроде "В каком поле A есть явные преимущества по сравнению с B и наоборот?" Позвольте мне перефразировать это: "Когда мне нужен молоток, и когда мне нужна пила?"
Ответ 3
Большинство основных преимуществ, по крайней мере, причин, по которым мы используем OSGi, перечислены в http://karaf.apache.org/, особенно первые два.
Кроме того, альянс OSGi имеет длинный список преимуществ: https://www.osgi.org/developer/benefits-of-using-osgi/.
Ответ 4
Извините, но ВСЕ ответы здесь полностью смешны. Проблемы с версией зависимостей решаются с помощью OSGi? Pooooohlease.... Когда-нибудь слышали о политике загрузчика классов на серверах приложений?
OSGi кажется идеей продолжать продавать новые книги и обучение, в то время как функциональные потребности были покрыты за эоны упаковкой JAR/EAR и развертыванием в JEE. Те, кто покупают его, просто никогда не понимали, как ими манипулируют. Там также вопрос о тенденциях и моде. То есть нетехнические соображения, которые являются позором для этой отрасли.
Переосмыслить колесо выгодно, потому что там много дураков. К сожалению, есть тонны простых стилей управляющего типа, которые хотят быть на "краю технологий", которые с радостью будут финансировать курсы своих сотрудников, поглощать кривую обучения, а затем оплачивать свой нос в "реинжиниринг" вещей что с ними не было ничего плохого.
Это не вопрос "я должен использовать отвертку молотка". Это скорее вопрос "эй босс, там эта новая вещь там называется ХЕММАРО, и это действительно здорово!". "Разве это не МОЛОЧНИК?", "Нет, нет, это лучше, это ХЕММАР, это для того, чтобы водить гвозди в доски, это произведет революцию в мире".
