MuleSoft - Dự án Mule

Động lực đằng sau dự án Mule là -

để làm cho mọi thứ đơn giản hơn cho các lập trình viên,
nhu cầu của giải pháp nhẹ và mô-đun có thể mở rộng từ khung nhắn tin cấp ứng dụng sang khung phân phối cao trong toàn doanh nghiệp.

Mule ESB được thiết kế như một khung chương trình cũng như hướng sự kiện. Nó hướng đến sự kiện vì nó được kết hợp với sự đại diện thống nhất của các thông điệp và có thể mở rộng bằng các mô-đun có thể cắm được. Nó có tính lập trình vì các lập trình viên có thể dễ dàng cấy ghép một số hành vi bổ sung như xử lý thông báo cụ thể hoặc chuyển đổi dữ liệu tùy chỉnh.

Lịch sử

Quan điểm lịch sử của dự án Mule như sau:

Dự án SourceForge

Dự án Mule được bắt đầu với tên gọi là dự án SourceForge vào tháng 4 năm 2003, và sau 2 năm, phiên bản đầu tiên của nó đã được phát hành và chuyển sang CodeHaus. API đối tượng thông báo chung (UMO) là cốt lõi của kiến trúc. Ý tưởng đằng sau UMO API là hợp nhất logic trong khi giữ chúng cách ly với các phương thức vận chuyển cơ bản.

Phiên bản 1.0

Nó được phát hành vào tháng 4 năm 2005 chứa nhiều phương tiện giao thông. Trọng tâm chính của nhiều phiên bản khác sau đó là gỡ lỗi và thêm các tính năng mới.

Phiên bản 2.0 (Thông qua mùa xuân 2)

Spring 2 làm khung cấu hình và đấu dây đã được thông qua trong Mule 2 nhưng nó đã được chứng minh là một quá trình lớn vì thiếu tính biểu đạt của cấu hình XML yêu cầu. Sự cố này đã được giải quyết khi cấu hình dựa trên Lược đồ XML đã được giới thiệu trong Spring 2.

Xây dựng với Maven

Cải tiến lớn nhất giúp đơn giản hóa việc sử dụng Mule, cả ở thời điểm phát triển và triển khai, là việc sử dụng Maven. Từ phiên bản 1.3, nó bắt đầu được xây dựng với Maven.

MuleSource

Năm 2006, MuleSource được thành lập “để giúp hỗ trợ và cho phép cộng đồng đang phát triển nhanh chóng sử dụng Mule trong các ứng dụng doanh nghiệp quan trọng”. Nó được chứng minh là cột mốc quan trọng của Mule Project.

Đối thủ của Mule ESB

Sau đây là một số đối thủ cạnh tranh chính của Mule ESB -

WSO2 ESB
Xe buýt dịch vụ Oracle
WebSphere Message Broker
Nền tảng Aurea CX
Fiorano ESB
WebSphere DataPower Gateway
Khung quy trình kinh doanh ngày làm việc
Xe buýt dịch vụ doanh nghiệp Talend
Xe buýt dịch vụ doanh nghiệp JBoss
Quản lý dịch vụ iWay

Khái niệm cốt lõi của Mule

Như đã thảo luận, Mule ESB là một nền tảng tích hợp và bus dịch vụ doanh nghiệp dựa trên Java (ESB) nhẹ và có khả năng mở rộng cao. Bất kể các công nghệ khác nhau được sử dụng bởi các ứng dụng, Mule ESB cho phép dễ dàng tích hợp các ứng dụng, cho phép chúng trao đổi dữ liệu. Trong phần này, chúng ta sẽ thảo luận về khái niệm cốt lõi của Mule sẽ hoạt động để làm cho sự tích hợp như vậy xảy ra.

Đối với điều này, chúng ta cần hiểu kiến trúc cũng như các khối xây dựng của nó.

Ngành kiến trúc

Kiến trúc của Mule ESB có ba lớp cụ thể là lớp Giao thông vận tải, lớp Tích hợp và lớp Ứng dụng như thể hiện trong sơ đồ sau:

Nói chung, có ba loại tác vụ sau có thể được thực hiện để định cấu hình và tùy chỉnh việc triển khai Mule -

Phát triển thành phần dịch vụ

Nhiệm vụ này liên quan đến việc phát triển hoặc sử dụng lại các POJO hiện có, hoặc Spring Beans. POJOs là một lớp với các thuộc tính tạo ra các phương thức get và set, các trình kết nối đám mây. Mặt khác, Spring Beans chứa đựng logic kinh doanh để làm phong phú thêm thông điệp.

Điều phối dịch vụ

Tác vụ này về cơ bản cung cấp dàn xếp dịch vụ liên quan đến việc cấu hình bộ xử lý tin nhắn, bộ định tuyến, máy biến áp và bộ lọc.

Hội nhập

Nhiệm vụ quan trọng nhất của Mule ESB là tích hợp các ứng dụng khác nhau bất kể giao thức mà chúng đang sử dụng. Với mục đích này, Mule cung cấp các phương thức truyền tải cho phép nhận và gửi thông điệp trên các đầu nối giao thức khác nhau. Mule hỗ trợ nhiều phương thức vận chuyển hiện có hoặc chúng tôi cũng có thể sử dụng phương thức vận chuyển tùy chỉnh.

