Синхронизация бизнес-объектов между службами WCF

Я перемещаю свою архитектуру из связанной в слабо связанную SOA (WCF). У меня есть несколько сервисов, которые общаются друг с другом. Как бы вы синхронизировали бизнес-экземпляры между службами?

Я вижу здесь два сценария:

  1. Все бизнес-объекты создаются только в одной службе, назовем ее MainService, и только она имеет доступ ко всем изменениям, внесенным в объекты. Сервис отвечает за обновление объектов в базе данных. Любое обновление объекта вызывает уведомление. Другие сервисы регистрируются на нужные им события и получают соответствующие уведомления. Я называю это централизованным подходом.

    + Уведомлять службу сразу после внесения изменений
    - Много вызовов между службами.
    - Больше связи.

  2. Все сервисы просто загружают нужные им объекты и периодически контролируют базу данных на предмет внесенных в них изменений. Моя идея состояла в том, чтобы использовать отслеживание изменений SQL Server 2008 для обнаружения любых изменений, внесенных в объекты.

    + Меньше трафика и возможных проблем со связью между службами.
    + Меньшая связанность
    - Задержка из-за периодического мониторинга.

Итак, каков ваш ответ на это? (если у вас есть 3, 4 и т. д., тоже было бы неплохо)


architecture c# wcf change-tracking synchronization
person Roubachof    schedule 23.10.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Зачем вам нужно синхронизировать бизнес-экземпляры между службами? Мне кажется, что сервисы еще недостаточно слабо связаны.

person Christian Hayter    schedule 23.10.2009
comment
Проблема в том, что некоторые службы должны быть уведомлены определенным образом, чтобы узнать, какие объекты (бизнес-экземпляры) были изменены. Итак, у меня есть два решения. Во-первых, это компонент, который уведомляет другие службы об изменении бизнес-объектов. Другой — опрос изменений в базе данных благодаря отслеживанию изменений. - person Roubachof; 27.10.2009

arrow_upward
0
arrow_downward

В первом варианте основная служба становится единой точкой отказа и узким местом в производительности.

Во втором вы рискуете получить много ненужного опроса информации.

Третьим предложением будет:

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

ИЗМЕНИТЬ

На основании вашего комментария. Вы можете попробовать кэширование корпоративной библиотеки с резервным хранилищем базы данных. Таким образом, у вас есть данные в памяти, но они будут обновлены, если значения в базе данных будут обновлены.

person Shiraz Bhaiji    schedule 23.10.2009
comment
Да ! Вы хорошо описали недостатки двух методов. Репликация в моем случае не поможет, нужно уведомление. В идеальном мире мои службы WCF подписывались бы на некоторые события базы данных и соответственно обновляли бы свои бизнес-объекты... - person Roubachof; 27.10.2009
comment
Спасибо за этот ответ! Однако Caching Block делает то же самое, что и мое решение № 2, но менее умным способом. Он периодически обновляет весь кеш (необходимо сравнивать версии всех объектов) и соответственно инициирует события. Мой будет периодически опрашивать, как блок кеша, но будет отслеживать только измененный элемент в таблице отслеживания изменений нужных элементов. - person Roubachof; 28.10.2009