Содержание


Работа с XML на различных уровнях приложения

Использование XML в промежуточном слое в целях повышения производительности, точности соответствия и упрощения разработки

Создание XML-приложения при помощи JDBC 4.0, SQLXML и пакета дополнений XML для сервера приложений IBM WebSphere

Comments

Серия контента:

Этот контент является частью # из серии # статей: Работа с XML на различных уровнях приложения

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Работа с XML на различных уровнях приложения

Следите за выходом новых статей этой серии.

31 марта 2010 г.: в начало раздела Ресурсы добавлены ссылки на три видео-ролика.

04 октября 2010 г.: в начало раздела Ресурсы добавлена ссылка на вторую часть статьи.

Демонстрационное приложение: проверка комментариев в блоге, интегрированная с базой данных

В этой статье рассматривается приложение, архитектура которого представлена на рисунке 1.

Рисунок 1. Схема проверки комментариев в блоге, интегрированном с базой данных
Diagram of blog checker with database integration
Diagram of blog checker with database integration

Это Web-приложение обрабатывает информацию, предоставленную Web-сервисами онлайн-дневников (блогов). Информация, включающая в себя данные, которые относятся ко всем блогам указанного владельца, а также все комментарии к записям в этих блогах, может быть получена в виде XML-документов Atom (пример такого документа приведен в листинге 1). Приложение позволяет авторам блогов быстро просмотреть свежие комментарии к своим записям и удалять комментарии с нежелательным содержанием. Оно способно представлять данные в виде Web-страниц с формами ввода в формате XHTML. Учитывая тот факт, что в XML предоставляются как комментарии, так и исходный текст страниц (XHTML), логично использовать средства, позволяющие манипулировать данными непосредственно в этом формате.

Листинг 1. Пример комментариев в виде XML-документа в формате Atom
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">WebSphere Community Blog</title>
  ...
  <entry>
    <id>tag:blogger.com,1999:blog-1417695962027703953.post-6498982274841848264</id>
    <published>2009-10-17T13:06:00.000-05:00</published>
    <updated>2009-10-17T13:06:00.000-05:00</updated>
    <atom:title xmlns="" xmlns:atom="http://www.w3.org/2005/Atom" type="text">
      Questionable spamming comment title
    </atom:title>
    <atom:content xmlns="" xmlns:atom="http://www.w3.org/2005/Atom" type="html">
      Questionable spamming comment content
    </atom:content>
    ...
    <atom:author xmlns="" xmlns:atom="http://www.w3.org/2005/Atom">
      <atom:name>Joe Smith</atom:name>
      <atom:uri>http://joe.uri.com</atom:uri>
      <atom:email>jsmith@email.com</atom:email>
    </atom:author>
  </entry>
  ...
</feed>

В какой-то момент автор блога может заметить, что нежелательные комментарии поступают от одних и тех же пользователей или от адресов одного домена (см. элемент atom:author в листинге 1). В этом случае приложение позволяет не только удалить комментарий, но и пометить пользователя или весь домен флагом "спам". Этот флаг не содержится в документах, поступающих от Web-сервисов, поэтому его необходимо хранить в некоторой базе данных. Поскольку информация уже представлена в XML, логично использовать в качестве базы данных XML-хранилище. В будущем это позволит реализовать такие функции приложения, как, например, построение статистических отчетов о спамерах и автоматические рекомендации об удалении комментариев.

Как лучше всего реализовать такое приложение?

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

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

В связи с ростом популярности XML в корпоративных приложениях некоторые СУБД начали предоставлять возможность хранения данных не только в табличном виде, но и в виде XML-документов. В этом случае информация содержится в колонках, имеющих тип "XML". К таким СУБД относятся Apache Derby, IBM DB2®, Oracle Database и Microsoft® SQLServer.

Кроме того, ранее возникали сложности с передачей информации из промежуточного слоя приложения в базу данных. До появления JDBC 4.0 единственным вариантом было использование типов данных String или CLOB. Ранее уже упоминалось, что при этом ухудшается производительность из-за необходимости сериализации. К тому же, при таком подходе требуются нестандартные расширения SQL для разбора данных при сохранении в столбцах типа "XML". К счастью, в JDBC 4.0 появилась стандартная поддержка типа данных SQLXML, благодаря которому документы могут считываться и записываться в виде XML. JDBC 4.0 позволяет обращаться к данным как к строкам при помощи потоков чтения и записи, а также как к объектам Source и Result из JAXP. Таким образом, данные в формате XML могут свободно передаваться между промежуточным слоем и базой данных без необходимости дополнительных затрат на отображение и потерь производительности.

