SoftWell: Navigator bus

Концепция продукта

В качестве логической модели объединения систем выбрана модель "чёрных ящиков". Её суть заключается в том, что системы, входящие в комплекс, ничего не знают о внутренней архитектуре и структурах БД других систем.

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

В качестве транспортной среды выбран MSMQ (Microsoft Message Queuing).

Каждая из систем при первоначальной регистрации в комплексе, сообщает другим перечень информации, которую она готова поставлять для них по запросу. Кроме того, системы могут публиковать структуры информации, которые могут быть переданы другими системами для использования (добавления, их модификации, использования в расчётах и проч.).

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

Учитывая, что в комплекс должны включаться как разрабатываемые в рамках договора системы, так и наследуемые (разработанные ранее) и системы, которые могут разрабатываться другими поставщиками, взаимодействие между системами посредством MSMQ возлагается на т.н. адаптеры, требования к которым и их интерфейсы разрабатываются в рамках проекта. Витрина данных НОТА ВИЗОР для налогового мониторинга 2.1 т

Для каждой из систем разрабатывается свой адаптер. Функции, возлагаемые на адаптеры: Взаимодействие с диспетчером шины (регистрация системы, получение описания др. систем, получение информации, необходимой для начала сеанса взаимодействия в соответствии с протоколом и проч.) Преобразование полученных запросов от др. систем в понятный для своей системы формат. Формирование наборов выходных данных (в соответствии с полученными запросами) и преобразование их в промежуточный формат обмена, понятный всем системам. Формирование нотификационных сообщений о событиях, произошедших в своей системе и преобразование их в промежуточный формат обмена, понятный всем системам, для передачи системам, подписавшимся на получение такой информации. Формирование подтверждений о получении информации (если такое требование содержалось в документе) в формате обмена, понятном всем системам. Ведение протокола поставок информации, требующих подтверждения (в соответствии с полученным запросом) и отметки о доставке (на основании документов-подтверждений). Обработка информации, переданной другими системами для использования внутри системы (если такая возможность поддерживается и описана в диспетчере). Обработка нотификационных сообщений от диспетчера. Подготовка данных для использования в других системах при наступлении тех или иных событий в своей системе для передачи системам, подписавшимся на получение такой информации. Передача информации о текущем состоянии своём и своей системы в диспетчер шины для централизованного её накопления и хранения.

Учитывая, что протокол взаимодействия с MSMQ един для всех адаптеров и документы, перемещающиеся в комплексе, должны пониматься всеми системами (промежуточный формат), в рамках проекта создан объект, реализующий взаимодействие с MSMQ. Интерфейсы этого объекта известны адаптерам всех систем и разработаны xdr-файлы, описывающие структуру документов обмена между системами (промежуточный формат) и структуру информации о системах, зарегистрированных на диспетчере шины. Однако адаптеры систем могут самостоятельно реализовать механизм работы с MSMQ. Обязательным требованием является умение понимать и готовить документы в промежуточном формате.

Для обеспечения устойчивости системы, возможно разнесение очередей и адаптеров по разным компьютерам. В целях повышения устойчивости системы и уменьшения вероятности потери информации, принят ряд мер структурного и системного характера. Кроме этого, для обеспечения срочного обмена информацией и в случае возникновения тех или иных проблем с доставкой информации посредством MSMQ, для адаптеров предусмотрены интерфейсы непосредственного обращения к ним (минуя MSMQ), для чего вся необходимая информация так же хранится на диспетчере шины. Однако и в этом случае обмен осуществляется посредством документов в промежуточном формате.

Помимо формата XML, адаптеры могут поддерживать и другие, т.н. бинарные форматы. При этом формат должен быть однозначно описан или совместно с адаптером должен поставляться объект, предназначенный для работы с этим форматом. Подготовка документом в бинарном формате должна быть альтернативной подготовке документов в формате XML, а не заменять её, т.е. адаптер может дополнительно уметь готовить и обрабатывать документы в бинарном формате. Число бинарных форматов, поддерживаемых системой, не ограничено и определяется только разработчиками системы. При появлении нового бинарного формата, система должна передавать соответствующую информацию диспетчеру шины для обеспечения возможности регистрации соответствующей библиотеки работы с новым форматом в других системах.

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

