В текущем состоянии развелось множество buzz-words связанных с различными фреймворками и обработкой XML. Местами они ничего не значат. Местами суть концепции очень простая – но всё размазано по куче книжек и FAQ-ов. Описание не претендует на 100% верное – это лишь сжатая абстракция, которая сложилась у меня в голове после разработки интеграционного проекта на базе ESB\SOA\ XML \Web Services\BPEL в течение 2х лет. Если где-то сильну вру – поправьте ;) Оглавление
- XML
XML
Well-formed XML
Valid XML
DTD
XML Schema / XSD
Relax NG
XML Namespaces
Xpath
XSLT
Binary XML
- JAVA + XML
Типы парсеров
XML фреймворки и парсеры
Beans-to-XML mapping
- WEB SERVICES
SOAP + WSDL
Передача бинарных данных
Совместимость
- JAVA + WEB SERVICES
JAXWS/METRO
Apache AXIS
Apache CXF
Spring WS
- SOA / ESB / BPM
SOA
ESB
Задачка из жизни
- Утилиты для xml
XML
XML
суть текстовый формат хранения структурированных данных, Плюсы
- структурированный, хорошо мапится на объектные модели
- Читабелен в редакторе, умеет Unicode
- Хорошая обратная совместимость, решает проблемы по части интеграции систем на различных ОС\платформах итп, является W3C стандартом.
- Поддерживает ссылки между сущностями
- Поддерживает типы данных и валидацию
- Плохая производительность в сравнении с бинарными форматами
- Большая избыточность данных
- Нельзя хранить бинарные данные без перекодировки в BASE64 (+30% места на диске)
Well-formed XML
XML который удовлетворяет ограничениям
- есть корневой элемент
- все теги правильно вложены друг в друга и закрыты
- шапка и заголовок файла валидные
- все спец. символы правильно закодированы с использованием xml entites (всякие ‘&’ итп…) или использована секций CDATA
- важно понимать что далеко не любые данные можно написать в xml без перекодирования во что-то вроде BASE64
Valid XML
Формулировка означает что данные файла соответствуют некоторой структуре документа или правилам; правила задаются через cпециальный синтаксис – XML Schema или DTD. Valid = такой XML уже можно обрабатывать парсером с включенной валидацией
DTD
Это старый формат валидации XML, чем-то напоминает BNF-нотацию объявления синтаксиса. Выглядит примерно так
- Не имеет нормальных встроенных типов данных
- Не позволяет делать сложную валидацию
- Можно втыкать прямо внутрь самого документа (не ссылаясь на внешний ресурс)
XML Schema / XSD
Более новый вариант валидации
- объявляет простые и сложные типы данных, каждый тип может включать в себя другие
- за счет этого позволяет более формально маппить объекты на xml и валидировать их
- поддерживает примитивы и ограничения по значению
- втыкать внутрь документа (embedded) нельзя
Relax NG
Альтернативный способ описания струкутры xml, считается более простым чем xml schema. Бывает в 2х видах – XML и compact. Пример compact синтаксиса
XML Namespaces
Пространства имен, фича которая появилась в xml позднее и поэтому местами продумана довольно плохо и костыльно. Основная идея в том что любой элемент можен объявить префикс namespace и проассоциировать этот префикс с URL. URL используется просто как уникальный идентификатор Это позволяет в теории не бояться что частям xml не хватит имен в названиях, это активно используется в Xpath и при валидации.
- элементы из разных namespace’ов с одним названием воспринимаются как разные.
- у каждого элемента есть default namespace который ему достается по наследству от родительского элемента, при этом уже ничего не нужно указывать – все автоматом получит нужный префикс
Здесь <test/> == <a:test/>Обучалка по xml namespaces
Xpath
Язык для выполнения запросов к XML DOM дереву. Достаточно гибкий, но движок запросов, как правило, не очень быстрый. Пример: выбрать все элементы BBB в дереве с атрибутом name равным bbb: выбрать все элементы, являющиеся прямыми потомками /AAA/CCC/DDD Обучалка по XPATH
XSLT
Язык для работы с XML шаблонами – позволяет выбирать данные, преобразовывать и мержить с другими xml. Чаще всего используется для отделения разметки веб страницы (xhtml) и данных (например таблиц выгруженных в xml) или для процессинга\конвертации xml-файлов. Побочным эффектом такой универсальности является мозго-взрывной синтаксис и совершенно отвратный и нечитаемый результат (имхо). Хотя при должном упорстве язычок поддается изучению, в совершенстве его знают только избранные и некоторые верстальщики. Пример Обучалка по 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 файлов.
- все что нельзя сделать по умолчанию конфигурируется чз аннотации.
- умеет сериализовать графы
WEB SERVICES
SOAP – протокол для пересылки сообщений.
- Определяет 2 основных поля – header и body.
- Обычно используется в стеке вебсервисов поверх HTTP.
WSDL –язык описания веб-сервисов WSDL определяет
- какие типы данных у нас есть (комплексные типы, на базе xsd-типов),
- какие сообщения (состоящие из полей нужных типов) могут передаваться\приниматься,
- какие есть сервисы,
- какие есть в них порты (endpoints),
- какие методы есть у каждого из портов.
Пример: Версии
- 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
- RPC/encoded
- RPC/literal
- Document/encoded
- Document/literal
- Document/literal wrapped
Передача бинарных данных
SAAJ – один из стандартов который так и не прижился. MTOM - активно используется, есть во всех популярных JAVA-фреймворках; идея аналогична добавлению вложений в email: после soap сообщения добавляется специальная секция в которую пишутся raw бинарные данные. Прим:
- mtom не является спекой, ноды м-ду собой должны знать что оба поддерживают mtom и одинаково это понимают.
- Некоторые реализации могут делать все так как будто mtom корректно поддерживается, но в реальности в конец добавлять xop:include с Base64 данными (+33% размер аттача)…
Совместимость
Разные SOAP версии\биндинги не совместимы, например эти связки НЕ будут работать по дефолту:
- Axis + weblogic
- Jaxws + ms sharepoint
JAVA + WEB SERVICES
JAXWS/METRO
Стек веб-сервисов в JavaEE сделан на базе проекта METRO, туда входят JAXB, JAXWS, MTOM, STAX итп.. сама реализация хорошая, быстрая и стабильная. Простой пример: Скачиваем JAXWS RI, добавляем немного аннотаций , получаем веб-сервис который можно запускать прямо из main метода. Запускать можно вот таким кодом
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
Задачка из жизни
Недавно моим мнением поинтересовались вот в таком кейсе:
Задача: у кастомера есть более 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?).
- сколько лет это проживет после того как этот проект завершится, и насколько тяжело будет разбираться потомкам в том что останется
- вроде как есть графический редактор для 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, в них можно делать практически всё, но необходимость в их использовании довольно сомнительна
Спасибо!
ОтветитьУдалить