Посмотрите внимательно условия и не выдумывайте про одинаковые базы, legacy системы и т.п.
Все, что просили - дать способ доставки клиенту его набор правил , в минимально возможный срок, поэтому без сообщений с гарантированной доставкой не обойтись, хотя бы вовремя получить ID записи, которую надо обновить, а дальше - XML, SELECT - все равно, хотя, повторяю, наиболее универсально - доставлять информацию в сообщении. И что сложного в создании сообщения и его получении? JMS не поддается изучению? А вот с самоделками - куча вопросов.
Что если клиент - это другое ЗАО, давать ему пароль в основную базу?
Что если центральная база ушла в офлайн, а работать на местах надо?
Что если в центре решили поставить супер-пупер SQL, а для филиалов денег не хватило и они по прежнему на H2?
И даже если сейчас это не актуально и приложение состоит из 2-3 рабочих мест, хороший руководитель проекта должен задумываться, что будет с его системой через год и далее.

Petro123ivanraВсе, что просили - дать способ доставки клиенту его набор правил ,
а не сделать БД одинаковыми после обрыва связи?
)
Нет, одинаковые базы сделать не просили.
Если кратко:
1) меняется правило для заказчика на центральном сервере
2) правило обновляется на центральном сервере заказчика (как это делается - вопроса не было)
3) изменения в таблице правил при первой возможности надо доставить в клиентское приложение, база в этом приложении не обязательно такая же как на сервере, только эта таблица/набор таблиц.
И все это, видимо, в условиях неустойчивой связи, со всеми вытекающими последствиями прямой работы с SQL