Использование XML в бизнес-приложениях

ТЕХНОЛОГИЯ

Замечательная технология XML позволяет решать многие застарелые проблемы автоматизации на современном уровне и открывает пути к совершенно новым возможностям. Но, как и любая другая технология, она требует взвешенного применения, основанного на тщательном анализе конкретной задачи и выборе среди множества вариантов. Надеемся, что практический опыт компании Intersoft Lab., о котором рассказано в этой статье, будет полезен и интересен читателям.

В настоящее время применение XML (eXtensible Markup Language) становится все более широким. Основные задачи, решаемые при помощи этой технологии в бизнес-приложениях, таковы:

- обмен данными между системами разных производителей;

- сбор данных из удаленных подразделений;

- обмен коммерческими документами между предприятиями (B2B);

- сбор отчетности государственными организациями;

- поставка данных и метаданных тонким Интернет-клиентам;

- хранение и дистрибуция метаданных хранилищ и других систем.

Обладая множеством достоинств, XML, однако, не является ключом к решению всех проблем. Эффективность данной технологии напрямую зависит от способа ее использования, адекватного конкретной задаче.

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

XML обладает рядом преимуществ перед другими языками/форматами описания данных при обмене данными между приложениями:

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

2. Поддержка производителями. Библиотеки для работы с XML созданы для всех ведущих языков программирования и популярных СУБД. Использование этих библиотек позволяет существенно уменьшить объем кодирования при разработке “шлюзов” между приложениями.

3. Самодокументированность. XML-документ “читабелен” для человека. Кроме того, наличие внутри него описания данных позволяет создавать автоматические программы их обработки, например универсальные модули загрузки данных, поступающих из разных систем в единое хранилище.

4. Иерархичность. Это ключевое свойство языка. В отличие от формата CSV (текстового файла с разделителем “;”), XML позволяет легко описывать сложные структуры данных с неограниченной вложенностью объектов.

5. Объектность. Структура данных XML отлично сочетается с объектно-ориентированной моделью программирования. Каждый тег XML-документа может быть поставлен в соответствие классу или свойству класса обрабатывающей программы. С другой стороны, есть возможность описать в XML-формате каждый прикладной объект предметной области как отдельный тег.

6. Расширяемость. В процессе эксплуатации XML-формата в него можно добавлять новые теги. Это не приведет к фатальному изменению структуры данных, просто читающие и пишущие программы нужно будет дополнить классами или функциями, распознающими эти теги.

Анализ перечисленных выше преимуществ показывает эффективность и долгосрочную перспективность применения XML в качестве формата обмена данными между приложениями вместо устаревших “тяжелых” решений или примитивных текстовых файлов с разделителями. Однако гибкость языка XML позволяет совершенно по-разному подойти к описанию одних и тех же данных, к организации их обмена.

Подробнее с языком XML можно познакомиться, например, обратившись к электронному журналу Клуба знатоков технологий DWH, OLAP, XML на сайте www.iso.ru/.

Различные подходы к созданию форматов обмена данными

Можно выделить несколько технологий описания XML-форматов, предназначенных для обмена данными между бизнес-приложениями:

Описание физических таблиц. Такой подход очень легко реализовать, например, используя продукты Borland. При сохранении таблицы (ClientDataSet) в XML создается документ, содержащий “пакет данных”, в который вложены метаданные таблицы - тег <METADATA> и записи таблицы - тег <ROWDATA>. Внутри тега <METADATA> находятся поля <FIELDS> с описанием их физических наименований и типов данных, а внутри тега <ROWDATA> - записи таблицы - теги <ROW>. Запись есть минимальный элемент данных:

<ROW RowState=”4” ID=”1” Name=”Петров”/>

Такой же простой подход предлагается и в СУБД MS SQL Server 2000. Обычное выражение Select, дополненное ключевыми словами For XML, возвращает XML-документ, состоящий из записей вида:

<Customers CustomerID=”1” ContactName=”Иванов”/>, где имя тега равно имени таблицы, а его свойства - именам полей таблицы.

