В текущем состоянии развелось множество 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 (всякие ‘&’ итп…) или использована секций 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/*
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>
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]](http://www.duct-tape-architect.ru/wp-content/uploads/2014/01/400px-WSDL_11vs202.png)
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). Различают вот такие варианты:
Биндинг по сути определяет что попадет в 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 = "logPortType", serviceName = "logService", portName = "logPort", targetNamespace = "http://logservice")
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL, parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public class LogService {
@WebMethod(operationName = "logMessage")
@WebResult(name = "return", targetNamespace = "http://logservice")
public String logMessage(
@WebParam(name = "msgParam", targetNamespace = "http://logservice") String msg) {
final String result = "LogMessage:" + msg;
System.out.println(result);
return result;
}
@WebMethod(operationName = "doFail")
public void doFail() throws ServiceException {
System.out.println("doFail:");
throw new ServiceException();
}
}
Запускать можно вот таким кодом
javax.xml.ws.Endpoint.publish("http://localhost:8000/myService/", 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, в них можно делать практически всё, но необходимость в их использовании довольно сомнительна
![java-vs-cpp[1]](http://www.duct-tape-architect.ru/wp-content/uploads/2014/01/java-vs-cpp1-520x245.jpg)
![java-vs-cpp[1]](http://www.duct-tape-architect.ru/wp-content/uploads/2014/01/java-vs-cpp1-160x160.jpg)
![Dilbert-big-front[1]](http://www.duct-tape-architect.ru/wp-content/uploads/2012/12/Dilbert-big-front1-160x160.jpg)
![konb[2]](http://www.duct-tape-architect.ru/wp-content/uploads/2012/07/konb2-160x160.png)
![xml[8]](http://www.duct-tape-architect.ru/wp-content/uploads/2014/01/xml8-160x160.jpg)
![java_evil[1]](http://www.duct-tape-architect.ru/wp-content/uploads/2014/01/java_evil1-160x160.jpg)
1 Ответ
[…] не совсем о тестировании. Но про XML-технологии. Полезно для […]