MuleESB入門
1. 概要
Mule ESB は、軽量のJavaベースのエンタープライズサービスバスです。 開発者は、さまざまな形式のデータを交換することにより、複数のアプリケーションを相互に接続できます。 メッセージの形でデータを運びます。
ESBは、次のような多くのサービスを提供することにより、強力な機能を提供します。
- サービスの作成とホスティング
- サービス調停
- メッセージルーティング
- データ変換
ESBは、複数のアプリケーションを統合する必要がある場合、または将来的にアプリケーションを追加するという考えがある場合に役立ちます。
ESBは、複数のタイプの通信プロトコルを処理する場合や、メッセージルーティング機能が必要な場合にも使用されます。
AnyPointStudioを使用してセクション5のサンプルプロジェクトを作成しましょう。これはここからダウンロードできます。
2.ミュールメッセージ構造
簡単に言えば、ESBの主な目的は、サービス間を仲介し、メッセージをさまざまなエンドポイントにルーティングすることです。 したがって、さまざまなタイプのコンテンツまたはペイロードを処理する必要があります。
メッセージ構造は2つの部分に分かれています。
- にメッセージメタデータが含まれるヘッダー
- ビジネス固有のデータを含むペイロード
各アプリケーションは、1つ以上のフローで構成されます。
フローでは、コンポーネントを使用して、メッセージとそのさまざまなプロパティにアクセス、フィルタリング、または変更できます。
たとえば、Javaコンポーネントを使用してメッセージのインスタンスを取得できます。 このコンポーネントクラスは、org.mule.api.lifecycleパッケージのCallableインターフェースを実装します。
public Object onCall(MuleEventContext eventContext) throws Exception {
MuleMessage message = eventContext.getMessage();
message.setPayload("Message payload is changed here.");
return message;
}
3. プロパティと変数
メッセージメタデータはプロパティで構成されます。 変数は、メッセージに関するデータを表します。 プロパティと変数がメッセージのライフサイクル全体にどのように適用されるかは、それらのスコープによって定義されます。 プロパティには、スコープに基づいて、インバウンドとアウトバウンドの2つのタイプがあります。
インバウンドプロパティには、フローをトラバースするときにメッセージがスクランブルされるのを防ぐメタデータが含まれています。 インバウンドプロパティは不変であり、ユーザーが変更することはできません。 これらはフローの期間中のみ存在します。メッセージがフローを出ると、インバウンドプロパティは存在しなくなります。
アウトバウンドプロパティは、Muleによって自動的に設定することも、ユーザーがフロー構成を介して設定することもできます。 これらのプロパティは変更可能です。 メッセージがトランスポートバリアを通過した後に別のフローに入ると、これらはインバウンドプロパティになります。
それぞれのスコープで関連するsetterメソッドとgetterメソッドを呼び出すことにより、それぞれアウトバウンドプロパティとインバウンドプロパティを設定および取得できます。
message.setProperty(
"outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND);
String inboundProp = (String) message.getInboundProperty("outboundKey");
アプリケーションで宣言できる変数には2つのタイプがあります。
1つは、Muleフローに対してローカルであり、フロー、サブフロー、およびプライベートフロー全体で使用可能なフロー変数です。
宣言されたセッション変数は、アプリケーション全体で使用できるようになります。
4. 輸送障壁とflow-ref
トランスポートバリアは、メッセージをルーティングするためのパスまたはエンドポイントを必要とするHTTPコネクタ、VM、JMS、または同様のコネクタです。 フロー変数はトランスポートバリアを越えて利用できませんが、セッション変数はすべてのフローでプロジェクト全体で利用できます。
サブフローまたはプライベートフローを作成する必要がある場合は、flow-refコンポーネントを使用して親または別のフローからのフローを参照できます。 フロー変数とセッション変数の両方が、flow-refを使用して参照されるサブフローとプライベートフローで使用できます。
5. サンプルプロジェクト
Anypoint Studioで、インバウンドコネクタとアウトバウンドコネクタを介して相互に通信する複数のフローを含むアプリケーションを作成してみましょう。
最初のフローを見てみましょう。
HTTPリスナーを次のように構成できます。
<http:listener-config name="HTTP_Listener_Configuration"
host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>
フローコンポーネントは内部にある必要があります
<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.baeldung.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;
}
トランスクラスは拡張する必要があります
これで、メッセージオブジェクト内のペイロードがすでに変換され、ロガーを使用してコンソールに記録されました。 フロー変数とセッション変数を設定しています。
最後に、アウトバウンドVMコネクタを介してペイロードを送信しています。 VMコネクタのパスによって受信エンドポイントが決まります:
初期フローによって伝送および変換されたメッセージは、インバウンドVMエンドポイントを介してFlow1に到達します。
Javaコンポーネントは、最初のフローによって設定されたアウトバウンドプロパティを取得し、メッセージペイロードとなるオブジェクトを返します。
このタスクのtransformMessage()メソッド:
public Object transformMessage(
MuleMessage message,
String outputEncoding) throws TransformerException {
return (String) message.getInboundProperty("outboundKey");
}
次に、フロー変数とセッション変数が2番目のフローに設定されます。 その後、flow-refコンポーネントを使用してFlow2への参照を取得します。
Flow2では、 Javaコンポーネントクラスを使用してメッセージを変換し、コンソールに記録しました。 フロー変数F3も設定しました。
電話した後 Flow2 を使用して flow-ref、Flow1 メッセージが処理されるのを待ちます Flow2
Flow1およびFlow2で設定されたフロー変数は、これらのフローがトランスポートバリアによって分離されていないため、両方のフローで使用できます。
最後に、メッセージはVMを介してHTTPリクエスターに返送されます。 すべてのVMを要求/応答として構成しました。
本文にJSONデータを投稿することで、RESTクライアントからこのアプリケーションを呼び出すことができます。 URLは、HTTPリスナーで構成されている localhost:8081になります。
6. Mavenアーキタイプ
MulesoftのMavenアーキタイプを使用してMuleESBプロジェクトを構築できます。
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サーバーのappsフォルダーにアーカイブをデプロイします。
7. MuleSoftのMavenリポジトリを介したスタンドアロンMuleサーバー
先ほど述べたように、作成したプロジェクトにはスタンドアロンの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. 結論
この記事では、MuleでESBアプリケーションとして構築するために必要なさまざまな概念について説明しました。 説明されているすべての概念を示すサンプルプロジェクトを作成しました。
これで、Anypoint Studioを使用してESBアプリケーションの作成を開始し、さまざまなニーズを満たすことができます。
いつものように、完全なプロジェクトはGitHubでにあります。