Простой пример использования JDBC 4.0 при работе с XML

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

  1. подготовка запроса (prepared statement);
  2. выполнение подготовленного запроса и получение выборки;
  3. получение объекта типа SQLXML из выборки;
  4. чтение содержимого объекта типа SQLXML при помощи одного из предоставляемых get-методов;
  5. освобождение объекта типа SQLXML.

Простой пример приведен в листинге 2.

Листинг 2. Чтение XML-данных при помощи JDBC 4.0
PreparedStatement ps =
        dbConnection.prepareStatement("SELECT somexmlcolumn FROM somexmltable");

ResultSet result = ps.executeQuery();

result.next();

SQLXML xml = result.getSQLXML("somexmlcolumn");

StreamSource source = xml.getSource(StreamSource.class);

// Чтение данных из потока

xml.free();

В этом примере чтение данных производится при помощи JAXP-объекта source, являющегося экземпляром StreamSource. Таким образом, обращаться к XML-данным может любой API, способный работать с источниками JAXP. StreamSource позволяет использовать любое представление данных в памяти. Как правило, потоковое представление является более эффективным по сравнению с такими типами источников, как DOM или SAX, работа с которыми связана с накладными расходами на конвертацию данных в объекты и вызовы методов API.

Для записи документов XML в базу данных через JDBC 4.0 выполняются следующие действия:

  1. подготовка запроса;
  2. формирование объекта SQLXML после установки соединения с базой данных;
  3. получение доступа к содержимому объекту SQLXML через один из доступных set-методов;
  4. указание объекта SQLXML в качестве параметра подготовленного запроса;
  5. запись содержимого объекта SQLXML с использованием ранее полученного доступа;
  6. выполнение запроса;
  7. освобождение объекта SQLXML.

Пример выполнения этих действий приведен в листинге 3.

Листинг 3. Запись документа XML в базу данных через JDBC 4.0
PreparedStatement ps = dbConnection.prepareStatement(
        "UPDATE somexmltable SET somexmlcolumn = ?");

SQLXML xml = dbConnection.createSQLXML();

StreamResult result = new StreamResult(xml.setBinaryStream());

ps.setSQLXML(1, xml);

// Запись в поток

ps.executeUpdate();

xml.free();

Промежуточный слой программного обеспечения

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

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

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

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

Наконец, XML позволяет упростить разработку, поскольку используется единственная модель данных, с которой можно работать согласованным образом через интерфейсы XML. С точки зрения Java™-разработчиков может показаться, что в ряде случаев в промежуточном слое проще отображать объекты на структуры данных DOM или JAXB. Однако эти случаи оказываются далеко не столь просты, например, при работе с упомянутыми выше налоговыми документами. Кроме того, в этом случае приходится изучать не только JDBC и XML, но и другие модели XML-программирования и выполнения запросов. Если же данные всегда представлены только в XML, то разработчику достаточно знать только модель данных XML и стандарты W3C для навигации по документам, их преобразованию и выборке информации. Более того, большинство разработчиков обладают этими навыками, поскольку такие языки, как XPath и XQuery уже используются в базах данных XML для навигации и выполнения запросов.

Подобное упрощение разработки легче всего достигается при помощи инфраструктуры, которая берет на себя большую часть низкоуровневой работы по получению информации от источника, ее преобразованию и сохранению в базе данных, причем без создания промежуточных копий. При создании демонстрационного приложения мы будем использовать набор инструментов (Feature Pack) XML для IBM WebSphere Application Server V7.0. Этот инструментарий не создает лишних копий данных, избегая тем самым дополнительных накладных расходов. При этом на всех этапах обработки информация представлена в XML, что позволяет легко осуществлять навигацию, конвертации и запросы к данным.

Пакет дополнений XML для сервера приложений IBM WebSphere Application Server V7.0

