Может ли OSGi снизить сложность?

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

Интересно, стоит ли решать OSGi promises даже вопрос...? Это напомнило мне о первых днях ОО, когда подобные претензии были горничной:

Когда OO был новым, большой аргумент был многократным. Широко утверждалось, что при использовании ОО можно было бы только "написать один раз" и затем "использовать везде".

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

С OSGi, у меня есть подозрение, что здесь мы снова можем упасть на promises, потенциальные решения проблем, которые у нас на самом деле отсутствуют. Или, если у нас их есть, у нас их нет в достаточно большом количестве и серьезности, что оправдывало бы покупку в OSGi для помощи. "Горячая", например, подмножество модулей, безусловно, отличная идея, но как часто она действительно работает? Как часто не из-за того, что оказалось, что модуляция неправильно для конкретной проблемы? Как о объектах модели, которые совместно используются несколькими модулями? Нужно ли одновременно менять эти модули? Или вы сглаживаете свои объекты на примитивы и используете только те, которые находятся в межмодульной связи, чтобы иметь возможность поддерживать интерфейсные контракты?

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

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

Учитывая, что никакая инфраструктура никогда не сможет решить, что делать с модулями, может ли OSGi когда-либо платить за вас?
Помогло ли вам облегчить вашу жизнь при работе в командах?
Помогло ли это сократить количество ошибок?
Вы когда-либо успешно "hotdeploy" основных компонентов?
Помогает ли OSGi сократить сложность с течением времени?
Поддерживала ли OSGi promises?
Это оправдало ваши ожидания?

Спасибо!

Ответ 1

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

Это определенно помогает облегчить работу в командах, если вы позволите командам сосредоточиться на одном модуле (возможно, в наборе пакетов), и если вы получите право на модуляцию. Можно утверждать, что можно сделать то же самое с инструментом построения, таким как Ant + Ivy или Maven и зависимостями, гранулярность зависимостей, которые использует OSGi, на мой взгляд, намного превосходит, не вызывая типичного "перетаскивания во все, кроме кухни" раковина ", что вызваны зависимости уровня JAR.

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

Горячее развертывание, даже если вы не используете его во время выполнения, является очень хорошим тестом для проверки правильности вашего модульного приложения. Если вы вообще не можете запускать свои пакеты в случайном порядке, вам следует выяснить, почему. Кроме того, это может сделать ваш цикл разработки намного быстрее, если вы можете обновить произвольный пакет.

Пока вы можете управлять своими модулями и зависимостями, большие проекты остаются управляемыми и могут быть легко развиты (избавляя вас от плохой "полной перезаписи" ).

Недостаток OSGi? Это очень низкоуровневая структура, и в то время как она решает проблемы, которые она предназначена для достаточно хорошо, есть вещи, которые вам еще нужно решить самостоятельно. Особенно, если вы исходите из среды Java EE, где вы получаете бесплатную безопасность потоков и некоторые другие концепции, которые могут быть весьма полезными, если они вам нужны, вам нужно найти решения для них в OSGi самостоятельно.

Общей ошибкой является не использование абстракций поверх OSGi, чтобы сделать это проще для среднего разработчика. Никогда не позволяйте им работать с ServiceListeners или ServiceTrackers вручную. Внимательно рассмотрите, какие пакеты и не разрешены делать: готовы ли вы предоставить разработчикам доступ к BundleContext или скрываете все это от них, используя некоторую форму декларативной модели.

Ответ 2

Я работал с OSGi уже несколько лет (хотя в контексте проекта eclipse, а не в веб-проекте). Понятно, что структура не освобождает вас от размышлений о модуляции. Но это позволяет вам определять правила.

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

OSGi не снижает сложность. Но это определенно помогает справиться с этим.

Ответ 3

Я использую OSGI уже более 8 лет, и каждый раз, когда я погружаюсь в проект, не относящийся к OSGI, я испытываю чувство чрезмерной скорости без ремня безопасности. OSGI упрощает настройку и развертывание проекта и заставляет вас думать о модуляции заранее, но дает вам простое представление о соблюдении правил во время выполнения. Возьмите в качестве примера верблюда верблюда. Когда вы создаете новый проект maven и добавляете верблюд apache в качестве зависимости, приложения, похоже, имеют все свои зависимости, и вы заметите только ClassNotFoundExceptions во время выполнения, что плохо. Когда вы запускаете контейнер OSGI и загружаете модули верблюда apache, модули с неудовлетворенными зависимостями не запускаются, и вы заранее знаете, в чем проблема.

Я также использую горячее развертывание все время и обновляю части своего приложения на лету без необходимости перезапуска.

Ответ 4

Я использовал OSGI в одном проекте (признаюсь - не очень). Он обеспечивает хороший promises, но, как сказал @Arne, вам все равно нужно самостоятельно подумать о том, как вы модулируете.

OSGI сделал наш проект, потому что он сделал архитектуру более стабильной. Нарушение модуляции является более "трудным", поэтому решения, принятые нами в отношении модуляции, оставались действительными в течение более длительного времени.
Иными словами, без OSGI, и под давлением времени, чтобы доставить, иногда вы или члены вашей команды делаете компромиссы, ярлыки и другие хаки, а первоначальные намерения архитектуры теряются.

Таким образом, OSGI не уменьшала сложность как таковую, но защищала ее от излишнего с течением времени. Я думаю, это хорошо:)

Я не использовал функцию горячего развертывания, поэтому я не могу прокомментировать это.

Чтобы ответить на ваш последний вопрос, он оправдал мои ожидания, но для этого потребовалась кривая обучения и некоторая адаптация, а выигрыш - только для долгосрочного.

(как побочная заметка, ваш вопрос напоминает мне немного поговорки о том, что "maven - это awt систем сборки" )

Ответ 5

OSGi не окупается. Факт OSGi не прост в использовании, и в конце дня или года в зависимости от того, сколько времени вам нужно, чтобы заставить все работать, оно не добавляет значения:

Ваше приложение не будет более модульным в целом, напротив, оно заканчивается тем, что оно более открыто и не изолировано от других приложений, поскольку оно является общим для всех, а не для совместного использования.
Вертикализация продвигается дальше по стеку, вы боретесь с транзитивными зависимостями maven только для повторного выполнения во время выполнения в OSGI.
Большинство библиотек предназначены для работы в качестве библиотек в загрузчике классов приложений не как пакеты с их собственным загрузчиком классов.
Возможно, подходит для плагиновых архитектур, где сторонние разработчики должны быть изолированы или, может быть, просто EJB2.0 снова и снова.

Я добавил следующие слайды, и я продолжу пример кода, чтобы продемонстрировать, как успешно работать с OSGi, если он на вас навязан. http://www.slideshare.net/ielian/tdd-on-osgi

Ответ 6

Нет, OSGI сделает вас серым раньше.