Наверное, создание формата “от таблицы” - это самое неудачное решение для обмена данными. Такой обмен предполагает всего лишь низкоуровневую репликацию баз данных и требует знания физических структур источника и приемника. При малейшем изменении структур придется перепрограммировать процедуры экспорта-импорта. Кроме того, на этапе загрузки нет возможности выполнять правила бизнес-логики, построенные на понимании программой элементов загружаемых данных, поскольку объектами документа являются физические записи таблицы.

Более сложный запрос к базе данных MS SQL 2000, когда таблицам и ее полям присвоены псевдонимы, а в запросе содержатся вложенные запросы, возвращает XML-документ, имеющий объектную иерархическую структуру:

<company CompanyName=”ООО Радуга”>

<order OrderID=”10248” OrderDate=”1996-07-04”>

+

Результатом применения XML, встроенного в SQL, может быть “правильный” XML-документ, состоящий из описаний объектов предметной области, но только в том случае, если структура базы достаточно проста, чтобы можно было описать соответствие таблиц и их полей предметным объектам XML-документа таким лаконичным средством, как язык SQL. А это не всегда возможно для старых систем и не всегда оправданно с точки зрения внутренней логики БД. Кроме того, прямое чтение (запись) XML в базе данных также означает отсутствие в системе промежуточного слоя, выполняющего правила бизнес-логики.

Описание отчетных форм. Этот подход часто применяется на практике, когда головной офис собирает с филиалов отчеты, например о прибылях и убытках. Существует стандарт XBRL, в котором регламентируется создание “топономий” - словарей отчетных форм для отраслей. Этот стандарт независим от реализации автоматизированных систем, но предполагает ограниченное использование собранных отчетных данных, в основном для печати отчетов. В разных отчетных формах могут дублироваться одинаковые финансовые показатели и другие объекты, что неизбежно должно привести к рассогласованию ссылочной целостности, если использовать этот формат не для сбора отчетов, а для обмена данными.

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

Обмен данными внутри одной организации

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

Однако в рамках одного предприятия более разумным и экономичным представляется “диктаторский” подход с принудительным введением единого формата. Это позволит отказаться от дополнительного ПО для преобразования форматов и соответствующих регламентных и административных работ.

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

Обмен данными между организациями

Для систем класса B2B, позволяющих независимым и равноправным партнерам обмениваться деловыми документами, взаимное преобразование нескольких корпоративных XML-форматов неизбежно. Несмотря на большие усилия, предпринимаемые инициативными группами по созданию отраслевых или даже всеобщих деловых форматов обмена данными, судя по всему, всегда будет существовать множество независимых XML-схем внутри отраслей. Для решения этой проблемы существуют специальные XML-серверы, например BiZTalk корпорации Microsoft, XMLSphere IBM и др.

Сбор отчетности государственными органами

В том случае, когда данными обмениваются вышестоящие организации с нижестоящими - например, Центральный банк с коммерческими банками, МНС с предприятиями, - возникает другая ситуация. Административные возможности государственных организаций могут сыграть положительную роль в создании стандартных XML-схем. Так, принудительное введение XML-формата для передачи в Центральный банк банковских платежей приведет к тому, что все разработчики АБС и бухгалтерских систем предприятий встроят в свои системы модули обмена платежными документами в едином формате. Это не только ускорит прохождение платежей, но и даст импульс развитию систем B2B.

Создание стандарта отчетности в виде XML-документов, содержащих наборы уникальных показателей, позволит банкам и предприятиям получить существенную экономию при формировании отчетности. Контролирующим органам будет легче внедрить современные технологии, такие, как хранилища данных и OLAP.

Предоставление данных Интернет-клиентам

Формальное решение проблемы находится на поверхности. Поскольку изначально предполагалось, что технология XML всего лишь должна была отделить данные от их представления, то XML-документ, поставляемый бизнес-приложениями Интернет-клиентам, легче всего представить себе как перечень колонок и строк таблицы, содержащей данные и XSL-файл с описанием отображения этой таблицы на экране. Однако такой подход представляется слишком упрощенным. Он идет не от структуры данных и информационной модели бизнес-системы, а опять же от технологии отображения статичных данных в браузере.

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

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

(Окончание следует)