Распределенные транзакции (XA) с помощью JTA в JavaSE (на примере Spring + Atomikos)

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

Для решения данной проблемы используются т.н. распределенные транзакции - транзакции, охватывающие несколько источников данных. В мире Java такие транзакции поддерживаются с помощью Java Transaction API (JSR 907), являющегося частью спецификации JavaEE. Однако, данный факт не обозначает, что работать с JTA можно только с помощью Java EE-сервера приложений. Существуют различные, в том числе и OpenSource, реализации JTA, в частности - Atomikos TransactionsEssentials, которая содержит JDBC/XA и JMS/XA пулы соединений, а также координатор распределенных транзакций. В данной статье мы рассмотрим использование Atomikos TransactionsEssentials для управления распределенными транзакциями, в которых будут участновать JDBC- и JMS-соединения, а также Hibernate. Для объединения компонентов системы будем использовать Spring Framework.

Содержание

1. Понятие XA-транзакции.
2. Использование JDBC/XA-пулов и координатора транзакций из Atomikos с помощью Spring Framework.
3. Подключение JMS/XA (ActiveMQ).
4. Использование Atomikos в качестве менеджера транзакций для Hibernate.
5. Заключение.
6. Ресурсы.

Введение в OSGi: Среда исполнения (Execution Environment)

Среда исполнения (Execution Environment) в мире OSGi - это символьное представление версии JRE, т.е. указание платформе с какой версией JRE совместимы классы, составляющие бандл.

Понятие "среда исполнения" становится необходимо, когда бандл разрабатывается на одной JRE, но предполагается, что использоваться он будет на другой JRE или, что более характерно, нескольких JRE. Возникновение данного понятия имеет глубокие исторические причины, т.к. OSGi изначально создавалась для использования во встроенных решениях, для которых имеется довольно широкое многообразие различных версий Java-платформы.

В общих чертах идея использования среды исполнения заключается в следующем: при разработке бандла указывается в каких версиях JRE предполагается его использовать, в зависимости от этого становятся доступными те или иные API. Во время исполнения же, если среда исполнения бандла не совместима со средой, в которой запущена платформа OSGi, он не будет загружаться.

В данной статье мы подробно рассмотрим следующие вопросы:
- Стандартные среды исполнения.
- Конфигурирование среды исполнения в Eclipse SDK.
- Настройка Eclipse PDE для верификации API, доступных в той или иной среде исполнения.
- Создание бадла и использование информации о среде исполнения при его разработке.
- Запуск бандлов в различных средах исполнения.

Eclipse RCP: Понятие "возможности" (feature) в Eclipse RCP

Одним из важных понятий платформы Eclipse является понятие "возможности" (feature). Под возможностью понимается логическая группа бандлов, которые рассматриваются как единое целое. Важность понятия "возможность" проистекает из того факта, что механизм обновления и инсталяции программного обеспечения, применяемый в платформе Eclipse, - Eclipse Equinox p2 - позволяет выбирать для установки/обновления только возможности.

Строго говоря, общепринятого перевода данного термина на русский язык не существует, поэтому здесь и далее будет употребляться слово "возможность". Если у вас есть другое мнение по данному вопросу - добро пожаловать в комментарии.

Если бандл является элементом технической декомпозиции, т.к. любое приложение, построенное на платформе Eclipse, с технической точки зрения может рассматриваться как множество бандлов, то возможность - это элемент маркетинговой декомпозиции, позволяющий указать, что некоторая группа бандлов является отдельной функциональностью, созданной разработчиком X, имеющей название Y и решающей тот или иной набор задач. Оперирование при установке/обновлении приложений возможностями, а не бандлами облегчает работу пользователей, т.к. позволяет им оперировать меньшим количеством более крупных компонентов, нежели отдельные бандлы.

При этом необходимо четко понимать, что возможность - это лишь логическое объединение бандлов, она не содержит jar-архивов, а значит один бандл может быть включен в несколько возможностей.

Знакомимся: Tycho - набор плагинов к Maven для сборки OSGi-бандлов и RCP-приложений

Сообщество разработчиков Eclipse не перестает радовать новыми проектами. Об одном из молодых проектов мне бы и хотелось сегодня рассказать. Встречайте - проект Eclipse Tycho - набор плагинов к системе сборки Maven 3, позволяющий собирать OSGi-бандлы и RCP-приложения.

Допустим вполне резонный вопрос: зачем нужна еще одна система сборки для бандлов, если уже есть Eclipse PDE и BND-Tools? Основной особенностью Tycho является то, что он помогает разрешать зависимости, основываясь на файлах манифестов и Eclipse-специфичной метаинформации (файлы plugin.xml и feature.xml), что отличает его от BND-Tools и в тоже время делать это из командной строки с помощью Maven, не требуя установленного и запущенного Eclipse'а, в отличие от PDE. Первая возможность - manifest-based разрешение зависимостей - избавляет от необходимости делать двойную работу: прописывать зависимости в манифесте, а затем еще и в POM-файле. Вторая особенность - интеграция c Maven - позволяет управлять сборкой бандлов/плагинов с помощью систем непрерывной интеграции, например Hudson, а также использовать для разработки другие IDE - не содержащие Eclipse PDE, например IntelliJ IDEA.

Другой приятной возможностью Tycho является управление модульным и интеграционным тестированием в OSGi-среде. Можно создавать бандлы, которые будут содержать JUnit-тесты для плагинов, а Tycho возьмет на себя работу по запуску данных тестов, причем все это будет производиться в стандартном цикле сборки Maven'а. Данная функция аналогична возможности Run as JUnit Plug-in Test, предоставляемой PDE.

