ООП   XML   СУБД   ЯиМП   3GL   4GL   5GL   технологии прогр.

Язык XML. Объектно-ориентированное программирование

XML-технологии

Сегодня, кажется, уже всем объяснили: XML - вот волшебная палочка, с помощью которой будет наведен порядок в хаосе форматов данных. Язык разметки XML - одна из наиболее динамично завоевывающих внимание разработчиков и пользователей Интернет-технологий. Слово "завоевывающая" в предыдущем предложении появилось не случайно, так как реклама XML хотя и менее настойчива, чем реклама сотовых телефонов, но уже переплюнула клинское пиво. Однако до последнего времени реальная польза, как и смысл изучения и использования этой технологии, были сомнительны. Международная организация W3C утвердила спецификацию "Extensible Markup Language(XML) 1.0" еще в начале февраля 1998 года, но только теперь становится ясно, для чего этот самый XML употребить, и каким именно образом.

Дело в том, что сам по себе язык XML ничего особенного не представляет, и никаких задач решить не может. Посудите сами - вам предоставляется замечательная возможность самим определить теги и использовать их по собственному разумению, подчиняясь немногочисленным и несложным правилам. Да, таким образом можно создать структурированный документ или хранить небольшие количества информации, но, во-первых, ничего нового в этом нет, а, во-вторых, результат ваших трудов будет понятен только вам, никакой браузер этот документ понять не сможет. Мало того, поступающая извне информация может включать элементы с такими же названиями, что и использованные вами, но с совершенно другим смыслом и типом данных. Это может легко привести к ошибкам в интерпретации и отображении информации. Таким образом, сам по себе XML дает вам максимум свободы, и никакой возможности этой свободой разумно распорядиться. Еще в Windows 3.х существовал формат ini-файлов, который на порядок примитивнее XML, зато по количеству применений до сих пор его превосходит - потому, что изначально существовал простой и доступный в любой версии Windows API.

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

Области применения, или волшебная палочка о двух концах

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

  1. XML позволяет разработчику создать собственную разметку структуры хранимой информации.
  2. Разбор XML хорошо стандартизирован и реализован большим количеством производителей ПО, что позволяет извлечь информацию из XML-документов практически повсеместно.
  3. В стандарт XML включена поддержка кодовых страниц Unicode, что упрощает создание многоязычных документов.
  4. Приложения могут использовать XML-парсеры для проверки структуры документов, а при использовании схем - и типов данных. Это может значительно упростить разбор строго структурированных документов, снимая с программиста задачу проверки правильности документа.
  5. XML - это текстовый формат, то есть читаемый, легко документируемый и, иногда, более простой в отладке. Хотя на сегодня отладочные средства для ряда XML-технологий пребывают в зачаточном состоянии.
  6. Для работы с XML создано множество средств на самых разных платформах, что делает использование XML более простым по сравнению с бинарными форматами при обмене сложными информационными потоками.
  7. XML-документы могут использовать значительную часть инфраструктуры, созданной для HTML, включая протокол HTTP и браузеры.

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

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

Преимущества перед БД

В качестве средства хранения данных XML действительно располагает некоторыми преимуществами перед традиционными РСУБД (впрочем, и множеством недостатков тоже). Скорее всего, отказываясь в свое время от иерархического представления данных, отцы-основатели реляционной модели БД не подозревали, что наступит время, когда такое представление окажется необходимым. Как известно, иерархическая модель была одной из первых моделей БД. Единственной альтернативой ей была сетевая модель. Сетевая модель - это модель графов, как известно, не имеющая высокопроизводительных алгоритмов. Иерархическая же позволяла достаточно легко реализовать производительные СУБД. Когда была предложена реляционная модель, многие поддались на достаточно абстрактные рассуждения о её неоспоримых преимуществах. В качестве главных рекламных лозунгов звучало следующее - полностью систематизированная модель, имеющая хорошее математическое основание и четкие алгоритмы. В отличие от иерархической модели, она гипотетически позволяла стоить модели данных любой сложности, а язык SQL, придуманный специально для этой модели, окончательно определил её победу. Однако ни программист, ни, тем более, нормальный человек не думают понятиями реляционной алгебры. Да и конкретные реализации серверов столкнулись с тем, что красивые и эффективные математические методы не так просто превратить в эффективные и быстрые алгоритмы. Даже сегодня, через несколько десятков лет после появления концепции реляционной модели БД, серверы, обладающие эффективным и быстрым оптимизатором запросов, можно пересчитать по пальцам одной руки. Теперь, с покупкой IBM фирмы Informix, их станет еще меньше. В программировании же незаметно появилась объектно-ориентированная парадигма. Она оказалось удобна в практическом применении, и не требовала сложных алгоритмов обработки. Что перечислять достоинства этого подхода - сейчас почти все средства разработки стали объектно-ориентированными.

