Интеграция корпоративных приложений. Подход Oracle

Глеб Ладыженский

Введение

Стратегии хранения XML-документов в базе данных Oracle

Поддержка XML в Oracle XML Developer’s Kit

   Программы-анализаторы и XSLT-процессоры

   Генераторы XML-классов

   XML SQL Utility

   XSQL Servlet

Другие полезные компоненты XML SDK

Обмен документами между приложениями

Архитектура для обмена XML-данными

Заключение

Введение

В этой статье я попытался описать основы нового, быстро развивающегося направления — так называемой интеграции корпоративных приложений (Enterprise Architecture Integration, EAI). Интерес к этому направлению возник, когда стало ясно, что рост решений для внутренней автоматизации компаний постепенно выходит на «плато стабильности» — прежде всего за счет появления большого числа разномасштабных готовых решений в области ERP¹. Достижение высокой производительности труда за счет внутренней автоматизации не гарантирует высокой эффективности работы компании в целом. Внутренне хорошо организованная и эффективная компания, применяющая современные методы автоматизации, тем не менее может очень много терять из-за архаичных способов взаимодействия с внешним миром и прежде всего с другими компаниями — партнерами, поставщиками и т.д. Похоже, что основной упор в разработке новых информационных технологий в следующие 5-10 лет будет сделан именно в области интеграции бизнесов, точнее, в области интеграции корпоративных приложений. Нужно быть готовыми к этому идейно и технологически.

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

Стратегии хранения XML-документов в базе данных Oracle

Существуют три стратегии хранения 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:

1. Хранение атрибутов элементов XML-документов только в таблицах базы данных и использование объектных представлений для воспроизведения структуры XML-документов.
2. Хранение структурированных элементов XML в объектных таблицах.

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

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

Наконец, если необходимо обрабатывать документы смешанных типов, когда имеются как структурированные, так и неструктурированные данные в формате XML, рассматриваемые тем не менее как единый документ, можно использовать представления Oracle. Они позволяют конструировать объекты «на лету», комбинируя данные, которые хранятся в различном виде. Таким образом, структурированные данные (такие, например, как данные о сотрудниках, заказчиках и т.д.) можно хранить в одной точке с использованием объектно-реляционных таблиц, а неструктурированные данные (например, описания и комментарии) — как данные типа CLOB. Если необходимо обновить данные в целом, можно попросту создать структуру из различных «кусочков» данных с использованием конструктора типов в операторе SELECT, примененном к view. XML SQL Utility (будет описана ниже) даст возможность поиска сконструированных данных в view как отдельного XML-документа.

Поддержка XML в Oracle XML Developer’s Kit

Прежде всего следует рассказать об инструментарии, необходимом для программирования процессов обмена электронными документами.

Корпорация Oracle поставляет набор компонентов, утилит и интерфейсов для организации работы с XML-документами. Этот набор называется XML Developer’s Kit (XDK). Он существует в пяти вариациях: XDK for Java, XDK for JavaBeans, XDK for C, XDK for C++, XDK for PL/SQL. XDK включает в себя следующие компоненты:

1. XML Parsers (Java, C, C++, PL/SQL).
2. XSLT Processors.
3. XML Class Generator (Java, C++).
4. XML SQL Utility.
5. XSQL Servlet.
6. XML Scheme Processor.
7. XML Transviewer Java Beans.

Более подробно перечисленные компоненты будут рассмотрены ниже.

Программы-анализаторы и XSLT-процессоры

В рамках XML Parsers Oracle поставляет набор программ-анализаторов XML-документов для Java, C, C++ и PL/SQL (рис. 1). Каждый из них представляет собой отдельно устанавливаемый компонент, который анализирует (разбирает) XML-документ (или DTD) таким образом, что далее с ним (документом) может продолжить работу некоторая программа. Программы-анализаторы обеспечивают генерацию интерфейсов прикладного программирования в одном из двух вариантов: DOM (Document Object Model) или SAX (Simple API for XML). Кроме того, программы-анализаторы поддерживают механизм XML Namespace (спецификация W3C XML Namespaces 1.0), обеспечивают проверку структурной и синтаксической корректности XML-документов.

Интерфейс прикладного программирования для доступа к XML-документам может быть в двух вариациях: основанный на событиях (спецификация SAX 1.0) и основанный на древовидных структурах (W3C DOM 1.0).

Программа-анализатор строит в собственном пространстве памяти некоторую (древовидную или событийную) структуру, позволяющую оперировать ею любой программе с конкретными целями, например с целью преобразования структуры документа. Доступ к этой структуре осуществляется с помощью DOM- или SAX-интерфейса.

