Уровни преобразования данных

Преобразование данных может осуществляться на различных уровнях:

• Транспортный уровень (Transport) – это самый нижний уровень который отвечает за доставку сообщений. Примером преобразования может служить инфраструктура, позволяющая читать разделяемые файлы (shared files) и посылать запрос в виде HTTP, получать ответ и записывать в разделяемый файл. Транспортный уровень не заботится о содержании данных и поэтому прозрачно передаёт набор байт или символов от источника к приёмнику. Если проводить аналогию с моделью TCP/IP – то транспортному уровню соответствует протокол TCP.
• Уровень представления данных (Data Representation) (называемый так же синтаксическим уровнем) – определяет то в каком виде данные представлены в сообщении. Например, файл разделённый запятыми или файл на основе XML. Трансляторы работающие на уровне представления могут преобразовывать данные из одного представления в другое, не зависимо от способа их транспортировки (т.е. независимо от Транспортного уровня).
• Уровень типов данных (Data Types) – это уровень задающий набор типов, их формат и представление, понятное приложению. Например то как представлена дата – в виде числа миллисекунд относительно фиксированной даты или в виде текстовой строки в формате UTC (например, Sat Nov 12 19:30:54 UTC 2005). Типы данных, понятные приложению (или группе приложений) называют так же словарями данных (Data Dictionaries), однако определение Data Dictionaries охватывает более широкое значение. Примером преобразования на данному уровне может служить преобразование сторон света в одном приложении кодируемых буквенным кодом (‘S’, ‘N’, ‘W’, ‘E’) а в другом числовыми кодами (1, 2, 3, 4). При этом делается сопоставление (‘S’=1, ‘N’=2, и т.д.).
• Уровень структур данных (Data Structures) – это уровень, определяющий структуры данных и их семантику, понятные приложению. Например, понятие Заказа (Order) – его отношение с Клиентом (Customer), т.е., например тот факт, что одному клиенту может быть сопоставлено несколько заказов. Преобразование, осуществляемое на этом уровне, как правило, наиболее сложное с организационной точки зрения, так как, например, разные приложения, входящие в одно интеграционное решение, могут по-разному понимать основные сущности (например, Заказ или Клиент). И, если преобразование осуществляемые на более низких уровнях являются как правило чисто технической задачей (например преобразование файла разделённого запятыми (coma separated values, csv) в файл на основе XML), то семантическое преобразование на уровне структур данных требует глубокого понимания предметной области, и, как следствие, является более дорогим и трудоёмким.

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

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

Для объединения воедино трансляторов на всех уровнях используется архитектура Pipes and Filters, которая позволяет гибко переконфигурировать набор и связь трансляторов.

Транзакции

Общие положения

Дадим общее определение системной транзакции как атомарный набор действий переводящий систему из одного целостного состояния в другое.

К основным свойствам транзакции относятся (ACID):

• Atomicity атомарность – транзакция либо полностью успешно завершается (commit) либо все результаты её деятельности откатываются (rollback) в случае неуспешного завершения транзакции (failure)
• Consistency целостность – результат деятельности транзакции целостный, т.е. после успешного её завершения в системе соблюдаются все бизнес-инварианты (бизнес-правила).
• Isolation изолированность – промежуточные результаты в процессе выполнения транзакции до момента успешного её завершения не видны другим транзакциям.
• Durability устойчивость – результат завершённой транзакции всегда сохраняется и не теряется даже в случае сбоя в системе.

Транзакция может быть закончена (terminated) двумя способами:

• Commit – успешное завершение. В этом случае все изменения выполненные в рамках транзакции сохраняются на постоянном носителе в таком виде, что даже сбой в системе не должен приводить к потери результатов работы транзакции.
• Rollback – откат. В эжтом случае все изменения выполненные в рамках транзакции отменяются и система должна возвратиться в своё состояние на момент до начала выполнения транзакции.

Дата добавления: 2015-10-24