Если вдуматься, объектно-ориентированное представление данных является ничем иным, как деревом, но со ссылками на другие объекты. Получается дурацкая ситуация - программист, работая с объектами, данные вынужден по-прежнему хранить в реляционной модели. Несоответствие налицо. Поэтому XML со своим представлением данных, похожим на ООП, подвернулся как нельзя кстати. Усилия, затраченные на проработку концепции данных в XML, привели к тому, что сейчас XML-представление данных превосходит то, что сейчас называют "объектно-ориентированными" и "объектно-реляционными" СУБД. По логике вещей, в ближайшие несколько лет должны появиться СУБД, в качестве представления (но не хранения!) данных использующие парадигму XML.

В качестве преимущества XML можно рассматривать и текстовое представление информации. XML-файл можно редактировать с помощью любого текстового редактора - от Notepad до Emacs. Данные, хранящиеся в виде XML, как правило, доступны для человеческого понимания без преобразования. Это положение в корне отличается от бинарного представления данных, требующего программной трансформации в пригодный для использования человеком вид. Разумеется, хранение информации в текстовом виде более расточительно (как с точки зрения объема, так и по требуемым для обработки ресурсам), чем бинарное. Но зачастую удобство использования стоит затрачиваемых ресурсов. Следует заметить, что XML хранит только данные и элементы, определяющие их структуру. Представление этих данных может быть любым, оно полностью отдается на откуп разработчику (подробнее об этом будет рассказано ниже).

Если же вспомнить эталонный пример внесения мусора в документ - я имею в виду HTML-документы, создаваемые MS Office - то станет ясно, что HTML-документ с помощью несложных ухищрений можно раздуть до размеров двух исходных документов Word. Из-за наличия большого количества форматирования реальное содержание HTML-документа может составлять всего несколько процентов от общего объема документа. В таких условиях сокращение размера документа (особенно с учетом пораженных сложным букетом хворей отечественных линий связи) действительно имеет значение. Кстати, о документах. Структура документов, как правило, достаточно сложна, и их хранение в РСУБД - непростая задача. Многие системы документооборота хранят документы, не разбирая их - в том виде, как они поступили в систему. В то же время практически все документы имеют некоторую объектную структуру, что позволяет хранить их в XML-формате. Причем к таким документам можно применять программные алгоритмы, из них можно выбирать нужную информацию, основываясь на жестких критериях, задаваемых тегами, программно изменять их или конвертировать. У документа появляется функциональность, ранее присущая только программным объектам и СУБД.

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

XML же довольно критичен к синтаксису (по сравнению с HTML), но безразличен, когда речь заходит об определении значений элементов в XML-документах. Если HTML - это один словарь, в смысле - набор заранее определенных значений (тег <b> значит одно и то же для любого браузера), то в XML можно либо выбрать готовый словарь из уже существующих, либо создать собственный, наиболее точно соответствующий потребностям вашего предприятия или проекта. Создать и описать такой словарь, или пространство имен XML, позволяют схемы и определения типов документов (DTD - Document Type Definition).

Такой подход требует совершенно другой архитектуры браузеров, чем HTML-браузеры. Разработчик не может полагаться на способность браузера разобраться в смысле разметки и способе ее интерпретации. Современные браузеры могут выводить XML-документы, но как это убого выглядит! Без использования соответствующих шаблонов XSL Transformations (XSLT) такой вариант просмотра годится исключительно для служебных (диагностических или отладочных) целей. Пользователю (тем паче заказчику) этого показывать нельзя.

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

