MuleSoft-ミュールプロジェクト

Muleプロジェクトの背後にある動機は次のとおりです。

プログラマーにとって物事をより簡単にするために、
アプリケーションレベルのメッセージングフレームワークから企業全体の高度に分散可能なフレームワークに拡張できる軽量でモジュール式のソリューションの必要性。

Mule ESBは、イベント駆動型およびプログラム型のフレームワークとして設計されています。メッセージの統一された表現と組み合わされ、プラグ可能なモジュールで拡張できるため、イベント駆動型です。プログラマーは特定のメッセージ処理やカスタムデータ変換などの追加の動作を簡単に組み込むことができるため、これはプログラマティックです。

歴史

Muleプロジェクトの歴史的展望は次のとおりです。

SourceForgeプロジェクト

Muleプロジェクトは2003年4月にSourceForgeプロジェクトとして開始され、2年後に最初のバージョンがリリースされ、CodeHausに移行されました。ユニバーサルメッセージオブジェクト（UMO）APIは、そのアーキテクチャの中核でした。UMO APIの背後にある考え方は、基盤となるトランスポートからロジックを分離したまま、ロジックを統合することでした。

バージョン1.0

2005年4月にリリースされ、多数のトランスポートが含まれています。それに続く他の多くのバージョンの主な焦点は、デバッグと新機能の追加でした。

バージョン2.0（Spring 2の採用）

構成および配線フレームワークとしてSpring2がMule2で採用されましたが、必要なXML構成の表現力が不足しているため、大幅なオーバーホールであることが判明しました。この問題は、Spring2でXMLスキーマベースの構成が導入されたときに解決されました。

Mavenを使用した構築

開発時とデプロイ時の両方でMuleの使用を簡素化した最大の改善点は、Mavenの使用でした。バージョン1.3から、Mavenで構築され始めました。

MuleSource

2006年、MuleSourceは、「ミッションクリティカルなエンタープライズアプリケーションでMuleを使用して急速に成長するコミュニティをサポートおよび有効化するために」組み込まれました。これは、Muleプロジェクトの重要なマイルストーンであることが証明されました。

MuleESBの競合他社

以下は、MuleESBの主要な競合他社の一部です-

WSO2 ESB
Oracle Service Bus
WebSphere Message Broker
AureaCXプラットフォーム
フィオラノESB
WebSphere DataPower Gateway
Workdayビジネスプロセスフレームワーク
Talendエンタープライズサービスバス
JBoss Enterprise Service Bus
iWayサービスマネージャー

ミュールのコアコンセプト

説明したように、Mule ESBは、軽量で拡張性の高いJavaベースのエンタープライズサービスバス（ESB）および統合プラットフォームです。アプリケーションで使用されるさまざまなテクノロジーに関係なく、Mule ESBを使用すると、アプリケーションを簡単に統合して、データを交換できます。このセクションでは、このような統合を実現するために機能するMuleのコアコンセプトについて説明します。

このためには、そのアーキテクチャとビルディングブロックを理解する必要があります。

建築

Mule ESBのアーキテクチャには、次の図に示すように、トランスポート層、統合層、アプリケーション層の3つの層があります。

一般に、Muleデプロイメントを構成およびカスタマイズするために実行できるタスクには次の3つのタイプがあります-

サービスコンポーネントの開発

このタスクには、既存のPOJOまたはSpringBeanの開発または再利用が含まれます。POJOは、getメソッドとsetメソッド、クラウドコネクタを生成する属性を持つクラスです。一方、Spring Beansには、メッセージを充実させるためのビジネスロジックが含まれています。

サービスオーケストレーション

このタスクは基本的に、メッセージプロセッサ、ルーター、トランスフォーマー、およびフィルターの構成を含むサービスメディエーションを提供します。

統合

Mule ESBの最も重要なタスクは、使用しているプロトコルに関係なく、さまざまなアプリケーションを統合することです。この目的のために、Muleは、さまざまなプロトコルコネクタでメッセージを受信およびディスパッチできるようにするトランスポートメソッドを提供します。Muleは多くの既存の転送方法をサポートしていますが、カスタムの転送方法を使用することもできます。

ビルディングブロック

