Перспективная технология облегчает создание сервисов, работающих с XML

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

Те, кто работает с XML, Web-сервисами или сервис-ориентированной архитектурой (СОА), вероятно, смогут получить преимущества от использования вновь появившегося стандарта XQuery. Он еще даже не является формально принятым, но уже широко внедрен в практику, облегчая жизнь архитекторам и разработчикам программного обеспечения. Язык, начинавшийся как стандарт для запросов к XML-документам, сегодня включает стандарты следующего поколения для осуществления выбора фрагментов XML-документа (XPath 2), преобразований XML-документа в поток байтов, полнотекстового поиска и функционального моделирования XML-данных. Вокруг такого значительного проекта неизбежно возникает множество мифов и заблуждений, которые нуждаются в разоблачении. Ниже рассматриваются некоторые из наиболее распространенных мифов, связанных с XQuery.

Заблуждение: компании, создающие базы данных, рассматривают XQuery как непосредственного конкурента их основному бизнесу

На самом деле компании, занимающиеся базами данных, рассматривают XQuery как возможность расширить свои решения.

Для архитекторов и разработчиков программного обеспечения XQuery - это увеличение производительности и скорости выполнения операций. Поэтому объяснимо желание поставщиков инструментов (см. раздел Ресурсы) воспользоваться возможностями этого языка.

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

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

Доказательством этой возможности является тот факт, что XQuery сплотил жестких конкурентов - компании IBM и Oracle - для совместной разработки спецификации JSR 225 (см. раздел Ресурсы) - интерфейса прикладного программирования на языке XQuery для Java (XQJ). А Microsoft и IBM объединились для того, чтобы представить тестовый комплект XQuery в Консорциум всемирной сети (World Wide Web Consortium W3C).

Миф: XQuery заменит XSLT

За XQuery и XSLT стоят достаточно мощные движущие силы разработчиков, поэтому они будут сосуществовать. На самом деле, последние спецификации, описывающие XQuery 1.0 и XSLT 2.0, разрабатываются в тандеме.

Область пересечения XQuery и XSLT - это те проблемы, для решения которых они созданы: трансформация данных в формате XML, федерализация XML-наборов и расширенные запросы к XML-данным. Разработчикам придется наблюдать и дальнейшие дискуссии о возможностях каждого из этих языков, в которых будет немало мифов и заблуждений. Например, бытует утверждение, что способность XQuery осуществлять запросы к многочисленным несовместимым источникам за один проход дает ему очевидное преимущество над XSLT. На самом деле, процессоры, работающие с XSLT версии 2.0, могут представлять кратные узлы как входную последовательность. В версии XSLT 1.0 есть функция document() для доступа к нескольким источникам за одну операцию трансформации, а версия 2.0 поддерживает функцию new collection() (новый набор). Также существует мнение, что, хотя синтаксис XQuery выглядит лучше, в нем отсутствует возможность поддержки шаблонов стилей, характерная для XSLT. Возможно, это и так, но, вероятно, в XQuery скоро появится такая функция. В конце концов, разработчики могут ожидать как новых улучшений, так и проблем в обеих технологиях, поэтому их функции и возможности будут оставаться достаточно близкими.

Кроме того, есть еще проблема некоторой "заторможенности" разработчиков. Иногда после посещения презентаций, посвященных XSLT, так и не появляется ощущение реального понимания этого языка. XSLT - это синтаксис для операций трансформации, у которого нет функции main() или метода запуска, в отличие от программ на Java и Jython. Поэтому иногда XSLT-скрипт может выглядеть недетерминированным.

Миф: XQuery заменит SQL

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

Как уже было сказано, XQuery имеет такое же значение для XML, как и SQL для реляционных данных. Но иногда XQuery легче использовать, причем даже для работы с реляционными данными. Например, для обычного разработчика гораздо сложнее использовать SQL для создания outer join, которое выводит результаты в новый XML-документ, чем сделать это на языке XQuery.

Популярность XML заставила рабочие группы, занимающиеся стандартами, расширить SQL-спецификацию и включить в нее функции обработки XML.

Заблуждение: для того, чтобы работать с XQuery, необходимо отказаться от процедурного программирования в пользу объектно-ориентированного

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

XQuery полезен для разработчиков тем, что позволяет существенно сократить размер программы, необходимой для выполнения запросов. Например, разработчик имеет реляционные данные, находящиеся в двух или более базах, и ему требуется выдать отчет, показывающий объединение этих баз. Разработчик, использующий процедурный язык программирования, например, такой, как Python, может написать программу в 100 или более строк для извлечения, разбора и обработки данных. Или же он может написать всего несколько строк на языке XQuery.

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

