подходит для OSGi платформа?

Question

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

Я играл с двумя (возможно, самыми популярными) платформами OSGi, Eclipse Equinox (с Gemini Blueprint) и Apache Felix (с Овном). В основном я сейчас нахожусь в принятии решения, которое мы должны использовать.

Мы имеем довольно большой опыт работы с Spring, поэтому мы хотели бы продолжать использовать, что, наряду с аннотациями (например @Autowired для автоматического связывания бобов ВНУТРИ ЖЕ пачки, @ServiceReference для автоматического связывания по жгутам), некоторые частные пружина аддонов (например, Data JPA), Hibernate как поставщик JPA (до сих пор у нас есть опыт только с Hibernate в качестве реализации JPA, у него есть все возможности, которые нам нужны, поэтому мы хотим избежать необходимости переключиться на что-то еще), обмен сообщениями JMS (с клиентом ActiveMQ) и несколько других функций. Позже мы также хотим иметь возможность реализовать собственный диспетчер безопасности (для контроля доступа к определенным пакетам на основе, например, их цифровых подписей, сертификатов с встроенными в них разрешениями)

До сих пор я мог сделайте два пакета тестирования (один из них использовал услугу у другого) и рассматривайте их как «Весенние бобы» на равноденствии с Gemini BP. Однако у меня были некоторые проблемы с аннотациями (и мне не очень нравятся компоновки в XML-файлах, особенно с не столь сложной архитектурой - большинство из них - Singletons).

Я тоже пробовал Овна (но не удалось с помощью Spring, возможно, просто не потратил на это достаточно времени :)).

Какую платформу OSGi вы рекомендуете для такого использования?

Answer 1

Возможно, это будет не лучший ответ, но я думаю, что это полезно для вас, если я расскажу о своих переживаниях. Пару лет назад у меня была такая же ситуация. Я был опытным с Spring, JPA (Hibernate и EclipseLink). Я нашел модульность OSGi полезной, поэтому мы начали проекты на основе OSGi.

Как я использовал Spring раньше, было очевидно использовать Blueprint (мы закончили использование Apache Aries, поскольку он был более стабильным, чем Gemini Blueprint). Мы это делали два года. Однако у нас было много проблем, поэтому я начал внедрять новый контейнер Blueprint на основе спецификации. Я слышал много раз, что OSGi DS лучше, но, поскольку я был поклонником Spring раньше, уроки не заставили меня передумать. У меня было ощущение, что ConfigAdmin было бы очень приятно использовать, но с Blueprint было бы невозможно написать хороший код (я знаю, что есть пространство имен cm, но это не сработало для нас).

В EclipseCon я поговорил с Питером Крийсом, и он убедил меня попробовать DS на проекте. Я сделал это, и теперь мне очень грустно, когда я использовал Blueprint (я не хотел причинить вам боль, парни Овны :)). Декларативные услуги вместе с ConfigurationAdmin предназначены для работы в рамках модульного мира OSGi. Я уверен, что хорошо знаю ваши текущие чувства, но если я действительно предлагаю вам не совершать те же ошибки, что и я. Попытайтесь создать два пакета с компонентами DS, получив конфигурацию из felix-configadmin и почувствуйте мощность.

По состоянию на JPA мы использовали первый EclipseLink. Поскольку это было слишком плохо, мы переключились на Hibernate. Я написал адаптер, чтобы иметь возможность использовать его (доступно на GitHub). Насколько я знаю, Hibernate теперь больше поддерживает эту тему, я никогда не пробовал. В конце концов, мы решили оставить JPA. Мы заканчиваем замену нашей инфраструктуры с JPA на Liquibase + QueryDSL. Компоненты более или менее готовы на уровне https://github.com/everit-org, нам необходимо работать с документацией.Если вас интересует, почему мы перешли от JPA, прочитать комментарии по почте в этом блоге: http://blog.osgi.org/2013/12/attributes-attributes-and-attributes.html

Мой ответ коротко:

• Если вы хотите, чтобы избежать использования декларативных услуг в силу исторических причин (это ошибка, но я могу это понять), используйте Apache Aries или Gemini BP (что вы найдете лучше). Поскольку Apache Aries был создан для OSGi, все обработчики пространства имен, написанные для Овна, будут работать точно. Овен не будет поддерживать обработчики пространства имен, написанные для Spring, поскольку у Овна есть свой собственный API. Однако в ActiveMQ и других проектах реализованы реализации обработчиков пространства имен Aries. Еще раз, я предлагаю рассмотреть использование DS вместо этого и написать свой код в Java вместо XML. Если вы разрабатываете небольшие модули, время развертывания не будет проблемой. С другой стороны, вы получите много преимуществ в части конфигурации и стабильности.
• JPA с Hibernate может использоваться в OSGi. Пример можно найти здесь: https://github.com/everit-org/osgi-hibernate. Более современные примеры доступны, если вы google. Я рекомендую вам посмотреть, как работает JPA, но это не OSGi.
• Относительно двигателя: Если вы используете Felix, вы можете быть уверены, что ваш код будет работать в других контейнерах, таких как Equinox или Knopflerfish. У двух других есть специальные функции, которые, если вы используете, вы можете столкнуться с проблемой, по которой вы не сможете позже портировать свой код. Я лично использую Equinox, но у меня есть исторические причины.

Answer 2

Мы используем план с Apache aries. В последнее время было много ошибок, связанных с ариями, но большинство из них исправлено прямо сейчас. Blueprint работает очень хорошо для нас, но ему не хватает поддержки функций предприятия по сравнению с JavaEE. Он имеет основные транзакции, управляемые контейнером, но немного больше с этой стороны.

Декларативные услуги кажутся более стабильными и легкими, чем план. Они также действительно охватывают динамичный характер OSGi. С другой стороны, DS не имеет расширения, например. JPA и транзакции, управляемые контейнером. Поэтому я не уверен, как сложно писать с ними реальный бизнес-код.

Я был бы очень осторожен с планом Близнецов. Кажется, что Springsource полностью закрыл OSGi. Поэтому я боюсь, что план Близнецов будет идти так же, как весна дм, которая не поддерживается вообще. Конечно, Близнецы сейчас в затмении, но я не уверен, что это сообщество может поддержать это.

В среднесрочной перспективе я бы очень хотел использовать CDI и полную поддержку JavaEE на OSGi. Там уже есть pax cdi, который обеспечивает поддержку CDI на OSGi, и есть переносные расширения, например. JPA и транзакции, управляемые контейнером от Apache Deltaspike. К сожалению, он еще не полностью работает, поэтому на данный момент это не реальный вариант.

Таким образом, моя рекомендация заключается в том, чтобы в настоящее время сделать ваше собственное доказательство концепций с планом Овна и DS и решить между ними. В то же время я буду следить за поддержкой JavaEE в OSGi, чтобы увидеть, когда она может быть готова.

Для базовой платформы OSGi я считаю, что феликс и равноденствие оба хороши. Также может иметь смысл взглянуть на Apache Karaf, который обеспечивает управление и корпоративные функции поверх обеих фреймворков.