Введение в XML

Нужен ли мне этот учебник?

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

В этом учебнике вы изучите:

• Почему XML был создан
• Правила для XML-документов
• Как определить, что XML-документ может и не может содержать
• Программные интерфейсы, которые работают с XML-документами
• Каковы главные стандарты XML и как они работают вместе
• Как компании в реальном мире используют XML

Раздел 2. Что такое XML?

Введение

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

<p><b>Mrs. Mary McGoon</b>
<br>
1401 Main Street
<br>
Anytown, NC 34829</p>

Беда HTML состоит в том, что он был разработан с прицелом на человека. Даже не просматривая приведенный выше HTML-документ в браузере, вы и я можем понять, что это чей-то почтовый адрес. (В частности, это почтовый адрес в Соединенных Штатах; даже если вы незнакомы с компонентами почтового адреса в США, вы, возможно, догадаетесь, что здесь представлено.)

Чтобы отобразить HTML, браузер просто следует инструкциям в HTML-документе. Тег параграфа (<p>) сообщает браузеру, что нужно отобразить новую строку, обычно, с пропуском строки перед ней, а два тега разрыва (<br>) сообщают браузеру, что нужно перейти на новую строку без пропусков между строками. Браузер прекрасно форматирует документ, но машина все же не знает, что это адрес.

Чтобы завершить обсуждение примера HTML-документа, рассмотрим задачу выделения из адреса почтового кода. Вот алгоритм (приблизительный) нахождения почтового кода в разметке HTML:

Если вы нашли параграф с двумя тегами <br>, почтовый код является вторым словом после первой запятой после второго тега разрыва.

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

<address>
 <name>
  <title>Mrs.</title>
  <first-name>
   Mary
  </first-name>
  <last-name>
   McGoon
  </last-name>
 </name>
 <street>
  1401 Main Street
 </street>
 <city>Anytown</city>
 <state>NC</state>
 <postal-code>
  34829
  </postal-code>
</address>

Теги, элементы и атрибуты

Есть три общих термина, используемых для описания частей XML-документа: теги, элементы и атрибуты. Вот пример документа, иллюстрирующего эти термины:

<address>
 <name>
  <title>Mrs.</title>
  <first-name>
   Mary
  </first-name>
  <last-name>
   McGoon
  </last-name>
 </name>
 <street>
  1401 Main Street
 </street>
 <city state="NC">Anytown</city>
 <postal-code>
  34829
 </postal-code>
</address>

• Тег - это текст между левой угловой скобкой (<) и правой угловой скобкой (>). Есть начальные теги (такие, как <name>) и конечные теги (такие, как </name>)
• Элементом является начальный тег, конечный тег и все, что есть между ними. В примере выше элемент <name> содержит два дочерних элемента: <title>, <first-name> и <last-name>.
• Атрибут - это пара имя-значение внутри начального тега элемента. В данном примере state является атрибутом элемента <city>; в предыдущем примере <state> был элементом. (См. Пример документа XML).

Как XML изменяет Web

Теперь, когда вы увидели, как разработчики могут использовать XML, чтобы создавать документы с данными, описывающими сами себя, давайте посмотрим, как люди, используют эти документы, чтобы усовершенствовать Web. Вот несколько ключевых направлений:

• XML упрощает обмен данными. Поскольку разные организации (или даже разные части одной организации) редко используют единый стандартизированный набор инструментов, для приложений соединение может требовать некоторого объема работы. При использовании XML каждая группа создает свою утилиту, которая преобразует ее внутренние форматы данных в XML и наоборот. Лучше всего, если производители программного обеспечения уже обеспечили инструменты для преобразования из записей базы данных (или каталогов LDAP, или заказов на покупки и т.д.) в и из XML.
• XML создает возможность изящного кода. Поскольку XML-документы могут быть структурированы для идентификации каждой важной части информации (а также и отношений между частями), возможно написать код, который может обрабатывать эти XML-документы без участия человека. То, что производители программного обеспечения вкладывают большие объемы времени и денег в построение средств разработки XML, означает, что написание такого кода - относительно простой процесс.
• XML создает возможность "умного" поиска. Хотя поисковые машины с годами неуклонно совершенствуются, все еще трудно получить результаты поиска без ошибок. Если вы ищете страницы HTML для чего-то, под названием "Chip", вы можете найти страницы про шоколадные плитки (chocolate chips), компьютерные чипы (computer chips), древесно-стружечные плиты (wood chips) и много других бесполезных образцов. Поиск XML-документов по элементам <first-name>, которые содержат текст Chip, даст вам значительно лучший набор результатов.

