PC Week/RE
Замечательная технология XML позволяет решать многие застарелые проблемы автоматизации на современном уровне и открывает пути к совершенно новым возможностям. Но, как и любая другая технология, она требует взвешенного применения, основанного на тщательном анализе конкретной задачи и выборе среди множества вариантов. Надеемся, что практический опыт компании Intersoft Lab, о котором рассказано в этой статье, будет полезен и интересен читателям.
В настоящее время применение XML (eXtensible Markup Language) становится все более широким. Основные задачи, решаемые при помощи этой технологии в бизнес-приложениях, таковы:
Обладая множеством достоинств, 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-страницы на основе чтения тех же метаданных.