Mulesoft-the-mule-project
MuleSoft-Muleプロジェクト
Muleプロジェクトの背後にある動機は-
- プログラマーのために物事を簡単にするために、
- アプリケーションレベルのメッセージングフレームワークから企業全体の高度に分散可能なフレームワークまで拡張できる軽量でモジュール式のソリューションの必要性。
ESB Muleは、プログラム駆動型のフレームワークと同様にイベント駆動型のフレームワークとして設計されています。 メッセージの統一表現と組み合わされ、プラグ可能なモジュールで拡張できるため、イベント駆動型です。 プログラマーは、特定のメッセージ処理やカスタムデータ変換などの追加の動作を簡単に埋め込むことができるため、プログラム的です。
歴史
Muleプロジェクトの歴史的展望は次のとおりです-
SourceForgeプロジェクト
MuleプロジェクトはSourceForgeプロジェクトとして2003年4月に開始され、2年後にその最初のバージョンがリリースされ、CodeHausに移行されました。 ユニバーサルメッセージオブジェクト（UMO）APIは、そのアーキテクチャの中核でした。 UMO APIの背後にある考え方は、基礎となるトランスポートから隔離されたまま、ロジックを統合することでした。
バージョン1.0
2005年4月にリリースされ、多数のトランスポートが含まれていました。 それに続く多くの他のバージョンの主な焦点は、デバッグと新しい機能の追加にありました。
バージョン2.0（Spring 2の採用）
Mule 2では、構成および配線フレームワークとしてのSpring 2が採用されましたが、必要なXML構成の表現力が不足しているため、大幅なオーバーホールであることが判明しました。 この問題は、XML Schemaベースの構成がSpring 2で導入されたときに解決されました。
Mavenを使用した構築
Muleの使用を開発時とデプロイ時の両方で簡素化した最大の改善は、Mavenの使用でした。 バージョン1.3から、Mavenでの構築が開始されました。
MuleSource
2006年、MuleSourceは「ミッションクリティカルなエンタープライズアプリケーションでMuleを使用して急速に成長しているコミュニティをサポートし、有効にするために」組み込まれました。 Muleプロジェクトの重要なマイルストーンであることが証明されました。
ESB Mule ESBのライバル
Mule ESBの主要な競合他社の一部を次に示します-
- WSO2 ESB
- Oracle Service Bus
- WebSphere Message Broker
- Aurea CXプラットフォーム
- フィオラノESB
- WebSphere DataPower Gateway
- Workday Business Process Framework
- Talend Enterprise Service Bus
- JBoss Enterprise Service Bus
- iWayサービスマネージャー
Muleのコアコンセプト
前述のように、ESB Muleは軽量で拡張性の高いJavaベースのエンタープライズサービスバス（ESB）および統合プラットフォームです。 Mule ESBを使用すると、アプリケーションで使用されるさまざまなテクノロジーに関係なく、アプリケーションを簡単に統合して、データを交換できます。 このセクションでは、このような統合を実現するために登場するMuleのコアコンセプトについて説明します。
そのためには、そのアーキテクチャとビルディングブロックを理解する必要があります。
建築
ESB Muleのアーキテクチャには、次の図に示すように、トランスポート層、統合層、アプリケーション層の3つの層があります-
一般的に、ESB Muleのデプロイを設定およびカスタマイズするために実行できるタスクには、次の3つのタイプがあります-
サービスコンポーネントの開発
このタスクには、既存のPOJOまたはSpring Beanの開発または再利用が含まれます。 POJOは、getおよびsetメソッド、クラウドコネクタを生成する属性を持つクラスです。 一方、Spring Beanには、メッセージを充実させるビジネスロジックが含まれています。
サービスオーケストレーション
このタスクは、基本的に、メッセージプロセッサ、ルーター、トランスフォーマー、フィルターの構成を伴うサービスメディエーションを提供します。
統合
ESB Mule ESBの最も重要なタスクは、使用しているプロトコルに関係なく、さまざまなアプリケーションを統合することです。 この目的のために、Muleはさまざまなプロトコルコネクタでメッセージを受信およびディスパッチできるトランスポートメソッドを提供します。 ESB Muleは多くの既存のトランスポート方法をサポートしていますが、カスタムのトランスポート方法を使用することもできます。
ビルディングブロック
ESB Muleの構成には次の構成要素があります-
春豆
Spring Beanの主な用途は、サービスコンポーネントの構築です。 Spring Serviceコンポーネントを構築した後、設定ファイルがない場合は、設定ファイルを介して、または手動で定義できます。
エージェント
これは基本的に、Mule Studioの前にAnypoint Studioで作成されたサービスです。 サーバーを起動するとエージェントが作成され、サーバーを停止するとエージェントが破棄されます。
コネクタ
これは、プロトコルに固有のパラメーターで構成されたソフトウェアコンポーネントです。 主にプロトコルの使用を制御するために使用されます。 たとえば、JMSコネクタは Connection で構成され、このコネクタは実際の通信を担当するさまざまなエンティティ間で共有されます。
グローバル構成
名前が示すとおり、このビルディングブロックはグローバルプロパティと設定を設定するために使用されます。
グローバルエンドポイント
フローで何度も使用できるグローバル要素タブで使用できます-
グローバルメッセージプロセッサ
名前が示すように、メッセージまたはメッセージフローを監視または変更します。 トランスフォーマーとフィルターは、グローバルメッセージプロセッサの例です。
- トランスフォーマー-トランスフォーマーの主な仕事は、データをある形式から別の形式に変換することです。 グローバルに定義でき、複数のフローで使用できます。
フィルター-どのMuleメッセージを処理するかを決定するのはフィルターです。 フィルタは基本的に、メッセージが処理されてサービスにルーティングされるために満たす必要がある条件を指定します。
モデル
エージェントとは対照的に、それはスタジオで作成されるサービスの論理的なグループです。 特定のモデル内のすべてのサービスを開始および停止する自由があります。
サービス-サービスは、ビジネスロジックまたはコンポーネントをラップするものです。 また、そのサービス専用にルーター、エンドポイント、トランスフォーマー、フィルターも構成します。
エンドポイント-サービスがメッセージを受信（受信）および送信（送信）するオブジェクトとして定義できます。 サービスはエンドポイントを介して接続されます。
Flow
メッセージプロセッサは、フローを使用して、ソースとターゲット間のメッセージフローを定義します。
ラバのメッセージ構造
Muleメッセージオブジェクトの下に完全にラップされたMuleメッセージは、Muleフローを介してアプリケーションを通過するデータです。 構造ミュールのメッセージは、次の図に示されています-
上の図に見られるように、Muleメッセージは2つの主要な部分で構成されています-
ヘッダ
それはさらに次の2つのプロパティによって表されるメッセージのメタデータにすぎません-
インバウンドプロパティ-これらは、メッセージソースによって自動的に設定されるプロパティです。 ユーザーが操作または設定することはできません。 本来、インバウンドプロパティは不変です。
アウトバウンドプロパティ-これらは、インバウンドプロパティなどのメタデータを含むプロパティであり、フローの過程で設定できます。 Muleが自動的に設定するか、ユーザーが手動で設定できます。 本質的に、送信プロパティは変更可能です。
メッセージがトランスポートを介して、あるフローのアウトバウンドエンドポイントから別のフローのインバウンドエンドポイントに渡されると、アウトバウンドプロパティはインバウンドプロパティになります。
メッセージがコネクタではなくflow-refを介して新しいフローに渡される場合、送信プロパティは送信プロパティのままです。
ペイロード
メッセージオブジェクトによって運ばれる実際のビジネスメッセージは、ペイロードと呼ばれます。
変数
メッセージに関するユーザー定義のメタデータとして定義できます。 基本的に、変数は、メッセージを処理しているアプリケーションで使用されるメッセージに関する一時的な情報です。 メッセージとともに宛先に渡されることを意図していません。 それらは以下に示すように3つのタイプがあります-
フロー変数-これらの変数は、それらが存在するフローにのみ適用されます。
セッション変数-これらの変数は、同じアプリケーション内のすべてのフローに適用されます。
レコード変数-これらの変数は、バッチの一部として処理されるレコードにのみ適用されます。
添付ファイルと追加のペイロード
これらは、メッセージペイロードに関する追加のメタデータであり、必ずしもメッセージオブジェクトに毎回表示されるとは限りません。
