Глеб Ладыженский, Oracle Россия
Обсуждение XML не сходит со страниц большинства компьютерных изданий, а сам язык и его применение в сфере электронного бизнеса является "темой года". На наш взгляд, такая популярность вполне заслужена - не только и не столько как собственно языка разметки электронных документов, но и как универсального формата для обмена электронными документами.
Наибольший интерес вызывает возможность организации обмена электронными документами между приложениям при помощи стандарта XML. В силу самоопределенности XML-документов, приложения могут передавать друг другу данные через XML-документы, не имея никакой дополнительной информации о струткуре передаваемых данных. Дело в том, что приложения могут работать с XML-документами нормальным образом, не привлекая для этого соответствующий DTD (Document Type Definition), то есть в общем случае двум приложениям, чтобы понять один XML-документ, не нужно пользоваться каким-то общим DTD, задающим XML-документ. Как раз этот факт делает обмен документами между приложениями простым, гибким и надежным.
Доклад посвящен программной инфраструктуре, которая необходима для осуществления такого обмена. Очевидно, что в качестве ее основы можно было бы использовать традиционные средства ПО промежуточного слоя - собственно, в работающих системах передачи XML-документов они и применяются.
Корпорация Oracle поставляет набор компонентов, утилит и интерфейсов для организации работы с XML-документами. Этот набор включает:
Существуют три базовых стратегии хранения XML-документов в базе данных Oracle
(1). Хранение XML-документов (вместе с тэгами, то есть полностью) как отдельных неделимых объектов. Документы храняться как данные типа CLOB или BLOB.
(2). Хранение элементов XML-документов как данных (то есть собственно данных, без тэгов) в объектно-реляцонном представлении; фактически, в таблицах реляционной базы данных.
(3). Смешанное хранение документов и данных с использованием представлений (views)
Хранение XML-документов в базе как неделимых объектов подходит в том случае, когда их содержание статично и, что существенно, любое обновление документа сводится к его перезаписи в базе данных. Типичные примеры таких документов - статьи, книги, технические руководства, контракты и т.д.То есть документы в обычном значении этого слова, и они храняться в базе данных целиком и поставляются из нее вовне также целиком.
Oracle умеет хранить документы такого типа в различных форматах (MS Word, WordPerfect, Acrobat и так далее), более того, организовывать по ним эффективный изощренный поиск и в том числе с использованием морфологии русского языка. В смысле особенностей хранения и обработки XML-документы ничем не отличаются от документов других форматов и сервер Oracle хранит их как большие объекты и не делает никакого различия между ними и, например, документами в формате MS Word.
Если документ структурно корректен и содержит элементы, которые могут обновляться и вообще использоваться по отдельности, а не как единое целое, то такой документ можно назвать датацентрическим. Обычно такие документы включают один или несколько элементов со сложной структурой. Примерами могут послужить бланки заказов, финансовые счета и т.д., то есть документы на базе сложных форм. Сервер Oracle8i предоставляет адекватные структуры для хранения и обработки элементов сложных документов. Речь идет об объектах в базе данных Oracle, конкретно - о типах, ссылках и коллекциях (collections). Возможны два варианта отображения структурированных XML-документов в объектно-реляционные структуры базы данных Oracle:
Будучи сохраненными в объектно-реляционной базе данных, элементы документа становятся объектом различных операций, таких как выборка, обновление и т.д., осуществляемых с помощью утверждений языка SQL. Собственно процедура отображения документа в объектно-реляционную базу данных, равно как и различные поисковые операции над данными-элементами документа, занесенными в базу данных, выполняются программой XML SQL Utility (о ней подробнее будет расказано ниже).
Если документ структурирован, но его структура в целом не соответствует схеме поддерживающей (underlaying) базы данных, необходимо преобразовать документ к нужному формату до его записи в базу данных. Этого можно достигнуть, используя механизм стилей.
Наконец, если необходимо обрабатывать документы смешанных типов, когда имеются как структурированные, так и неструктурированные данные в формате XML, рассматриваемые, тем не менее, как единый документ, целесообразно использовать представления Oracle. Они позволяют конструировать объекты "на лету", комбинируя данные, которые храняться в различном виде. Таким образом, можно хранить структурированные данные (такие, например, как данные о сотрудниках, заказчиках и т.д.) в одной точке с использованием объектно-реляционных таблиц, и хранить неструктурированные данные (такие как описания и комментарии) как данные типа CLOB. Когда необходимо обновить данные в целом, можно попросту создать структуру из различных "кусочков" данных с использованием конструктора типов в операторе SELECT, примененном к view. Утилита XML SQL далее даст возможность поиска сконструированных данных в view как отдельного XML-документа.
В общем случае, обмен данными между приложениями, которые разделяют некий общий DTD, сводится к выполнению следующих действий:
Существует несколько сценариев организации обмена XML-данными, которые рассматриваются ниже.
На рис.1 приведен пример такого обмена. Здесь пользователь вводит запрос посредством использования Web-формы. XML-данные генерируются компонентом XSQL Servlet. XML-документ структурирован в соотвествии с некоторым DTD, который далее рассматривается как разделяемый несколькими приложениями. Приложение-приемник получает XML-документ, выполняет его анализ с привлечением программы-анализатора для Java и записывает XML-данные в свою базу данных с помощью XML SQL Utility.
Рис.1. Пример обмена XML-данными с использованием общего DTD
Возможен иной вариант развития событий, представленный на рис.2. Некий заказчик оформляет заказ на покупку, обращаясь к Web-странице. Ввод заказов обеспечивает приложение Электронный магазин. Введенный заказ передается некоторому приложению Бухгалтерия, и, после обработки, направляется приложеним Склад и Поставка. Каждое приложение в цепочке читает и обрабатывает XML-данные так, как это предписано их логикой и записывает некоторые из этих данных в их собственные базы данных. Каждое приложение в цепочке передает следующему исходный или модифицированный в процессе обработки XML-документ.
Рис.2. Альтернативный вариант обмена XML-данными с использованием общего DTD
Ниже расписаны роли каждого из приложений.
Приложение Электронный магазин
Приложение Бухгалтерия
Приложение Склад и Поставка
В этом случае необходимо выполнение некоторых дополнительных действий. Например, возможна ситуация, когда мы хотим записать содержание XML-документа в базу данных, однако его структура не соответствует структуре таблицы (или таблиц) поддерживающей базы данных. Следовательно, необходимо выполнить преобразование XML-документа до записи значений из него в базу данных.
Хорошим способом будет использование стилей для преобразования исходного документа в новый, структура которого соответствует структуре таблицы поддерживающей базы данных. В этом случае можно было бы получить XML-документ, соответствующей структуре таблицы, используя XML SQL Utility. Дополнительно можно было бы получить таким образом и "локальный" DTD и использовать его для "оформления" приходящих "внешних" по отношению к этой базе данных документов. Общая схема описанного процесса представлена на рис.3.
Рис.3. Обмен XML-документами при отсутствии общего DTD
XML SQL Utility создает DTD в отдельном файле или добавляет его к сгенерированному XML-документу в тэге DOCTYPE. DTD можно использовать для разработки стилей, которые будут использованы для преобразования исходного XML-документа до записи в базу данных. Эта возможность проиллюстрирована рис.4.
Рис.4. Использование DTD для разработки стилей
Очевидны естественные ограничения DTD. Основная неприятность состоит в том, что DTD не содержит информации о типах данных. Собственно основным и единственным типов данных документов, описывемых DTD, является строка символов. Ясно, что при извлечении данных из базы данных будет потеряна такая важная характеристика, как тип данных. Это означает, что приложение использующее DTD, должно само присваивать типы данным, опираясь на контекст, то есть выводя типы из элементов, которым они приписаны.
Как добиться того, чтобы данные, введенные посредством заполнения полей Web-формы, были бы адекватно отображены в таблицу (таблицы) поддерживающей базы данных? Ответ дает приведенная ниже псоледовательность действий.
Существует несколько возможностей по передаче XML-документов между приложениями. Во-первых, их можно передавать попросту как файлы, используя для этой цели FTP, NFS, SMB либо другие известные протоколы передачи файлов. Во-вторых, можно использовать HTTP. В этом случае приложение, которому необходим XML-документ, запрашивает по HTTP сервлет. Третьей возможностью является использование Web-форм.
Наконец, можно использовать компонент Oracle8i Server под названием Advanced Queuing (специализированное средство для управления очередями). Рассмотрим эту возможность более подробно. Oracle Server может инициировать отправку XML-документа через Net8 и JDBC в качестве сообщения одному или нескольким приложениям-приемникам, используя для этой цели Oracle Advanced Queuing (AQ). Приложение-приемник извлекает XML-документ из входной очереди сообщений и обрабатывает его. Это как раз тот подход, который используется Oracle для интеграции приложений. Здесь сообщения в формате XML направляются инициирующими приложениями некоторому серверу, который можно было бы назвать сервером сообщений (AQ Hub) - по отношению к тем приложениям, которые хотели бы получать сообщения, циркулирующие в системе. При этом может быть использован стандартный механизм взаимодействия "публикация/подписка", который уже реализован в Oracle8i.
На рис.5 представлена архитектура системы, в которой различные приложения асинхронно взаимодействуют, направляя друг другу стандартизованные (XML) сообщения, извлекают из них собственно данные, размещая их в локальных, принадлежащих им базах данных и генерируя сообщения на основе данных, хранящихся в локальных базах. Вся инфраструктура целиком строится на основе продуктов Oracle, ядром системы является сервер Oracle8i Enterprise Edition. Использование только Net8 является некоторым ограничением архитектуры, не позволяя расширить ее до масштабов глобальной сети, однако не будем забывать, что пересылку данных можно будет организовать и другими способами (FTP, HTTP).
Рис.5. Архитектура системы с асинхронной передачей стандартизованных сообщений
Рассмотрим более общую ситуацию, когда необходимо организовать обмен документами между двумя независимыми организациями. Пусть одна из них использует приложения Oracle Applications (на основе СУБД Oracle), другая - какие-либо другие приложения и не обязательно на основе Oracle. Более того, в рамках локальной сети первой организации для обмена электронными документами между различными приложениями используется описанная выше схема на основе Net8 и AQ, в другой же организации в качестве Message Oriented Middleware (MOM) используется IBM MQSeries. Очевидно, что в такой неоднородной среде необходим посредник, умеющий работать с различными системами MOM. В этом качестве Oracle предлагает использовать продукт Oracle Message Broker, реализованный на основе спецификации Java Message Service (JMS).