Таким образом, программа, которая должна поработать с XML-документом, должна вызвать предварительно программу-анализатор, получить с ее помощью требуемую структуру и затем оперировать ее элементами посредством использования интерфейса DOM или SAX таким способом, который зависит от типа используемой программы-анализатора. Так, имея дело с C++- или Java-анализатором, мы будем использовать методы соответствующих классов; для C это будут функции некоторой библиотеки и т.д.

Вторая версия программ-анализаторов XML-документов включает специальную утилиту для преобразований XML-данных с использованием механизма стилей. Это так называемый XSL Transformation (XSLT) Processor, или, для краткости, XSLT-процессор (рис. 2). Используя его, мы получаем возможность трансформации документов различных форматов, например XML в XML, в HTML или любой иной текстовый формат.

XSLT-процессоры соответствуют спецификациям W3C XSL Transform Proposed Recommendation 1.0 и Xpath Proposed Recommendation 1.0. Доступны библиотеки для Java, C, C++, PL/SQL.

Генераторы XML-классов

Цель XML Class Generators — создание программных единиц (классов) на основе данных, предоставляемых DTD. Типичная задача обмена документами — обмен XML-данными между двумя приложениями.

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

Данный генератор создает исходные файлы из XML DTD. Это полезно, когда приложение хочет послать XML-сообщение другому приложению, опираясь на согласованный DTD. Используя эти классы, Java-приложение может конструировать, проверять и печатать XML-документы, совместимые с входным DTD. Генератор классов работает в связке с программой-анализатором XML для Java, который разбирает DTD и передает разобранный документ генератору классов (рис. 3).

В рамках XDK доступны генераторы классов для Java и C++.

XML SQL Utility

Эта утилита представляет собой набор классов Java, которые выполняют следующие функции:

• передают SQL-запрос серверу баз данных и генерируют XML-документ исходя из результирующего набора данных, возвращаемого по запросу (result set);
• записывают данные XML в соответствующие таблицы базы данных.

Как показано на рис. 4, XML SQL Utility обрабатывает SQL-запросы и возвращает результат как XML-документ.

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

XML SQL Utility используется и для записи XML-данных в таблицы базы данных, причем в качестве сервера баз данных используется Oracle8i.

Помещение XML-документа в базу данных под управлением Oracle8i сохраняет структуру документа. Имена элементов преобразуются в имена столбцов таблицы; элементы документа, содержащие только текст, — в скалярные столбцы; элементы, содержащие вложенные элементы, — в типы объектов; списки элементов преобразуются в коллекции. Неструктурированные данные, такие как текстовые комментарии или описания, не могут быть преобразованы к хранимым в базах данных типам и должны быть сохранены как CLOB.

XSQL Servlet

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

Сервис — реализация серверной части какого-либо протокола прикладного уровня, такого как HTTP, FTP и т.п.

Сервер — процесс (в смысле операционной системы), содержащий виртуальную Java-машину, в которую загружены классы, обеспечивающие работу одного или нескольких сервисов.

Сервлет — это класс, стандартным образом расширяющий функциональность какого-либо сервиса.

XSQL Servlet предназначен для обработки SQL-запросов и поставки пользователю результирующих наборов данных в виде XML-документов. Этот процессор реализован как сервлет Java, берет в качестве входного XML-файл, содержащий встроенный SQL-запрос, и использует программу-анализатор XML-документов.

XSQL Servlet можно использовать совместно с любым Web-сервером, который поддерживает сервлеты Java. На рис. 5 показана схема работы пользователя с данными с применением сервлетов.

Цифрами на рисунке обозначена последовательность действий. Она выглядит следующим образом:

1. Пользователь, работая с навигатором, вводит URL, который интерпретируется и передается через Java Web Server компоненту XSQL Servlet. URL содержит имя XSQL-файла (с расширением .xsql) и, возможно, некоторые параметры, такие как значения и имя стиля. В то же время пользователь может вызвать XSQL Servlet и из командной строки.
2. Сервлет передает XSQL-файл программе-анализатору XML-документов (XML Parser for Java), которая, в свою очередь, разбирает XML и предоставляет программный интерфейс для доступа к документу.
3. Процессор страниц (page processor), один из компонентов сервлета, использует сгенерированный API для передачи XML-параметров и запросов на языке SQL (которые помещаются между тэгами <tag></tag>) компоненту XML SQL Utility. Процессор страниц также передает любые операторы XLS-процессинга XSLT-процессору.
4. Компонент XML SQL Utility направляет SQL-запрос к запрашиваемой базе данных под управлением Oracle8i, сервер баз данных возвращает результирующий набор данных компоненту XML SQL Utility
5. Компонент XML SQL Utility возвращает результат запроса XSLT-процессору в виде текста на языке XML. Этот текст помещается на то место в исходном файле, которое было помечено тэгом <query>.
6. Если это необходимо, результат запроса и любые другие XML-данные трансформируются XSLT-процессором с использованием заданных стилей. Данные могут быть преобразованы в HTML или любые другие форматы, определенные стилем. XSLT-процессор может выборочно применять различные стили, имея в виду тип клиента, который сделал исходный URL-запрос.
7. Наконец, XSLT-процессор возвращает сформированный документ навигатору, и тот отображает его для пользователя.

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