Основные принципы

• Одновременное или последовательное внедрение систем, подлежащих объединению;
• Уже внедрённые и объединённые системы ни чего не знают о системах, которые появятся после них;
• Необходимость обеспечения как синхронного, так и асинхронного обмена между системами
• Вся информация, которую система может предоставить другим системам, объединяется в объекты - поименованные логически завершённые сущности (например: сделки, ценные бумаги, контрагенты и проч.);
• Описания всех объектов каждой из систем должны храниться в едином хранилище для обеспечения равного доступа к ним как уже существующих систем, так и разработчиков новых систем;
• Обращение к системе за информацией должно быть сформулировано в терминах этой системы;
• Гарантированная доставка информации;
• Необходимость объединять, в том числе и, уже внедрённые системы;
• Системы ни чего не знают о внутренней архитектуре и структуре баз данных (и о факте их наличия) других систем;
• Перечень объединяемых систем заранее не определён;
• Необходимость выполнения объединённых транзакций отсутствует (вытекает из последовательного появления систем).

Общая архитектура

Каждая из систем должна зарегистрироваться в Bus Navigator. Регистрации подлежит

• общая информация о системе и
• описание объектов системы.

Взаимодействие с Диспетчером

Основные задачи взаимодействия — регистрация системы, получение описания др. систем, получение информации, необходимой для начала сеанса взаимодействия в соответствии с протоколом и прочие:

• Преобразование полученных запросов от др. систем в понятный для своей системы формат.
• Формирование наборов выходных данных (в соответствии с полученными запросами) и преобразование их в промежуточный формат обмена, понятный всем системам.
• Формирование нотификационных сообщений о событиях, произошедших в своей системе и преобразование их в промежуточный формат обмена, понятный всем системам, для передачи системам, подписавшимся на получение такой информации.
• Формирование подтверждений о получении информации (если такое требование содержалось в документе) в формате обмена, понятном всем системам.
• Ведение протокола поставок информации, требующих подтверждения (в соответствии с полученным запросом) и отметки о доставке (на основании документов-подтверждений).
• Обработка информации, переданной другими системами для использования внутри системы.
• Обработка нотификационных сообщений от диспетчера.
• Подготовка данных для использования в других системах при наступлении тех или иных событий в своей системе для передачи системам, подписавшимся на получение такой информации.

• Передача информации о текущем состоянии своём и своей системы в диспетчер шины для централизованного её накопления и хранения.

Адаптеры

Адаптеры всех систем выполняются в виде DCOM-приложений. Это обеспечивает возможность их удалённого запуска (в том числе и другими адаптерами) для обеспечения возможности оперативной реакции на запросы.

Синхронный режим обмена реализован при помощи удалённого вызова методов интерфейсов объектов адаптеров (перечень таких методов и их параметры определены и обязательны для всех адаптеров).

Обмен информацией, равно как и описание систем, производится XML-документами. Схемы этих документов являются частью Bus Navigator.

Таким образом, адаптер взаимодействует как с Bus Navigator, получая из неё и поставляя в неё необходимую информацию, так и со своим приложением, получая от него требования на запросы той или иной информации от других систем и поставляя её своему приложению. Порядок передачи своей системе информации от других систем, полученной из Bus Navigator, определяется при реализации адаптера и на него не накладывается ни каких дополнительных требований. Собственно система взаимодействует только с адаптером, для неё все прочие источники информации и есть адаптер. Пример построения системы приведён на следующей схеме:

(Кликните на изображение, чтобы просмотреть схему в полном размере.)

Подчеркнем, что весь обмен информацией между системами ведётся через шину (Bus Navigator).