К сожалению, продвижение XML и связанных с ним технологий не избежало обычных в таком случае перегибов. Практически любую вновь появляющуюся технологию продвигающие ее фирмы и организации стремятся объявить (см. начало статьи) всемогущей панацеей, лечащей всё, включая проблему последней мили и головную боль. Этим грешит практически любая крупная софтверная фирма. Так было с Java, так сейчас обстоят дела с Linux. Но действительность, к сожалению, часто вносит свои коррективы. Все изложенные выше достоинства XML несомненны, но и недостатков хватает.

Сама концепция хранения данных в текстовом виде далеко не универсальна. Прежде всего, далеко не все типы данных можно (и имеет смысл) хранить в текстовом виде. Кроме всего прочего, текстовое представление (мягко говоря) не повышает производительности. При заверениях некоторых вполне уважаемых средств массовой информации в том, что работа через XML, например, с SQL Server, быстрее, чем традиционный обмен бинарными данными, так и хочется спросить - "Как вы измеряли?". Если и впрямь спросить, выясняется, что никак. Переписали пресс-релиз, и успокоились.

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

Рассмотрим некоторые из них.

Способы обработки XML

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

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

Проверка корректности структуры документа

Спецификации XML 1.0 оговаривает, что XML-парсеры могут проверять синтаксис, а могут и не проверять корректность структуры документа. Не следует путать проверку корректности документа с точки зрения XML как такового и проверку корректности документа с точки зрения соответствия DTD или XML-схеме.

Непроверяющие парсеры

Проверяют синтаксис документа и сообщают обо всех нарушениях ограничений формы документа. Непроверяющие парсеры могут добавлять информацию к документу, основанному на декларациях DTD. MSXML читает DTD, включая внешние источники, и действует на основе этой информации.

Проверяющие парсеры

Делают то же, что и непроверяющие, но, кроме этого, сравнивают структуру документов с правилами DTD или XML-схемы.

Использование того или иного вида парсера определяется потребностями приложения. Если строится общее XML-приложение, не рассчитывающее встретить конкретную структуру документа, непроверяющий парсер позволит использовать документы, не отвечающие какой-то конкретной структуре. По умолчанию Microsoft Internet Explorer использует именно непроверяющий режим работы для отображения наибольшего числа документов.

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

Рисунок 1. Отображение XML в Internet Explorer 5.5.

Проверка соответствия структуры документа с помощью IE5

В Internet Explorer можно открыть любой документ, помеченный как XML. Если в документе не указано иного, Internet Explorer выведет документ, используя встроенный алгоритм преобразования (рис. 1). Если документ неверно сформирован, Internet Explorer сообщит об ошибке. Если документ содержит несколько ошибок, вам придется устранить ошибку, открыть документ заново и устранить следующую ошибку.

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

Это можно сделать с помощью несложного VBScript-кода:

Set xmldoc = CreateObject("msxml2.DOMDocument")
xmldoc.ValidateOnParse = true
xmldoc.Load(url)
ООП   XML   СУБД   ЯиМП   3GL   4GL   5GL   технологии прогр.

Знаете ли Вы, как разрешается парадокс Ольберса?
(Фотометрический парадокс, парадокс Ольберса - это один из парадоксов космологии, заключающийся в том, что во Вселенной, равномерно заполненной звёздами, яркость неба (в том числе ночного) должна быть примерно равна яркости солнечного диска. Это должно иметь место потому, что по любому направлению неба луч зрения рано или поздно упрется в поверхность звезды.
Иными словами парадос Ольберса заключается в том, что если Вселенная бесконечна, то черного неба мы не увидим, так как излучение дальних звезд будет суммироваться с излучением ближних, и небо должно иметь среднюю температуру фотосфер звезд. При поглощении света межзвездным веществом, оно будет разогреваться до температуры звездных фотосфер и излучать также ярко, как звезды. Однако в дело вступает явление "усталости света", открытое Эдвином Хабблом, который показал, что чем дальше от нас расположена галактика, тем больше становится красным свет ее излучения, то есть фотоны как бы "устают", отдают свою энергию межзвездной среде. На очень больших расстояниях галактики видны только в радиодиапазоне, так как их свет вовсе потерял энергию идя через бескрайние просторы Вселенной. Подробнее читайте в FAQ по эфирной физике.

Bourabai Research Institution home page

Боровское исследовательское учреждение - Bourabai Research Bourabai Research Institution