Начало работы с Mule ESB

1. обзор

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

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

Сервис создания и хостинга
Служба посредничества
Маршрутизация сообщений
Преобразование данных

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

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

Давайте создадим образец проекта в разделе 5, используяAnyPoint Studio, который доступен для загрузкиhere.

2. Mule Message Structureс

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

Структура сообщения делится на две части:

Заголовок сообщения–, содержащий метаданные сообщения
Полезная нагрузка сообщения, которая содержит специфичные для бизнеса данные

Message is embedded within a message object. Мы можем извлечь объект сообщения из контекста. Мы можем изменить его свойства и полезную нагрузку, используя пользовательские компоненты Java и преобразователи в потоке Mule.

Каждое приложение состоит из одного или нескольких потоков.

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

Например, мы можем получить экземпляр сообщения, используя компонент Java. Этот класс компонентов реализует интерфейсCallable из пакетаorg.mule.api.lifecycle:

public Object onCall(MuleEventContext eventContext) throws Exception {
    MuleMessage message = eventContext.getMessage();
    message.setPayload("Message payload is changed here.");
    return message;
}

3. Свойства и переменные

Метаданные сообщения состоят из свойств. Переменные представляют данные о сообщении. Как свойства и переменные применяются на протяжении жизненного цикла сообщения, определяется их областью действия. Properties can be of two types, based on their scope: inbound and outbound.с

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

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

Мы можем устанавливать и получать исходящие и входящие свойства соответственно, вызывая связанные методы setter и getter в соответствующих областях:

message.setProperty(
  "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND);
String inboundProp = (String) message.getInboundProperty("outboundKey");

Существует два типа переменных, доступных для объявления в приложениях.

Одним из них является переменная потока, которая является локальной для потока Мула и доступна через поток, подпотоки и частные потоки.

Однажды объявленные переменные сеанса становятся доступными во всем приложении.

4. Транспортные барьеры иflow-ref

Транспортными барьерами являются HTTP-соединители, виртуальные машины, JMS или аналогичные соединители, которым требуются пути или конечные точки для маршрутизации сообщений. Flow variables aren’t available across transport barriers, but session variables are available across the project in all flows.с

Когда нам нужно создать подпоток или частный поток, мы можем ссылаться на поток из родительского или другого потока, используя компонентflow-ref. Both flow variables and session variables are available in sub-flows and private flows referred using flow-ref.

5. Пример проекта

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

Давайте посмотрим на первый поток:

Мы можем настроить прослушиватель HTTP как:

Компоненты потока должны быть внутри тега<flow>. Итак, пример потока с несколькими компонентами:

Внутри потока мы предоставляем ссылку на настроенный HTTP-прослушиватель. Затем мы сохраняем регистратор для регистрации полезной нагрузки, которую HTTP-прослушиватель получает через метод POST.

После этого размещается пользовательский класс преобразователя Java, который преобразует полезную нагрузку после получения сообщения:

public Object transformMessage(
  MuleMessage message,
  String outputEncoding) throws TransformerException {

    message.setPayload("Payload is transferred here.");
    message.setProperty(
      "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND);
    return message;
}

The transformer class must extend*AbstractMessageTransformer*. Мы также устанавливаем свойство outbound внутри класса.

Теперь мы уже преобразовали полезную нагрузку внутри объекта сообщения и зарегистрировали ее в консоли с помощью регистратора. Мы устанавливаем переменную потока и переменную сеанса.

Наконец, мы отправляем нашу полезную нагрузку через исходящий соединитель виртуальной машины. The path in VM connector determines the receiving endpoint:с

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

Компонент Java извлекает исходящие свойства, установленные первым потоком, и возвращает объект, который становится полезной нагрузкой сообщения. МетодtransformMessage() для этой задачи:

public Object transformMessage(
  MuleMessage message,
  String outputEncoding) throws TransformerException {

    return (String) message.getInboundProperty("outboundKey");
}

Затем переменные потока и сеанса устанавливаются во второй поток. После этого у нас есть ссылка наFlow2 с использованием компонентаflow-ref.

ВFlow2, мы преобразовали сообщение с помощью класса компонентов Java и занесли его в консоль. Мы также установили переменную потокаF3.

После вызоваFlow2 с использованиемflow-ref, Flow1 будет ждать обработки сообщения вFlow2.

Любая переменная потока, заданная вFlow1 иFlow2, будет доступна в обоих потоках, поскольку эти потоки не разделены никакими транспортными барьерами.

Наконец, сообщение отправляется обратно в HTTP-запросчик через виртуальные машины. Мы настроили все виртуальные машины как запрос-ответ.

Мы можем вызвать это приложение из любого клиента REST, разместив любые данные JSON в теле. URL-адрес будетlocalhost:8081, как настроено в прослушивателе HTTP.

6. Создание проектов с использованием Maven в командной строке

В файлsettings.xml, расположенный в каталоге Maven conf, нам нужно включитьpluginGroup:


    org.mule.tools

Мы также должны указать Maven, где искать репозитории Mule, и это нужно включить в тег профиля:


    Mule Org
    
        true
    
    
        
            mulesoft-releases
            MuleSoft Repository
            https://repository-master.mulesoft.org/releases/
            default
        
        
            mulesoft-snapshots
            MuleSoft Snapshot Repository
            https://repository-master.mulesoft.org/snapshots/
            default

Теперь мы можем легко инициировать проект Maven с помощью команды:

mvn mule-project-archetype:create -DartifactId=muleesb -DmuleVersion=3.8.1

После настройки нашего проекта мы можем создать развертываемый архив с помощью командыmvn package. Теперь мы можем развернуть архив в папкеapps любого автономного сервера Mule.

7. Заключение

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

Теперь мы можем приступить к созданию приложения ESB с использованием Anypoint Studio для удовлетворения наших различных потребностей.

Как обычно, полный проект находится вover on GitHub.

TOC

Начало работы с Mule ESB