Средство связывания данных XML

для платформы Java

Mark Reinhold
Core Java Platform Group
Sun Microsystems, Inc. Java Software
901 San Antonio Road
Palo Alto, CA 94303 U.S.A. 30 июля 1999

Недавно Sun Microsystems взяла на себя обеспечение базовой поддержки для XML
на платформе Java. Предлагаемые возможности включают как событийно-
ориентированный SAX-совместимый синтаксический анализатор, так и
реализацию API дерева грамматического разбора W3C DOM (Document Object
Model (Объектная модель документа)). Это первый решительный шаг, но
использование этих, довольно низкоуровневых API, требует достаточно глубокого
понимания XML.
Чтобы сделать XML доступнее для широкой аудитории разработчиков, мы
ищем способы более прямого связывания XML документов с объектами «в
памяти». Такая связь позволит писать программы, манипулирующие с XML
содержимым, на том же концептуальном уровне, что и само XML содержимое, а
не на уровне событий синтаксического анализатора или дерева грамматического
разбора. Это также устранит необходимость использования низко-уровневых API,
таких как SAX и DOM в основанных на XML системах обмена данными и
сообщениями, таким образом, упрощая создание и поддержку этих систем.
Наиболее многообещающий подход, включает компиляцию, или связывание,
XML схемы в один или более Java классов. Эти автоматически генерируемые
классы управляют преобразованием между XML документами, которые должны
следовать схеме, и взаимосвязанными экземплярами классов. Они также
гарантируют, что ограничения, описанные в схеме, сохранятся в экземплярах
обрабатываемых классов.
В этой проектной ноте обозреваются основные концепции XML и схем,
мотивируется и определяется основанное на XML связывание данных,
представляется пространный пример, и наконец очерчивается круг требований к
средствам связывания данных для платформы Java.

Пожалуйста, отправляйте замечания к этой ноте по адресу <xml-binding-

[email protected]>.
Авторские права © 1999 Sun Microsystems, Inc.,
901 San Antonio Rd., Palo Alto, California, 94303 U.S.A.
Все права защищены.

Этот документ защищен авторским правом. Ни какая часть этого документа не

может быть воспроизведена ни в какой форме, ни каким способом без
письменного разрешения Sun и ее лицензиаров, если таковые имеются.
Информация, описанная в этом документе может быть защищена одним или
несколькими патентами США, иностранными патентами, или приложениями,
находящимися на стадии разработки.
Sun, Sun Microsystems, логотип Sun, Java и JavaBeans – торговые марки или
зарегистрированные торговые марки Sun Microsystems, Inc. в Соединенных
Штатах и других странах.

ЭТОТ ДОКУМЕНТ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ» БЕЗ ГАРАНТИЙ

ЛЮБОГО РОДА, ЯВНЫХ ИЛИ НЕЯВНЫХ, В ТОМ ЧИСЛЕ,
ПРЕДПОЛАГАЕМЫХ ГАРАНТИЙ ТОВАРНОГО СОСТОЯНИЯ,
ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ, ИЛИ НЕНАРУШЕНИЯ ПРАВИЛ.
ЭТОТ ДОКУМЕНТ МОЖЕТ СОДЕРЖАТЬ ТЕХНИЧЕСКИЕ НЕТОЧНОСТИ
ИЛИ ТИПОГРАФСКИЕ ОШИБКИ. ПРИВЕДЕННАЯ ЗДЕСЬ ИНФОРМАЦИЯ
ПЕРИОДИЧЕСКИ ОБНОВЛЯЕТС; ЭТИ ИЗМЕНЕНИЯ БУДУТ ВНЕСЕНЫ В
СЛЕДУЮЩИЕ РЕДАКЦИИ ДОКУМЕНТА. SUN MICROSYSTEMS, INC.
МОЖЕТ ДЕЛАТЬ ИСПРАВЛЕНИЯ И/ИЛИ ИЗМЕНЕНИЯ В ПРОДУКТЕ(АХ)
И/ИЛИ ПРОГРАММЕ(АХ), ОПИСАННЫХ В ЭТОМ ДОКУМЕНТЕ, В ЛЮБОЕ
ВРЕМЯ.
Введение

XML - в высшей степени платформо-независимый способ структуризации

