Я бы сказал, что синхронные отношения с центром вводят связь, которая вам не нужна. Следовательно, ваша асинхронная идея кажется мне довольно хорошей. Предположительно, у вас есть некоторый зависящий от местоположения идентификатор в записях, так что создание новых контрактов в разных местоположениях не будет конфликтовать, и вы допустите некоторую задержку при репликации в центр.
Таким образом, простой случай заключается в том, что просто используйте сообщения JMS из каждого местоположения в центр.
Хорошая вещь в этом приборе состоит в том, что спутникам даже не нужно знать о структуре базы данных в центре, она может быть спроектирована совершенно разумно.
Вещи становятся более интересными, если вам также нужно копировать изменения обратно из центра в спутники. Большой вопрос в том, можем ли мы получить конфликты между изменениями в центре и изменениями на спутнике.
Простой случай: любой элемент данных имеет один «дом». Например, исходный спутник - это место, где вносятся изменения. Или после создания центр - единственное место, где можно внести изменения. В этом случае мы можем рассматривать центр как «Хаб», он может распространять изменения на спутники. Простой JMS отлично подойдет для этого.
Немного сложнее: изменения могут быть сделаны где угодно, но только в одном месте за раз. Следовательно, мы можем ввести сомне-вид схемы блокировки. Я бы хотел иметь Центр в качестве владельца и использовать синхронные веб-сервисы для блокировки и обновления данных. Теперь мы связаны, но это необходимо, если мы хотим иметь окончательного владельца.
Довольно сложный случай: любой может изменить что угодно в любом месте без блокировки. Это своего рода подход «Сначала действуй, потом извинись». Мы придерживаемся оптимистичного подхода, чтобы изменения не противоречили друг другу. Мы можем отправить изменения на утверждение в центр, и центр может либо использовать оптимистическую блокировку, либо объединить подход, не противоречащий изменениям. Я хотел бы сделать это, помещая в очередь изменения в инициаторе, но фактически обрабатывая их синхронными вызовами. Так что развязка спецификации изменений от наличия центра. Некоторые более сложные базы данных имеют возможности сравнения / слияния, которые могут помочь с этим.
Большие вопросы - это степень, в которой вы хотите быть связаны с доступностью центра и вероятностью конфликтующих изменений. Нередко хитрый дизайн приложения может значительно снизить вероятность конфликта.