Использование JNDI для распределенной конфигурации - PullRequest
6 голосов
/ 12 января 2010

Мы рассмотрим, как выполнить распределенную настройку в рамках нашего развертывания, основанного преимущественно на Java. У нас есть несколько приложений, и имеет смысл централизовать настройку приложений. JNDI, кажется, является стандартным выбором, вероятно, возвращаясь к чему-то вроде ApacheDS (таким образом, мы также можем хранить не Java-конфигурации). Вот некоторые из вещей, которые я рассмотрел. Кто-нибудь пробовал что-то подобное? Любые рекомендации?:

Распространяется

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

Легкий

У JNDI есть чувство J2EE. Любой использует альтернативный механизм распределенной конфигурации. Приложения сами, как правило, относительно легкий, а не полные приложений Java EE (ки спорна ли Java EE по-прежнему считаются тяжеловесным и требование, конечно, весом).

Поддерживает запасные варианты

Часто одна и та же конфигурация применяется к нескольким приложениям (например, несколько приложений могут подключаться к одной и той же базе данных). С другой стороны, некоторые приложения могут нуждаться в конкретной конфигурации. Иногда сложно заранее узнать, будет ли приложение использовать «глобальную» конфигурацию или что-то конкретное, поэтому сначала будет полезен поиск конкретной конфигурации приложения / хоста, а затем откат назад. Я думаю о структуре примерно так:

/ global / host / application / instance или / global / application / host / instance:

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

Изменения конфигурации в реальном времени

Spring позволяет конфигурировать с помощью jee: jndi-lookup, и вы можете не кэшировать значение, что означает, что он просматривается при каждом запросе. Я не уверен, что имеет смысл для значений конфигурации типа "String". Он также не использует способ NamingListener для обнаружения изменений в DS. Было бы хорошо иметь возможность обновлять значение на сервере каталогов и транслировать это изменение всем приложениям, которые его используют.

Другие соображения

  • Управление различными средами
  • Добавление конфигурации в систему контроля версий, чтобы к ней можно было применить управление изменениями
  • Управление разными версиями
  • Откат

1 Ответ

1 голос
/ 12 февраля 2010

Рассматривали ли вы использование базы данных для хранения конфигурации приложения? Apache Commons имеет класс DatabaseConfiguration, который представляет вашу таблицу как экземпляр java.util.Properties (см. http://commons.apache.org/configuration/apidocs/org/apache/commons/configuration/DatabaseConfiguration.html).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...