- MuleSoft 教程
- MuleSoft - 主頁
- MuleSoft - Mule ESB 介紹
- MuleSoft - Mule專案
- MuleSoft - 我們機器上的 Mule
- MuleSoft - Anypoint Studio
- MuleSoft - 發現 Anypoint Studio
- 建立第一個 Mule 應用程式
- MuleSoft - DataWeave 語言
- 訊息處理器和指令碼元件
- 核心元件及其配置
- MuleSoft - 端點
- 流控制和轉換器
- 使用 Anypoint Studio 的 Web 服務
- MuleSoft - Mule 錯誤處理
- MuleSoft - Mule 異常處理
- MuleSoft - 使用 MUnit 測試
- MuleSoft 有用資源
- MuleSoft - 快速指南
- MuleSoft - 有用資源
- MuleSoft - 討論
MuleSoft - Mule專案
Mule 專案背後的動機是 -
為程式設計師簡化工作,
需要輕量級、模組化的解決方案,該解決方案可以從應用程式級訊息傳遞框架擴充套件到企業級高度可分配框架。
Mule ESB 被設計為一個事件驅動的同時也是一個程式設計框架。它之所以是事件驅動的,是因為它與統一的訊息表示相結合,並可以透過可插拔模組進行擴充套件。它之所以是程式設計性的,是因為程式設計師可以輕鬆地植入一些附加行為,如特定訊息處理或自定義資料轉換。
歷史
Mule 專案的歷史視角如下 -
SourceForge 專案
Mule 專案於 2003 年 4 月啟動,作為 SourceForge 專案,並且在其首個版本釋出並移至 CodeHaus 2 年之後。通用訊息物件 (UMO) API 是其架構的核心。UMO API 背後的想法是在將邏輯統一起來的同時,將其與底層傳輸保持隔離。
1.0 版
該版本於 2005 年 4 月釋出,其中包含許多傳輸。隨後的許多其他版本的關鍵重點在於除錯和新增新功能。
2.0 版(採用 Spring 2)
Spring 2 作為配置和接線框架在 Mule 2 中被採用,但由於缺少所需的 XML 配置的可表達性,這被證明是一個重大的改進。在 Spring 2 中引入基於 XML 模式的配置時,這個問題得到了解決。
透過 Maven 構建
簡化 Mule 使用的最大改進(在開發和部署時間)是使用 Maven。從 1.3 版本開始,它開始透過 Maven 構建。
MuleSource
2006 年,MuleSource 成立,“以幫助支援和幫助快速增長的社群在關鍵任務企業應用程式中使用 Mule”。它被證明是 Mule 專案的一個關鍵里程碑。
Mule ESB 的競爭對手
以下是 Mule ESB 的一些主要競爭對手 -
- WSO2 ESB
- Oracle 服務匯流排
- WebSphere 訊息代理
- Aurea CX 平臺
- Fiorano ESB
- WebSphere DataPower Gateway
- Workday 業務流程框架
- Talend 企業服務匯流排
- JBoss 企業服務匯流排
- iWay 服務管理器
Mule 的核心概念
如前所述,Mule ESB 是一款輕量且高度可擴充套件的基於 Java 的企業服務匯流排 (ESB) 和整合平臺。Mule ESB 無論應用程式使用何種技術,都能輕鬆整合應用程式,使應用程式之間能夠交換資料。在本節中,我們將討論使此類整合得以實現的 Mule 核心概念。
為此,我們需要了解其架構和構建基塊。
架構
Mule ESB 架構包含三層,即傳輸層、整合層和應用程式層,如下所示 −
通常,可以執行以下三類任務來配置和自定義 Mule 部署 −
服務元件開發
此任務涉及開發或重新使用現有 POJO 或 Spring Bean。POJO 是一個包含生成 get 和 set 方法以及雲聯結器的帶有屬性的類。而 Spring Bean 則包含用於豐富訊息的業務邏輯。
服務編排
此任務基本提供服務中介,涉及配置訊息處理器、路由器、轉換器和篩選器。
整合
Mule ESB 最重要的任務是整合各種應用程式,無論它們使用何種協議。為此,Mule 提供傳輸方法,允許在各種協議聯結器之上接收和分派訊息。Mule 支援許多現有傳輸方法,我們也可以使用自定義傳輸方法。
構建基塊
Mule 配置具有以下構建基塊 −
Spring Bean
Spring Bean 的主要用途是構建服務元件。構建 Spring 服務元件後,我們可以透過配置檔案對它進行定義,或者在沒有配置檔案的情況下手動進行定義。
代理
它基本上是在 Mule Studio 之前在 Anypoint Studio 中建立的服務。代理是在啟動伺服器後建立的,在停止伺服器後將被摧毀。
聯結器
它是一個配置有特定於協議的引數的軟體元件。它主要用於控制協議的使用。例如,JMS 聯結器已配置有一個“連線”,該聯結器將在負責實際通訊的各種實體之間共享。
全域性配置
顧名思義,此構建基塊用於設定全域性屬性和配置。
全域性終結點
它可以在“全域性元素”選項卡中使用,可以在流程中多次使用 −
全域性訊息處理器
顧名思義,它觀察或修改訊息或訊息流程。轉換器和篩選器是全域性訊息處理器的示例。
轉換器 − 轉換器的主要工作是將資料從一種格式轉換為另一種格式。它可以在全域性進行定義,並可以在多個流程中使用。
篩選器 − 它是一個將決定應處理哪條 Mule 訊息的篩選器。篩選器基本上會指定訊息必須滿足的條件,然後才會對訊息進行處理並將其路由到服務。
模型
它與代理形成對比,它是在 Studio 中建立的服務的一個邏輯分組。我們可以自由啟動和停止特定模型內的所有服務。
服務 − 服務是包裝我們的業務邏輯或元件的服務。它還會專門針對該服務配置路由器、終結點、轉換器和篩選器。
端點 − 它是可以定義為服務將入站(接收)和出站(傳送)訊息的物件。服務透過端點連線。
流程
訊息處理器使用流程來定義源與目標之間的訊息流程。
Mule 訊息結構
Mule 訊息完全封裝在 Mule 訊息物件中,是透過 Mule 流程在應用程式間傳遞的資料。Mule 訊息的結構在以下圖表中顯示 −
如圖所示,Mule 訊息包含兩個主要部分 -
頭部
它只是該訊息的元資料,由以下兩個屬性進一步表示 −
入站屬性 − 這些是由訊息源自動設定的屬性。它們不能被使用者修改或設定。實際上,入站屬性是不可變的。
出站屬性 − 這些屬性包含元資料,如入站屬性,可以在流程中設定。它們可以由 Mule 自動設定,也可以由使用者手動設定。實際上,出站屬性是可變的。
當訊息透過傳輸從一個流程的出站端點傳遞到另一個流程的入站端點時,出站屬性變為入站屬性。
當訊息透過流引用而不是聯結器傳遞到新流程時,出站屬性仍然是出站屬性。
有效載荷
訊息物件承載的實際業務訊息稱為有效載荷。
變數
它可以定義為使用者定義的關於訊息的元資料。基本上,變數是應用程式在處理訊息時使用的有關訊息的臨時資訊片段。它不應連同訊息一起傳遞給其目標位置。它們有三種類型,如下所示 −
流程變數 − 這些變數僅適用於它們所存在的流程。
會話變數 − 這些變數適用於同一應用程式中的所有流程。
記錄變數 − 這些變數僅適用於作為批處理一部分處理的記錄。
附件和額外有效載荷
這些是有關訊息有效載荷的一些額外元資料,而不是每次都會出現在訊息物件中。