И, наконец, Tycho позволяет гибко управлять целевыми платформами, используемыми при сборке и тестировании бандлов/приложений, что облегчает пользователям подключение новых разработчиков к команде, т.к. позволяет не тратить время на решение вопросов вида "где взять тот или иной бандл, требуемый для приложения".

Нет, я не забросил свой дневник

Во-первых, хочется поздравить всех читателей с прошедшим Новым годом.

Во-вторых, тех, кто празднует - с Рождеством.

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



Меня больше ничего не связывает с компанией Наумен, теперь я работаю в Москве. По личным причинам не буду разглашать текущее место работы, могу лишь написать про ряд особенностей: компания занимается как оутсорсингом, так и оутстаффингом. В клиентах компании ходит практически вся деловая Москва: от банков до промышленных предприятий. Проекты самые разные: от разработки учетных систем на базе JavaEE, до проектирования интеграционных решений (в основном на базе продуктов Oracle и IBM, но есть специалисты так же и по технологиям Microsoft). Думаю, что в компании, имеющей такой широкий портфель заказов, мне будет чему научиться.

Т.к. зачастую заказчики требуют присутствия программистов в их офисе, а заказчиков много, то приходится активно перемещаться по самому красивому городу России. Впрочем, есть и минусы: иногда дорога от дома до работы занимает около двух часов.

Немного жалею, что мало уделял внимания изучению систем промышленного уровня (например, WebLogic, SOA Suite, Oracle BPM и т.д.), нужно было меньше внимания уделять легковесным open source фреймворкам. Понятно, что у каждого фреймворка и технологии своя область использования, но умение управлять большими системами ценится выше. С другой стороны спрос на системы действительно промышленного уровня есть далеко не везде, например, в Челябинске я такой работы не видел.

В целом, несмотря на небольшие недостатки (в частности - время, которое приходится тратить на дорогу), я доволен.

Возможно кому-то будет интересно: пригласил меня непосредственно работодатель, сам я работу в Москве не искал. Все общение происходило на МоемКруге и в Скайпе. Там же - в Скайпе - было проведено собеседование. Что мне понравилось: не было мудацких вопросов типа "напишите запрос", разговор был больше "за жизнь". Так как Челябинск для меня так же неродной город, то особо ничего не удерживало. Работодатель же предоставил жилье в Москве, т.е. избавил от необходимости его искать и снимать. Мне кажется, это - идеальные условия для переезда. Если у вас есть вопросы, касающиеся работы в Москве и переезда в Москву, - задавайте их в комментариях.



UPD: Наконец-то решил вопрос с армией - получил честный военник. Взяток никому не давал, все делал по закону. Что могу сказать: не так страшен военкоматовский черт, как его малюют.

UPD2: Часто задают вопрос по поводу блога: почему я пишу мало статей для начинающих. Я понимаю, что это очень характерно для западной блогосферы - кто более Капитан Очевидность - тот и более заслуженный звездун, но это не характерно для русского менталитета. Я писал "статьи" в стиле Капитана, теперь мне за них стыдно, хотя такие статьи и приносят определенный трафик. Решил писать или о результатах каких-то миниисследований (что-то вроде "перелопатил литературу/источники и нашел, что..."), конкретно o своей практике или, в крайнем случае, теорию, но о том, о чем на русском языке писать не принято. Прошу не удивляться, если писать буду существенно меньше. Призываю приводить в комментариях темы, мнение Сурового о которых вам будет интересно.

Еще один момент: я выпилил свои аккаунты в Twitter'e, ВКонтакте (таки да!) и на Хабрахабре (ресурс для людей, озабоченных кармой, и прочих русофобов) ибо нефиг - работать надо.

Понравилось сообщение - подпишитесь на блог

ECF: Выпущен ECF 3.4

После четырех месяцев разработки выпущена версия 3.4 Eclipse Communication Framework.

Eclipse полностью работоспособен c OpenJDK на Mac'ах

Сейчас в интернете активно обсуждается следующая тема: Apple отказывается от поддержки своей JVM. Ситуация интересна тем, что официальной Oracle JVM для MacOS X нет. Замечу, что ситуация несколько напоминает ситуацию, которая сложилась с Microsoft во времена JDK 1.2: корпорация зла распространяла свою версию JVM, которая в лучших традициях Microsoft была не совместима со стандартом. Apple точно так же разрабатывала свою версию JVM, которая со стандартом была совместима, однако имела некие "секретные API" для лучшего взаимодействия с графической подсистемой вендора.

Позиция Apple в целом понятна:
1. Убиваем JDK на платформе Mac.
2. Без JDK не работает Eclipse.
3. Соответственно не работает Android Development Tool.
4. ...
5. Profit!

Однако в данном вопросе Apple просчитались. Eclipse замечательно работает на OpenJDK port - SoyLatte без X11. Известный Eclipse и OSGi евангелист - Neil Bartlett приводит в доказательство скриншот:



Все дело в использовании SWT. Да, OpenJDK не имеет оптимизаций, которые есть в Apple JVM, однако они и не нужны, потому что SWT использует нативный код для отрисовки графики, а не Swing/AWT.

Соответственно, другие приложения, использующие SWT, например RSSOwl, точно так же будут полностью работоспособны, а вот гарантировать полную работоспособность NetBeans и IDEA не представляется возможным.

Понравилось сообщение - подпишитесь на блог