информации. Документ XML – это дерево элементов. Элемент может иметь набор
атрибутов, в форме пар «ключ-значение», и может содержать другие элементы,
текст или их комбинацию. Элемент может ссылаться на другие элементы
посредством специальных атрибутов, позволяя, таким образом, представлять
произвольные структуры графов.
Структура XML документа не должна следовать каким-либо правилам, кроме
тех, которые заложены в спецификации XML. Однако, чтобы обмениваться
документами значимым образом, требуется, чтобы их структура описывалась и
ограничивалась таким образом, чтобы различные составляющие части
интерпретировали ее корректно и единообразно. Этого можно достичь, путем
использования схемы. Схема состоит из набора правил, ограничивающих
структуру и содержимое компонентов документа, т.е. их элементов, атрибутов и
текста. Схема также описывает, по меньшей мере неформально и часто неявно,
подразумеваемое концептуальное значение компонентов документа. Другими
словами, схема - это спецификация синтаксиса и семантики (потенциально
бесконечного) набора XML документов. Говорят, что документ действительный
по отношению к схеме, если и только если он удовлетворяет ограничениям,
описанным в схеме.
На каком языке пишутся схемы? Спецификация XML сама описывает
подмножество языка для написания определения типа документа, или DTD
(Document Type Definition). Как схемы, DTD достаточно слабы. Они
поддерживают определение простых ограничений на структуру и содержимое, но
не предоставляют средств для выражения типов данных или сложных
структурных отношений. Эти недостатки послужили причиной различных
попыток определить более сложные языки схем, и существует рабочая группа
W3C, призванная определить стандартный язык схем к концу 1999. (Эти новые
языки схем сами по себе являются приложениями XML, приводя к интересным
рекурсивным зависимостям, что не будет здесь детально освещаться.)

Связывание данных

Таким образом, любое нетривиальное приложение XML будет основано на одной

или нескольких схемах и будет содержать одну или более программ, которые
создают, уничтожают и управляют документами, чей синтаксис и семантика
определяются этими схемами. Хотя, конечно, возможно написать такие
программы, используя низко-уровневый API синтаксического анализатора SAX
или несколько более высокоуровневый API дерева грамматического разбора DOM,
вероятно, это действие утомительно и подвержено ошибкам. Результирующий код
также, вероятно, страдает большой избыточностью, что сделает его трудным для
поддержки как исправления ошибок, так и прослеживания схем.
Было бы гораздо проще писать XML-совместимые программы, если бы мы
могли просто отобразить компоненты XML документа на объекты «в памяти»,
которые представляют в ясной и удобной манере, предполагаемое значение
документа согласно его схеме. Экземплярами каких классов должны быть эти
объекты? В некоторых случаях это будет явное отображение компонент схемы на
существующие классы, особенно для общих типов, такие как String, Date, Vector и
так далее. В общем, однако, потребуются классы, специфичные для используемой
схемы. Вместо того, чтобы обременять разработчиков написанием этих классов,
мы можем создавать классы непосредственно из схемы, производя, таким образом,
связывание схемы на уровне Java.
Таким образом, средство связывания данных XML содержит компилятор
схемы, который транслирует схему в набор специфичных для схемы классов с
соответствующими методами доступа и мутации (т.е. get и set). Оно также
содержит структуру маршаллинга, которая поддерживает демаршаллинг XML
документов в графы взаимосвязанных экземпляров, как существующих, так и
порождаемых схемой классов и маршаллинг таких графов обратно в XML
документы. Процесс демаршаллинга проверяет входящие XML документы на
действительность по отношению к схеме. Подобным образом компилятор
генерирует код в производные классы, чтобы привести в исполнение ограничения,
описанные в схеме, обеспечивая, таким образом, что только действительные
документы сгенерированы процессом маршаллинга.

Подведем итог: Схемы описывают структуру и значение XML документа, почти

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

Пример

Чтобы проиллюстрировать преимущества связывания данных, рассмотрим

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

<ShoeOrder id=”4040458” style=”Sandal”>

<color>Brown</color>
<size>9 1/2</size>
<wirth>AA</width>
</ShoeOrder>

Схема для такого обувного заказа, написанная на проектируемом языке схем,

недавно опубликованном рабочей группой по схемам XML W3C, будет
начинаться с декларации типа элемента ShoeOrder, его атрибутов и его
подэлементов:

<schema name=”ShoeOrder”>
<elementType name=”ShoeOrder”>
<attrDecl name=”id” required=”true”>
<datetypeRef name=”ID”/>
</attrDecl>