Шина представляет собой менеджер очередей (в данном случае MSMQ) и Диспетчер. Диспетчер реализован в виде DCOM-приложения и хранит в своей БД необходимую для обеспечения межсистемного взаимодействия информацию обо всех системах. состав этой информации входит:

• Уникальный идентификатор системы.
• Версия описания системы.
• Дата описания системы.
• Название системы на естественном языке.
• Описание системы для понимания разработчиками других систем.
• GUID адаптера системы.
• Имя компьютера с адаптером системы.
• Название входной очереди системы.
• Название выходной очереди системы.
• Имя компьютера с очередями системы
• Описание объектов системы (таблиц, процедур, функций и прочего), содержащих или создающих информацию, которую система готова публиковать или принимать для использования в своей бизнес логике.

Каждый объект содержит следующее описание:

• Название публикуемого объекта системы.
• Тип публикуемого объекта системы (таблица, метод СОМ, хранимая процедура, функция, скрипт, абстрактный объект, т.е. объект не имеющий точного соответствия в пространстве методов и свойств системы, а описывающий некоторые общие понятия системы)
• Тип возвращаемого значения объекта (для ObjectType=Method, Function или Script).
• Название объекта на естественном языке.
• Описание объекта для понимания разработчиками других систем.
• Свойства объекта (поля таблицы, параметры методов, процедур, функций и проч.). Каждое свойство объекта описывается следующими атрибутами:
• Имя свойства объекта.
• Являются ли значения свойства уникальными в рамках системы (только для полей таблицы и абстрактных объектов).
• Тип свойства объекта в соответствии с urn:schemas-microsoft-com:datatypes.
• Является ли свойство входным или выходным параметром (только для полей методов, процедур, функций и скриптов).
• Уникальный ID свойства объекта в базе диспетчера (присваивается диспетчером в процессе регистрации).
• Название свойства на естественном языке.
• Описание свойства объекта для понимания разработчиками других систем

Общее описание адаптеров

Структура адаптеров систем и их взаимодействие с другими компонентами системы и комплекса в целом, может быть представлена на примере адаптера VaR в виде следующей схемы:

(Кликните на изображение, чтобы просмотреть схему в полном размере.)

Собственно к адаптеру относятся модули

• 1.2.1 (Модуль бизнес логики) и
• 1.2.2 (Модуль логики взаимодействия с Bus Navigator).

Модуль бизнес логики уникален для каждого приложения и в общем случае может отсутствовать (например, при реализации двухуровневой модели клиент-сервер). Модуль логики взаимодействия с Шиной собственно и реализует обмен информацией. К его функциям относятся: � Получение от Диспетчера необходимой информации для организации обмена между системами (имена очередей, компьютеров с очередями и адаптерами, GUID адаптеров). � Формирование документов, помещаемых в очереди в соответствии с принятой схемой.

Получение документов от других систем, их анализ, выполнение необходимых действий как в соответствии с принятым протоколом обмена, так и в соответствии с внутренней логикой системы, преобразование (при необходимости) полученных от других систем данных во внутренний формат.

Транспортный модуль

Транспортный модуль является встраиваемым COM-объектом и обеспечивает взаимодействие с MSMQ, для чего предоставляет адаптеру интерфейс.

Структура документов

Заголовок. Включает в себя:

• Номер документа;
• Систему, подготовившую документ;
• Тип документа (стандартный или бинарный);
• Действие, описываемое документом:
• Запрос;
• Ответ на запрос;
• оповещение о событии в системе (изменение, удаление, добавление информации);
• квитанция (подтверждение получения информации);
• нотификация о событии в системе с одновременной передачей информации (изменённой, удалённой, новой);
• служебная информация;
• подтверждение получения информации в нотификационном документе с данными.
• Срочность;
• Транзакционность;
• Другая служебная информация.

Тело документа

Может быть пустым или включать в себя следующую информацию:

• Объекты (запрашиваемые или высылаемые в ответ на запрос или с нотификационным сообщением);
• Условия запроса объектов (в документах с запросом информации).