На самом деле, XQuery легче использовать с XML-данными, чем интерфейсы прикладного программирования, осуществляющие разбор XML-документов. JDOM, JAXP и другие интерфейсы предоставляют код на языке Java и методы работы с XML-данными. Многие стандартные подходы объектно-ориентированного программирования предполагают создание объектов, которые будут работать со сложными XML-документами. Создание объектов Java требует времени, усилий и опыта. Любое, даже небольшое изменение базового XML-формата данных требует поддержки этого объекта. Энтузиасты XQuery считают, что XQuery-скрипт быстрее найдет XML-данные, которые должно вывести приложение, чем объект Java, созданный с использованием JDOM. Помимо этого, многие библиотеки XQuery предоставляют Java-интерфейс, так что код на XQuery появляется в классах Java и выдает результат в таком виде, как будто для его получения был вызван метод. А класс Java затем обрабатывает результат.

Миф: XQuery трудно освоить

Разработчики программного обеспечения, пользующиеся языками Java, .NET и другими, не испытывают проблем с освоением XQuery. Напротив, в XML есть множество компонентов, которые никак нельзя назвать элегантными, в том числе те его части, которые сохранились от более раннего SGML-стандарта. XQuery использует краткий набор команд для облегчения работы с XML-данными. Хотя обычный разработчик и может испытывать определенные проблемы в освоении XQuery, это не потребует каких-то чрезвычайных усилий или затрат времени.

Заблуждение: XQuery - это не продукт, а слой в стеке

Во всех случаях, когда требуется осуществить управление данными в формате XML или какие-либо манипуляции с ними, XQuery является подходящей спецификацией для функций, которые могут обеспечить библиотека, прикладная программа или сервисный стек. Но механизм, лежащий в основе хранения, извлечения и индексирования XML-данных, вносит существенные отличия в функции, выполнение и масштабируемость XQuery-приложений. Например, первые попытки хранения XML-данных в полях varchar2 реляционной базы данных сопровождались низкой производительностью выполнения запросов в тех случаях, когда инструменты XQuery просто помещались сверху. Это привело к разработке специализированных решений XQuery для целого ряда разнообразных задач. Данные задачи включают управление контентом, обеспечение сохранности данных, работу Web-сервисов и сервис-ориентированной архитектуры, создание Хранилищ данных, оперативную аналитическую обработку (OLAP), процедуры извлечения, преобразования и загрузки (ETL), интеграцию корпоративных приложений (EAI), а также управление питанием.

Заблуждение: XQuery не имеет значения для увеличения производительности и снижения сложности сервис-ориентированной архитектуры

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

• первичный анализ показывает, что XQuery играет важную роль в тех случаях, когда резко возрастают полезная нагрузка и сложность XML-схемы в сервисах на основе ebXML и UBL;
• XQuery существенно улучшает решения UDDI, поскольку он лучше управляет ресурсами, перечисленными в UDDI-реестре;
• архитекторы программного обеспечения считают, что один из способов улучшения производительности СОА - это кэширование медленно передающихся данных. В аналогичной ситуации - при кэшировании границ Web-страницы сервисы, получающие много запросов на одну и ту же информацию, могут использовать средства XQuery для временного кэширования XML-данных. Приложения XQuery обычно предоставляют как возможности для написания XQuery-скриптов, так и средства для обеспечения сохранности или хранения данных. Сервис использует XQuery как сервис, а находящуюся в его основе базу данных XML - для временного кэширования XML-данных.

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

Заблуждение: XQuery не играет роли в преобразовании данных

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

XQuery позволяет преобразовать ("мэппировать") существующую схему в другой формат без необходимости создавать большую библиотеку нового кода. Вместо этого пишется XQuery-программа, позволяющая преобразовать ответные данные в новый формат.

Заблуждение: XQuery бесполезен для OLAP и приложений Хранилищ данных

На самом деле XQuery обеспечивает необходимые возможности для связи с OLAP и приложениями Хранилищ данных. Например, обычно корпорация имеет более одного Хранилища для отслеживания и анализа данных о своей деятельности. Эти Хранилища играют роль изолированных структур, и извлечение бизнес-информации из них требует определенных усилий, средств и опыта. Установление связи между ними обычно является трудоемкой и дорогой задачей. XQuery предлагает решение, облегчающее использование средств OLAP за счет установления связи между многочисленными Хранилищами данных на основе запросов. Например, в одном Хранилище содержатся данные о продукции, поставляемой в цепь розничных поставок внутри страны, а в другом - записи о запросах на продукцию, предлагаемую в розничных поставках. XQuery связывает эти Хранилища, показывая, запросы на какую продукцию удовлетворяются хуже всего. Этот пример иллюстрирует преимущества XQuery в логических операциях в Хранилищах данных, аналитике, ETL-операциях и интеграции корпоративных приложений.

Миф: XQuery не подходит для работы с большими объемами данных; XQuery никогда не будет работать так же быстро, как реляционная база данных

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

Масштабируемость и производительность решений XQuery зависят от цели внедрения этого языка. Например, в ряде случаев XQuery используется преимущественно для управления контентом и интеграционных сервисов. Такие решения лучше всего подходят для создания и поддержки Web-сайтов и порталов для ограниченной аудитории. Решения XQuery для функций баз данных на основе XML очень полезны для эффективной обработки больших массивов данных.

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

Заблуждение: не являются ли XPath и XQuery фактически одним и тем же языком?