Пакет дополнений XML для IBM WebSphere Application Server V7.0 предоставляет средства для навигации, конвертации и запросов к XML в промежуточном слое приложения на основе таких стандартов W3C, как XPath 2.0, XSLT 2.0 и XQuery 1.0. Учитывая популярность XML в слое хранения данных, мы применим общий подход, предлагаемый JDBC 4.0, в приложении, использующем этот инструментарий и базу данных XML, например IBM DB2 с pureXML®, Apache Derby или Oracle. При этом взаимодействие между базой данных и инструментарием будет выглядеть, как показано на рисунке 2.

Рисунок 2. Простая диаграмма взаимодействия пакета дополнений XML от IBM и базы данных XML
Simple topology diagram of XML Feature Pack, a network,  and XML database
Simple topology diagram of XML Feature Pack, a network, and XML database

Далее мы продемонстрируем работу с XML в базе данных и промежуточном слое приложения при помощи СУБД c поддержкой XML, JDBC 4.0 и типа данных SQLXML, а также пакета дополнений XML для WebSphere.

Исходный код этого приложения входит в состав пакета дополнений XML, поэтому вы можете взять его за основу ваших собственных экспериментов. В разделе Ресурсы приведены ссылки на пакет дополнений XML, а также СУБД Apache Derby и DB2 Express.

Базы данных с собственной поддержкой XML, JDBC 4.0, а также пакет добавлений XML для WebSphere позволяют создавать приложения с простой и высокопроизводительной архитектурой.

Реализация демонстрационного приложения

В этом разделе мы рассмотрим реализацию демонстрационного приложение при помощи пакета дополнений XML, ОВИС 4.0 и СУБД с поддержкой XML. Вначале будет реализована функция получения подозрительных комментариев к записям в блоге с использованием Web-сервиса, передающего ленты Atom (см. рисунок 1). В процессе обработки этих комментариев приложение будет обращаться к базе данных, проверяя, не были ли их авторы ранее занесены в список спамеров. На всех этапах обработки данные будут представлены в виде документов XML. Итак, приступим к получению данных о комментариях в виде лент Atom.

Набор дополнений XML позволяет загружать данные лент Atom через HTTP-соединение с Web-сервисом блогов и обращаться к ним через процедуры XQuery. Эти процедуры исполняются средой пакета дополнений XML, которая, в свою очередь, вызывается через Java API того же пакета.

Для выборки подозрительных комментариев из ленты Atom используется следующие выражения XPath в XQuery:

Листинг. Выражения XPath
declare variable $comments := (
  /atom:feed/atom:entry[atom:author/atom:name = 'Anonymous'] |
  /atom:feed/atom:entry[matches(atom:content, $my:vulgarwords, 'i')])
  [atom:published > current-dateTime() - $my:monthsAgo];

В данном примере XPath используется для поиска комментариев в указанном пользователем временном интервале, которые были отправлены анонимными пользователями и содержали вульгарные слова. Выбранные комментарии сохраняются в переменной comments.

Далее в XQuery можно проверить, поступал ли ранее спам от тех же авторов. Для этого выполняется запрос к базе данных, в котором $i - это показанный выше вложенный запрос на выборку комментариев (листинг 5).

Листинг 5. Выражение XQuery
let $spammedbefore := local:hasEmailHasSpammedBefore($i/atom:author/atom:email/text())

Обратившись к определению функции, показанной в листинге 4, вы увидите, как информация загружается из базы данных в виде XML (листинг 6).

Листинг 6. Тело функции в XQuery
declare function local:hasEmailHasSpammedBefore($emailaddress) as xs:boolean {

let $domainName := substring-after($emailaddress, '@')

return
  if ($domainName = '') then
    false()
  else
    let $jdbcURI := concat('jdbc://getAuthorsWhoHaveSpammedFromDomain?', $domainName)
    let $domainSpammers := collection($jdbcURI)
    return
      not(empty($domainSpammers/spammers/spammer/email[. eq $emailaddress]))
};

В этом примере из адреса e-mail извлекается имя домена, которое затем конкатенируется с текстом запроса jdbc://getAuthorsWhoHaveSpammedFromDomain. После этого формируется коллекция XPath 2.0 на основе URI jdbc://getAuthorsWhoHaveSpammedFromDomain?ИМЯ_ДОМЕНА.

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