Раздел 3. Правила XML-документа

Обзор: правила XML-документа

Если вы рассматривали HTML-документы, вы знакомы с базовыми концепциями использования тегов для разметки текста документа. Этот раздел обсуждает различия между HTML-документами и XML-документами. В нем мы проходим по основным правилам XML-документов и обсуждаем терминологию, используемую для их описания.

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

Есть три вида XML-документов:

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

Корневой элемент

Документ XML должен содержаться в единственном элементе. Этот единственный элемент называется корневым элементом и содержит весь текст и любые другие элементы документа. В следующем примере XML-документ содержит единственный элемент, элемент <greeting>. Заметьте, что документ содержит комментарий вне корневого элемента, который является вполне допустимым.

<?xml version="1.0"?>
<!-- Правильно-форматированный документ -->
<greeting>
 Hello, World!
</greeting>

А вот документ, который не содержит единственного корневого элемента:

<?xml version="1.0"?>
<!-- Неправильный документ -->
<greeting>
 Hello, World!
</greeting>
<greeting>
 Hola, el Mundo!
</greeting>

Элементы XML не могут перекрывать друг друга. Вот некоторая разметка, которая не является правильной:

<!-- Неправильная разметка XML -->
<p>
<b>I <i>really
love</b> XML.
</i>
</p>

Если вы начинаете элемент <i> внутри элемента <b>, вы должны его там же и закончить. Если вы хотите, чтобы текст XML появлялся в наклонном шрифте, вам нужно добавить в разметку второй элемент <i>:

<!-- Правильная разметка XML -->
<p>
<b>I <i>really
love</i></b>
<i>XML.</i>
</p>

Конечные теги являются обязательными

Вы не можете опускать какие-либо закрывающие теги. В первом примере, приведенном выше, разметка неправильна потому, что нет закрывающего тега параграфа (</p>). Хотя это приемлемо для HTML (и, в некоторых случаях, для SGML), XML-парсер это забракует.

<!-- Неправильная разметка XML -->
<p>Yada yada yada...
<p>Yada yada yada...
<p>...

Если элемент вообще не содержит разметки, он называется пустым элементом; HTML-элементы разрыва (<br>) и изображения (<img>) являются примерами этого. В пустом элементе XML-документа вы можете поместить закрывающую косую черту в начальный тег. Следующие два элемента разрыва и два элемента изображения являются для XML-парсера одним и тем же:

<!-- Два эквивалентных элемента разрыва -->
<br></br>
<br />
<!-- Два эквивалентных элемента изображения -->
<!-- Two equivalent image elements -->
<img src="../img/c.gif"></img>
<img src="../img/c.gif" />

Элементы чувствительны к регистру

Элементы XML чувствительны к регистру. В HTML <h1> и <H1> - одно и то же; в XML - нет. Если вы попытаетесь закончить элемент <h1> тегом </H1>, вы получите ошибку. В примере ниже заголовок вверху неправильный, а внизу - правильный.

<!-- Неправильная разметка XML -->
<h1>Elements are
case sensitive</H1>
<!-- Правильная разметка XML -->
<h1>Elements are
case sensitive</h1>

Атрибуты должны иметь значения в кавычках

Есть два правила для атрибутов в XML-документах:

• Атрибуты должны иметь значения
• Эти значения должны быть заключены в кавычки

Сравните два примера ниже. Разметка вверху правильна в HTML, но не в XML. Чтобы сделать ее эквивалент в XML, вы должны дать атрибуту значение и взять его в кавычки.

