Какова альтернатива OSGI для внутримодульной инъекции услуг в Wildfly?

Мы находимся в процессе расформирования классического старого монолитного EAR-пакета Java EE-приложения. Наш (наиболее сложный) компонентный шаблон подключения выглядит следующим образом: компонент A требует интерфейса X, в то время как компоненты B и C (... N) каждый «обеспечивают» интерфейс X. Наше требование состоит в том, чтобы упаковать и развернуть A, B, C и X отдельно и независимо, чтобы минимизировать время простоя и минимизировать влияние на бизнес.Какова альтернатива OSGI для внутримодульной инъекции услуг в Wildfly?

Поэтому мы нуждаемся в необходимой надежности, чтобы позволить удалять и добавлять (перераспределять) поставщиков (B, C) интерфейсов во время выполнения без необходимости перераспределения потребителей (A) интерфейса или перезапуска сервер. Решение будет работать на Wildfly 8, но может использовать или другие технологии, пока они работают на Wildfly 8.

Мы реализовали POC с использованием JBoss-OSGI и Weld-OSGI, которые выполнили все наши требования и предложили нам отличный путь миграции. Однако в Wildfly 8 Alpha 3 JBoss-OSGI был удален из дистрибутива по умолчанию. Это заставило нас думать, что мы должны исследовать альтернативы, которые в большей степени соответствуют мыслям людей, стоящих за Wildfly.

Вопрос в том, что на Wildfly 8, что является альтернативой OSGI для межмодульной инъекции услуг, которая соответствовала бы нашим требованиям?

Ради бюджетов, простоты, накладные расходы производительности и политики компании, мы должны были устранить следующие:
1. удаленного EJB в
2. Web Services
3. JSon/Отдых
4. SCA

Обратите внимание, что это не просьба об обсуждении жизнеспособности OSGI, а также для оценки или сравнения различных решений. Я просто ищу любое решение (ы), которое соответствует нашим критериям и НЕ основывается на OSGI.

источник

2013-07-26 Ampie Barnard

Я ценю, что вы не хотите дискуссий, и вы правы, что StackOverflow не место для дебатов. Но ... вы сказали, что JBoss-OSGi выполнил все ваши требования и предложил отличный путь миграции. И, чтобы быть понятным, JBoss-OSGi по-прежнему доступен и поддерживается Red Hat, хотя теперь он является дополнительным дополнением, а не готовым к использованию. Поэтому я действительно не понимаю мотивацию этого вопроса. –

Действительная точка. Да JBoss-OSGI по-прежнему доступен как дополнение. Тем не менее, поддержка Red Hat является более сложной проблемой, исключенной из EAP и т. Д., Что является моей первой проблемой. Кроме того, рискованно использовать JBoss-OSGI на Wildfly, когда важные люди, стоящие за Wildfly, на самом деле не покупают его. Еще раз я не хочу обсуждать обоснованность их точки зрения, но тот факт, что он существует, представляет собой риск использования JBoss-OSGI. Наконец, я чувствую, что мне не хватает более очевидного решения, которое они имели в виду для такого сценария, как это, и что моя склонность думать в концепциях OSGI, возможно, закрыла мне глаза. –

Эй, @ArjanTijms, вы действительно патрулируете весь StackOverflow, чтобы убедиться, что люди говорят «Java EE» вместо широко понятых терминов JEE и J2EE? Ваша преданность номенклатуре и товарным знакам замечательна, но немного узко сфокусирована ... Я имею в виду, почему бы не исправить OSGI OSGi? –

Поскольку вы спрашиваете о мышлении людей, стоящих за WildFly, я отсылаю вас к следующему сообщению списка рассылки. Он был отправлен в список разработки Jigsaw Дэвидом Ллойдом, который (я считаю) дизайнер JBoss Modules, на котором основан WildFly. Контекст была дискуссией о введении модели обслуживания в Головоломка: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html

Что кажется Давид, говорит либо о том, что идее услуг сам по себе несовершенной - то есть вам не нужно! - или что это требование уже достаточно разрешено API-интерфейсом ServiceLoader, который был введен в Java 6.

Однако ServiceLoader, как известно, не работает в системах модулей, которые используют изолятор класса loader, который включает в себя как модули OSGi, так и JBoss. Это связано с тем, что ServiceLoader использует сканирование классов, а в модульной системе нет «classpath». В OSGi мы разработали способ адаптации ServiceLoader (хотя он и yucky и требует байт-кода). Возможно, JBoss Modules также имеет способ справиться с этим, но я не мог найти ничего из быстрого сканирования своих документов.

