Все XML-технологии за 5 минут. XML, XML-NS, Fast Infoset, XPATH, XSLT, XSD, DTD, XML schema, SOAP, WSDL, MTOM, SAAJ, DOM, SAX, STAX, JAXB, dom4J, jdom, xerces, xalan, xsteam, JAX-WS, JAX-RT, SOA, ESB.

В текущем состоянии развелось множество buzz-words связанных с различными фреймворками и обработкой XML. Местами они ничего не значат. Местами суть концепции очень простая – но всё размазано по куче книжек и FAQ-ов. Описание не претендует на 100% верное – это лишь сжатая абстракция, которая сложилась у меня в голове после разработки интеграционного проекта на базе ESB\SOA\ XML \Web Services\BPEL в течение 2х лет. Если где-то сильну вру – поправьте ;)

XML

 XML

суть текстовый формат хранения структурированных данных,

<?xml version="1.0" encoding="ISO-8859-1"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

Плюсы

  • структурированный, хорошо мапится на объектные модели
  • Читабелен в редакторе, умеет Unicode
  • Хорошая обратная совместимость, решает проблемы по части интеграции систем на различных ОС\платформах итп, является W3C стандартом.
  • Поддерживает ссылки между сущностями
  • Поддерживает типы данных и валидацию

Минусы

  • Плохая производительность в сравнении с бинарными форматами
  • Большая избыточность данных
  • Нельзя хранить бинарные данные без перекодировки в BASE64 (+30% места на диске)

 Well-formed XML

XML который удовлетворяет ограничениям

  • есть корневой элемент
  • все теги правильно вложены друг в друга и закрыты
  • шапка и заголовок файла валидные
  • все спец. символы правильно закодированы с использованием xml entites (всякие ‘&amp;’ итп…) или использована секций CDATA
  • важно понимать что далеко не любые данные можно написать в xml без перекодирования во что-то вроде BASE64

т.е. Well formed = такой XML уже можно парсить парсером.

 Valid XML

Формулировка означает что данные файла соответствуют некоторой структуре документа или правилам; правила задаются через cпециальный синтаксис – XML Schema или DTD. Valid = такой XML уже можно обрабатывать парсером с включенной валидацией

 DTD

