Первое знакомство с Red Hat JBoss Fuse

Здравствуйте, коллеги.

Сегодня проводил семинар в Accenture Riga Delivery Center по поводу интересной для меня темы Red Hat JBoss Fuse и решил поделиться своими впечатлениями от этой сервисной шины с вами.

Что такое Red Hat JBoss Fuse? По сути это - среда исполнения для реализации набора паттернов интеграции корпоративных приложений (Enterprise Application Integration Patterns (EIP)) Apache Camel.

Данная среда исполнения поставляется в двух вариантах:

• Apache Karaf - готовая к промышленному использованию реализация стандарта OSGi.
  
  
• Red Hat JBoss Enterprise Application Platform - широко известный Java EE-совместимый сервер приложений с коммерческой поддержкой. К сожалению, Red Hat JBoss Fuse устанавливается только на версию 6.4.0 данного сервера приложений, реализующую лишь стандарт Java EE 6, что приводит к проблемам, некоторые из которых описаны ниже.
  

"Универсальный сервис", почему заказчики так часто его хотят и почему его делать не нужно

В очередной раз столкнувшись с предложением заказчика "а сделайте мне универсальный транспорт, в котором сообщения будут представлять собой обычные строки, содержащие XML, и который не будет осуществлять никакой валидации/обогащения/мониторинга, но зато я должен иметь возможность включать новые маршруты/преобразования правкой строчек в некоторой конфигурационной базе данных, а да, еще очень хочу чтобы это все было на Oracle Service Bus/IBM WebSphere ESB/IBM WebSphere Message Broker", Суровый решил написать вам о своем отношении к подобным решениям. Статья из серии "не могу молчать".

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

Пример разработки веб-сервиса по контракту с использованием Oracle SOA Suite и Spring Framework

В прошлых заметках мы рассмотрели теоретические вопросы проектирования контракта сервиса и валидации сообщений с помощью XShema и Schematron. В данной статье продемонстрируем использование этих знаний на практике: создадим веб-сервис, основываясь на его контракте. В качестве технологической платформы будем использовать Oracle SOA Suite и Spring Framework.

Разработка контракта сервиса

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

Пример использования Spring Framework совместно с SCA-контейнером Oracle WebLogic

В одной из предыдущих заметок я привел теоретическое описание компонентной архитектуры сервисов (SCA). Однако любая теория требует практического подкрепления, поэтому в данной заметке мы рассмотрим использование SCA-контейнера сервера приложений Oracle WebLogic и Spring Framework для реализации некоторых из довольно часто используемых паттернов интеграции корпоративных приложений (EIP) - Обогатитель данных (Data Enricher) и основанный на нем паттерн Квитанция (Claim Check).

Паттерн Обогатитель данных

Если есть две интегрируемые системы, одна из которых возвращает меньше данных, нежели нужно другой, то такие данные требуется обогащать - добавлять недостающие, получая их из некоторого хранилища. Например, по почтовому индексу, передаваемому системой-источником, можно получить во внешнем хранилище, например в БД КЛАДР, населенный пункт абонента и передать его в систему-приемник. В данном случае Обогатитель данных выступает специальным трансформатором преобразующим сообщение с неполным набором данных в итоговое сообщение. Важным компонентом данного паттерна является внешнее хранилище данных, которое может представлять собой СУБД, некоторое предустановленное корпоративное приложение или публичную службу.

Паттерн Квитанция

Данный паттерн решает следующую проблему: передаваемое через интеграционный слой, например через очередь, сообщение слишком большое, а его обработка осуществляется в несколько шагов. Чтобы не передавать большое сообщение на каждый шаг обработки, что может повлечь снижение производительности системы, можно поступить следующим образом: сохранить сообщение во внешнем хранилище, например в СУБД, а передавать некоторую квитанцию - сообщение, содержащее лишь указатель на сохраненные данные. При этом в том узле, в котором необходимо получить доступ к содержимому сообщения, оно извлекается из хранилища с помощью паттерна Обогатитель данных.