Итак, что такое управление конфигурацией и его основные цели? Без чрезмерного усложнения вещей я думаю, что две следующие цели не слишком далеки от истины.
- Создайте конфигурацию предсказуемым образом, гарантирующую правильную работу системы.
- Поддерживайте согласованность конфигурации, так как изменения происходят со временем.
Другими словами, возможность управлять изменением поведения надежным и безопасным способом на протяжении всего жизненного цикла программного обеспечения.
Но что такое конфигурация? Это исходный код? Он загружен статически в текущий загрузчик классов? Это может быть изменено во время выполнения? Это постоянные данные? Это отслеживается VCS? На самом деле, где он хранится? Может ли каждый компьютер в кластере получить к нему доступ? Что происходит при изменении конфигурации? Мы заботимся о том, чтобы изменения были подтверждены? Имеет ли пользователь право изменять конфигурацию для этого? Как изменения распространяются на членов кластера? Будут ли приложения уведомлены об изменениях конфигурации?
Прежде чем углубляться в это, я бы хотел вспомнить кое-что об обслуживании.
Обслуживание обычно занимает от 40 до 80 процентов (в среднем 60 процентов) затрат на программное обеспечение. Следовательно, это, вероятно, самая важная фаза жизненного цикла.
Часто забытые фундаментальные факты о разработке программного обеспечения
Короче говоря (не говоря уже о цифрах), OAM сложен и дорог, явно больше в динамичных и гибких средах облачных вычислений. И с точки зрения производительности, если мы сможем спроектировать наше программное обеспечение таким образом, чтобы избежать перегрузки VCS, повторять выпуск продукта по всему конвейеру развертывания в производство и при этом иметь возможность управлять изменением поведения, мы, возможно, должны рассмотреть это правильно? Очевидно, что это также сделает программное обеспечение более адаптируемым к различным средам, духу и душе Java.
Я бы сказал, что мы используем конфигурацию для задержки решений , не только в отношении среды и ее ресурсов, но также и для решений, специфичных для приложений и бизнеса. Бизнес должен уметь быстро настраивать предложения / правила, которые не связаны с ресурсами / инфраструктурой сервера приложений.
Поэтому я считаю, что части, которые не должны изменяться после выпуска (поведенческая целостность), являются частью программы, а конфигурация является поведенческим инвариантом времени выполнения, строго регулируемым политиками программы , так что предсказуемое поведение системы может быть гарантировано, применено на разных уровнях в зависимости от скорости изменение — НО (и здесь шаг) продуктивным, ненавязчивым и надежным способом. На ум приходит принцип Open / Closed .
В контексте Java EE это определение все еще недостаточно ясно. Java EE 6 выпустила аннотацию DataSourceDefinition , которая предполагает, что конфигурация является кодом. Роли Ассемблера / Развертывания дают немного больше гибкости конфигурации. Проще говоря, предполагается, что приложение (в частности, его XML-дескрипторы) может быть изменено непосредственно перед развертыванием, возможно, с переопределением жестко закодированных значений.
Такой подход всегда меня озадачивал, но, может быть, это вопрос перспективы того, как разные люди воспринимают, какой тип данных считается конфигурацией? Однако в своей карьере я никогда не слышал, не читал и не встречал кого-либо, кто действительно использует этот механизм по назначению. И для этого могут быть веские причины.
В цикле обратной связи Maven компиляция и упаковка практически идут рука об руку — и почти каждый проект Maven предназначен для создания артефакта в форме архива. Дескрипторы генерируются Maven или статически отслеживаются VCS. В любом случае, этот процесс запечатывает приложение для дальнейшей модификации, если архив не распакован и не изменен.
Но я не могу представить себе ситуацию, когда было бы неплохо открыть файл JAR, изменить текстовый файл, перепаковать и повторно развернуть (используя проприетарные инструменты — asadmin, wlst и т. Д.). Почему? Подумайте, что произойдет, когда будет выпущен новый выпуск * аутентичного * архива. Изменения, которые сделали ассемблер / развертыватель, будут либо перезаписаны, либо их необходимо будет заново настроить. Из-за этого, возможно, не стоит вносить специальные изменения в файлы с управлением версиями, если эти изменения никогда не возвращаются для отслеживания VCS. Даже если бы они это сделали, мы бы потеряли гибкость.
Стоит упомянуть, что многие проекты с открытым исходным кодом подписывают релизы цифровой подписью, чтобы пользователи, находящиеся в безопасности, могли найти цифровой путь доверия к архиву. Как изменить конфигурацию для такого архива, не нарушая подписи?
Рассмотрим влияние на разработку, где каждый разработчик может иметь отдельное табличное пространство базы данных для своих интеграционных тестов. Умный разработчик, вероятно, создает некоторые чувствительные к профилю плагины maven для поиска / замены своих личных данных в дескрипторах развертывания. Но почему он должен быть обременен этим и получать поворотный удар при изменении значения конфигурации, например, между двумя тестами JUnit (я не смею думать, как будут выглядеть эти тесты)? Одни только XML-файлы не могут сами проверить изменения, для этого нам нужна программа. Подождите 1-2 минуты, пока приложение развернется, только чтобы обнаружить, что ваши значения недействительны, а затем повторите все это снова, что станет катастрофой для производительности разработчика .
Если мы посмотрим дальше на то, как программное обеспечение может быть развернуто с использованием этапа, то переключаем подход для кластерных систем, дескрипторы развертывания становятся еще более проблематичными, поскольку потребуются две версии одного и того же архива. И почему производственная система должна быть нарушена ( модернизирована ), имея дело с успокоением , потому что нужно изменить несвязанное значение? Подумайте о том, когда значение отклоняется — вы меняете значение обратно (переупаковка приложения и т. Д.) И откатываете по кластеру, исправляете значение и пробуете снова? Я не знаю… но я начинаю чувствовать себя неловко из-за поддержания надежности SLA и согласованности конфигурации в кластере.
В контексте мультитенантности тип конфигурации «плоское имя = значение» также является сдерживающим фактором. Иерархическая или графическая спецификация конфигурации лучше подходит для моделирования арендаторов, позволяющих создавать конфигурации и т. Д. Может быть что-то вроде этого:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
import javax.validation.constraints.Max;import javax.validation.constraints.Min;import javax.validation.constraints.Pattern;import javax.validation.constraints.Size;@Configurationpublic class MysqlXADataSource { @Property(desc = "User name to use for connection authentication.") @Size(min = 6, max = 255) private String user = ""; // default value - hence optional property @Property(desc = "Password to use for connection authentication.") @Size(min = 6, max = 255) private String password = ""; // default value - hence optional property @Property(desc = "A JDBC URL.") @Pattern(regexp = "([a-zA-Z]{3,})://([\w-]+\.)+[\w-]+(/[\w- ./?%&=]*)?") private URL url; // required property @Property(desc = "Port number where a server is listening for requests.") @Min(0) @Max(65535) private Integer portNumber = 1521; // default value - hence optional property @Resource private List<ConfigurableItem> items; // configuration childs}@Statelesspublic class SessionBean { @Resource(name = "jdbc/mysql-ds") private DataSource ds;} |
Это будет представление приложения и обратите внимание, что не делается никаких предположений о том, где и как создается конфигурация, и мы можем быстро выполнить отказ, обеспечив безопасность типов во время компиляции с использованием процессора аннотаций .
Это мое спонтанное отражение и, возможно, оно слишком предприимчивое. Но я все еще думаю, что как большие, так и маленькие приложения выиграют от настройки во время выполнения, незавершенного и отделенного от источников конфигурации (файл, db, ldap, mib и т. Д.) И от того, как ими управляют.
Я даже думаю, что Java SE также выиграет от управления конфигурацией.
Есть много других аспектов, связанных с управлением конфигурациями, которые необходимо обсудить, таких как безопасность, администрирование, уведомления, регистрация / обнаружение схемы и т. Д. Но я собираюсь остановиться здесь для комментариев / размышлений / мнений — являются ли дескрипторы развертывания хорошим способом управления конфигурацией или мы нужно что-то более сложное?
Это сообщение относится к темам «[jsr342-experts] Re: Configuration» и «[jsr342-experts] Re: конфигурация ресурсов» в списке рассылки Java EE 7 Expert Group. Пожалуйста, не стесняйтесь комментировать здесь или в списке рассылки .
Справка: Управление конфигурацией в Java EE от нашего партнера по JCG из блога Deep Hacks .
Статьи по Теме :