Почему StAX?

Проект StAX был возглавлен BEA с поддержкой от Sun Microsystems, и JSR 173 спецификации, которые передают избирательный бюллетень одобрения финала Процесса Сообщества Java в марте 2004 (http://jcp.org/en/jsr/detail?id=173). Основная цель API StAX состоит в том, чтобы дать “контроль парсингом программисту, представляя простой iterator базируемый API. Это позволяет программисту просить следующее событие (вытяните событие), и позволяет состоянию быть сохраненным процедурным способом.” StAX создавался, чтобы адресовать ограничения в двух самых распространенных API парсинга, SAX и ДОМЕ.

Потоковая передача против ДОМА

Вообще говоря, есть две модели программирования для того, чтобы работать с инфонаборами XML: потоковая передача и объектная модель документа (ДОМ).

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

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

Модели потоковой передачи для обработки XML особенно полезны, когда у Вашего приложения есть строгие ограничения памяти, как с сотовым телефоном, выполняющим Платформу Java, Микро Выпуск (платформа ME Java), или когда Ваше приложение должно обработать несколько запросов одновременно, как с сервером приложений. Фактически, можно утверждать, что большинство бизнес-логики XML может извлечь выгоду из потоковой обработки, и не требует обслуживания в памяти всех деревьев ДОМА.

Вытяните Парсинг против Парсинга Нажатия

Потоковая передача парсинга получения по запросу обращается к модели программирования, в которой клиентское приложение вызывает методы на библиотеке парсинга XML, когда это должно взаимодействовать с инфонабором XML — то есть, клиент только добирается (вытягивает) данные XML, когда это явно просит это.

Потоковая передача парсинга нажатия обращается к модели программирования, в которой передается синтаксический анализатор XML (продвигает) данные XML клиенту, поскольку синтаксический анализатор встречается с элементами в инфонаборе XML — то есть, синтаксический анализатор отправляет данные, готов ли клиент использовать это тогда.

Парсинг получения по запросу обеспечивает несколько преимуществ перед парсингом нажатия, работая с потоками XML:

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

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

• Клиенты получения по запросу могут считать многократные документы когда-то с единственным потоком.

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

Варианты использования StAX

Спецификация StAX определяет много вариантов использования для API:

• Привязка данных

  • Немаршалинг XML-документа

  • Маршалинг XML-документа

  • Параллельная обработка документов

  • Радиосвязь

• Простой Объектный Протокол Доступа (SOAP) обработка сообщения

  • Парсинг простых предсказуемых структур

  • Парсинг представлений графика со ссылками вперед

  • Парсинг Языка описания веб-сервисов (WSDL)

• Виртуальные источники данных

  • Просматривая, поскольку данные XML сохранены в базах данных

  • Просмотр данных в объектах Java создается привязкой данных XML

  • Навигация по дереву ДОМА как поток событий

• Парсинг определенных словарей XML

• Конвейерная обработка XML

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

Сравнение StAX к Другим API JAXP

Как API в семействе JAXP, StAX может быть сравнен, среди других API, к SAX, TrAX, и JDOM. Из последних двух StAX не столь же мощен или гибок как TrAX или JDOM, но, и при этом это не требует, чтобы так много памяти или процессора загрузились, чтобы быть полезными, и StAX может, во многих случаях, выиграть у DOM-на-основе API. Те же самые параметры, обрисованные в общих чертах выше, взвешивая стоимость/преимущества модели ДОМА против модели потоковой передачи, применяются здесь.

С этим в памяти, самые близкие сравнения могут быть сделаны между StAX и SAX, и именно здесь StAX предлагает функции, которые выгодны во многих случаях; некоторые из них включают:

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

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

• SAX является API нажатия, тогда как StAX является получением по запросу. Компромиссы между API нажатия и получения по запросу, обрисованными в общих чертах выше, применяются здесь.

Следующая таблица суммирует сравнительные функции StAX, SAX, ДОМ, и TrAX (таблица, адаптированная от “StAX, принадлежит в Вашем XML Панель инструментов?” в http://www.developer.com/xml/article.php/3397691 Джеффом Райаном).

Таблица: XML Сводка Функции API Синтаксического анализатора