<!-- Неправильная разметка XML -->
<ol compact>
<!-- legal XML markup -->
<ol compact="yes">

Вы можете использовать одинарные или двойные кавычки, но только согласованно.

Есть несколько других вещей, которые вы можете найти в XML-документе:

• Комментарии: Комментарии могут появляться где угодно в документе; они могут даже появляться перед корневым элементом. Комментарий начинается с <!-- и заканчивается -->. Комментарий не может содержать двойного дефиса (--) нигде, кроме как в конце; за этим исключением, комментарий может содержать что угодно. Самое важное, что любая разметка внутри комментария игнорируется; если вы хотите удалить большой раздел из XML-документа, просто заключите этот раздел в комментарий. (Чтобы восстановить закомментированный раздел, просто удалите теги комментария.) Вот некоторая разметка, содержащая комментарий:

  <!-- Это PI для Cocoon: -->
  <?cocoon-process type="sql"?>
  

• Инструкции обработки: Инструкция обработки является разметкой предназначенной для определенного кода. В примере выше это инструкция обработки (иногда называемая PI) для Cocoon, библиотеки обработки XML от Apache Software Foundation. Когда Cocoon обрабатывает XML-документ, он ищет инструкции обработки которые начинаются с cocoon-process, а затем обрабатывает XML-документ в соответствии с ними. В данном примере атрибут type="sql" сообщает Cocoon, что the XML-документ содержит оператор SQL.

  <!-- Это сущность: -->
  <!ENTITY dw "developerWorks">
  

• Сущности: Приведенный выше пример определяет сущность для документа. Везде, где XML-процессор находит строку &dw;, он заменяет сущность на строку developerWorks. Спецификация XML также определяет пять сущностей, которые вы можете использовать вместо различных специальных символов. Эти сущности такие:
  • < для символа меньше
  • > для символа больше
  • " для двойной кавычки
  • ' для одинарной кавычки (апострофа)
  • & для амперсанда.

Пространства имен

Мощность XML происходит от его гибкости, из того факта, что вы и я, и миллионы других людей можем определять наши собственные теги, чтобы описывать наши данные. Помните пример XML-документа для имени и адреса человека? Этот документ включает в себя элемент <title> для вежливого именования человека, вполне подходящий выбор для элемента имени. Если же вы работаете с онлайновым книгохранилищем, вы можете создать элемент <title> для названия книги. Если же вы работаете с онлайновой закладной компанией, вы можете создать элемент <title> для части закладного документа. Все это разумные варианты, но все они создают элементы с одним и тем же именем. Как вы сообщите, что данный элемент <title> относится к человеку, книге или части закладной? При помощи пространств имен.

Чтобы использовать пространство имен, вы определяете префикс пространства имен и отображаете его на определенную строку. Вот так вы можете различить префиксы пространства имен для наших трех элементов <title>:

<?xml version="1.0"?>
<customer_summary
    xmlns:addr="http://www.xyz.com/addresses/"
    xmlns:books="http://www.zyx.com/books/"
    xmlns:mortgage="http://www.yyz.com/title/"
    >
... <addr:name><title>Mrs.</title> ... </addr:name> ...
... <books:title>Lord of the Rings</books:title> ...
... <mortgage:title>NC2948-388-1983</mortgage:title> ...

В этом примере три префикса пространства имен: addr, books, и mortgage. Заметьте, что определение пространства имен для определенного элемента означает, что все его дочерние элементы принадлежат к тому же пространству имен. Первый элемент <title> принадлежит к пространству имен, поскольку к нему принадлежит его родительский элемент, <addr:Name> .

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

Обзор: Определение содержимого документа

Недавно в этом учебнике вы узнали о базовых правилах XML-документов; это все хорошо, но вам нужно определить элементы, которые вы собираетесь использовать для представления данных. Вы узнаете о двух способах сделать это в данном разделе.