Наша реализация интерфейса XCollectionResolver отвечает за формирование коллекций, чей URI начинается с префикса jdbc://. При этом остальная часть URI используется для поиска соответствующего именованного запроса. Конструктор коллекций получает именованный запрос, добавляет в него параметры и выполняет его в базе данных при помощи JDBC.

В листинге 7 показано создание экземпляра конструктора после определения нескольких базовых запросов. Конструктор получает на вход JDBC-соединение с базой данных для выполнения запросов.

Листинг 7. Конфигурирование конструктора коллекций
dbStatementsSupportsSQLXML = new HashMap<String, String>();

dbStatementsSupportsSQLXML.put("getAuthorsWhoHaveSpammedFromDomain",
        "SELECT CONTACTS from SPAMMERS where DOMAINNAME = ?");

dbStatementsSupportsSQLXML.put("updateAuthorsWhoHaveSpammedByDomain",
        "UPDATE SPAMMERS SET CONTACTS = ? WHERE DOMAINNAME = ?");

dbStatementsSupportsSQLXML.put("insertAuthorsWhoHaveSpammedByDomain",
        "INSERT INTO SPAMMERS (CONTACTS, DOMAINNAME) VALUES (?, ?)");

Connection conn = getDatabaseConnection();

JDBCCollectionResolver inputResolver =
  new JDBCCollectionResolver(conn, dbStatementsSupportsSQLXML);

Фрагменты реализации конструктора показаны в листинге 8. Полный вариант реализации можно найти в примерах кода, входящего в состав пакета дополнений XML. Конструктор фактически выполняет действия по выборке XML-данных через JDBC, которые были описаны выше.

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

  1. Именованные запросы передаются в конструктор извне, а не содержатся в коде в жестко заданном виде.
  2. Конструктор анализирует метаданные возвращаемых строк и столбцов, тем самым гарантируя, что только данные типа SQLXML преобразуются в XML.
  3. Конструктор использует два других класса из API пакета дополнений XML, а именно XSequenceCursor и XItemView, для формирования последовательности XML на основе результатов запроса JDBC.
Листинг 8. Реализация конструктора
public XSequenceCursor getCollection(String uri, String base) {
        // Поиск запроса в заданном наборе (см. листинг 7)
        String query = lookupNamedQuery(uri);
        PreparedStatement p = dbConnection.prepareStatement(query);
        ResultSet rs = p.executeQuery();
        ...

        // Итерирование по результатам выполнения запроса
        ResultSetMetaData metadata = rs.getMetaData();
        int colType = metadata.getColumnType(jj+1);
        if (colType = Types.SQLXML) {
                SQLXML sqlx = rs.getSQLXML(...);
                StreamSource source = sqlx.getSource(StreamSource.class);
                XItemView item = itemFactory.item(source);
                sqlx.free();
        }

        // Создание последовательности на основе полученных XML-данных 
        // при помощи API пакета дополнений XML
        ...
        XItemView itemView[] = items.toArray(new XItemView[0]);
        XSequenceCursor sequence = itemFact.sequence(itemView);

        return sequence;
}

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

Листинг 9. Примеры XQuery
Java:
  dbStatementsSupportsSQLXML.put("getAllSpammers", "SELECT CONTACTS from SPAMMERS");
XQuery:
  let $allSpammers := collection('jdbc://getAllSpammers')
  return
    for $i in $allspammers
    let $first := $i/name/first
    order by $i/name/last
    return
      <name>
        <first>{ $first }</first>
        <last>{ $i/name/last }</last>
      </name>

Java:
  dbStatementsSupportsSQLXML.put("getAllSpamAuthorsWhereSpamCountGreaterThan",
    "SELECT CONTACTS from SPAMMERS where COUNT > ?");
XQuery:
  let $minCount := 10
  let $allSpammers := collection(concat(
    'jdbc:// getAllSpamAuthorsWhereSpamCountGreaterThan?',
    $minCount)
  )
  return
    count($allSpammers)
}

Следует отметить, что поскольку конструктор является частью XPath 2.0, его можно использовать в XSLT 2.0 с таким же успехом, что и в XQuery 1.0. В листинге 10 приведен простой примеры вызова конструктора из XSLT 2.0.

Листинг 10. Примеры XSLT
<xsl:variable name="allSpammers" select="collection('jdbc://getAllSpammers')"/>

