1. Обзор
Mule ESB — это облегченная корпоративная служебная шина на основе Java. Это позволяет разработчикам соединять несколько приложений вместе, обмениваясь данными в разных форматах. Он несет данные в виде сообщения.
ESB предлагают мощные возможности, предоставляя ряд услуг, таких как:
- Создание сервиса и хостинг
- Сервисное посредничество
- Маршрутизация сообщений
- Преобразование данных
Мы найдем ESB полезными, если нам нужно интегрировать несколько приложений вместе или если у нас есть идея добавить больше приложений в будущем.
ESB также используется для работы с несколькими типами коммуникационных протоколов и когда требуются возможности маршрутизации сообщений.
Давайте создадим пример проекта в Разделе 5, используя AnyPoint Studio , который можно скачать здесь .
2. Структура сообщения мула
Проще говоря, основной целью ESB является посредничество между службами и маршрутизация сообщений к различным конечным точкам. Поэтому ему нужно иметь дело с различными типами контента или полезной нагрузки.
Структура сообщения делится на две части:
- Заголовок, ** ** содержащий метаданные сообщения .
- Полезная нагрузка, содержащая специфические для бизнеса данные.
Сообщение встроено в объект сообщения. Мы можем получить объект сообщения из контекста. Мы можем изменить его свойства и полезную нагрузку, используя пользовательские компоненты 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. Свойства и переменные
Метаданные сообщения состоят из свойств. Переменные представляют данные о сообщении. Применение свойств и переменных в жизненном цикле сообщения определяется их областями действия. Свойства могут быть двух типов в зависимости от их области действия: входящие и исходящие.
Свойства входящих сообщений содержат метаданные, которые предотвращают шифрование сообщений при перемещении между потоками. Входящие свойства являются неизменяемыми и не могут быть изменены пользователем. Они присутствуют только на время потока — как только сообщение выходит из потока, входящие свойства больше не существуют.
Исходящие свойства могут быть установлены Mule автоматически, или пользователь может установить их через конфигурацию потока. Эти свойства изменчивы. Они становятся входящими свойствами, когда сообщение входит в другой поток после пересечения транспортных барьеров.
Мы можем установить и получить исходящие и входящие свойства соответственно, вызвав соответствующие методы установки и получения в их соответствующих областях:
message.setProperty(
"outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND);
String inboundProp = (String) message.getInboundProperty("outboundKey");
Существует два типа переменных, доступных для объявления в приложениях.
Одной из них является переменная потока, которая является локальной для потока Mule и доступна в потоке, подпотоках и частных потоках.
Переменные сеанса после объявления становятся доступными во всем приложении.
4. Транспортные барьеры и реф .
Транспортные барьеры — это HTTP-коннекторы, виртуальные машины, JMS или аналогичные коннекторы, которым требуются пути или конечные точки для маршрутизации сообщений. Переменные потока недоступны через транспортные барьеры, но переменные сеанса доступны в рамках проекта во всех потоках.
Когда нам нужно создать подпоток или частный поток, мы можем обратиться к потоку из родительского или другого потока, используя компонент потока-ссылки . И переменные потока, и переменные сеанса доступны в подпотоках и частных потоках, на которые ссылается поток-ref .
5. Пример проекта
Давайте создадим приложение в Anypoint Studio, содержащее несколько потоков, которые взаимодействуют между собой через входящие и исходящие соединители.
Давайте посмотрим на первый поток:
Мы можем настроить прослушиватель HTTP как:
<http:listener-config name="HTTP_Listener_Configuration"
host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>
Компоненты потока должны находиться внутри тега <flow> . Итак, пример потока с несколькими компонентами:
<flow name="Flow">
<http:listener
config-ref="HTTP_Listener_Configuration"
path="/" doc:name="HTTP"
allowedMethods="POST"/>
<logger message="Original
paylaod: #[payload]"
level="INFO" doc:name="Logger"/>
<custom-transformer
class="com.foreach.transformer.InitializationTransformer"
doc:name="Java"/>
<logger message="Payload After Initialization: #[payload]"
level="INFO" doc:name="Logger"/>
<set-variable variableName="f1"
value="#['Flow Variable 1']" doc:name="F1"/>
<set-session-variable variableName="s1"
value="#['Session variable 1']" doc:name="S1"/>
<vm:outbound-endpoint exchange-pattern="request-response"
path="test" doc:name="VM"/>
</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;
}
Класс преобразователя должен расширять AbstractMessageTransformer . Мы также устанавливаем исходящее свойство внутри класса.
Теперь мы уже преобразовали полезную нагрузку внутри объекта сообщения и зарегистрировали это в консоли с помощью регистратора. Мы устанавливаем переменную потока и переменную сеанса.
Наконец, мы отправляем нашу полезную нагрузку через исходящий коннектор виртуальной машины. Путь в коннекторе виртуальной машины определяет принимающую конечную точку:
Сообщение, переданное и преобразованное исходным потоком, достигает потока 1 через входящую конечную точку виртуальной машины.
Компонент 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 .
Любая переменная потока, установленная в потоках 1 и 2 , будет доступна в обоих потоках, поскольку эти потоки не разделены никакими транспортными барьерами.
Наконец, сообщение отправляется обратно запрашивающему HTTP через виртуальные машины. Мы настроили все виртуальные машины как запрос-ответ.
Мы можем вызвать это приложение из любого клиента REST, разместив в теле любые данные JSON. URL-адрес будет localhost:8081 , как настроено в прослушивателе HTTP.
6. Архетип Знатока
Мы можем построить проект Mule ESB, используя архетип Mulesoft Maven.
В файле Maven settings.xml нам сначала нужно добавить группу плагинов org.mule.tools :
<pluginGroups>
<pluginGroup>org.mule.tools</pluginGroup>
</pluginGroups>
Затем нам нужно добавить тег профиля , в котором указано, где Maven должен искать артефакты Mulesoft:
<profile>
<id>Mule Org</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<id>mulesoft-releases</id>
<name>MuleSoft Repository</name>
<url>https://repository.mulesoft.org/releases/</url>
<layout>default</layout>
</repository>
</repositories>
</profile>
Наконец, мы можем создать проект, используя mule-project-archetype:create :
mvn mule-project-archetype:create -DartifactId=muleesb -DmuleVersion=3.9.0
После настройки нашего проекта мы можем создать развертываемый архив с помощью пакета mvn .
После этого мы развернули архив в папку приложений любого автономного сервера Mule.
7. Автономный сервер Mule через репозиторий MuleSoft Maven.
Как только что было отмечено, для только что созданного нами проекта требуется автономный сервер Mule .
Если у нас его еще нет, мы можем отредактировать наш pom.xml , чтобы получить его из репозитория MuleSoft Maven :
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>2.2.1</version>
<configuration>
<deploymentType>standalone</deploymentType>
<muleVersion>3.9.0</muleVersion>
</configuration>
<executions>
<execution>
<id>deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
8. Заключение
В этой статье мы рассмотрели различные необходимые концепции построения приложения ESB в Mule. Мы создали типовой проект, иллюстрирующий все описанные концепции.
Теперь мы можем приступить к созданию приложения ESB с помощью Anypoint Studio для удовлетворения наших различных потребностей.
Как обычно, полный проект можно найти на GitHub .