OSGi помогают, может уменьшить сложность?
Я видел много представлений OSGi, и я думаю, что это звучит как обещание для осуществления лучшей модуляризации. По-видимому, "hotdeployment" и "выполнение различных версий x параллельно" являются коммерческими аргументами мэра также.
Интересно, является ли то, что OSGi обещает решить, даже проблемой...? Это напомнило мне о первых годах OO, когда подобные требования были девицей:
Когда OO было новым, большим спором была возможность многократного использования. Широко утверждалось, что при использовании OO, нужно было бы только "записать однажды" и могло тогда "использовать везде".
На практике я только видел эту работу для некоторых довольно низкоуровневых примеров. Я думаю, что причина этого состоит в том, что написание повторно используемого кода трудно. Не технически, но с точки зрения дизайна интерфейса. Необходимо ожидать, как будущие клиенты захотят использовать классы и взять правильный выбор впереди. Это трудно по определению, и таким образом потенциальному преимуществу возможности многократного использования часто не удавалось поставить.
С OSGi у меня есть подозрение, что здесь снова мы могли попасться на обещания, потенциальные решения для проблем, которые мы действительно не имеем. Или если бы у нас есть они, у нас нет их в достаточно большом количестве и серьезности, которая выровняла бы по ширине для покупки в OSGi для справки. "Hotdeployment", например, подмножества модулей является определенно прекрасной идеей, но как часто он действительно работает? Как часто, не потому что это сложилось, Вы поняли модуляризацию превратно для конкретного вопроса? Как насчет образцовых объектов, которые совместно используются несколькими модулями? Эти модули должны все быть изменены одновременно? Или Вы сглаживаете свои объекты к примитивам и используете только тех, которые в межмодульной коммуникации, чтобы быть в состоянии сохранить интерфейсные контракты?
Самая трудная проблема при применении OSGi, я предположил бы, для разбираний в модуляризации. Подобный разбиранию в интерфейсах Ваших классов в OO, с OSGi, проблема остается такой же, в большем масштабе на этот раз, пакете или даже уровне обслуживания.
Как Вы, возможно, предположили, я в настоящее время пытаюсь оценить OSGi для использования в проекте. Основная проблема, которую мы имеем, увеличивает сложность, когда кодовая база растет, и я хотел бы разбить систему в меньших модулях, которые меньше и больше определили взаимодействия.
- Учитывая никакую платформу может когда-либо помогать решению, что построить из модулей, OSGi когда-либо окупался для Вас?
- Это сделало Вашу жизнь легче при работе в командах?
- Это помогло уменьшить количество ошибки?
- Вы когда-нибудь успешно "hotdeploy" главные компоненты?
- OSGi помогает уменьшить сложность со временем?
- OSGi сдерживал свои обещания?
- Это выполняло Ваши ожидания?
Спасибо!
4 ответа
OSGi окупается, потому что обеспечивает модульность во время выполнения, чего у вас раньше не было, что часто приводит к тому, что дизайн на бумаге и реализация расходятся. Это может быть большой победой во время разработки.
Это определенно помогает упростить работу в командах, если вы позволите командам сосредоточиться на одном модуле (возможно, на наборе комплектов) и если вы правильно сделаете модульную структуру. Можно возразить, что то же самое можно сделать с помощью инструмента сборки, такого как Ant + Ivy или Maven и зависимостей, степень детализации зависимостей, которую использует OSGi, на мой взгляд, намного превосходит, не вызывая типичного «перетаскивания всего плюс кухонная раковина» что вызывают зависимости уровня JAR.
Модульный код с меньшим количеством зависимостей, как правило, приводит к более чистому и меньшему количеству кода, что, в свою очередь, приводит к меньшему количеству ошибок, которые легче тестировать и устранять. Он также способствует созданию максимально простых и понятных компонентов, в то же время имея возможность подключать более сложные реализации или добавлять такие аспекты, как кэширование, в качестве отдельных компонентов.
Горячее развертывание, даже если вы не используете его во время выполнения, является очень хорошим тестом для проверки правильности модульности вашего приложения. Если вы вообще не можете запускать свои пакеты в случайном порядке, вам следует выяснить, почему. Кроме того, это может значительно ускорить ваш цикл разработки, если вы можете обновить произвольный пакет.
Пока вы можете управлять своими модулями и зависимостями, большие проекты остаются управляемыми и могут легко развиваться (избавляя вас от, возможно, плохого «полного переписывания»).
Обратная сторона OSGi? Это очень низкоуровневый фреймворк, и хотя он неплохо решает проблемы, для которых он предназначен, есть вещи, которые вам все же нужно решить самостоятельно. В особенности, если вы пришли из среды Java EE, где вы получаете бесплатную безопасность потоков и некоторые другие концепции, которые могут быть весьма полезны, если они вам нужны, вам нужно самостоятельно придумывать решения для них в OSGi.
Распространенная ошибка - не использовать абстракции поверх OSGi, чтобы упростить задачу среднему разработчику. Никогда не позволяйте им связываться с ServiceListeners или ServiceTrackers вручную. Тщательно подумайте, какие пакеты есть, а какие нельзя делать: готовы ли вы предоставить разработчикам доступ к BundleContext или вы скрываете все это от них, используя какую-либо форму декларативной модели.
Я использовал ОСГИ в одном проекте (я признаю - не очень много). Это обеспечивает хорошие обещания, но, как сказал @arne, вам все еще нужно подумать о том, как вы модулируете.
ОСГИ сделал , помогал нашему проекту, потому что он сделал архитектуру более стабильной. Разрыв модуляции более «сложно», поэтому решения, которые мы сделали в отношении того, как модулировать оставаться действительным в течение более длительного времени.
Чтобы потушить это по-другому - без ОСГИ, а под временем давление, чтобы доставить, иногда вы или члены вашей команды делают компромиссы, ярлыки и другие взломать, а первоначальное намерение архитектуры теряется.
Итак, Осги не снизил сложность сами по себе, но оно защищено его от того, как ненужно растет со временем. Я думаю, это хорошо :)
Я не использовал функцию горячей развертывания, поэтому я не могу комментировать это.
Чтобы ответить на ваш последний момент, он соответствовал моим ожиданиям, но требует кривой обучения и некоторую адаптацию, и выплата только для долгосрочных.
(Как побочная записка, ваш вопрос напоминает мне немного пословицы, что «Maven - это AWT для систем сборки»)
Я работал с OSGi уже несколько лет (хотя в контексте проекта eclipse, а не в веб-проекте). Понятно, что фреймворк не освобождает вас от размышлений о том, как модулировать. Но это позволяет вам определять правила.
Если вы используете пакеты и определяете (в проектном документе? Verbal?), Что определенные пакеты могут не иметь доступа к классам в других пакетах, без применения этого ограничения, это будет нарушено. Если вы нанимаете новых разработчиков, они не знают правил. Они БУДУТ нарушать правила. С OSGi вы можете определять правила в коде. Для нас это была большая победа, так как это помогло нам сохранить архитектуру нашей системы.
OSGi не снижает сложность. Но это определенно помогает справиться с этим.
Я использую OSGI уже более 8 лет, и каждый раз, когда я погружаюсь в проект, не связанный с OSGI, у меня возникает ощущение превышения скорости без пристегнутого ремня безопасности. OSGI усложняет настройку и развертывание проекта и заставляет Вам следует заранее подумать о модульности, но при этом вы легко сможете обеспечить соблюдение правил во время выполнения. В качестве примера возьмем maven apache camel. Когда вы создаете новый проект maven и добавляете apache camel в качестве зависимости, приложения, похоже, имеют все его зависимости, и вы заметите только ClassNotFoundExceptions во время выполнения, что плохо. Когда вы запускаете контейнер OSGI и загружаете модули apache camel, модули с неудовлетворенными зависимостями не запускаются, и вы заранее знаете, в чем проблема.
Я также постоянно использую горячее развертывание и обновляю части своего приложения на лету без необходимости перезапуска.