<xsl:template match="/">
        <p>The current spammer database contains the following domains and spammers.</p>
        <xsl:for-each select="$allSpammers">

        <table>
        <tr>
                <th>Name</th><th>Email</th>
        </tr>
        <xsl:for-each select="$allSpammers">
        <tr>
                <td><xsl:value-of select="name"/></td>
                <td><xsl:value-of select="email"/></td>
        </tr>
        </xsl:for-each>
        </table>
</xsl:template>

Аналогичным образом можно реализовать запись в базу данных XML. XSLT 2.0 позволяет записывать результаты преобразования в несколько документов с указанными URI при помощи инструкции xsl:result-document. Как и ранее, разрешение подобных URI остается на усмотрение среды выполнения. В состав пакета дополнений входит интерфейс XResultsResolver, благодаря которому можно указывать, куда следует записывать результаты. В нашем приложении такой разрешающий класс (resolver) реализован на основе JDBC. Он использует именованные запросы и нумерованные параметры, среди которых один имеет специальное имя —XML—.

Это позволяет записывать данные в базу данных, как показано в листинге 11.

Листинг 11. Пример использования инструкции result-document в XSLT
<!--  Проверка: вставка или обновление данных? -->

<xsl:variable name="insert" select="count($spammersByDomain/spammers/spammer) eq 0"/>

<!-- Подготовка именованного запроса типа insert -->

<xsl:variable name="insertJdbcURI"
        select="concat('jdbc://insertAuthorsWhoHaveSpammedByDomain?--XML--&', $domain)"/>

<!-- Подготовка именованного запроса типа update -->

<xsl:variable name="updateJdbcURI"
        select="concat('jdbc://updateAuthorsWhoHaveSpammedByDomain?--XML--&', $domain)"/>

<!—
В случае insert следует добавить содержимое xsmldoc в БД.
В противном случае обновить данные, переданные в xmldoc.
-->

<xsl:template match="/">
        <xsl:when test="$insert">
                <xsl:result-document href="{$insertJdbcURI}" method="xml" indent="yes"> 
                        <xsl:copy-of select="$xmldoc"/>
                </xsl:result-document>
        </xsl:when>
        <xsl:otherwise>
                <xsl:result-document href="{$updateJdbcURI}" method="xml" indent="yes">
                        <xsl:copy-of select="$xmldoc"/>
                </xsl:result-document>
        </xsl:otherwise>
</xsl:template>

Если указанный спамер ранее не встречался, то будет выполнена первая часть инструкции xsl:when и информация о нем будет добавлена в базу данных. В этом случае среда XML получит запрос на запись содержимого переменной xmldoc по следующему URI:

Листинг 12. URI для записи результата
jdbc://insertAuthorsWhoHaveSpammedByDomain?--XML--&domain.com

Этот URI будет преобразован (разрешен) в именованный запрос, который в нашем случае выглядит следующим образом:

Листинг 13. Именованный запрос
INSERT INTO SPAMMERS (CONTACTS, DOMAINNAME) VALUES (?, ?)

В этом примере разрешающий класс помещает содержимое документа XML, который содержится в переменной xmldoc, на место первого параметра. В качестве второго параметра используется domain.com.

Как и в случае с чтением данных, запись XML-документов по указанным URI может использоваться в разных языках работы с XML. В предыдущем примере применялся XSLT (см. листинг 11), но аналогичным образом можно написать программу на XQuery 1.0, которая будет записывать результаты в базу данных XML.

Замечание: разрешающие классы на основе JDBC и альтернативные методы

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

Вы также можете создать конструктор коллекций в виде функции-расширения XPath 2.0. Это более специализированное решение, пример которого приведен в листинге 14.

Листинг 14. Функция специального назначения в XQuery
declare function local:hasEmailHasSpammedBefore($emailaddress) as xs:boolean {

let $domainName := substring-after($emailaddress, '@')

return
  if ($domainName = '') then
    false()
  else
    let $domainSpammers := my:getAuthorsWhoHaveSpammerFromDomain($domainName)
      return
        not(empty($domainSpammers/spammers/spammer/email[. eq $emailaddress]))
};

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

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

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

Заключение

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

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


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML, Information Management, WebSphere
ArticleID=632214
ArticleTitle=Работа с XML на различных уровнях приложения: Использование XML в промежуточном слое в целях повышения производительности, точности соответствия и упрощения разработки
publish-date=03142011