• Одним методом является использование Document Type Definition или DTD (Определение Типа Документа). DTD определяет элементы, которые могут появляться в XML-документе, порядок, в котором они могут появляться, как они могут быть вложены друг в друга и другие основные детали структуры XML-документа. DTD являются частью исходной спецификации XML и они очень похожи на DTD в SGML.
• Другим методом является использование XML Schema (схема XML). Схема может определить все то в структуре документа, что вы можете поместить в DTD, и может также определить типы данных и более сложные правила, чем DTD. W3C разработала спецификацию XML Schema через пару лет после исходной спецификации XML.

DTD - Определение Типа Документа

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

• <!ELEMENT address (name, city, state)>
  Элемент <address> должен содержать элементы <name>, <city> и <state> в таком порядке. Все элементы являются обязательными. Запятая показывает список элементов.
• <!ELEMENT name (title?, first-name, last-name)>
  Это означает, что элемент <name> содержит необязательный элемент <title>, за которым следуют обязательные элементы <first-name> и <last-name>. Знак вопроса показывает, что элемент является необязательным; он может появляться один раз или не появляться вообще.
• <!ELEMENT addressbook (address+)> Элемент <addressbook> содержит один или более элементов <address>. Вы можете иметь столько элементов <address>, сколько вам нужно, но должен присутствовать хотя бы один. Знак плюс показывает, что элемент появляется хотя бы один раз, но может появляться и сколько угодно раз.
• <!ELEMENT private-addresses (address*)>
  Элемент <private-addresses> содержит ноль или более элементов <address>. Звездочка показывает, что элемент может появляться сколько угодно раз, включая ноль.
• <!ELEMENT name (title?, first-name, (middle-initial | middle-name)?, last-name)> Элемент <name> содержит необязательный элемент <title>, за которым следует элемент <first-name>, за которым, возможно следует элемент <middle-initial> или элемент <middle-name> , за которым следует элемент <last-name>. Другими словами, оба элемента <middle-initial> и <middle-name> являются необязательными, и вы можете иметь только один из этих двух. Вертикальная черта показывает список вариантов; вы можете выбрать только один элемент из списка. Также заметьте, что этот пример использует скобки для группирования определенных элементов и он использует знак вопроса применительно к группе.
• <!ELEMENT name ((title?, first-name, last-name) | (surname, mothers-name, given-name))> Элемент <name> может содержать одну из двух последовательностей. Необязательный <title>, за которым следуют <first-name> и <last-name>; или <surname>, <mothers-name> и <given-name>.

Замечание по поводу гибкости

Этот вводный учебник не слишком вдается в подробности о том, как работают DTD, но есть еще одна основная тема, которую мы рассматриваем здесь: определение атрибутов. Вы можете определить атрибуты для элементов, появляющихся в вашем XML-документе. При помощи DTD вы можете также:

• Определить, какие атрибуты являются обязательными
• Определить значение по умолчанию для данного атрибута
• Перечислить допустимые значения для данного атрибута

Предположим, вы хотите изменить DTD, чтобы сделать state атрибутом элемента <city>. Вот как это сделать:

<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA #REQUIRED>

Здесь элемент <city> определяется, как и прежде, но пересмотренный пример также использует объявление ATTLIST для перечисления атрибутов элемента. Имя city в списке атрибутов сообщает парсеру, что эти атрибуты определяются для элемента <city>. Имя state является именем атрибута, а ключевые слова CDATA и #REQUIRED сообщают парсеру, что атрибут state содержит текст и является обязательным (если он не обязательный, это обеспечится при помощи CDATA #IMPLIED).

Чтобы определить много атрибутов для элемента, запишите ATTLIST, подобный такому:

<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA #REQUIRED
postal-code CDATA #REQUIRED>

Этот пример определяет и state, и postal-code как атрибуты элемента <city>.

Наконец, DTD позволяют вам определять значения по умолчанию для атрибутов и перечислять все допустимые значения для атрибута:

<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA (AZ|CA|NV|OR|UT|WA) "CA">

Со схемами XML вы имеете больше возможностей для определения того, как выглядят правильные XML-документы. Они имеют несколько преимуществ по сравнению с DTD:

• Схемы XML используют синтаксис XML. Другими словами, схема XML является XML-документом. Это означает, что вы можете обрабатывать схему так же, как и любой другой документ. Например, вы можете написать таблицу стилей XSLT, которая преобразует схему XML Web-форму вместе с автоматической генерацией кода JavaScript, который будет проверять данные по мере их ввода.
• Схемы XML поддерживают типы данных. Хотя DTD выполняет поддержку типов данных, оно рассматривает эти типы данных только с точки зрения публикации. Схемы XML поддерживают все исходные типы данных DTD (такие, как ID и ссылки ID). Они также поддерживают целые и вещественные числа, даты и времена, строки, URL и другие типы данных, полезные для обработки и проверки данных.
• Схемы XML являются расширяемыми. Кроме типов данных, определенных в спецификации XML schema, вы можете также создавать собственные типы и можете создавать типы-наследники на базе других типов данных.
• Схемы XML имеют более мощные выражения. Например, при помощи схем XML вы можете определить, что любое значение атрибута <state> не может быть длиннее двух символов или что любое значение элемента <postal-code> должно соответствовать регулярному выражению [0-9]{5}(-[0-9]{4})?.

Вот схема XML, которая соответствует исходному DTD имени и адреса. В ней добавлено два ограничения. Значение элемента <state> должно состоять точно из двух символов, а значение элемента <postal-code> должно соответствовать регулярному выражению [0-9]{5}(-[0-9]{4})?. Хотя схема значительно длиннее, чем DTD, она выражает больше ясности в том, на что похож правильный документ. Вот эта схема:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="address">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="name"/>
    <xsd:element ref="street"/>
    <xsd:element ref="city"/>
    <xsd:element ref="state"/>
    <xsd:element ref="postal-code"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="name">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="title" minOccurs="0"/>
    <xsd:element ref="first-Name"/>
    <xsd:element ref="last-Name"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="title" type="xsd:string"/>
 <xsd:element name="first-Name" type="xsd:string"/>
 <xsd:element name="last-Name" type="xsd:string"/>
 <xsd:element name="street" type="xsd:string"/>
 <xsd:element name="city" type="xsd:string"/>
 <xsd:element name="state">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:length value="2"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>
 <xsd:element name="postal-code">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>
</xsd:schema>

Определение элементов в схемах

Определение содержимого элемента в схемах

Пример схемы определяет ограничения для содержимого двух элементов: Содержимое элемента <state> должно иметь длину в два символа, а содержимое элемента <postal-code> должно соответствовать регулярному выражению [0-9]{5}(-[0-9]{4})?. Вот как это сделано:

 <xsd:element name="state">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:length value="2"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>
 <xsd:element name="postal-code">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>

Для элементов <state> и <postal-code> схема определяет новые типы данных с ограничениями. В первом случае используется элемент <xsd:length>, а во втором - элемент <xsd:pattern> для определения регулярного выражения, которому этот элемент должен соответствовать.

Раздел 5. Программные интерфейсы XML

Обзор: Программные интерфейсы XML

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

Когда была разработана исходная DOM для XML-документов, многие люди в списке рассылки XML-DEV выразили беспокойство по поводу ее:

• DOM строит в памяти дерево всего документа. Если документ очень большой, это требует значительного объема памяти.
• DOM создает объекты, которые представляют все, что есть в исходном документе, включая элементы, текст, атрибуты и пропуски. Если вам нужно иметь дело только с небольшой порцией исходного документа, то крайне расточительно создавать все эти объекты, которые никогда не будут использованы.
• Парсер DOM должен прочитать весь документ прежде, чем ваш код получит управление. Для очень больших документов это может привести к значительной задержке.

Чтобы обойти проблемы DOM, участники XML-DEV (возглавляемой David Megginson) создали интерфейс SAX. SAX имеет несколько характеристик, направленных на преодоление недостатков DOM:

• Парсер SAX посылает в ваш код события. Парсер сообщает вам, когда он находит начало элемента, конец элемента, текст, начало и конец документа и т.д. Вы решаете, какие события важны для вас, вы решаете, какой вид структуры данных вы хотите создать для хранения данных из этих событий. Если вы явным образом не сохраняете данные из этих событий, они теряются.
• Парсер SAX не создает никаких объектов вообще, он просто доставляет события в ваше приложение. Если вы хотите создавать объекты на основе этих событий - это ваше дело.
• Парсер SAX начинает доставляет вам события сразу же после начала своей работы. Ваш код получить событие, когда парсер найдет начало документа, когда он найдет начало элемента, когда он найдет текст и т.д. Ваше приложение сразу же начнет генерировать результаты и не будет должно ожидать, пока будет разобран весь документ. Даже лучше, если вы ищете только определенные вещи в документе, ваш код может сгенерировать исключение, если он нашел то, что искал. Исключение останавливает парсер SAX, и ваш код может делать то, что ему нужно сделать с найденными данными

Чтобы быть честными, парсеры SAX также имеют проблемы, которые могут вызывать опасения:

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

JDOM

Разочарованные трудностями в выполнении определенных задач при помощи моделей DOM и SAX, Jason Hunter и Brett McLaughlin создали пакет JDOM. JDOM - проект с открытым кодом на основе технологии Java, в который старается следовать правилу 80/20: распределитель, который нужен 80% пользователей, и 20% функций DOM и SAX. JDOM работает с парсерами SAX и DOM, так что он реализован, как относительно небольшой набор Java-классов.

Хотя DOM, SAX и JDOM обеспечивают стандартные интерфейсы для наиболее общих задач, есть все же несколько вещей, на которые они не рассчитаны. Например, процесс создания объекта DOMParser в программе Java отличается от парсера DOM в другой. Для решения этой проблемы фирма Sun реализовала JAXP, Java API for XML Parsing. Этот API обеспечивает общие интерфейсы для обработки XML-документов с использованием DOM, SAX и XSLT.

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

• Будет ли ваше приложение написано на Java? JAXP работает с DOM, SAX и JDOM; если вы будете писать код на Java, вы должны использовать JAXP, чтобы изолировать ваш код от подробностей реализации различных парсеров.
• Как ваше приложение будет разворачиваться? Если вы собираетесь разворачивать ваше приложение как аплет Java и хотите минимизировать объем выгружаемого кода, имейте в виду, что парсеры SAX меньше, чем парсеры DOM. Также помните, что использование JDOM требует очень маленького объема кода в дополнение к парсеру SAX или DOM.
• После того, как вы разобрали XML-документ, нужно ли вам будет обращаться к данным много раз? Если вам нужно возвращаться к разобранной версии XML-файла, возможно, DOM является правильным вариантом. Когда генерируется событие SAX, то от вас (разработчика) зависит сохранение чего-либо, что может понадобиться позже. Если вам нужно обратиться к событию, которое вы не сохранили, вам придется разобрать файл заново. DOM сохраняет все данные автоматически.
• Не нужно ли вам всего несколько вещей из источника XML? Если вам нужно всего несколько вещей из источника XML, возможно, SAX является правильным вариантом. SAX не создает объектов для всего в исходном документе, вы можете сами решить, что является важным. При помощи SAX, вы можете просматривать каждое событие и определять, относится ли оно к тому, что вам нужно, и соответствующим образом его обрабатывать. Даже лучше, если вы нашли то, что искали, ваш код может сгенерировать исключение, чтобы остановить и парсер SAX.
• Работаете ли вы на машине с очень маленькой памятью? Если так, SAX является наилучшим для вас вариантом, хотя вы можете рассмотреть и все другие факторы.

Раздел 6. Стандарты XML

Обзор: Стандарты XML

Язык XML Schema определен в трех частях:

Document Object Model определяет, как XML-документ преобразуется в структуру дерева в памяти. DOM определена в нескольких спецификациях в W3C:

SAX, JDOM и JAXP

В мире XML есть два стандарта для связывания и ссылок: XLink и XPointer:

Безопасность

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

Другие стандарты

Раздел 7. Практические примеры

Примеры из реальной жизни

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

Рисунок 2. Провинция Манитоба

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

Разработка приложения

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

