Мотивация проекта Мул была —
-
сделать вещи проще для программистов,
-
потребность в легкомодульном модульном решении, которое может масштабироваться от инфраструктуры обмена сообщениями на уровне приложений до масштабируемой среды масштаба предприятия.
сделать вещи проще для программистов,
потребность в легкомодульном модульном решении, которое может масштабироваться от инфраструктуры обмена сообщениями на уровне приложений до масштабируемой среды масштаба предприятия.
Mule ESB разработан как управляемый событиями, так и программный фреймворк. Он управляется событиями, потому что он объединен с унифицированным представлением сообщений и может быть расширен с помощью подключаемых модулей. Это программно, потому что программисты могут легко внедрить некоторые дополнительные функции, такие как обработка определенных сообщений или преобразование пользовательских данных.
история
Историческая перспектива проекта Мул такова —
Проект SourceForge
Проект Mule был запущен как проект SourceForge в апреле 2003 года, а через 2 года его первая версия была выпущена и перемещена в CodeHaus. Универсальный объект сообщения API (UMO) был в основе своей архитектуры. Идея UMO API заключалась в том, чтобы унифицировать логику, сохраняя их изолированными от основных транспортов.
Версия 1.0
Он был выпущен в апреле 2005 года с многочисленными транспортными средствами. Основное внимание во многих других версиях было уделено отладке и добавлению новых функций.
Версия 2.0 (Принятие Spring 2)
Spring 2 в качестве структуры конфигурации и проводки был принят в Mule 2, но это оказалось серьезной проблемой из-за недостаточной выразительности требуемой конфигурации XML. Эта проблема была решена, когда в Spring 2 была представлена конфигурация на основе XML-схемы.
Здание с Maven
Самым большим улучшением, которое упростило использование Mule как во время разработки, так и во время развертывания, стало использование Maven. Начиная с версии 1.3, он начал создаваться с Maven.
MuleSource
В 2006 году MuleSource был включен «для поддержки и поддержки быстро растущего сообщества, использующего Mule в критически важных корпоративных приложениях». Это оказалось ключевой вехой для проекта Mule.
Конкуренты Mule ESB
Ниже приведены некоторые из основных конкурентов Mule ESB —
- WSO2 ESB
- Сервисная шина Oracle
- WebSphere Message Broker
- Платформа Aurea CX
- Fiorano ESB
- WebSphere DataPower Gateway
- Рабочий день бизнес-процесса
- Сервисная шина Talend Enterprise
- Сервисная шина JBoss Enterprise
- iWay Service Manager
Основная концепция Mule
Как уже говорилось, Mule ESB — это легкая и масштабируемая корпоративная сервисная шина на основе Java (ESB) и платформа интеграции. Независимо от различных технологий, используемых приложениями, Mule ESB обеспечивает простую интеграцию приложений, позволяя им обмениваться данными. В этом разделе мы обсудим ключевую концепцию Mule, которая должна привести к такой интеграции.
Для этого нам нужно понять его архитектуру, а также строительные блоки.
Архитектура
Архитектура Mule ESB имеет три уровня, а именно: транспортный уровень, уровень интеграции и уровень приложений, как показано на следующей диаграмме.
Как правило, для настройки и настройки развертывания Mule можно выполнить следующие три типа задач:
Разработка сервисных компонентов
Эта задача включает разработку или повторное использование существующих POJO или Spring Beans. POJOs — это класс с атрибутами, который генерирует методы get и set, облачные коннекторы. С другой стороны, Spring Beans содержит бизнес-логику для обогащения сообщений.
Сервисное управление
Эта задача в основном обеспечивает сервис-посредник, который включает в себя настройку процессора сообщений, маршрутизаторов, преобразователей и фильтров.
интеграция
Наиболее важной задачей Mule ESB является интеграция различных приложений независимо от используемых ими протоколов. Для этого Mule предоставляет методы транспорта, которые позволяют получать и отправлять сообщения по различным протокольным соединителям. Mule поддерживает множество существующих методов транспорта, или мы также можем использовать собственный метод транспорта.
Строительные блоки
Конфигурация мула имеет следующие строительные блоки —
Весенние бобы
Основное использование Spring bean-компонентов — создание сервисного компонента. После создания компонента службы Spring мы можем определить его через файл конфигурации или вручную, если у вас нет файла конфигурации.
Агенты
В основном это сервис, созданный в Anypoint Studio до Mule Studio. Агент создается при запуске сервера и будет уничтожен при остановке сервера.
соединитель
Это программный компонент, настроенный с параметрами, специфичными для протоколов. Он в основном используется для контроля использования протокола. Например, соединитель JMS сконфигурирован с подключением, и этот соединитель будет совместно использоваться различными объектами, отвечающими за фактическую связь.
Глобальная конфигурация
Как следует из названия, этот строительный блок используется для установки глобальных свойств и настроек.
Глобальные конечные точки
Его можно использовать на вкладке «Глобальные элементы», которую можно использовать столько раз в потоке —
Глобальный процессор сообщений
Как следует из названия, он наблюдает или изменяет сообщение или поток сообщений. Трансформаторы и фильтры являются примерами Глобального обработчика сообщений.
Трансформаторы . Основная задача преобразователя — преобразовывать данные из одного формата в другой. Он может быть определен глобально и может использоваться в нескольких потоках.
Фильтры — это фильтр, который решает, какое сообщение Mule должно быть обработано. Фильтр в основном определяет условия, которые должны быть выполнены, чтобы сообщение было обработано и направлено в службу.
модели
В отличие от Агентов, это логическая группировка сервисов, которые создаются в студии. У нас есть свобода запускать и останавливать все сервисы внутри конкретной модели.
Сервисы — сервисы, которые обертывают нашу бизнес-логику или компоненты. Он также настраивает маршрутизаторы, конечные точки, преобразователи и фильтры специально для этой службы.
Конечные точки — это может быть определено как объект, для которого сервисы будут входить (получать) и исходящие (отправлять) сообщения. Услуги связаны через конечные точки.
поток
Обработчик сообщений использует потоки для определения потока сообщений между источником и целью.
Структура сообщения мулов
Сообщение Mule, полностью заключенное в объект сообщения Mule, представляет собой данные, которые проходят через приложения через потоки Mule. Структура сообщения Мула показана на следующей диаграмме —
Как видно на приведенной выше диаграмме, Mule Message состоит из двух основных частей:
заголовок
Это не что иное, как метаданные сообщения, которые дополнительно представлены следующими двумя свойствами:
Входящие свойства — это свойства, которые автоматически устанавливаются источником сообщения. Они не могут быть изменены или установлены пользователем. В природе входящие свойства неизменны.
Исходящие свойства — это свойства, которые содержат метаданные, например входящее свойство, и могут быть установлены в ходе потока. Они могут быть установлены автоматически Mule или вручную пользователем. В природе исходящие свойства изменчивы.
Исходящие свойства становятся входящими свойствами, когда сообщение переходит от исходящей конечной точки одного потока к входящей конечной точке другого потока через транспорт.
Исходящие свойства остаются исходящими, когда сообщение передается новому потоку через ссылку-поток, а не через соединитель.
полезная нагрузка
Фактическое бизнес-сообщение, переносимое объектом сообщения, называется полезной нагрузкой.
переменные
Он может быть определен как пользовательские метаданные о сообщении. По сути, переменные — это временные фрагменты информации о сообщении, используемые приложением, которое его обрабатывает. Он не предназначен для передачи вместе с сообщениями по назначению. Они бывают трех типов, как указано ниже —
Переменные потока — эти переменные применяются только к потоку, в котором они существуют.
Переменные сеанса — эти переменные применяются ко всем потокам в одном приложении.
Переменные записи — эти переменные применяются только к записям, обработанным как часть пакета.
Вложения и дополнительная полезная нагрузка
Это некоторые дополнительные метаданные о полезной нагрузке сообщения, которые не обязательно появляются каждый раз в объекте сообщения.