Источник: http://citforum.ru/internet/xml/xmltech/
Постановка проблемы
В задачах построения сложных информационных систем одной из главных проблем является обмен данными между различными подсистемами. Нередко самая простая задача импорта/экспорта данных из одной системы в другую приводит к необходимости серьезных разработок модулей на стыке подсистем. Задача существенно облегчается, если данные определенного класса будут перемещаться между подсистемами, при условии, что в этих подсистемах будет заложена технологически реализованная возможность воспринимать извне и отдавать наружу данные в стандартном формате импорта/экспорта. Данный подход является основой для разработки метаданных и интерфейсов для обмена регулярными данными для различных унаследованных разноформатных систем. На этапе построения инфологических моделей документарного обеспечения управления и создания спецификаций протокола взаимодействия разноформатных систем используются технологии XML.
Данный подход прошёл апробацию в проекте интеграции функциональных подсистем, базирующихся на разнородных программных платформах ERP-класса с системой автоматизированного документооборота и делопроизводства, построенной на технологиях платформы Lotus Notes Domino, DominoDoc.
Для решения этой задачи необходимо:
- разработать формат документа обмена, основанный на языке XML, и спецификации на создание программных средств обмена между различными информационными системами и/или подсистемами, как уже созданными, так и, по возможности, теми, что будут созданы в будущем.
- разработать спецификации на различные слои метаданных, которые будут описывать данные в каждой из подсистем, вовлеченные в процессы информационного обмена. Сам по себе стандарт XML является обобщенным форматом данных, он создан консорциумом, состоящим из многих компаний, и необходимо дополнить язык XML семантикой, которая существует в области разработки информационных систем, основанных на понятии "документ", таких как: электронные архивы, системы документооборота и делопроизводства, генераторы отчетов из различных ERP-систем и т.д..
- разработать сценарии информационного обмена, которые будут включать в себя и использовать подмножество XML-схем, что обеспечивает с одной стороны возможность работы с файлами в едином универсальном формате стандартным XML-инструментарием, а с другой стороны упрощает разрабатываемые программы для импорта/экспорта структурированных данных в XML-формате.
Два основных варианта использования сценариев обмена между разноформатными системами
Прежде чем перечислить предполагаемые сценарии использования универсального формата XML-обмена, отметим, что существует два взгляда на эти сценарии. Представим, что имеются 3 системы различного класса, обозначенные, как: X-система, Y-система, Z-система.
2.1 Вариант регулярного периодического обмена данными
В каждой системе имеется XML-Репозитарий, где хранятся XML-файлы, содержащие схемы загрузки и выгрузки информации из собственного Хранилища (1-й слой метаданных). Со схемами загрузки/выгрузки работают универсальные Java-приложения DBImport и DBExport, доступ к которым может быть осуществлен через Web-интерфейс (см. на схеме Web-приложение). Они не модифицирутся при переносе из системы в систему (или при добавлении новых систем), а настраиваются на работу со схемами данных (XML-схемы). Достоинством этих модулей является то обстоятельство, что они не нуждаются в перепрограммировании. Они обеспечивают возможности экспорта/импорта через гибкие, универсальные интерфейсы:
уровень XML-схемы (XML-парсер, обеспечивающий разбор XML-файлов из Репозитария и безошибочное извлечение данных);
уровень доступа к Хранилищу (JDBC или Сonnector), обеспечивающий извлечение и запись данных в Хранилище c использованием XML-конвертора и валидации данных по схеме.
В общем случае процесс обмена осуществляется с использованием сценариев загрузки/выгрузки автоматически, или с возможностью административного интерфейса через Web-приложение, так как это обозначено на схеме:
"Выгрузить из системы X данные по схеме выгрузки N и загрузить в систему Y по схеме загрузки M ".
Способы организации административного интерфейса в варианте регулярного периодического обмена.
Таких способов в этом варианте также может существовать два:
1. Централизованное администрирование репозитария сценариев загрузки/выгрузки данных. Этот вариант предполагает создание единого репозитария схем загрузки/выгрузки для всех систем участвующих в обмене данными и средства его администрирования.
2. Распределенное администрирование локальных репозитариев для каждой системы в отдельности. Этот вариант предполагает создание отдельных репозитариев схем загрузки/выгрузки для каждой из систем и развертывания локальных средств их администрирования.
2.2 Вариант динамического обмена
Формат обмена данными
В этом варианте ключевым звеном является единый универсальный формат документа обмена и протокол SOAP, по которому передаются динамически запрашиваемые данные. Этот формат представляет собой подмножество XML-схем, дополненный XML семантикой, существующей в области разработки информационных систем.
Предполагается, что каждая из информационных систем имеет внутреннее хранилище (например, базу данных). Связь между системами осуществляется по принципу "точка-точка" через канал передачи: отправитель экспортирует внутренние данные в формат, а получатель импортирует данные из формата в свое внутреннее хранилище. В этом случае данные находятся в родном формате системы, к которой обращаются по запросу и каждая из запрашивающих клиентских SOAP-программ имеет доступ только к метаданным, но не к методам извлечения этих данных. Методы извлечения нужных данных, определяемых в метаописаниях, реализуют специальные программные компоненты Plug-Ins, написанные средствами той системы, к которой обращаются по запросу. Plug-Ins должны уметь извлекать данные и формировать документ в соответствии с форматом передачи данных. Для этого plug-ins должны реализовывать в полном объеме интерфейсы взаимодействия с SOAP-сервером обмена и снабжаться необходимыми библиотеками для непосредственного доступа к источнику данных. В свою очередь SOAP-сервер должен реализовывать механизм взаимодействия с клиентами посредством SOAP-сообщений, в соответствии с разрабатываемой спецификацией.
Заголовки пакета (содержимое элемента
Тело пакета состоит из одного или более документов. Документами считаются все элементы, непосредственным родителем которых является .
В соответствии с разрабатываемой спецификацией , в состав SOAP-сообщения могут входить один или более XML - документов, являющиеся уни версальными документами обмена между системами. Спецификация предусматривает один стандартный тип документа обмена, прикладные программы могут вводить свои.
Вместе с этим, спецификация определяет четыре стандартных подтипа передаваемых сообщений:
1. Команды для управления действиями систем;
2. Метаданные (описания) предоставляемых ресурсов;
3. Передаваемые данные;
4. Результат обработки запроса системой.
При этом спецификация никак не ограничивает возможности передачи нескольких документов в одном SOAP-сообщении.
Процесс обмена
Процесс обмена динамическими данными между разноформатными системами представляет собой взаимодействие SOAP-клиента и SOAP-сервера, обменивающихся SOAP-сообщениями. После процесса установления соединения, SOAP-клиент запрашивает у удаленного SOAP-сервера блок метаданных, где описана структура предоставляемой для экпорта информации. На данном этапе происходит SOAP-обмен управляющими блоками (пакеты данных еще не передаются). После получения метаданных, клиент формирует специальный запрос на получение определенного пакета данных в едином универсальном формате. SOAP-сервер принимает запрос клиента, вызывает необходимый модуль выгрузки (plug-in), который выгружает нужные данные из источника данных в единый формат передачи. SOAP-сервер формирует SOAP-сообщение, проверяет его на целостность и передает по линии связи (протокол HTTP) в принимающую систему. На принимающей стороне начинает работу импортирующая программа (соответствующий plug-in), который обеспечивает импорт данных, конвертируя XML-представление во внутреннее представление источника данных. Для различных ERP-систем существуют готовые XML конверторы, которые могут быть использованы при необходимости.
3. Разработка спецификации
В данном проекте предложено унифицированное решение, которое базируется на едином представлении документа. Необходимое требование - на всех этапах жизненного цикла работа с документом ведётся единообразно. Это позволяет выделить часто встречающиеся преобразования для повторного использования в других информационных системах.
Спецификация документов
В системе существует несколько типов документов. В процессе жизненного цикла документ создается, преобразуется из одного типа в другой, становится основой для создания новых документов и, в конце концов, уничтожается, или сохраняется в архиве долговременного хранения. Над каждым документом в системе производятся операции, иначе называемые преобразованиями.
Входные преобразования
Можно выделить несколько источников для входных преобразований:
1. Неэлектронный документ. В этом случае происходит распознавание в том или ином виде: распознавание текста отсканированных бумажных документов, распознавание речи, введенной с микрофона и т.д.
2. Неструктурированный документ. Необходимо выделение информации из такого документа. Примерами могут служить рубрикация, авторефирирование, автовыделение информации определенного типа: дат, географических названий, номеров телефонов и т.д.
3. Структурированный документ. Это самый простой случай. Здесь необходимо лишь преобразование данных из одного формата в другой, например из DBF в XML.
Выходные преобразования
Выходное преобразование переводит структурированную информацию в неструктурированную. Результатом являются, как правило, текстовые форматы, предназначенные для печати - HTML, RTF, TEX, PDF и другие.
Преобразование может предваряться подготовкой данных и, возможно, их агрегацией. Это делают программы, называемые обычно генераторами отчетов.
4. Метаданные
Метаданные в процессе обмена данными между разноформатными системами также могут быть описаны на двух уровнях:
1. Схемы метаданных для регулярного периодического обмена
2. Схемы метаданных для динамического обмена данными по запросам через протокол SOAP
Схемы метаданных для регулярного периодического обмена
Загружаемые документы XML могут поступать из другого приложения, из внешнего источника данных (база данных или файл) или из формы ввода данных. Для загрузки/выгрузки данных XML в реляционные БД и документальные БД типа Lotus Notes разработаны специальные программные средства. Данные программные средства представляют собой набор библиотек, позволяющих осуществлять загрузку и выгрузку данных в формате XML произвольной структуры. Настройка под конкретную структуру осуществляется при помощи т.н. карт загрузки/выгрузки, которые представляют из себя XML-документы, описывающие сценарий преобразования данных. В свою очередь описание работы с источником данных содержится в XML-документах, включающих в себя информацию о метаданных источника (информация о типах, параметры подключения и т. д.).
Схемы метаданных для динамического обмена
Для того, чтобы разнородные системы могли динамически обмениваться информацией, спецификация предусматривает разработку форматов двух типов универсальных документов:
1. Формат документа, являющегося сообщением, передаваемым от одной системы к другой (Схема описания сообщений message.xsd).
2. Формат документа, описывающий хранящиеся на данной системе ресурсы (Схема описания метаданных resources.xsd);
При этом в схему документа, описывающего сообщения обмена импортирована схема описывающая хранящимися в данной системе ресурсы.
5.Требования к программным модулям и API
Для ERP - систем, участвующих в процессе обмена предъявляется требование обеспечения WEB-интерфейса к своим данным. Почти все современные системы уже имеют такие интерфейсы:
1. WEB-расширения 1C: предприятие.
2. WEB-расширения Парус On-line
3. Web-расширение SAP/R3
Любое WEB-расширение обеспечивает доступ к данным с помощью собственных встроенных методов (V7Script 1C, ASP, JSP и т. д.). Например, в Парус взаимодействие WEB-клиента с базой данных осуществляется через WEB-сервер (IIS), на котором хранятся asp-сценарии (active server pages), обеспечивающие механизм ADO доступа к БД Oracle. (см. asp.parus.ru).
В 1С WEB-расширение также обеспечивает ASP-разработку через собственную библиотеку связи с V7Script.
В любом случае SOAP-сервер, обеспечивающий вызовы native-plug-ins ДОЛЖЕН быть реализован как WEB-приложение:
1. для DOMINO - как WEB-приложение DOMINO с использованием библиотеки SOAP-поддержки;
2. для 1С и ПАРУС как WEB-приложение IIS с использованием MS SOAP Toolkit;
3. для систем, базирующихся на СУБД Oracle, как внешнее приложение на базе WEB - сервера APACHE с использованием библиотеки поддержки APACHE AXIS и APACHE SOAP.
Литература
1. Дейт К. Дж. Введение в системы баз данных / Пер. с англ. 6-е изд. К.: Диалектика, 1998)
2. Д.С. Порай "Обработка документов как основа построения информационных систем"
3. Башмаков А.И., Старых В.А. Систематизация информационных ресурсов для сферы образования: классификация и метаданные. - М.: "Европейский центр по качеству", 2003. - 384 с.
4. Дунаев С.Б. "Технология Интернет-программирования" BHV Cпб 2001