Используя JNDI для распределенной конфигурации

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

Распределенный

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

Легкий вес

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

Нейтрализации поддержек

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

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

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

Живые изменения конфигурации

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

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

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