На самом деле, XQuery создан на основе XPath и XSLT. Архитекторы и разработчики программного обеспечения используют XPath как язык запросов для нахождения элементов в XML-документе и преобразовании их в XHTML или другой XML-формат с помощью XSLT. Например, разработчик может использовать XPath для нахождения в XML-файле информации о посещении зубного врача пациентом и XSLT - для преобразования этой информации в HTML-формат, удобный для ее просмотра в браузере. Такая схема хорошо работает, если данные уже находятся в XML-формате, но надо иметь в виду, что XPath и XSLT работают только с XML-файлами.

Язык XPath ориентирован на операции выбора, а язык XSLT - на преобразование данных; при этом обе технологии все еще нуждаются в разработке эффективного способа выбора, объединения и преобразования данных в необходимую форму. XQuery способен удовлетворять потребности в данных того или иного приложения за счет того, что он обеспечивает доступ к многочисленным источникам, выбор информации из них и объединение данных. Это относится не только к данным в XML-формате: источники, с которыми способен работать XQuery, включают формы документов, Web-страницы и другие слабо структурированные данные.

Заблуждение: в XQuery нет механизма обновления

Это действительно правда: в спецификации XQuery нет механизма обновления. Но на момент написания этой статьи рабочая группа по XQuery готовилась к выпуску основной спецификации XQuery, и несколько ее членов собирались заняться спецификацией для обновлений. Автор статьи предсказывает, что в спецификации XQuery будет использован подход, характерный для SQL. Механизмы обновлений скорее всего будут реализованы в виде набора автономных операций, отражающих и поддерживающих уже существующие команды реляционных баз данных. Но некоторые специалисты по внедрению, а также существующие XQuery-решения предлагают более свободный способ осуществления обновлений с помощью XQuery.

Важно отметить, что большинство реализаций XQuery предоставляют собственный механизм осуществления обновлений. Например, одно из популярных решений XQuery включает расширение, в которое входят операции CRUD: Create (создать), Read (читать), Update (обновить), and Delete (уничтожить) - для работы как с данными в формате XML, так и с другими.

Миф: спецификация XQuery никогда не достигнет статуса RFC (Requests for Comments - Запросы на комментарии¹)

Казалось, что этому не будет конца, но на момент написания статьи рабочие группы по XML Query и XSL находятся на завершающей стадии работы над языками XQuery, XPath и XSLT. Помимо этого, уже существует целый набор готовых предложений XQuery.

Миф: XQuery поддерживает текстовый поиск по маркерам

Хотя спецификация полнотекстового поиска для XQuery и определяет текстовый поиск по маркерам, рабочая группа по XQuery умышленно оставила некоторые области не до конца разработанными. Например, в XQuery нет стандартного механизма загрузки документа или просмотра списка доступных документов. С точки зрения автора, отсутствие тотальной спецификации обеспечивает плавное развитие XQuery. Существующие реализации XQuery варьируют по своей направленности, а также по средствам управления данными, лежащими в их основе. Такая гибкость делает XQuery таким же удобным механизмом, как и система поиска в базе данных для организации фильтрации. А это усиливает его позиции.

Заключение

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

Ресурсы

1. Спецификации XQuery, XSLT, и XPath 2.0 на сайте W3C.
2. Ховард Кац (Howard Katz). Введение в XQuery (Introduction to XQuery).
3. JSR 225 - интерфейс прикладного программирования XQuery для Java.
4. Тестовый сайт XQuery.
5. Группы, работающие над расширением стандарта SQL для XML-операций:
   • The SQLX Group;
   • The INCITS H2 group;
   • ISO/IEC JTC1/SC32/WG2.
6. XQEngine - компонент Java с открытым исходным кодом для запросов к XML-документам.
7. XQuery Normalizer и Static Analyzer (XQNSTA) - интерфейс прикладного программирования и графический интерфейс пользователя на основе Java для нормализации и расчетов выражений XQuery статичного типа.
8. Сайт автора статьи PushToTest.com, где можно найти TestMaker - свободный тестовый инструмент с открытым исходным кодом, включающий средства XQuery для разбора ответов Web-сервиса.
9. Проект IBM Xperanto, который объединяет XML, XQuery, возможности текстового поиска и технологию Web-сервисов для того, чтобы предоставить пользователю инструменты поиска в XML-документах, плоских файлах, электронных таблицах и других источниках информации, содержащихся в отдельной базе данных.
10. Сайт developerWorks XML zone - дополнительные XML-ресурсы.
11. Литература по XML на сайте Developer Bookstore, в т.ч. книга автора статьи "Тестирование и проектирование на Java: от тестов элементов до автоматических Web-тестов" (Java Testing and Design: From Unit Tests to Automated Web Tests).
12. Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий (IBM Certified Developer in XML and related technologies).

Примечания:

¹Серия документов IETF (Internet Engineering Task Force - проблемная группа проектирования Internet), начатая в 1969 году и содержащая описания набора протоколов Internet и связанную с ними информацию (прим. переводчика).