В любом случае, как я сказал в своем комментарии выше, я озадачен вашей мотивацией. Вы явно получаете преимущества от модели обслуживания, предоставляемой OSGi, а JBoss-OSGi по-прежнему доступна и поддерживается Red Hat ... так почему бы не продолжать использовать ее?Особенно если нет ничего ясно предоставленного WildFly из коробки, которая делает то, что вы хотите.

источник

2013-07-26 10:28:02

Очень релевантная ссылка, и она многое разъясняет. Я вижу, куда идет Дэвид Ллойд, но в нашем случае я действительно думаю, что хороший аргумент может быть сделан в пользу идеи обслуживания.Не то, чтобы у меня была эта роскошь, так как это устаревшее приложение. См. Мой комментарий выше относительно моей мотивации. –

Не могли бы вы подтвердить, что jboss-osgi все еще доступен и поддерживается Red Hat? Насколько я знаю (и я долгое время говорил об этой стене с поддержкой RH), она никогда не поддерживалась Red Hat только благодаря усилиям сообщества, а в наши дни даже этого не было. Также он не работает с OOB с любой окончательной версией Wildfly (см. [This] (https://developer.jboss.org/thread/238007) и [this] (https://developer.jboss.org/thread/ 237976)), а лицо, ответственное за интеграцию (Thomas Diesler), больше не является сотрудником Red Hat. – eis

Хорошо, я просто заметил, что это сообщение было написано в 2013 году. В то время была, по крайней мере, идея о поддержке JBoss-OSGi, поэтому, возможно, этот ответ просто устарел в этом отношении. – eis

Apache Felix может быть встроен в ваш сервер приложений как «OSGI host». Затем вы можете создать механизм плагина для требуемой системы. Все ваши услуги могут быть реализованы как «пакеты». Хост OSGI на сервере может найти пакеты в папке развертывания и устанавливает/запускает их. Затем вы можете включить веб-сервис, отдых и другие сервисы без перезапуска сервера приложений.

источник

2013-07-26 09:15:45 Canberk

Принимая во внимание, что Феликс действительно является альтернативой JBoss-OSGI, и ваше решение может очень хорошо работать, оно не выводит нас из OSGI как такового. Помните, что мы пытаемся согласовать наше мышление с миром Wildfly 8 в этом отношении, мир без OSGI. Инфраструктура jboss-modules Wildfly предлагает множество аналогичных функций OSGI, поэтому должно быть возможно какое-то OSGI-подобное решение без фактического использования OSGI. Я добавлю ваше предложение в свой список задач, хотя ... –

«Мир без OSGI». Apache Felix предлагает вам функции osgi, а не WildFly. Затем вы можете использовать IPojo или т. Д. Но вы также хотите уйти от решений OSGI, а не только из-за ограничения WildFly? – Canberk

Правильно. См. Мой ответ на комментарий Нила Бартлетта для моих рассуждений. –

Где я работаю, нам нужно было что-то выбрать, чтобы продолжить проект, когда JBoss-OSGi был declared dead. Мы пошли с JBoss Modules + EJB, потому что они действительно поддерживаются Red Hat. Модули JBoss используются для статических зависимостей модулей, а EJB - для внедрения приложений во время выполнения.

Мы не используем удаленные EJB, но EJB 3.x локальные EJB, и это не было выброшено в ваш список, поэтому я предполагаю, что это нормально.

источник

2015-02-19 11:23:24 eis

Это действительно касается необходимости в межмодульной инъекции, но, насколько я знаю, когда вы вводите интерфейс EJB, вы должны указать реализацию. Это означает, что вы создаете статическую зависимость от конкретной реализации - либо B, либо C в моем вопросе. OSGi и Java ServiceLoader, к которым относится Нейл, обеспечивают способ реализации нескольких реализаций интерфейса и только во время исполнения определяют только тот, который будет использоваться. –

@AmpieBarnard um. Нет, вам не нужно указывать реализацию. Это своего рода точка зрения. У нас есть множество реализаций одного интерфейса, который вы можете изменить во время выполнения. – eis

Я в тупике. Пожалуйста, не могли бы вы прикрепить код, в котором у вас есть две реализации EJB (B и C) того же интерфейса X, вы вводите интерфейс в EJB A, вы развертываете обе реализации, а затем во время выполнения решаете, какую реализацию использовать? –

Какова альтернатива OSGI для внутримодульной инъекции услуг в Wildfly?

ответ

Смежные вопросы