Khu nhà

Cấu hình mule có các khối xây dựng sau:

Đậu xuân

Công dụng chính của Spring bean là xây dựng thành phần dịch vụ. Sau khi xây dựng thành phần dịch vụ mùa xuân, chúng tôi có thể xác định nó thông qua tệp cấu hình hoặc theo cách thủ công, trong trường hợp bạn không có tệp cấu hình.

Đại lý

Về cơ bản, nó là một dịch vụ được tạo trong Anypoint Studio trước Mule Studio. Tác nhân được tạo khi bạn khởi động máy chủ và sẽ bị phá hủy khi bạn dừng máy chủ.

Kết nối

Nó là một thành phần phần mềm được cấu hình với các tham số cụ thể cho các giao thức. Nó chủ yếu được sử dụng để kiểm soát việc sử dụng một giao thức. Ví dụ: một trình kết nối JMS được định cấu hình vớiConnection và trình kết nối này sẽ được chia sẻ giữa các thực thể khác nhau phụ trách giao tiếp thực tế.

Cấu hình Toàn cầu

Như tên của nó, khối xây dựng này được sử dụng để thiết lập các thuộc tính và cài đặt chung.

Điểm cuối toàn cầu

Nó có thể được sử dụng trong tab Global Elements, có thể được sử dụng nhiều lần trong một luồng -

Bộ xử lý tin nhắn toàn cầu

Như tên của nó, nó quan sát hoặc sửa đổi một thông điệp hoặc luồng thông báo. Máy biến áp và bộ lọc là những ví dụ của Bộ xử lý thông báo toàn cầu.

Transformers- Công việc chính của máy biến áp là chuyển đổi dữ liệu từ định dạng này sang định dạng khác. Nó có thể được định nghĩa trên toàn cầu và có thể được sử dụng trong nhiều luồng.

Filters- Bộ lọc sẽ quyết định tin nhắn Mule nào nên được xử lý. Bộ lọc về cơ bản chỉ định các điều kiện phải được đáp ứng để một thông báo được xử lý và chuyển đến một dịch vụ.

Mô hình

Ngược lại với Đại lý, đó là một nhóm hợp lý các dịch vụ được tạo trong studio. Chúng tôi có quyền bắt đầu và dừng tất cả các dịch vụ bên trong một mô hình cụ thể.

Services- Dịch vụ là thứ bao bọc logic kinh doanh hoặc các thành phần của chúng tôi. Nó cũng cấu hình Bộ định tuyến, Điểm cuối, máy biến áp và bộ lọc dành riêng cho dịch vụ đó.

Endpoints- Nó có thể được định nghĩa là một đối tượng mà các dịch vụ sẽ gửi đến (nhận) và gửi đi (gửi) thông điệp. Các dịch vụ được kết nối thông qua các điểm cuối.

lưu lượng

Bộ xử lý thông báo sử dụng các luồng để xác định luồng thông báo giữa nguồn và đích.

Cấu trúc tin nhắn Mule

Một tin nhắn Mule, được bao bọc hoàn toàn trong Đối tượng Tin nhắn Mule, là dữ liệu truyền qua các ứng dụng thông qua các luồng Mule. Thông điệp của cấu trúc Mule được hiển thị trong sơ đồ sau:

Như đã thấy trong sơ đồ trên, Mule Message bao gồm hai phần chính:

Tiêu đề

Nó không là gì ngoài siêu dữ liệu của thông báo được đại diện thêm bởi hai thuộc tính sau:

Inbound Properties- Đây là những thuộc tính được thiết lập tự động bởi nguồn thông báo. Người dùng không thể thao tác hoặc thiết lập chúng. Về bản chất, thuộc tính hướng nội là bất biến.

Outbound Properties- Đây là những thuộc tính chứa siêu dữ liệu giống như thuộc tính gửi đến và có thể đặt trong quá trình lưu chuyển. Chúng có thể được đặt tự động bởi Mule hoặc do người dùng thủ công. Trong tự nhiên, các thuộc tính hướng ngoại là có thể thay đổi.

Thuộc tính gửi đi trở thành thuộc tính gửi đến khi thông điệp chuyển từ điểm cuối đi của một luồng đến điểm cuối đến của một luồng khác thông qua một phương tiện truyền tải.

Thuộc tính gửi đi vẫn là thuộc tính gửi đi khi thông báo được chuyển đến luồng mới thông qua luồng-ref thay vì trình kết nối.

Khối hàng

Thông điệp nghiệp vụ thực tế được mang bởi đối tượng thông báo được gọi là tải trọng.

Biến

Nó có thể được định nghĩa là siêu dữ liệu do người dùng xác định về một tin nhắn. Về cơ bản, các biến là những phần thông tin tạm thời về một thông báo được sử dụng bởi ứng dụng đang xử lý nó. Nó không có nghĩa là được chuyển cùng với các thông điệp đến đích của nó. Chúng có ba loại như được đưa ra dưới đây -

Flow variables - Các biến này chỉ áp dụng cho luồng mà chúng tồn tại.

Session variables - Các biến này áp dụng trên tất cả các luồng trong cùng một ứng dụng.

Record variables - Các biến này chỉ áp dụng cho các bản ghi được xử lý như một phần của lô.