MuleSoft - Проект Мул

Мотивами проекта Mule были:

чтобы упростить работу программистов,
потребность в легковесном и модульном решении, которое можно масштабировать от инфраструктуры обмена сообщениями на уровне приложений до широко распространяемой инфраструктуры предприятия.

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

История

Историческая перспектива проекта Mule такова:

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 Project.

Конкуренты Mule ESB

Ниже приведены некоторые из основных конкурентов Mule ESB.

WSO2 ESB
Сервисная шина Oracle
WebSphere Message Broker
Платформа Aurea CX
Фьорано ESB
WebSphere DataPower Gateway
Структура бизнес-процессов рабочего дня
Сервисная шина Talend Enterprise
Сервисная шина JBoss Enterprise
Менеджер по обслуживанию iWay

Основная концепция мула

Как уже говорилось, Mule ESB - это легкая и хорошо масштабируемая служебная шина предприятия (ESB) и платформа интеграции на основе Java. Независимо от различных технологий, используемых приложениями, Mule ESB обеспечивает простую интеграцию приложений, позволяя им обмениваться данными. В этом разделе мы обсудим основную концепцию Mule, которая поможет реализовать такую интеграцию.

Для этого нам нужно понять его архитектуру, а также составные части.

Архитектура

Архитектура Mule ESB имеет три уровня, а именно транспортный уровень, уровень интеграции и уровень приложения, как показано на следующей диаграмме:

Как правило, для настройки и настройки развертывания Mule можно выполнить следующие три типа задач:

Разработка сервисных компонентов

Эта задача включает разработку или повторное использование существующих POJO или Spring Beans. POJOs - это класс с атрибутами, который генерирует методы получения и установки, облачные соединители. С другой стороны, Spring Beans содержит бизнес-логику для обогащения сообщений.

Сервисная оркестровка

Эта задача в основном обеспечивает посредничество служб, которое включает настройку процессора сообщений, маршрутизаторов, преобразователей и фильтров.

Интеграция

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

Строительные блоки

Конфигурация мула имеет следующие строительные блоки -

Весенние бобы

Основное использование компонентов Spring - создание служебного компонента. После создания компонента службы Spring мы можем определить его через файл конфигурации или вручную, если у вас нет файла конфигурации.

Агенты

По сути, это сервис, созданный в Anypoint Studio до Mule Studio. Агент создается при запуске сервера и будет уничтожен после остановки сервера.

Коннектор

Это программный компонент, настроенный с параметрами, специфичными для протоколов. Он в основном используется для управления использованием протокола. Например, коннектор JMS настроен сConnection и этот соединитель будет совместно использоваться различными организациями, отвечающими за фактическую связь.

Глобальная конфигурация

Как следует из названия, этот строительный блок используется для установки глобальных свойств и настроек.

Глобальные конечные точки

Его можно использовать на вкладке Global Elements, которую можно использовать сколько угодно раз в потоке -

Глобальный процессор сообщений

Как следует из названия, он наблюдает или изменяет сообщение или поток сообщений. Трансформаторы и фильтры являются примерами Global Message Processor.

Transformers- Основная задача преобразователя - преобразовывать данные из одного формата в другой. Его можно определить глобально и использовать в нескольких потоках.

Filters- Это фильтр, который решит, какое сообщение Mule следует обработать. Фильтр в основном определяет условия, которые должны быть выполнены, чтобы сообщение было обработано и направлено в службу.

Модели

В отличие от Агентов, это логическая группировка сервисов, которые создаются в студии. У нас есть свобода запускать и останавливать все службы внутри конкретной модели.

Services- Сервисы - это те, которые обертывают нашу бизнес-логику или компоненты. Он также настраивает маршрутизаторы, конечные точки, преобразователи и фильтры специально для этой службы.

Endpoints- Его можно определить как объект, на котором службы будут получать входящие (получать) и исходящие (отправлять) сообщения. Услуги подключаются через конечные точки.

поток

Обработчик сообщений использует потоки для определения потока сообщений между источником и целью.

Структура сообщения Mule

Сообщение Mule, полностью заключенное в объект сообщения Mule, - это данные, которые проходят через приложения через потоки Mule. Структура сообщения Мула показана на следующей диаграмме -

Как видно на диаграмме выше, Mule Message состоит из двух основных частей:

Заголовок

Это не что иное, как метаданные сообщения, которые дополнительно представлены следующими двумя свойствами:

Inbound Properties- Это свойства, которые автоматически устанавливаются источником сообщения. Пользователь не может управлять ими или устанавливать их. По своей природе входящие свойства неизменны.

Outbound Properties- Это свойства, которые содержат метаданные, такие как входящее свойство, и могут устанавливаться в процессе выполнения. Они могут быть установлены автоматически Mule или вручную пользователем. По своей природе исходящие свойства изменчивы.

Исходящие свойства становятся входящими свойствами, когда сообщение проходит от исходящей конечной точки одного потока к входящей конечной точке другого потока через транспорт.

Исходящие свойства остаются исходящими свойствами, когда сообщение передается в новый поток через ссылку на поток, а не через соединитель.

Полезная нагрузка

Фактическое бизнес-сообщение, переносимое объектом сообщения, называется полезной нагрузкой.

Переменные

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

Flow variables - Эти переменные применяются только к потоку, в котором они существуют.

Session variables - Эти переменные применяются ко всем потокам в одном приложении.

Record variables - Эти переменные применяются только к записям, обрабатываемым как часть пакета.

Вложения и дополнительная полезная нагрузка

Это дополнительные метаданные о полезной нагрузке сообщения, которая не обязательно появляется каждый раз в объекте сообщения.