<attrDecl name=”style” required=”true”>

<datetypeRef name=”IDREF”/>
</attrDecl>

<model>
<sequence>
<elementTypeRef name=”color”/>
<elementTypeRef name=”size”/>
<elementTypeRef name=”width”/>
</sequence>
</model>

Эти декларации определяют, что элемент ShoeOrder имеет два обязательных

атрибута, id и style; первый – идентификатор XML элемента, второй – ссылка на
идентификатор XML. Декларация model означает, что содержимое элемента
ShoeOrder должно быть последовательностью поименованных подэлементов
расположенных в заданном порядке. Каждый подэлемент определяется ссылкой
на тип элемента, который будет определен ниже.
Декларация продолжается определением производного типа данных для
цветов:

<datatype name=”Colors”>
<basetype name=”string”/>
<enumeration>
<literal>Black</literal>
<literal>Blue</literal>
<literal>Brown</literal>
<literal>Tan</literal>
<literal>White</literal>
</enumeration>
</datatype>

Определение означает, что цвет - это строка, которая может принимать одно из
следующих значений: Black, Blue, Tan или White. Затем мы можем определить тип
элемента color, на который ссылались в модели для элемента ShoeOrder:

<elementType name=”colors”>
<datatypeRef name=”Colors”/>
</elementType>

Размер обуви требует более интересного определения типа данных:

<datatype name=”Size”>
 <basetype name=”string”/>
<lexicalRepresentation>
<lexical>[1-9][0-9]?(1/2)?</lexical>
</lexicalRepresentation>
<minInclusive>3 1/2<minInclusive>
<maxInclusive>13</maxInclusive>
</datatype>

Здесь мы ограничили размер обуви строкой, находящейся в соответствии со

стандартным выражением, заданным в декларации lexicalRepresentation. То есть,
размер обуви - это строка, начинающаяся с цифры, не являющейся нулем, за
которой может следовать другая цифра (в том числе ноль), а за ней пробел или
выражение Ѕ для размеров «с половиной». Кроме того, размер обуви ограничен
диапазоном от 3 Ѕ до 13, в соответствии с обычным лексикографическим
порядком для строк.
Полнота обуви так же определяется, используя стандартное выражение:

<datatype name=”Width”>
<basetype name=”String”/>
<lexicalRepresentation>
<lexical>AAA|AA|[A-E]|EE|EEE<lexical>
</lexicalRepresentation>
</datatype>

Эта декларация ограничивает полноту обуви между A и E включительно, хотя так

же допускает предельные значения AAA, AA, EE и ЕЕЕ.
Чтобы закончить схему, нам нужны декларации типов элементов size и width.

<elementType name=”size”>
<datatypeRef name=”Size”/>
</elementType>

Наконец, мы имеем закрывающие теги для всей схемы:

</elementType>

</schema>

XML компилятор схем может связать описанные выше схемы в класс Java со
следующей сигнатурой:

public class ShoeOrder {

public ShoeOrder (String id, Style style,
String color, String size, String width);
public String getId();
public void setId(String id);

public String getStyle();

public void setStyle (String style);

public String getColor ();

public void setColor (String color);
 public String getSize();
public void setSize (String size);

public String getWidth();

public void setWidth (String width);

public void marshal (OutputStream out)

throws IOException;
public static ShoeOrder unmarshal (InputStream in)
throws IOException;
}

Мы также предполагаем, что определен элемент Style, который будет вызывать

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

public void acceptOrder(String s) throws IOException {

ShoeOrder so=ShoeOrder.unmarshal(s.getInputStream());
WarehouseDB.enter(so);
}

Подобным образом следующий метод находит заказ по номеру и передает его

через заданный сокет:

public void sendOrder (String id, Socket s) throws IOException {

ShoeOrder so=WarehouseDB.lookup(id);
so.marshal (s.getOutputStream());
}

Наконец, различные set-методы в созданном классе ShoeOrder производят полную

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

so.setColor(“Red”);
so.setSize(“5 ѕ”);
so.setWidth(“Z”);

Нет необходимости использовать производимые схемой классы в

