Sync Adapter RFC #2
Conversation
|
Предлагаю углубиться в проблему, сформулировать несколько примеров, для которых данное изменение в платформе было бы полезным. Пример 1Допустим создаётся распределённая информационная система для медицинских учреждений. Крупные частные поликлиники желают обмениваться информацией, у них есть собственные системы, разработанные с использованием платформы Flexberry, но приложения имеют существенные различия, связанные с особенностями каждой конкретной организации. Архитектура интеграцииНекоторый посредник разворачивает сервисную шину. |
text/0000-Sync-Adapter.md
Outdated
|
|
||
| ## Обоснование | ||
|
|
||
| > Часто на прикладных проектах возникает проблема интеграции/синхронизации данных между несколькими приложениями. В каждом случаи разработчики, задействованные на проекте, с помощью различных технологий и архитектуры, создают свои решения, нацеленные на работу с конкретными приложениями. Отсюда возникает проблема, что при возникновении задачи интеграции, зачастую необходимо начинать разработку интеграционного решения с нуля, из-за невозможности переиспользования или отсутствия других решений. В результате разработке данного проектного решения планируется получить универсальный адаптер, который позволит разработчикам обеспечить интеграцию данных между приложениями с использованием общей технологии и архитектуры. |
There was a problem hiding this comment.
Опечатка "случаи".
Тут надо не забывать про баланс между универсальностью, которая требует сложных настроек и специализированным решением, которое может оказаться сильно проще и надёжнее.
text/0000-Sync-Adapter.md
Outdated
|
|
||
| ## Краткое описание | ||
|
|
||
| > Необходимо разработать универсальный адаптер для решения задачи интеграции и синхронизации данных корпоративных приложений. |
There was a problem hiding this comment.
Во главу угла предлагаю поставить проблему, которую нужно решить, а способ её решения - на втором плане.
Можно начать с проработки темы интеграции и синхронизации данных в целом, не зацикливаясь на том адаптер это будет или что-то ещё. В самом простом случае достаточно иметь архитектуру некоего решения для интеграции и набора базовых компонент, которые можно настроить тем или иным образом.
text/0000-Sync-Adapter.md
Outdated
|
|
||
| > Адаптер должен решать две первичные задачи | ||
| > * обеспечить интеграцию данных между приложениями | ||
| > * обеспечить синхронизацию данных между приложениями |
There was a problem hiding this comment.
Чем отличается интеграция от синхронизации?
text/0000-Sync-Adapter.md
Outdated
| > Адаптер должен обладать следующими возможностями: | ||
| > 1. формировать запрос на получение данных из других источников | ||
| > 2. предоставление данных по запросу | ||
| > 3. получение данных по подписке, и обработка полученных данных |
There was a problem hiding this comment.
Понятие подписки есть в Flexberry Service Bus, как и понятие клиентов. Надо разобраться как "вписать" новые компоненты в уже существующую инфраструктуру, не изобретая велосипед.
text/0000-Sync-Adapter.md
Outdated
| > 2. предоставление данных по запросу | ||
| > 3. получение данных по подписке, и обработка полученных данных | ||
| > 4. отправка измененных данных в другой источник | ||
| > 5. поддерживать работу в операционных системах Linux и Windows |
There was a problem hiding this comment.
Хорошо бы разделить функциональные требования и технические.
text/0000-Sync-Adapter.md
Outdated
| **Изменение в прикладном приложении-источнике App** | ||
| > В приложение-источник App включается сборка в которой создаются наблюдатели (реализация ISyncObserver) за синхронизируемыми объектами. ISyncObserver – паттерн «наблюдатель», обеспечивает реакцию на изменение объекта синхронизации. Внутри наблюдателя может содержится логика по принятию решения о синхронизации объекта (Например, не хотим, чтобы при изменении некоторых отдельных полей объект синхронизировался). | ||
|
|
||
| > Для работы наблюдателя, приложение должно вести аудит изменения своих объектов. После фиксации аудита изменений вызывается соответствующий Observer изменённого объекта, который записывает факт об изменении объекта - SyncEntity(Date, ObjectPrimaryKey, ObjectStatus, Setting) в специальную таблицу БД ICS_SyncEntity. |
There was a problem hiding this comment.
Тут я предлагаю подумать над расширением таблиц аудита, а не введением ещё одной таблицы, хранящей примерно то же самое. Либо хранить сами факты событий, которые будут указывать на таблицу аудита.
text/0000-Sync-Adapter.md
Outdated
|
|
||
| #### Описание работы модулей адаптера | ||
| **Изменение в прикладном приложении-источнике App** | ||
| > В приложение-источник App включается сборка в которой создаются наблюдатели (реализация ISyncObserver) за синхронизируемыми объектами. ISyncObserver – паттерн «наблюдатель», обеспечивает реакцию на изменение объекта синхронизации. Внутри наблюдателя может содержится логика по принятию решения о синхронизации объекта (Например, не хотим, чтобы при изменении некоторых отдельных полей объект синхронизировался). |
There was a problem hiding this comment.
Синхронизируемые объекты должны наследоваться от интерфейса?
text/0000-Sync-Adapter.md
Outdated
| **ASP.NET веб-служба SyncAdapter** | ||
| > На сервере приложения разворачивается веб-служба адаптер SyncAdapter. К SyncAdapter подключается Synchronizer и сборки объектов приложения-источника App Object и приложений-приёмников XML Object и создаются соответствующие сборкам объектов наборы мапперов и наблюдателей. | ||
|
|
||
| > Synchronizer позволяет реализовать наборы преобразований объектов из одной системы в другую – мапперы (Реализация ISyncMapper) ISyncMapper – схож с паттерном «адаптер», обеспечивает преобразование объекта системы App в XML-объект для шины. Для изменения мастеров используются сабмапперы, настройки их использования прописываются отдельно. Детейлам соответствуют отдельные мапперы, где агрегатор выступает в роли мастера. Для преобразования из одного объекта в два используются два разных маппера с одним объектом-источником и разными объектами-приёмниками. |
There was a problem hiding this comment.
Вот вырисовывается ещё один независимый компонент, который можно упаковать в отдельный или один из существующих NuGet-пакетов (ORM).
text/0000-Sync-Adapter.md
Outdated
| > Реализация метода ProceedEntities определяет механизм, через который осуществляется связь между приложением-источником и приложеним-приёмником, в базовой реализации DefaultSyncService запись изменений осуществляется сразу в БД-приёмник. В данной реализации взаимодействия обработкой SyncEntity будет заниматься модуль Change Package Collector, который будет формировать сообщения для шины. | ||
|
|
||
| **WEB API** | ||
| > Управление веб-службой SyncAdapter осуществляется за счет средств Web API, гибкость которых позволяет решить проблему интеграции данных между приложениями, создав различные методы для обмена данными. В базовой реализации, Web API предоставляет метод для возможности синхронизации всех сущностей за заданный период (все накопившиеся изменения отправить на синхронизацию). SyncAdapter имеет прямое подключение к БД источника для обработки запросов данных и записи изменений, полученных от других приложений. |
There was a problem hiding this comment.
В контексте повального создания бакендов приложений на ODataService имеет смысл вынести эту функцию в отдельный класс, который может быть упакован как в WebApi-методы, так и в OData actions.
text/0000-Sync-Adapter.md
Outdated
|
|
||
| ## Альтернативы | ||
|
|
||
| > Реализация подобных адаптеров за частую является узкоспециализированной для конкретного проектного решения, что не позволяет их использовать в других решениях. |
There was a problem hiding this comment.
Надо декомпозировать архитектуру на отдельные компоненты, которые могут использоваться не только в рамках представленного сервиса. В этом случае, будет больше возможностей по применению данного решения, хотя бы и частично.
Rendered