Может ли OSGi помочь уменьшить сложность?

Question

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

Интересно, что обещает решить OSGi? Это напомнило мне о первых днях OO, когда подобные претензии были предъявлены:

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

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

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

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

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

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

Спасибо!

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

OSGI помог нашему проекту, потому что он сделал архитектуру более стабильной.Нарушение модульности является более «трудным», поэтому решения, которые мы приняли относительно того, как модульность, оставались в силе в течение более длительного времени.
Другими словами - без OSGI и под давлением времени, иногда вы или члены вашей командыкомпромиссы, ярлыки и другие взломы, и первоначальное намерение архитектуры потеряно.

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

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

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

(примечание: ваш вопрос немного напоминает мне пословицу: «мавенСборка систем ")

Answer 6

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