Это старый формат валидации XML, чем-то напоминает BNF-нотацию объявления синтаксиса. Выглядит примерно так

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE people_list [
<!ELEMENT people_list (person)*>
<!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT birthdate (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
<!ELEMENT socialsecuritynumber (#PCDATA)>]>
<people_list>
<person>
<name>Fred Bloggs</name>
<birthdate>2008-11-27</birthdate>
<gender>Male</gender>
</person>
</people_list>
  • Не имеет нормальных встроенных типов данных
  • Не позволяет делать сложную валидацию
  • Можно втыкать прямо внутрь самого документа (не ссылаясь на внешний ресурс)

еще примеры

 XML Schema / XSD

Более новый вариант валидации

  • объявляет простые и сложные типы данных, каждый тип может включать в себя другие
  • за счет этого позволяет более формально маппить объекты на xml и валидировать их
  • поддерживает примитивы и ограничения по значению
  • втыкать внутрь документа (embedded) нельзя

SimpleAddress.xsd

<?xml version="1.0" encoding="utf-8"?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Address">
<xs:complexType>
<xs:sequence>
<xs:element name="Recipient" type="xs:string"/>
<xs:element name="House" type="xs:string"/>
<xs:element name="Street" type="xs:string"/>
<xs:element name="Town" type="xs:string"/>
<xs:element name="County" type="xs:string" minOccurs="0"/>
<xs:element name="PostCode" type="xs:string"/>
<xs:element name="Country">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="UK"/>
<xs:enumeration value="US"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Test.xml

<?xml version="1.0" encoding="utf-8"?>
<address xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SimpleAddress.xsd">
<recipient>Mr. Walter C. Brown</Recipient>
<house>49</House>
<street>Featherstone Street</Street>
<town>LONDON</Town>
<postcode>EC1Y 8SY</PostCode>
<country>UK</Country>
</Address>

Relax NG

Альтернативный способ описания струкутры xml, считается более простым чем xml schema. Бывает в 2х видах – XML и compact. Пример compact синтаксиса

# Это — документационный комментарий к стартовому правилу
start = root

## Главный элемент схемы.
root = element element_user {
attribute user_name { text },
attribute first_name { text },
attribute last_name { text },
attribute date_of_birth {...},
# для ограничений используются дополнительные средства типа Schematron
attribute register_date { text },
( ContactInfo )*,
( Blogs )*
}
ContactInfo = ICQ | LinkedIn
Blogs = element blog_name {...}
element blog_url {...}

 XML Namespaces

Пространства имен, фича которая появилась в xml позднее и поэтому местами продумана довольно плохо и костыльно. Основная идея в том что любой элемент можен объявить префикс namespace и проассоциировать этот префикс с URL. URL используется просто как уникальный идентификатор Это позволяет в теории не бояться что частям xml не хватит имен в названиях, это активно используется в Xpath и при валидации.

<root xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:a="http://aaa.com/test"
xmlns:b="http://bbb.com/smthelse">
...
</root>
  • элементы из разных namespace’ов с одним названием воспринимаются как разные.
<root xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:a="http://aaa.com/test"
xmlns:b="http://bbb.com/smthelse">
...
<node1/>
<a:node1/>
<b:node1/>
<xhtml:p></xhtml:p>
...
</root>
  • у каждого элемента есть default namespace который ему достается по наследству от родительского элемента, при этом уже ничего не нужно указывать – все автоматом получит нужный префикс
<a:p>
<test/>
</a:p>

Здесь тег test == a:test
Обучалка по xml namespaces

Xpath

Язык для выполнения запросов к XML DOM дереву. Достаточно гибкий, но движок запросов, как правило, не очень быстрый. Пример: выбрать все элементы BBB в дереве с атрибутом name равным bbb:

//BBB[@name='bbb']

выбрать все элементы, являющиеся прямыми потомками /AAA/CCC/DDD

/AAA/CCC/DDD/*

Обучалка по XPATH

XSLT

Язык для работы с XML шаблонами – позволяет выбирать данные, преобразовывать и мержить с другими xml. Чаще всего используется для отделения разметки веб страницы (xhtml) и данных (например таблиц выгруженных в xml) или для процессинга\конвертации xml-файлов. Побочным эффектом такой универсальности является мозго-взрывной синтаксис и совершенно отвратный и нечитаемый результат (имхо). Хотя при должном упорстве язычок поддается изучению, в совершенстве его знают только избранные и некоторые верстальщики. Пример

<xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>

<xsl:template match="/">
<h1>
<xsl:value-of select="//title"/>
</h1>

<h2>
<xsl:value-of select="//author"/>
</h2>

</xsl:template>

</xsl:stylesheet>

Обучалка по XSLT

Binary XML

Поскольку XML так плох по части производительности и избыточности хранения, регулярно предпринимаются попытки изобрести более нативное представление \ замену Fast Infoset — цель формата сокращение места и ускорение парсинга. Vtd xml – отличный формат обработки гигабайтный DOM- деревьев.

JAVA + XML

JDK хорошо поддерживает все что есть в XML мире. По дефолту включаются почти все парсеры – SAX, StaX, DOM. С версии 1.4+ JDK поддерживает динамическую регистрацию XML-парсеров. Такие парсеры вызываются внутри JDK при использовании его XMl API. Раньше нужно было добавлять парсер как доп. библиотеку, теперь с 1.4 по дефолту используется XERCES, который переписывают от версии к версии. Важно: из за смены JDK могут меняться\ломаться и сами парсеры – от этого переносимость приложения между разными JDK не такая легкая, как того бы хотелось java-разработчикам.

Типы парсеров

SAX parser

  • Event-driven парсинг
  • код обрабатывает события такие как: найден начальный тег, найден атрибут, найден конечный тег.
  • Быстрый по производительности, и простой по реализации
  • Тяжело написать сложную логику

DOM parser

  • формируется дерево объектов из элементов с атрибутами;
  • дерево хранится в памяти, его можно крутить и изменять как угодно, удобно работать со сложными структурами
  • удобно вычислять XPATH функции
  • в целях оптимизации некоторые узлы могут не разбираться, пока к ним не обратятся

Pull parser

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

Вот такая табличка хорошо сравнивает их по фичам.

Feature StAX SAX DOM TrAX
API Type Pull, streaming Push, streaming In memory tree XSLT Rule
Ease of Use High Medium High Medium
XPath Capability No No Yes Yes
CPU and Memory Efficiency Good Good Varies Varies
Forward Only Yes Yes No No
Read XML Yes Yes Yes Yes
Write XML Yes No Yes Yes
Create, Read, Update, Delete No No Yes No

XML фреймворки и парсеры

Dom4j – лучшее что есть для DOM-парсинга, используется в Intellij IDEA. Сейчас уже дорос до поддержки DOM, SAX , JAXP (встраивается в JDK как парсер по умолчанию), XPATH, XSLT.

Jdom – чуть устаревший предшественник dom4j, хорошая библиотека т.к. всё есть.

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

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

xerces-j – парсер по умолчанию в JDK1.4+

xalan – популярный XSLT движок, используется в куче разных фреймворков.

Beans-to-XML mapping

JAXB – мощная система, входит в JAXP ( в JDK);

  • позволяет задать аннотации на объекте и смаппить его на xml
  • по аннотациям может генерится xsd
  • позволяет грузить из\сохранять в xml инстансы такого объекта
  • используется в стеке вебсервисов JavaEE, поэтому производительность должна быть на уровне
  • богатый функционал и непростое API, поэтому требует время на освоение

Xstream – легкий быстрый и удобный фреймворк для маппинга xml в java-бины

  • практически нулевая сложность настройки
  • чистый xml на выходе, без спец. полей итп мусора
  • must-have для парсинга конфигурационных xml файлов.
  • все что нельзя сделать по умолчанию конфигурируется чз аннотации.
  • умеет сериализовать графы

400px-WSDL_11vs20[2]

WEB SERVICES

SOAP & WSDL

SOAP – протокол для пересылки сообщений.

  • Определяет 2 основных поля – header и body.
  • Обычно используется в стеке вебсервисов поверх HTTP.

WSDL –язык описания веб-сервисов WSDL определяет

  • какие типы данных у нас есть (комплексные типы, на базе xsd-типов),
  • какие сообщения (состоящие из полей нужных типов) могут передаваться\приниматься,
  • какие есть сервисы,
  • какие есть в них порты (endpoints),
  • какие методы есть у каждого из портов.

Пример:

<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<porttype name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

Версии

  • soap 1.1 -> wsdl 1.1 (текущие версии связки – используется повсеместно)
  • soap 1.2 -> wsdl 2.0 (используется редко, плохо поддерживается фреймворками)
  • Soap 1.1 vs Soap 1.2 (раз, два, три) , wsdl 1.1 vs wsdl 2.0

Есть много разных способов отображения объектов на SOAP сообщения (SOAP-binding). Различают вот такие варианты:

  1. RPC/encoded
  2. RPC/literal
  3. Document/encoded
  4. Document/literal
  5. Document/literal wrapped

Биндинг по сути определяет что попадет в xml-сообщение: имена параметров? Типы параметров? Имя вызванной процедуры? Итп. Про биндинг детально можно прочитать тут

Передача бинарных данных

SAAJ – один из стандартов который так и не прижился. MTOM - активно используется, есть во всех популярных JAVA-фреймворках; идея аналогична добавлению вложений в email: после soap сообщения добавляется специальная секция в которую пишутся raw бинарные данные. Прим:

  • mtom не является спекой, ноды м-ду собой должны знать что оба поддерживают mtom и одинаково это понимают.
  • Некоторые реализации могут делать все так как будто mtom корректно поддерживается, но в реальности в конец добавлять xop:include с Base64 данными (+33% размер аттача)…

Совместимость

Разные SOAPверсии\биндинги не совместимы, например эти связки НЕ будут работать по дефолту:

  • Axis + weblogic
  • Jaxws + ms sharepoint

Разные производители (Microsoft, Sun) в своих веб-сервисах полагаются на различные дефолты.. поэтому иногда бывает непросто дернуть даже обычный веб-сервис.

JAVA + WEB SERVICES

 JAXWS/METRO

Стек веб-сервисов в JavaEE сделан на базе проекта METRO, туда входят JAXB, JAXWS, MTOM, STAX итп.. сама реализация хорошая, быстрая и стабильная. Простой пример: Скачиваем JAXWS RI, добавляем немного аннотаций , получаем веб-сервис который можно запускать прямо из main метода.

@WebService(name = &quot;logPortType&quot;, serviceName = &quot;logService&quot;, portName = &quot;logPort&quot;, targetNamespace = &quot;http://logservice&quot;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL, parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public class LogService {
@WebMethod(operationName = &quot;logMessage&quot;)
@WebResult(name = &quot;return&quot;, targetNamespace = &quot;http://logservice&quot;)
public String logMessage(
@WebParam(name = &quot;msgParam&quot;, targetNamespace = &quot;http://logservice&quot;) String msg) {
final String result = &quot;LogMessage:&quot; + msg;
System.out.println(result);
return result;
}

@WebMethod(operationName = &quot;doFail&quot;)
public void doFail() throws ServiceException {
System.out.println(&quot;doFail:&quot;);
throw new ServiceException();
}
}

Запускать можно вот таким кодом

javax.xml.ws.Endpoint.publish(&quot;http://localhost:8000/myService/&quot;, myServiceImplementation)

 Apache AXIS

Популярный и хороший фреймвок, текущая весия 2+, кое-где еще распространен Axis1.x но он не так удобен в использовании.. http://axis.apache.org/axis2/java/core/

Apache CXF

Фреймворк рабочий и полноценный, по попользовав его остался крайне недоволен кривой поддержкой некоторых вещей и глючностью. http://cxf.apache.org/

Spring WS

Кошерная реализация от SpringSource. Не использовал, но все хвалят. http://static.springsource.org/spring-ws/sites/2.0/

SOA / ESB / BPM

Все слышали слова SOA , BPM , ESB .. но на самом деле мало кто из заказчиков\PM-ов\руководителей ИТ на самом деле понимает что это всё такое..

Sales рисуют абстрактные картинки.. на которых все хорошо, гибко и чудесно. Но в головах — туман.. и желание потратить немного денег на всё это.. и с этим приходят чтобы “интегрироваться”. Вот хорошая статья как введение в наши проблемы — SOA и BPM

SOA

SOA — это очень простая концепция

  • каждая служба это сервис..
  • “давайте сделаем” общий orchestration который свяжет все эти службы между собой в некий сервис..
  • который будет предоставляться конечным пользователям с некоторым качеством (SLA?).
  • всё

Что SOA не делает:

  • SOA это не только +1 к business value: еще есть толстая техническая составляющая которая даст отдачу только чз большой промежуток времени
  • SOA не требует BPM
  • SOA не обязательно требует несколько хостов
  • SOA не обязывает пользоваться messaging или обработкой событий
  • SOA никак не относится к веб-сервисам, REST, XML, RMI итп. это всего лишь протоколы конкретных реализаций.

Почему SOA это трудно

  • тяжело выделить хорошую, ре-юзабельную службу в отдельный сервис и потом везде использовать
  • повторное использование очень тяжело предусмотреть, особенно если бизнес процессами рулят не-технические люди
  • маркетинг – сам термин SOA завален дурной рекламой от ведущих вендоров.. до такой степени что разобраться в терминах становится очень сложно. Каждый кому не лень переделал свой унылый и кроивой интеграционыый тул (или MOM-сервер) как SOA compatible и продает его..
  • мало внедрений

 ESB

Что такое ESB:

  • это единая архитектура интеграционной шины сделанная в соотв-ии с SOA подходом
  • чаще всего используют веб-сервисы для транспорта
  • чаще всего на шину втыкают движок для исполнения long-running бизнес процессов
  • для общения с внешним миром для каждой внешней системы пишутся адаптеры
  • самая важная функциональность это messaging (отправка сообщений через некоторую общую среду) и routing (управление доставкой сообщений подписанным компонентам) , поверх всего этого у самых крупных вендоров навернуто еще 10 слоев абстракций , но суть от этого не меняется.

Примеры ESB продуктов:

  • MS BizTalk
  • Oracle ESB
  • IBM WebSphere ESB
  • Open ESB
  • Mule
  • Tibco
  • Apache ServiceMix

ESB — Задачка из жизни

Недавно моим мнением поинтересовались вот в таком кейсе:
Задача: у кастомера есть более 40 приложений (и/или интерфейсов к другим системам) для автоматизации своего бизнеса. Приложения вида: вебпортал / десктоп / мобильные / SAP и т.п., написанные на разных языках / платформах. Примерно 10тыс. пользователей этих приложений в стационарных офисах и 1,5тыс. пользователй в мобильных офисах. Постепенно приложения переписываются под технологию .NET (C# / WCF / EF / Silverlight / ASP.NET / MSSQL / etc.). В качестве платформы для обмена данными между приложениями кастомер предлагает (но не настаивает) на BizTalk-е.

Нужно оценить применимость BizTalk и конкурирующих продуктов с точки зрения:
легкости интеграции с разными приложениями (написанных на Silverlight / ASP.NET / mobile apps)
скорости обучения девелоперов
стоимости деплоймента в энтерпрайз виде
безопасности
надежности
скорости работы
устойчивости к нагрузкам и т.д.

Напишите, если у Вас был опыт работы с BizTalk или его аналогами. В чем принципиальная выгода от использования BizTalk, по сравнению, например, с «самописной» системой обмена данными между приложениями?
Имхо, есть как минимум 3 «самописные» замены BizTalk:

1) написать свой сервер приложений. Т.е. это будет постоянно работающие в режиме 24/7 приложение на выделенном сервере, которое будет уведомлять об изменениях все подписанные на это клиентские приложения.
2) т.к. каждое приложение результаты своей работы складывает в БД (как правило, в  MSSQL) или в виде файлов на ftp сервер, то можно чтобы каждое приложение перодически (раз в несколько минут) опрашивало через вебсервис БД / ftp сервер на предмент наличия важных для него данных.
3) на уровне БД MSSQL в триггере при появлении новых данных в таблице, послать сообщение через .NET CLR stored procedure (WCF + MSMQ?). Для случая с файлами на ftp сервере — написать приложение которое будет периодически проверять каталог и рассылать уведомления при появлении новых файлов (WCF + MSMQ?).

Моё имхо: Плюсы применения BizTalk

  • сколько лет это проживет после того как этот проект завершится, и насколько тяжело будет разбираться потомкам в том что останется
  • вроде как есть графический редактор для orchestrations и готовая модель вида — пишем адаптер для каждой системы в biztalk, внутри biztalk’a ходят наши же сообщения
  • это легче продать, компании верят в коробочные решения, даже если они утыканы костылями как ёлка опилками. плюс есть туманная вера что они смогут найти другого вендора на поддержку (не вас).

Минусы BizTalk

  • если biztalk медленно работает или чего-то не умеет — проект обрастет костылями, будет медленно работать, будет тяжел в деплойменте итп.
  • не сможете писать юнит тесты, и вообще какие-либо тесты.. это большой «-»
  • если столкнетесь с багами которые MS откажется исправлять — будете плакать но пользоваться.
  • если будете пользоваться рисовалкой «процессов» — рано или поздно модель станет очень сложна в поддержке, т.е. только опытные ассы рискнут ее править, плюс уткнетесь в ограничения самого тула; (вообще это происходит с любым визуальным инструментом при разработке чего-либо сложного).

Xочется посоветовать

  • заюзать любой messaging framework с которым вы а) знакомы б) доверяете его производительности и надежности г) уверены что он проживет 10-20лет (или вы сможете его поддерживать сами)
  • слать через него xml-сообщения или бинарные с оговоренным форматом (или количество и вид этих форматов должен быть как-то декларативно описан)
  • стараться смотреть в сторону open source, не читать буклеты Oracle & Microsoft
  • в итоге вы получите 20% функционала biztalk который покроет 80% хотелок, остальное можно дописать по ходу дела..

Утилиты для xml

Intellij IDEA , Intellij WebStorm , Eclipse – тут всё ясно, прозрачная валидация и автоподстановка имен элементов, редактирование XML.

XMLPAD – править, смотреть, считать XPATH, валидировать итп

Xml Notepad – смотреть 1Gb+ файлы

Notepad++ — есть достаточно хороший plugin xml tools для работы с XML

SOAP UI – для работы с веб-сервисами: вызов, генерация тестовых сервисов по wsdl, отладка, авто-тесты.

TcpTrace – прозрачный port редиректор\сниффер для просмотра TCP-трафика

Altova, Oxygen – крутые и навороченные XML IDE, в них можно делать практически всё, но необходимость в их использовании довольно сомнительна

Другие записи...

1 Ответ

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

* Please Enter the Output

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>