ミュール構成には次のビルディングブロックがあります-

春の豆

Spring Beanの主な用途は、サービスコンポーネントを構築することです。Spring Serviceコンポーネントを構築した後、構成ファイルを介して、または構成ファイルがない場合は手動で定義できます。

エージェント

これは基本的に、MuleStudioの前にAnypointStudioで作成されたサービスです。エージェントは、サーバーを起動すると作成され、サーバーを停止すると破棄されます。

コネクタ

これは、プロトコルに固有のパラメーターで構成されたソフトウェアコンポーネントです。これは主にプロトコルの使用を制御するために使用されます。たとえば、JMSコネクタはConnection このコネクタは、実際の通信を担当するさまざまなエンティティ間で共有されます。

グローバル構成

名前が示すように、このビルディングブロックは、グローバルプロパティと設定を設定するために使用されます。

グローバルエンドポイント

フロー内で何度でも使用できる[グローバル要素]タブで使用できます-

グローバルメッセージプロセッサ

名前が示すように、メッセージまたはメッセージフローを監視または変更します。トランスフォーマーとフィルターは、グローバルメッセージプロセッサーの例です。

Transformers−トランスフォーマーの主な仕事は、データをある形式から別の形式に変換することです。グローバルに定義でき、複数のフローで使用できます。

Filters−どのMuleメッセージを処理するかを決定するのはフィルターです。フィルタは基本的に、メッセージが処理されてサービスにルーティングされるために満たす必要のある条件を指定します。

モデル

エージェントとは対照的に、これはスタジオで作成されるサービスの論理的なグループです。特定のモデル内のすべてのサービスを開始および停止する自由があります。

Services−サービスは、ビジネスロジックまたはコンポーネントをラップするサービスです。また、そのサービス専用にルーター、エンドポイント、トランスフォーマー、フィルターを構成します。

Endpoints−サービスがメッセージを受信（受信）および送信（送信）するオブジェクトとして定義できます。サービスはエンドポイントを介して接続されます。

フロー

メッセージプロセッサはフローを使用して、ソースとターゲット間のメッセージフローを定義します。

Muleメッセージの構造

Muleメッセージオブジェクトで完全にラップされたMuleメッセージは、Muleフローを介してアプリケーションを通過するデータです。構造Muleのメッセージを次の図に示します-

上の図に見られるように、Muleメッセージは2つの主要な部分で構成されています-

ヘッダ

これは、メッセージのメタデータに他なりません。これは、次の2つのプロパティによってさらに表されます。

Inbound Properties−これらは、メッセージソースによって自動的に設定されるプロパティです。ユーザーが操作または設定することはできません。自然界では、インバウンドプロパティは不変です。

Outbound Properties−これらは、インバウンドプロパティなどのメタデータを含むプロパティであり、フローの過程で設定できます。これらは、Muleによって自動的に設定することも、ユーザーが手動で設定することもできます。本質的に、アウトバウンドプロパティは変更可能です。

メッセージがトランスポートを介して、あるフローのアウトバウンドエンドポイントから別のフローのインバウンドエンドポイントに渡されると、アウトバウンドプロパティはインバウンドプロパティになります。

メッセージがコネクタではなくflow-refを介して新しいフローに渡される場合、アウトバウンドプロパティはアウトバウンドプロパティのままです。

ペイロード

メッセージオブジェクトによって運ばれる実際のビジネスメッセージは、ペイロードと呼ばれます。

変数

これは、メッセージに関するユーザー定義のメタデータとして定義できます。基本的に、変数は、メッセージを処理しているアプリケーションによって使用されるメッセージに関する一時的な情報です。メッセージと一緒に宛先に渡されることを意図したものではありません。以下の3種類があります−

Flow variables −これらの変数は、それらが存在するフローにのみ適用されます。

Session variables −これらの変数は、同じアプリケーション内のすべてのフローに適用されます。

Record variables −これらの変数は、バッチの一部として処理されるレコードにのみ適用されます。

添付ファイルと追加のペイロード

これらは、メッセージペイロードに関するいくつかの追加のメタデータであり、必ずしもメッセージオブジェクトに毎回表示されるとは限りません。