Как и в любом приложении, пользовательский интерфейс приложения был чрезвычайно важен. Чтобы упростить первую реализацию, необходимые XML-данные преобразовывались в HTML. Это давало пользователь возможность использовать браузер для интерфейса приложения. Реестр был построен с помощью VisualAge for Java, в частности, компонента Visual Servlet Builder. Он также использовал Enterprise Java Beans (EJB), включая бины сеанса и бины сущности.

Генерация различных пользовательских интерфейсов при помощи XML

Кроме интерфейса HTML, планируется также интерфейс Java-клиента и электронный интерфейс B2B. Для всех этих интерфейсов структурированные данные XML преобразуются в соответствующие структуры и документы. Начальная выгрузка сервиса позволяет одному бизнес-партнеру, Canadian Securities Registration Systems, посылать данные транзакции XML, используя Secure Sockets Layer. Данные транзакции XML преобразуются в соответствующий формат для транзакций на стороне сервера.

Рисунок 3. Банк First Union на XML

First Union National Bank, один из самых больших банков в США, находится в процессе реинжениринга многих своих приложений при помощи Java и XML. Как и у большинства больших компаний, его среда гетерогенна с серверами OS/390, AIX, Solaris, HP/9000 и Windows NT и клиентами Windows NT, Windows 98, Solaris и AIX. Имея такую среду, First Union выбрал Java для платформенно-независимых кодов и XML для платформенно-независимых данных.

Система на базе сообщений

Распределенное приложение банка построено на инфраструктуре обмена сообщениями с использование для доставки сообщений IBM's MQSeries для системы OS/390. Содержание сообщение базируется на спецификации, называемой Common Interface Message (CIM), собственном стандарте First Union. И клиентские, и серверные компоненты приложения зависят от формата сообщения. К протоколу обмена сообщениями добавлено использование XML, как формата данных, изолирующего обе стороны приложения от будущих изменений.

Использование инструментов XML для автоматизации потоков данных

Рисунок 4. Hewitt Associates LLC

Hewitt Associates LLC - глобальная консультативная фирма по менеджменту, которая специализируется на решениях по трудовым ресурсам. Компания имеет более 200 корпоративных клиентов во всем мире; эти компании реально имеют более 10 млн. сотрудников.

До заключения соглашения с jStart Hewitt строила собственные заказные решения, когда ее клиенты запрашивали данные о трудовых ресурсах. Эти заказные решения обычно были переходниками к существующим унаследованным приложениям Hewitt, в некоторых случаях решения работали с реальными потоками байтов. Эти заказные решения очень дорого обходились в разработке, тестировании и внедрении, что привело к тому, что Hewitt стала рассматривать возможность применения Web-сервисов.

Спасение в Web-сервисах!

Чтобы решить эти проблемы, Hewitt и команда jStart работали вместе для создания Web-сервисов для нужд потребителей Hewitt. Web-сервисы являются новым видом приложений, которые используют XML несколькими интересными способами:

• Прежде всего, Web-сервисы обычно используют SOAP, стандарт XML для перемещения XML-данных из одного места в другое.
• Во-вторых, интерфейсы, обеспечиваемые Web-сервисами (имена методов, переметры, типы данных и т.д.) описываются при помощи XML.
• Далее, описание Web-сервиса может быть сохранено и выбрано из реестра UDDI; вся информация, которая поступает в реестр или выходит из него форматирована как XML.
• Наконец, сами данные, обеспечиваемые Web-сервисом являются XML.

Hewitt представила два приложения, которые иллюстрируют возможность передавать данные более гибким способом:

• При помощи Secure Participant Mailbox авторизированные пользователи могут запрашивать отчеты, содержащие персонифицированную информацию о сотрудниках.
• При помощи With the Retirement Access B2B Connection авторизированные пользователи могут получать подробности финансовой информации клиента.

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

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

Раздел 8. Рекомендации

Полный вперед!

Теперь, я надеюсь, вы убедились, что XML является наилучшим способом перемещать структурированные данные и манипулировать ими. Если вы еще не используете XML, как вам начать? Вот некоторые соображения:

Ресурсы

Изучение

Об авторе