Другие полезные компоненты XML SDK

ХML Transviewer Java Beans представляет собой набор Java-классов, выполненных по технологии Java Beans и исключительно полезных при разработке интерактивных приложений, обрабатывающих XML-документы.

В XML SDK включено несколько простейших компонентов (beans), упрощающих работу с XML-документами. Компонент DOM Builder включает анализатор XML-документов и расширяет его функциональность, допуская асинхронный анализ документов. Компонент TreeViewer отображает XML-файлы в виде дерева; при этом структуру документа можно переопределять, перемещая узлы с помощью мыши. Компонент SourceVeiwer дает возможность отображать XML-файлы с динамической цветовой подсветкой некорректных конструкций параллельно с модификацией XML-файлов каким-либо из XML-редакторов (сам редактор не включен в набор XML SDK). Интегрируя данный компонент с DOM Builder, можно строить приложения для интерактивного анализа XML-документов и проверки их синтаксической корректности посредством сопоставления с DTD. Наконец, компонент XSL Transformer предоставляет возможность трансформации XML-документов практически во все типы текстовых документов, включая HTML, DDL, за счет применения к ним стилей.

XML Scheme Processor — это компонент, позволяющий описывать типы данных в документах XML c помощью конструкций XML Schema. Ведь DTD не содержит информации о типах данных. Собственно, основным и единственным типом данных документов, описываемых DTD, является строка символов. Ясно, что при извлечении данных из базы данных будет потеряна такая важная характеристика, как тип данных. Это означает, что приложение, использующее DTD, должно само присваивать типы данным, опираясь на контекст, то есть выводя типы из элементов, которым они приписаны. Этого делать не нужно, если в распоряжении разработчика имеется механизм для описания типов данных в XML-документах — что и предоставляет XML Schema (поддержка Java, C, C++).

Обмен документами между приложениями

Обычно обмен данными между приложениями, которые разделяют некий общий DTD, сводится к выполнению следующих действий:

1. Приложение, передающее данные (источник), генерирует XML-документ с использованием общего DTD.
2. Источник направляет сгенерированный XML-документ приложению, принимающему данные (приемник).
3. Приемник анализирует XML-данные, выполняет над ними свои собственные операции и записывает данные в базу данных, с которой он (приемник) работает.
4. Приемник становится источником и направляет оригинальный XML-документ (или, возможно, новый документ, сгенерированный им самим) следующему приложению в цепочке обмена данными.

Существует несколько сценариев организации обмена XML-данными; некоторые из них рассматриваются ниже.

На рис. 6 приведен пример такого обмена. Здесь пользователь вводит запрос с помощью Web-формы. XML-данные генерируются компонентом XSQL Servlet. XML-документ структурирован в соответствии с некоторым DTD, который далее рассматривается как разделяемый несколькими приложениями. Приложение-приемник получает XML-документ, выполняет его анализ с привлечением программы-анализатора для Java и записывает XML-данные в свою базу данных с помощью XML SQL Utility.

Возможен иной вариант развития событий, представленный на рис. 7. Некий заказчик оформляет заказ на покупку, обращаясь к Web-странице. Ввод заказов обеспечивает приложение Электронный магазин. Введенный заказ передается приложению Бухгалтерия и после обработки направляется приложению Склад и Поставка. Каждое из приложений в цепочке читает и обрабатывает XML-данные так, как это предписано их логикой, и записывает некоторые из этих данных в их собственные базы данных. Каждое приложение в цепочке передает следующему исходный или модифицированный в процессе обработки XML-документ.

Рассмотрим роли каждого из приложений.

Приложение Электронный магазин:

1. Приложение генерирует форму заказа.
2. Заказчик использует форму для запроса к базе данных для поиска доступных товаров, вводит необходимые для оформления заказа данные и подтверждает заказ.
3. Приложение получает заказ и на его основе генерирует XML-документ на основе общего DTD.
4. Приложение направляет DTD- и XML-документ в приложение Бухгалтерия.

Приложение Бухгалтерия:

1. Получает и обрабатывает заказ (XML-документ), полученный из Электронного магазина.
2. Преобразует XML с использованием соответствующего стиля в представление заказа навигатора, с которым работает бухгалтер.
3. Бухгалтер запрашивает базу данных о заказчиках, проверяет кредитную информацию по заказчику, подтверждает или отвергает заказ.
4. Приложение обновляет соответствующие записи в таблицах базы данных, используя для этого данные, полученные из XML-документа.
5. Приложение на основе общего DTD генерирует новый XML-документ (модифицированный заказ), содержащий все привнесенные бухгалтерией значения, и передает его следующему в цепочке приложению.

Приложение Склад и Поставка:

1. Получает и обрабатывает XML-документ, используя для этого DTD, также полученный из приложения Бухгалтерия.
2. Обновляет записи в базе данных поставок, используя для этого данные о заказчике и заказе, взятые из XML-документа.
3. Приложение генерирует внешнее представление XML-документа для навигатора, который используется пользователем-кладовщиком.
4. Кладовщик отпускает товар заказчику.

Очевидно, что помимо собственно баз данных для хранения XML-документов (Oracle8i) и средств их обработки (XML SDK) необходима среда для гарантированной и надежной доставки XML-сообщений приложениям. Роль такой среды выполняет ПО промежуточного слоя, конкретно — продукты, которые относятся к категории Message-oriented middleware, то есть программное обеспечение промежуточного слоя, ориентированное на обработку сообщений.

Архитектура для обмена XML-данными

Существует несколько возможностей передачи 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.

На рис. 8 представлена архитектура системы, в которой различные приложения асинхронно взаимодействуют, направляя друг другу стандартизованные (XML) сообщения, извлекают из них собственно данные, размещая их в локальных, принадлежащих им базах данных и генерируя сообщения на основе данных, хранящихся в локальных базах. Вся инфраструктура целиком строится на основе продуктов Oracle, ядром системы является сервер Oracle8i Enterprise Edition. Использование только Net8 является некоторым ограничением архитектуры, не позволяющим расширить ее до масштабов глобальной сети. Однако не будем забывать, что пересылку данных можно будет организовать и другими способами (FTP, HTTP).

Нетрудно увидеть, что в этой ситуации мы имеем дело с однородной архитектурой (все продукты от Oracle), но с относительно изолированными подсистемами (каждое из приложений работает изолированно, со своей собственной базой данных). Отличительными чертами архитектуры являются также асинхронный характер взаимодействия приложений (приложения направляют XML-документы адресату и продолжают выполнять свои функции) и использование единого протокола прикладного уровня (Oracle Net8).

Рассмотрим более общую ситуацию, когда необходимо осуществить обмен документами между двумя независимыми организациями. Пусть одна из них использует приложения Oracle Applications (на основе СУБД Oracle), другая — какие-либо другие приложения (не обязательно на основе Oracle). Более того, в рамках локальной сети первой организации для обмена электронными документами между различными приложениями используется описанная выше схема на основе Net8 и AQ, в другой же организации в качестве Message Oriented Middleware (MOM) используется IBM MQSeries. Очевидно, что в такой неоднородной среде необходим посредник, умеющий работать с различными системами MOM. В этом качестве Oracle предлагает использовать продукт Oracle Message Broker, реализованный на основе спецификации Java Message Service (JMS), разработанной Sun Microsystems. Разработчики определили JMS как «API for accessing enterprise messaging systems from Java», то есть интерфейс прикладного программирования для доступа к корпоративным системам передачи сообщений.

Упрощенно архитектура такой системы представлена на рис. 9.

На рисунке изображена архитектура взаимодействия трех корпоративных приложений, два из которых — Финансовый учет и Электронная торговая площадка (ЭТП) работают в однородной архитектуре на основе Oracle, а третье приложение — Каталоги товаров — функционирует вообще в рамках другой информационной системы, но должно взаимодействовать с приложением ЭТП, направляя ему текущий каталог товаров, выставляемых для продажи. Для доставки каталогов товаров — сообщений, тело которых представляет собой XML-документы, используется MQSeries. Получая из среды MQSeries сообщения, Oracle Message Broker преобразует их к универсальному формату JMS и перенаправляет в очередь Advanced Queuing для последующей доставки приложению ЭТП, которое в определенные моменты времени или по уведомлению актуализирует полученный каталог, помещая данные из XML-документа в базу данных.

Заключение

Итак, архитектурными и технологическим основами EAI являются промышленные реляционные базы данных с развитым инструментарием обработки XML-документов. В EAI приложения асинхронно взаимодействуют, направляя друг другу сообщения стандартных форматов через хранимые очереди сообщений. Главными архитектурными компонентами EAI являются интеграционный сервер и маршрутизатор сообщений на основе JMS, а программную инфраструктуру образует ПО MOM.

КомпьютерПресс 6'2001