оригинальной форме. При некоторых условиях может быть более удобным
расширить такие классы, чтобы добавить специфичные для приложения данные и
свойства. Например, класс ShoeOrder может быть расширен при помощи
подкласса WarehouseShoeOrder, который добавляет поля и методы необходимые
только в системе обработки заказов склада. С другой стороны он может быть
специализирован при помощи подкласса StoreShoeOrder для использования в
системе приема заказов розничного магазина. Этот стиль программирования
способен выиграть на средствах разработки, которые могут отслеживать
различные специализированные подклассы и перепроверять их действительность,
как схема ShoeOrder, и, следовательно, класс ShoeOrder.

Требования

Средство связывания данных для Java-платформы будет иметь два основных

компонента: cтруктуру маршаллинга и компилятор схем. Далее приводится
предварительный набросок требований к каждому компоненту.

Структура маршаллинга Структура маршаллинга будет представлять собой

платформенное расширение, которое вводит условия для аннотирования классов с
требуемыми метаданными. Эти метаданные, возможно в форме методов marshal и
unmarshal, приведенных выше, будет определять перевод между внешним XML
документом и внутренним экземпляром аннотированного класса. (Этот подход
напоминает операции encode и decode для переносимых типов в языке
программирования Argus.)
Структура маршаллинга будет содержать базовые интерфейсы для операций
маршаллинга и демаршаллинга, так же как и требуемые низкоуровневые службы
поддержки.
Структура маршаллинга должна быть применима для приложений, отличных
от связывания данных XML. Например, как часть работы над Swing, мы
экспериментируем с основанным на XML механизмом для архивации графов
JavaBeans в графические средства построения приложений. Этот механизм, так
же как и более общие механизмы архивации периода выполнения, должны быть
способны использовать ту же структуру маршаллинга, что и средство связывания
данных XML.
В идеале структура маршаллинга не будет специфичной для XML. Кажется
неразумным связывать такую общую структуру со специфическим форматом
данных., тем более, что, возможно, в будущем мы захотим поддерживать другие
форматы. Это значит, что условные обозначения метаданных и интерфейсы
должны быть предусмотрительно спроектированы так, чтобы быть независимыми
от XML. Поскольку эта цель может быть труднодостижимой, это скорее
пожелание, чем строгое требование.
Заметим, что в любом случае структура маршаллинга не намеревается
вытеснить механизм сериализации, который уже является центральной частью
платформы Java.

Компилятор схем Компилятор схем будет скорее инструментом типа командной

строки, чем расширением самой платформы, хотя он также может быть включен в
публичный, но не платформенный API для прямого использования средствами
разработки.
Остается открытым вопрос, какие именно из множества существующих
языков схем XML будет поддерживать компилятор. Почти наверняка будет
поддерживаться стандарт, разрабатываемый в данный момент рабочей группой по
схемам XML W3C. Существует ряд других языков схем, некоторые из которых
использовались и, возможно, они тоже будут поддерживаться, если на них будет
спрос. К ним относятся DCD, DDML, SOX и XML-Data. Наконец, DTD -
подмножество XML, сам по себе является простым языком схем, который уже
сейчас широко используется и, поэтому, также может поддерживаться.
Возможно множество стратегий преобразования схем. Простейшее
преобразование выражается в грубом сопоставлении одного Java-класса каждому
нетривиальному компоненту схемы. Более сложное преобразование должно
создавать интерфейсы или абстрактные классы, отражающие структуры и типы,
описанные в схеме, вместе со связанными классами, содержащими метаданные, и
код проверки ограничений.
Исходя из того, что на данный момент (еще) нет универсального языка схем
и большой вероятности появления еще большего колличества таких языков в
будущем, компилятор схем должен быть сконструирован модулярным образом,
что позволит в случае необходимости включать поддержку новых языков.

Ссылки

Рабочая группа по XML схемам W3C http://www.w3.org/XML/Group/Schemas.html

Рабочий проект XML схем
Часть 1: Структуры http://www.w3.org/1999/05/06-xmlschema-1
Часть 2: Типы данных http://www.w3.org/1999/05/06-xmlschema-2
Другие языки схем
DCD http://www.w3.org/TR/NOTE-dcd
DDML http://www.w3.org/TR/NOTE-ddml
SOX http://www.marketsite.net/xml/download/sox20.pdf
XML-Data
http://www.w3.org/TR/1998/NOTE-XML-data-0105

Argus http://www.pmg.lcs.mit.edu/Argus.html
Сериализация объектов Java ftp://ftp.java.sun.com/docs/jdk1.2/serial-spec-JDK1.2.pdf
XML и технология Java http://java.sun.com/xml