Tìm hiểu về Enterprise Service Bus (ESB) môn Kiến trúc hướng dịch vụ (SOA)

ĐẠI HỌC QUỐC GIA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN
BÁO CÁO
Môn học:
Kiến trúc hướng dịch vụ (SOA)
Đề tài:
Tìm hiểu về Enterprise Service Bus (ESB)
Giảng viên: TS. Võ Đình Hiếu
Nhóm thực hiện: Trần Mạnh Trường
Cù Kim Long
Trịnh Thị Mai Anh
Lương Thế Hùng
Vũ Xuân Nam
Lớp: Quản lý Hệ thống thông tin
Hà Nội, tháng 04/2011
MỤC LỤC
MỤC LỤC 2
1. Giới thiệu 3
2. ESB là gì? 5
3. Các vai trò của người sử dụng SOA và các nhiệm vụ của chúng 7
4. Các mẫu ESB 9
4.1. Các mẫu tương tác 11
4.2. Các mẫu hòa giải 12
4.3. Các mẫu phức tạp 14
4.4. Các mẫu triển khai 14
5. Ví dụ về ESB 16
6. MuleESB 17
6.1. Giới thiệu Mule ESB 17
6.2. Kiến trúc của Mule ESB 18
6.2.1. Xử lý dữ liệu 19
6.2.2. Điều hướng thông điệp giữa các thành phần dịch vụ 20

6.2.3. Tách biệt logic nghiệp vụ với thông điệp 20
6.2.4. Kết hợp các dịch vụ với nhau 22
6.3. Logic của luồng dữ liệu 23
7. Kết luận 24
2
1. Giới thiệu
Các SOA cung cấp một cách tiếp cận linh hoạt, mở rộng được và cấu tạo lại được để
sử dụng lại và mở rộng các ứng dụng hiện có đồng thời xây dựng các ứng dụng mới. Các dịch
vụ thông báo công khai các khả năng, cả khả năng cung cấp lẫn khả năng tiêu thụ, bằng cách
khai báo các giao diện mà chúng triển khai thực hiện hoặc mong chờ các dịch vụ khác sẽ triển
khai thực hiện và bằng cách khai báo các chính sách đang chi phối các tương tác của đối tác có
tiềm năng. Ngôn ngữ Mô tả Dịch vụ Web (WSDL) và các tiêu chuẩn dịch vụ web khác, ví dụ
như Chính sách dịch vụ Web (WS – Policy), cung cấp vốn từ vựng cho các khai báo này.
Việc ảo hóa của các chức năng nghiệp vụ, một mục tiêu then chốt của một SOA, thực
hiện được thông qua tách biệt định nghĩa dịch vụ và cách sử dụng dịch vụ khỏi việc triển khai
thực hiện dịch vụ. Các dịch vụ có thể được triển khai thực hiện bằng cách sử dụng một loạt
các công nghệ, bao gồm cả IBM WebSphere® MQ, IBM CICS® hoặc IBM IMS™, Java™ 2
Platform, Enterprise Edition (J2EE) Enterprise JavaBeans (EJB), các lớp Java, IBM DB2®
Queries, Java Message Services (JMS) hoặc Microsoft® .NET. Bên yêu cầu dịch vụ gửi đi các
yêu cầu tới bên cung cấp dịch vụ có cung cấp các khả năng mà mình mong muốn, không cần
biết về việc triển khai thực hiện dịch vụ.
Một ESB là một mẫu kiến trúc để hỗ trợ công nghệ ảo hóa và quản lý các tương tác
dịch vụ giữa các bên tham gia giao tiếp. Nó cung cấp kết nối giữa các bên cung cấp dịch vụ và
bên yêu cầu dịch vụ, tạo điều kiện thuận lợi cho sự tương tác của chúng ngay cả khi chúng
không ăn khớp chính xác. Mẫu này có thể được triển khai thực hiện bằng cách sử dụng nhiều
loại công nghệ phần mềm trung gian và các mô hình lập trình.
Một ESB là một kiến trúc phần mềm cho lớp giữa (middleware), cung cấp các dịch vụ
cơ bản phục vụ các lớp kiến trúc phức tạp hơn. Ví dụ: một ESB tổ chức chặt chẽ tất cả các tính
năng sẽ yêu cầu thực thi một kiến trúc hướng dịch vụ SOA.
Nói một cách tổng quan, ESB có thể được nghĩ như một cơ chế mà tại đó nó quản lý

việc truy cập vào các ứng dụng và các dịch vụ (đặc biệt là các hệ thống cũ với phiên bản khác
3
nhau), để đưa ra một giao diện, giao tiếp đơn giản và đồng nhất với người dùng cuối, có thể
thông qua Web, hoặc form tới người dùng cuối.
Hiểu cách khác, ESB thực hiện phân phối các dịch vụ cho các hệ thống và các ứng
dụng không đồng nhất phía sau với người dùng phía trước, hay các hệ thống cần thông tin
cũng không đồng nhất. Khi đó, các phần mềm lớp giữa sẵn sàng thực hiện: Ẩn các phần phức
tạp, đơn giản hóa các truy nhập, cho phép các nhà phát triển sử dụng các form truy vấn chung
và đồng nhất, truy nhập và tương tác, xử lý các chi tiết phức tạp phía sau.
Sự hấp dẫn của ESB và có thể thành công trong tương lai, chính là khả năng hỗ trợ sự
tăng lên nhanh chóng các dịch vụ và các ứng dụng tích hợp trong các hệ thống của tổ chức
doanh nghiệp theo đòi hỏi của nghiệp vụ kinh doanh có thể vượt quá khả năng của công nghệ
của các hệ thống đó.
Một ESB được xây dựng có khả năng:
- Phân phối thông tin cho toàn bộ doanh nghiệp một cách nhanh chóng và dễ dàng.
- Ẩn đi các nền tảng khách nhau phía sau của kiến trúc phần mềm và các giao thức
mạng.
- Đảm bảo thông tin được chuyển đi cho dù thậm chí khi vài hệ thống hoặc mạng bị
ngừng hoạt động gián đoạn.
- Định tuyến, lưu vết, và lưu trữ thông tin không đòi hỏi các ứng dụng cần viết lại
(coding).
- Đáp ứng việc triển khai dần dần, doanh nghiệp không nhất thiết phải chuyển toàn bộ
dịch vụ hay các ứng dụng ngay hoặc toàn bộ trong một lần.
Việc định tuyến các bản tin trên ESB, mỗi một hãng công nghệ có một sản phẩm khác
nhau. Nhưng có vẻ về nhìn chung, nó routing các bản tin gần như là Router trong Network
vậy. Các bản tin có thể được định tuyến theo chủ đề (Subject), hay nội dụng hay ID của bản
tin. Và giữa các subnets khác nhau, các bản tin cũng được quản lý giám sát để được Route qua
tường lửa
ESB không phải là một sản phẩm mới, nó chỉ là một cách nhìn mới về cách tích hợp
các ứng dụng, sự phối hợp các tài nguyên và quản lý xử lý thông tin mà thôi.

4
2. ESB là gì?
Trong mẫu ESB, thay vì tương tác trực tiếp, các bên tham gia vào một tương tác dịch
vụ sẽ giao tiếp thông qua một kênh (bus); kênh này cung cấp các đặc tính công nghệ ảo hóa và
quản lí để triển khai thực hiện và mở rộng định nghĩa cốt lõi của SOA. Mẫu ESB cung cấp
công nghệ ảo hóa về:
• Địa điểm và nhân dạng: Bên tham gia không cần biết địa điểm hoặc nhân dạng
của các bên tham gia khác. Ví dụ, bên yêu cầu không cần phải biết rằng một yêu
cầu có thể được phục vụ bởi bất kỳ một bên cung cấp dịch vụ nào. Bên cung cấp
dịch vụ có thể được thêm vào hoặc gỡ bỏ mà không làm đổ vỡ hệ thống.
• Giao thức tương tác: Những bên tham gia không cần phải chia sẻ cùng một giao
thức giao tiếp hay dạng tương tác. Một yêu cầu được biểu diễn dưới dạng
SOAP/HTTP có thể được phục vụ bởi một bên cung cấp chỉ hiểu được Java
Remote Method Invocation (RMI-Cách gọi phương thức từ xa của Java).
• Giao diện: Các bên yêu cầu và bên cung cấp dịch vụ không cần phải đồng ý về
một giao diện chung. ESB hóa giải các sự khác nhau bằng cách chuyển đổi các
thông báo yêu cầu thành một khuôn dạng mà nhà cung cấp trông đợi.
• Chất lượng (Tương tác) Dịch vụ (QoS): Các bên tham gia khai báo các yêu cầu
QoS của mình, bao gồm cả hiệu năng và độ tin cậy, quyền hạn của các yêu cầu, mã
hóa/giải mã các nội dung thông báo, kiểm tra tự động các tương tác dịch vụ và việc
định tuyến các yêu cầu ấy như thế nào (ví dụ như đi đến bản triển khai thực hiện
đang sẵn sàng, dựa trên tiêu chí về phân tải công việc). Các chính sách mô tả các
yêu cầu và khả năng QoS của những bên yêu cầu và bên cung cấp dịch vụ có thể
được chính các dịch vụ thỏa mãn hoặc được thỏa mãn bởi ESB qua việc bù trừ các
chỗ không ăn khớp.
Như vậy, mẫu ESB tránh cho bên yêu cầu không cần phải biết rõ việc thực hiện thực tế
của bên cung cấp dịch vụ từ quan điểm của cả nhà phát triển lẫn nhà triển khai ứng dụng.
ESB sẽ chịu trách nhiệm về việc phân phối các yêu cầu tới bên cung cấp dịch vụ có đưa ra các
chức năng và QoS cần thiết. Các bên cung cấp dịch vụ nhận được các yêu cầu và chúng sẽ đáp
ứng yêu cầu đó mà không biết nguồn gốc của thông báo. Chính ESB cũng là trong suốt đối với

5
các bên yêu cầu và cung cấp dịch vụ đang sử dụng nó. Logic ứng dụng có thể gọi hoặc phân
phối dịch vụ bằng cách sử dụng một loạt các mô hình và các kỹ thuật lập trình mà không cần
phải xem xét có kết nối trực tiếp không hoặc có đi xuyên qua một ESB không. Kết nối đến
một ESB là một quyết định triển khai; mã nguồn ứng dụng không thay đổi.
Một ESB hỗ trợ nhiều loại hình tương tác, bao gồm một-chiều, yêu cầu/đáp ứng,
không đồng bộ, đồng bộ và công bố/đăng ký. Nó cũng hỗ trợ quá trình xử lý sự kiện phức tạp
trong đó một loạt các sự kiện có thể được quan sát để sinh ra một sự kiện như là một hệ quả
của các mối quan hệ trong loạt sự kiện.
Hình 1 mô tả mẫu ESB cơ bản. Các thông báo chảy qua một kênh liên kết nhiều bên
tham gia giao tiếp. Một số bên tham gia gọi các dịch vụ được cung cấp bởi những bên khác;
những bên tham gia khác công bố thông tin cho những bên tiêu thụ quan tâm. Nơi mà ở đó
một điểm đầu cuối tương tác với ESB được gọi là một Điểm Tương tác Dịch vụ (Service
Interaction Point - SIP). Một SIP có thể, ví dụ, là một điểm đầu cuối dịch vụ web, một hàng
đợi MQ WebSphere hoặc một trình ủy quyền (proxy) của một đối tượng đầu xa RMI. Một sổ
đăng ký dịch vụ nắm giữ siêu dữ liệu mô tả các yêu cầu và các khả năng của các SIP (ví dụ,
các giao diện mà chúng cung cấp hoặc chúng yêu cầu), chúng muốn tương tác với các SIP
khác như thế nào (ví dụ như, đồng bộ hoặc không đồng bộ, thông qua HTTP hoặc JMS), các
yêu cầu QoS của chúng (ví dụ, các tương tác an toàn, độ tin cậy được ưu tiên) và các thông tin
khác để có thể tương tác với các SIP khác (chẳng hạn như các chú thích về ngữ nghĩa).
6
Hình 1. Mẫu ESB cơ bản
Việc chèn ESB vào giữa các bên tham gia mang lại cơ hội để điều biến sự tương tác
của chúng thông qua một cấu kiện logic được gọi là một thành phần hòa giải (mediation). Các
thành phần hòa giải hoạt động với các thông báo đang trên đường truyền dẫn giữa những bên
yêu cầu và cung cấp dịch vụ. Đối với các tương tác phức tạp, các thành phần hòa giải có thể
móc nối theo tuần tự. Mục Các mẫu hòa giải (Mediation patterns) sẽ trình bày các mẫu hòa
giải chung triển khai thực hiện công nghệ ảo hóa, QoS và các khái niệm quản lý này.
Mẫu ESB cung cấp một cách tiếp cận linh hoạt và dễ quản lý để triển khai thực hiện
SOA. Được chèn trong suốt giữa các điểm đầu cuối, kênh này nâng cao chất lượng dịch vụ;

tạo điều kiện thuận lợi cho các tương tác giữa bên yêu cầu - bên cung cấp mặc dù các giao
thức, các mẫu tương tác hay các khả năng dịch vụ không hoàn toàn ăn khớp và cho phép giám
sát và quản lý.
3. Các vai trò của người sử dụng SOA và các nhiệm vụ của chúng
Việc xem xét các vai trò và các nhiệm vụ của những người sử dụng, những người tạo
ra và quản lý các giải pháp SOA làm sáng tỏ hơn nữa về mẫu ESB. Các công cụ ESB và môi
trường chạy phân chia vòng đời giải pháp SOA thành bốn giai đoạn:
• Khám phá và mô tả: Nhận biết và mô tả các SIP để có thể kết nối chúng trên
ESB. Điều này bao gồm việc tạo ra dịch vụ mới, khám phá dịch vụ hiện có và mô
tả về các giao diện, các yêu cầu và các khả năng của chúng.
• Mô hình và xây dựng: kết nối giữa các SIP qua các thành phần hòa giải mới hoặc
hiện có để mô tả các tương tác đầu cuối đến đầu cuối của một giải pháp.
• Cấu hình và triển khai: Định cấu hình cho một khai báo trừu tượng của một giải
pháp dành cho một hình thái (topology) môi trường chạy thực và triển khai nó, tạo
ra những tạo phẩm chạy thực cần thiết.
• Theo dõi và quản lý: Theo dõi và quản lý giải pháp thông qua các hành vi của các
SIP và thành phần hòa giải. Giai đoạn này sử dụng các điểm đo và kiểm soát trong
môi trường chạy ESB, cũng như các thành phần hòa giải để theo dõi và tác động
đến dòng thông báo.
7
Đối với phần mềm trung gian ESB, các vai trò phát triển giải pháp SOA quan trọng
nhất là nhà phát triển tích hợp và nhà quản trị giải pháp, nhưng cũng có liên quan đến nhà
phân tích nghiệp vụ, kiến trúc sư giải pháp, người thực hiện (implementer), nhà phát triển bộ
tiếp hợp và người vận hành. (Các vai trò là khái niệm lôgic, một người có thể giữ nhiều vai
trò). Hình 2 cho thấy các vai trò này tương tác như thế nào.
Các nhà phân tích nghiệp vụ nhận biết các yêu cầu nghiệp vụ và xem xét lại các qui
trình nghiệp vụ. Họ phác thảo các mục tiêu của một giải pháp, các qui trình nghiệp vụ được
gọi, các chỉ báo then chốt để theo dõi trạng thái và sức khỏe các giải pháp và các loại hình
dịch vụ nghiệp vụ mà các hệ thống CNTT cần phải cung cấp.
Các kiến trúc sư giải pháp quyết định các yêu cầu nghiệp vụ nào có thể được đáp ứng

bằng cách sử dụng lại, sửa đổi hoặc kết hợp các tài sản CNTT hiện có và các yêu cầu nghiệp
vụ nào đòi hỏi các tài sản CNTT mới cần được viết hoặc mua. Họ định nghĩa các tương tác
giữa các tài sản CNTT, bao gồm nội dung trao đổi thông báo.
Công việc phát triển được phân chia giữa ba vai trò. Một người thực hiện viết mã ứng
dụng mới, sẽ được gọi thông qua một giao diện dịch vụ. Một nhà phát triển bộ tiếp hợp xây
dựng các dịch vụ để gói gọn các ứng dụng và các gói hiện có hoặc mới mua nhằm mang lại
khả năng truy cập cho các dịch vụ khác.
Một nhà phát triển tích hợp sử dụng các công cụ và công nghệ có liên quan đến ESB
để xây dựng một logic kiểm soát cách các yêu cầu được định tuyến giữa các dịch vụ này như
thế nào.

8
Hình 2. Các vai trò của người sử dụng
Một nhà quản trị giải pháp làm cho các tài sản CNTT mới sẵn sàng để sử dụng bằng
cách triển khai chúng và nhập khẩu các định nghĩa dịch vụ của chúng vào sổ đăng ký dịch vụ.
Khi giải pháp đã được triển khai sẵn sàng, những người vận hành theo dõi việc thi hành của
nó, khởi động và cho ngừng các hệ thống CNTT theo yêu cầu và tư vấn cho nhà quản trị giải
pháp, những người có thể điều chỉnh cấu hình của giải pháp.
4. Các mẫu ESB
Các nhà phát triển tích hợp và các nhà quản trị giải pháp sử dụng một bộ các mẫu để
thiết kế và triển khai các giải pháp SOA.
9
Hình 3. Các phần tử của mẫu ESB cơ bản
Mẫu ESB cơ bản trừu tượng hóa các thành phần ứng dụng thành một tập hợp các dịch
vụ để tương tác thông qua một kênh chứ không thông qua các giao tiếp điểm-đến-điểm trực
tiếp. Dịch vụ đang nói đến có thể là bên cung cấp, bên yêu cầu hoặc cả hai. Bất kỳ việc thực
hiện SOA nào đều cần làm cho công nghệ ảo hóa cơ bản có thể thực hiện được, cho phép thay
thế một triển khai thực hiện bên cung cấp dịch vụ tương đương mà không làm ảnh hưởng đến
các bên yêu cầu phụ thuộc nó. Mẫu ESB hoàn thiện khả năng SOA cơ bản này thông qua việc
quản lý rõ ràng các tương tác giữa bên yêu cầu - bên cung cấp dịch vụ. Bất cứ bên cung cấp

dịch vụ nào cũng có thể được thay thế bằng bên cung cấp dịch vụ khác miễn là nó có các khả
năng gần giống với yêu cầu của bên yêu cầu theo cách mà ESB có thể dàn xếp.
ESB cung cấp các điểm tương tác, nơi mà các các dịch vụ gửi các thông báo lên kênh
hoặc lấy chúng về. Nó áp dụng các thành phần hòa giải đến các thông báo đang trên đường
truyền dẫn và đảm bảo QoS cho các tương tác được quản lý này.
Từ phối cảnh của ESB, tất cả các điểm đầu cuối tương tác dịch vụ là như nhau, theo
nghĩa chúng gửi các yêu cầu/các sự kiện hoặc xử lý các yêu cầu/các sự kiện; chúng cũng yêu
10
cầu QoS cụ thể; và chúng có thể yêu cầu các hậu thuẫn cho tương tác. Mẫu ESB cho phép các
nhà phát triển tích hợp coi bên yêu cầu hay bên cung cấp mà tương tác với mọi người theo
cùng một cách (hướng-dịch vụ) giống như logic nghiệp vụ mới, các thành phần dàn dựng qui
trình, hoặc các dịch vụ web bên ngoài.
Các mẫu để xây dựng các giải pháp dựa trên ESB được phân loại như sau:
• Các mẫu tương tác: Cho phép các điểm tương tác dịch vụ gửi các thông báo đi
hoặc nhận thông báo từ kênh.
• Các mẫu hòa giải: Cho phép thao tác trao đổi thông báo.
• Các mẫu triển khai: Hỗ trợ triển khai giải pháp vào một cơ sở hạ tầng liên kết.
4.1. Các mẫu tương tác
ESB cho phép các điểm cuối tương tác trong các mô hình tương tác tự nhiên của chúng
thông qua kênh. Nó hỗ trợ một loạt các giao thức điểm cuối và các dạng tương tác. Một vài ví
dụ về các mẫu tương tác là:
• Yêu cầu /đáp ứng (Request/response): Xử lý các tương tác kiểu yêu cầu/đáp ứng
giữa các điểm cuối. ESB dựa trên một mô hình truyền thông điệp, vì thế một tương
tác yêu cầu/đáp ứng được xử lý bằng hai dòng thông điệp một chiều có liên quan
một dòng cho yêu cầu và một dòng cho đáp ứng.
• Một yêu cầu/nhiều đáp ứng (Request/multi-response): Một biến thể của dạng
nói trên, ở đây có nhiều hơn một đáp ứng có thể được gửi đi.
• Lan truyền sự kiện (Event propagation): Các sự kiện có thể được phân phối ẩn
danh đến một danh sách các bên quan tâm do ESB quản lý. Các dịch vụ có thể tự
bổ sung thêm mình vào danh sách.

Hình 4. Các mẫu tương tác
11
4.2. Các mẫu hòa giải
Các mẫu hòa giải xử lý các thông điệp trên đường truyền dẫn trên kênh (các yêu cầu
hoặc các sự kiện). Các thông điệp do một bên yêu cầu gửi đi được biến đổi thành các thông
điệp hiểu được đối với một nhà cung cấp, có thể hơi không tương thích, được chọn từ một tập
hợp các điểm cuối có tiềm năng.
Các mẫu hòa giải này hoạt động theo các thông điệp một chiều hơn là theo các cặp yêu
cầu-đáp ứng, bởi vì ESB đặt các mẫu tương tác phủ bên trên các mẫu hòa giải.

Hình 5. Các mẫu hòa giải
Có một số các mẫu cơ bản của các thành phần hòa giải; các mẫu phức tạp hơn có thể
được xây dựng bằng cách kết hợp các mẫu đơn giản:
• Chuyển mạch giao thức (Protocol switch): Cho phép những bên yêu cầu dịch vụ
gửi đi thông điệp của chúng, sử dụng một loạt các giao thức tương tác hoặc các
API, ví dụ như là SOAP/HTTP, JMS và MQ Integrator (MQI). Chuyển mã các yêu
cầu theo định dạng của bên cung cấp dịch vụ nhắm tới. Có thể được áp dụng tại
đầu bên yêu cầu hoặc đầu bên cung cấp của một tương tác, hoặc tại cả hai đầu,
hoặc tại bất cứ nơi nào ở giữa.
• Chuyển đổi (Transform): Dịch nội dung thông báo từ lược đồ của bên yêu cầu
sang lược đồ của bên cung cấp dịch vụ. Có thể bao gồm việc bao gói, mở gói hoặc
mã hóa.
12
• Làm giàu thêm (Enrich): Làm tăng thêm nội dung thông báo bằng cách bổ sung
thêm các thông tin từ các nguồn dữ liệu bên ngoài, chẳng hạn như các thông số tuỳ
chỉnh được định nghĩa bởi thành phần hòa giải, hoặc từ các truy vấn cơ sở dữ liệu.
• Định tuyến (Route): Thay đổi tuyến đường của một thông điệp, lựa chọn giữa các
bên cung cấp dịch vụ có hỗ trợ mục đích của bên yêu cầu. Tiêu chí lựa chọn có thể
bao gồm nội dung và bối cảnh thông điệp, cũng như các khả năng của các đích.

• Phân phối (Distribute): Phân phối thông điệp đến một tập hợp các bên quan tâm
và thường là dựa theo khái lược các quan tâm của người đăng ký.
• Theo dõi (Monitor): Theo dõi các thông điệp khi chúng đi qua một thành phần
hòa giải không thay đổi. Có thể được sử dụng để theo dõi các mức dịch vụ; trợ giúp
trong việc xác định vấn đề hay đo đạc việc sử dụng để sau đó tính tiền thu phí đối
với những người sử dụng; hay ghi lại các sự kiện mức nghiệp vụ, chẳng hạn như
đặt mua hàng vượt quá một mức (giá trị đô la) nào đó. Cũng có thể được sử dụng
để ghi nhật ký các thông báo, phục vụ kiểm định hoặc khai phá dữ liệu sau này.
• Thiết lập mối tương quan (Correlate): Tạo ra các sự kiện phức tạp từ các luồng
thông điệp hoặc luồng sự kiện. Bao gồm các quy tắc để nhận biết mẫu và các quy
tắc phản ứng lại việc khám phá mẫu, ví dụ, bằng cách tạo ra một sự kiện phức tạp
bắt nguồn từ nội dung của luồng sự kiện kích hoạt.
Các thành phần hòa giải có thể được định cấu hình rõ ràng trong một giải pháp. Ví dụ,
một nhà phát triển tích hợp có thể định cấu hình một thành phần hòa giải enrich để thay đổi
nội dung thông báo. Một nhà quản trị giải pháp có thể định cấu hình một thành phần hòa giải
route cho phép nó chuyển mạch một nhà cung cấp dịch vụ ở chế độ ngoại tuyến.
Các thành phần hòa giải khác được ESB đặt đúng chỗ để đáp ứng các yêu cầu QoS của
các bên yêu cầu dịch vụ và các bên cung cấp dịch vụ. Ví dụ, nếu một khai báo chính sách an
ninh của một nhà cung cấp dịch vụ đòi hỏi các thông báo phải được mã hóa, ESB có thể định
cấu hình một thành phần hòa giải mã hóa (encryption) một cách tự động.
Cũng giống như là các thuộc tính của các dịch vụ, nhà quản trị giải pháp có thể thiết
lập các chính sách đối với một tương tác hoặc nhóm các tương tác. Ví dụ, để ghi nhật ký tất cả
các thông báo đến một nhà cung cấp bên ngoài cụ thể hoặc với một giá trị giao dịch vượt quá
1 triệu Đôla. ESB sẽ triển khai thực hiện chính sách bằng cách định cấu hình một thành phần
hòa giải, trong trường hợp này, là một thành phần hòa giải monitor.
13
4.3. Các mẫu phức tạp
Hình 6. Các mẫu phức tạp
Các mẫu hòa giải và các mẫu tương tác có thể được kết hợp để thực hiện các mẫu phức
tạp hơn.

Ví dụ, một chuyển mạch giao thức, tiếp sau đó là một phép biến đổi có thể triển khai
thực hiện một mẫu bộ tiếp hợp chuẩn tắc (canonical adapter) trong đó tập hợp các thông điệp
và các đối tượng nghiệp vụ được sử dụng bởi tất cả các bên được chuẩn hóa theo một khuôn
dạng chuẩn tắc. Mẫu bộ tiếp hợp chuẩn tắc chuyển đổi các giao thức nguyên thủy, gắn với
kênh (bus-attachment) của các điểm cuối thành một giao thức tiêu chuẩn, chuẩn hóa nội dung
(payload) và biến đổi ngược trở lại khi chuyển giao cho bên nhận.
Một thành phần hòa giải phức tạp chung khác là mẫu biến đổi, ghi nhật ký và định
tuyến (transform, log and route).
Mẫu cổng kết nối (gateway) là một biến thể chuyển mạch giao thức phức tạp. Nó có
thể kết hợp các thành phần hòa giải chuyển đổi và theo dõi để cung cấp khả năng mã hóa, ghi
nhật ký hoặc kiểm định. Nó cũng có thể kết hợp lại và tách ra các thông điệp trong một mối
quan hệ một-tới-nhiều. Các cổng web dịch vụ tiêu biểu cho mẫu này, cung cấp một điểm liên
lạc đơn lẻ cho nhiều dịch vụ và ẩn giấu các chi tiết của các dịch vụ bên trong.
4.4. Các mẫu triển khai
Các nhà quản trị giải pháp có một vài sự lựa chọn dành cho các hình thái ESB. Một số
ví dụ thường gặp được chỉ ra dưới đây:
14
• ESB toàn cầu (Global ESB): Tất cả các dịch vụ chia sẻ chung một vùng tên và
mỗi bên cung cấp dịch vụ đều được mọi bên yêu cầu dịch vụ nhìn thấy, xuyên qua
một môi trường phân phối không thuần nhất, được quản lý tập trung, phân tán về
địa lý. Được sử dụng bởi các bộ phận hoặc các doanh nghiệp nhỏ, nơi tất cả các
dịch vụ đều có thể được áp dụng trên toàn bộ tổ chức.
• ESB được kết nối trực tiếp (Directly connected ESB): Một sổ đăng ký dịch vụ
chung làm cho tất cả các dịch vụ có trong một số bản cài đặt ESB độc lập nhau đều
có thể được nhìn thấy. Được sử dụng ở nơi dịch vụ được cung cấp và được quản lý
bởi một dòng nghiệp vụ nhưng đã tạo ra cho nhiều loại doanh nghiệp có sẵn.
• ESB được môi giới (Brokered ESB): Các dịch vụ cầu nối, đưa ra giới thiệu một
cách có chọn lọc các bên yêu cầu hoặc các bên cung cấp dịch vụ cho bên đối tác
trong các miền khác, điều phối việc chia sẻ giữa nhiều bản triển khai thực hiện
ESB mà mỗi bản quản lý một vùng tên riêng của mình. Các tương tác dịch vụ giữa

các ESB được hậu thuẫn thông qua một trình môi giới chung, mà trình này triển
khai thực hiện các dịch vụ cầu nối. Được sử dụng bởi các bộ phận để phát triển và
quản lý các dịch vụ riêng của mình, nhưng có chia sẻ một vài dịch vụ trong số đó
hoặc có truy cập các dịch vụ chọn lọc, được cung cấp trong toàn doanh nghiệp.
• ESB liên hiệp (Federated ESB): Một ESB chính mà một vài ESB phụ thuộc khác
liên hiệp với nó. Những người sử dụng dịch vụ và các nhà cung cấp dịch vụ kết nối
tới ESB chính hay tới một ESB phụ thuộc để truy cập vào các dịch vụ trên toàn
mạng. Được sử dụng bởi các tổ chức muốn liên kết một tập hợp các bộ phận tự trị
ở mức vừa phải dưới các ô của một bộ phận giám sát.
15

Hình 7. Các mẫu triển khai ESB
5. Ví dụ về ESB
Quán Hot Rock ở Giảng võ: Ta có thể chia ra 3 phần chính:
1. Khách hàng: Rất đa dạng, là những người sử dụng dịch vụ, họ yêu cầu đáp ứng món
ăn uống khách nhau. Tùy thời điểm sẽ có các activities cũng khác nhau như, người thì gọi món
ăn, người gọi thức uống, người gọi thanh toán, người chờ hóa đơn, hay người thì uống nước
ngồi chơi nghĩa là rất đa dạng dịch vụ cần cấp.
2. Bộ phận bên trong: Bao gồm cả các đầu bếp, hệ thống bếp, các nhà cung ứng vật tư,
đồ ăn, hệ thống văn phòng từ kế toán, thu ngân, quản lý, in hóa đơn, v.v nghĩa là rất đa dạng
hệ thống.
3. Bộ phận phục vụ: Họ sẽ giao tiếp với cả bộ phận bên trong và Khách hàng. Họ
không cần biết bếp nấu ăn thế nào, bằng gaz hay điện, xào hay nướng Nhưng cứ đáp ứng
dịch vụ họ cần tại cửa sổ ra là OK. Vẫn phục vụ đó, họ không chỉ lấy đồ ăn đáp ứng cho khách
hàng, họ còn nộp tiền vào quầy, họ đặt menu qua handphone, họ lấy hóa đơn cho khách.
16
Nghĩa là bộ phận phục vụ giao tiếp với rất đa dạng hệ thống. Từ bếp, kế toán, đến
CNTT (handphone) và khách hàng (đầu ra).
Họ thực hiện được tại sao?
Ban quản lý đã xây dựng SOA/BPM cho họ rồi và bộ phận phục vụ như cái ESB, nó

được tích hợp để giao tiếp với các hệ thống phía sau. BPM là các quy trình nghiệp vụ được
xây dựng để cô phục vụ cứ theo quy trình đặt món ăn, quy trình thanh toán, quy trình phục
vụ Với cô phục vụ và khách hàng, không quan tâm hệ thống bên trong, miễn sao hệ thống
đáp ứng dịch vụ cô được giao bán! Cái Handphone làm thế nào đặt món được cô không cần
biết nó dụng Linux server hay Oracle database, miễn sao có dịch vụ đặt món để dùng
Vậy có thể coi Bộ phận phục vụ chính là một mẫu ESB.
diện của ESB và sự hỗ trợ cơ sở hạ tầng thúc đẩy đáng kể việc thực hiện các nguyên
tắc của SOA.
6. MuleESB
Lợi thế của triển khai ứng dụng trên môi trường mạng là một ứng dụng có thể gửi dữ liệu cho
ứng dụng khác. Tuy nhiên nhiều ứng dụng không thể đọc hay xử lý dữ liệu gửi đến từ ứng
dụng khác. Mule ESB giải quyết vấn đề này bằng cách cung cấp một khung làm việc truyền
thông điệp mà có thể đọc, truyển đổi và gửi dữ liệu như một thông điệp (message) giữa các
ứng dụng với nhau. Một thông điệp có thể đơn giản là một gói tin mà có thể quản lý và gửi
giữa các ứng dụng trên một kênh cụ thể.
6.1. Giới thiệu Mule ESB
Mule ESB là một nền tảng mã nguồn mở dựa trên ngôn ngữ java cho phép nhà phát
triển ứng dụng có thể kết nối các ứng dụng với nhau một cách nhanh chóng và dễ dàng, cho
phép các ứng dụng có thể trao đổi dữ liệu. Mule ESB cho phép dễ dàng tích hợp các hệ thống
sẵn có, không quan tâm tới việc các hệ thống đó sử dụng công nghệ khác nhau, bao gồm các
giao thức như JMS, Web Services, JDBC, HTTP,
17
Ưu điểm chính của một ESB là cho phép các ứng dụng khách nhau có thể giao tiếp
được với nhau bằng cách hoạt động như một hệ thống trung chuyển cho phép truyền dữ liệu
giữa các ứng dụng trong doanh nghiệp thông qua mạng internet. Mule ESB có các khả năng
mạnh mẽ như:
• Service creation and hosting — Lưu trữ và phục vụ các dịch vụ có thể tái sử dụng,
Mule ESB hoạt động như một bộ chứa các dịch vụ một cách nhẹ nhàng.
• Service mediation — che dấu các dịch vụ khỏi định dạng thông điệp và các giao thức,
tách biệt logic nghiệp vụ với thông điệp và cho phép gọi dịch vụ ở các điểm độc lập.

• Message routing — điều hướng, lọc, tập hợp và sắp thứ tự các thông điệp dựa trên nội
dung và các qui tắc.
• Data transformation — chuyển đổi dữ liệu giữa các định dạng khách nhau và các giao
thức khác nhau.
6.2. Kiến trúc của Mule ESB
Phần này trình bày kiến trúc cơ bản của Mule ESB và cách quản lý thông điệp cũng
như dữ liệu của nó. Để dễ dàng minh họa, ta dựa trên ví dụ về một công ty cần phải xuất hóa
18
đơn từ việc đặt hàng của khách, thực hiện một số thao tác xử lý trên hóa đơn này và gửi chúng
tới phòng giao hàng để hoàn tất việc đặt hàng.
6.2.1. Xử lý dữ liệu
Khi một thông điệp được gửi đi giữa các ứng dụng (ví dụ như hóa đơn từ hệ thống đặt
hàng), Mule ESB tiếp nhận thông điệp, gửi nó tới dịch vụ xử lý với thông điệp đó một số logic
nghiệp vụ cần thiết (như kiểm tra khách hàng và cơ sở dữ liêu kho hàng), và sau đó điều
hướng nó tới ứng dụng cần thiết khác (như hệ thống hoàn tất hóa đơn). Mule chứa nhiều thành
phần khác nhau để quản lý việc xử lý và điều hướng thông điệp đó. Phần quan trọng của dịch
vụ là thành phần dịch vụ (service component). Thành phần dịch vụ thực hiện các logic nghiệp
vụ trên thông điệp, như đọc đối tượng hóa đơn, bổ xung thêm các thông tin vào đó và chuyển
tiếp hóa đơn tới ứng dụng khác có nhiệm vụ hoàn tất hóa đơn.
Một đặc tính quan trọng của thành phần dịch vụ là nó không cần phải viết mã code cụ
thể của Mule; nó đơn giản chỉ là một POJO, Spring bean, Java bean, hay web service có nhiệm
vụ xử lý logic nghiệp vụ dữ liệu theo một cách cụ thể. Mule quản lý thành phần dịch vụ, đưa
nó vào phần cài đặt cấu hình và thể hiện như một dịch vụ, và chắc chắn rằng thông tin đúng
đắn sẽ được chuyển đi dựa trên cài đặt mà ta chỉ định cho dịch vụ nào đó trong tệp cấu hình
của Mule.
Ta có thể có nhiều thành phần dịch vụ khác nhau để thực thi các logic nghiệp vụ khác
nhau, như một dịch vụ có nhiệm vụ xác thực xem mặt hàng của hóa đơn có trong kho hàng
19
hay không và dịch vụ khác cập nhật cơ sở dữ liệu khách hàng để ghi lại lịch sử của hóa đơn.
Sau đó, hóa đơn sẽ được đưa vào thông điệp và có thể chuyển theo một luồng tới thành phần

dịch vụ kế tiếp cho tới khi tất cả các yêu cầu được hoàn tất.
6.2.2. Điều hướng thông điệp giữa các thành phần dịch vụ
Như đề cập ở phần trên, thành phần dịch vụ chứ logic nghiệp vụ để xử lý dữ liệu trong
thông điệp. Nó không chứa bất kỳ thông tin nào về cách nhận và gửi bản thân thông điệp đó.
Để đảm bảo rằng thành phần dịch vụ nhận thông điệp đúng đắn và chuyển tiếp chúng tới điểm
xác định sau khi đã xử lý, ta phải chỉ định một inbound router và một outbound router cho
dịch vụ mà chứa thành phần đó khi cấu hình Mule ESB.
Inbound router chỉ ra những thông điệp nào thành phần dịch vụ sẽ xử lý. Chúng có thể
lọc thông điệp gửi đến, tổ chức và sắp xếp chúng trước khi chuyển tiếp chúng tới thành phần
dịch vụ.
Sauk hi một thành phần dịch vụ đã xử lý thông điệp, outbound router sẽ xác định nơi
chuyển tiếp thông điệp tới. Ta có thể chỉ định nhiều ràng buộc inboud và outbound router và
thậm chí là một chuỗi router cùng nhau để một thành phần dịch vụ nhận và chuyển thông điệp
một cách chính xác theo yêu cầu
6.2.3. Tách biệt logic nghiệp vụ với thông điệp
Một trong những lợi ích của Mule ESB là nó có thể quản lý các thông điệp được gửi
thông qua nhiều dạng giao thức khác nhau. Ví dụ, một hóa đơn có thể luôn luôn ở dạng XML,
20
nhưng nó có thể được gửi đi thông qua giao thức HTTP và ở tình huống khác lại được gửi đi
như một thông điệp JMS phụ thuộc vào ứng dụng nào tạo ra hóa đơn. Nếu một thành phần
dịch vụ chỉ quản lý logic nghiệp vụ và làm việc với dữ liệu, không phải là bản thân thông điệp,
làm thế nào để nó biết được cách đọc các định dạng khác nhau khi thông điệp đó gửi tới?
Câu trả lời là thành phần dịch vụ không biết cách đọc thông điệp, bởi vì theo mặc định
thì thành phần dịch vụ hoàn toàn tách biệt với định dạng dữ liệu. Thay vào đó, một transport
(bộ truyền dẫn) sẽ mang thông tin theo và một transformer (bộ chuyển đổi) chuyển đổi thông
điệp khi cần thiết thành định dạng mà thành phần dịch vụ có thể đọc được trước khi router (bộ
điều hướng) chuyển thông điệp đó tới thành phần dịch vụ. Ví dụ, nếu hóa đơn ở dạng XML
được gửi qua giao thức HTTP thì HTTP transport sẽ mang thông điệp, router sẽ định hướng
thông điệp tới mỗi thành phần dịch vụ cần xử lý nó, và transformer sẽ thay đổi hóa đơn theo
một cách nào đó (ví dụ từ XML thành đối tượng Java) theo yêu cầu của mỗi thành phần dịch

vụ. Tất cả các việc truyền dẫn, chuyển đổi và điều hướng thông điệp hoàn toàn trong suốt đối
với thành phần dịch vụ.
Bộ chuyển đổi (Transformer) là chìa khóa để trao đổi dữ liệu, vì chúng cho phép Mule
chuyển đổi dữ liệu sang định dạng mà thành phần dịch vụ hay ứng dụng có thể hiểu được. Một
điều quan trọng là dữ liệu chỉ được chuyển đổi khi cần thiết. Thay vì chuyển đổi mọi thông
điệp tới một định dạng chung, thông điệp và dữ liệu của chúng được chuyển đổi chỉ khi nào
cần thiết tới thành phần dịch vụ hay ứng dụng nhận thông tin. Cuối cùng, mạn có thể sử dụng
nhiều cách truyền thông điệp để quản lý các kênh khác nhau, như gửi thông điệp qua HTTP và
21
sau đó chuyển tiếp nó như một thông điệp JMS sau khi đã xử lý bởi thành phần dịch vụ
Customer Data.
Sự tách biệt giữa logic nghiệp vụ với việc gửi và chuyển đổi thong điệp cho phép sự
mở rộng theo cách ta cài đặt kiến trúc và làm cho việc tùy biến logic nghiệp vụ trở nên hết sức
đơn giản không cần phải lo lắng về việc có nhiều định dạng thông điệp khác nhau. Thành phần
dịch vụ của ta có thể làm việc với dữ liệu thô của thông điệp nếu cần, nhưng không bắt buộc.
6.2.4. Kết hợp các dịch vụ với nhau
Endpoints là các phần tử cấu hình và đó là chìa khóa để kết hợp các dịch vụ cùng nhau.
Bạn chỉ định endpoints trong inbound và outbound router để yêu cầu ESB rằng phương thức
truyền tin (transport) nào được sử dụng, nơi nào thông điệp được gửi tới, và những thông điệp
nào một thành phần dịch vụ được phép nhận. Thành phần chính của endpoints là địa chỉ, được
biểu diễn như một URI (Uniform Resource Identifier), dùng để chỉ ra các phương thức truyền
tin sẽ sử dụng, địa điểm gửi tới và các tham số khác.
Ví dụ, nếu một outbound router của dịch vụ chỉ ra endpoint là />thì HTTP transport sẽ chuyển tới dịch vụ đó bất kỳ thông điệp mà được gửi vào địa chỉ đó.
Nếu inbound router chỉ định file://myserver/files/, thì File transport sẽ tạo các file mới đưa vào
địa chỉ đó để dịch vụ sử dụng. Endpoint mà ta chỉ định trong outbound router cho biết nơi mà
thông điệp sẽ tiếp tục được gửi tới, thông điệp sẽ được chuyển tới thành phần dịch vụ tại địa
chỉ đó nếu như thành phần dịch vụ được khai báo endpoint trong inbound router của nó tương
ứng với endpoint trong outbound router của thành phần dịch vụ trước đó.
22
6.3. Logic của luồng dữ liệu

Ở phần trên, chúng ta giới thiệu các thành phần cơ bản của Mule ESB theo cách nhìn
mang tính lý thuyết. Bây giờ, chúng ta một lần nữa lại sử dụng ví dụ xử lý hóa đơn để thấy
logic của các luồng dữ liệu được chuyển đi giữa các thành phần của Mule. Thông qua tiến
trình này, Mule sử dụng tệp cấu hình để xác định các thành phần dịch vụ, router, transport và
transformer cần thiết trong qui trình.
1. Khách hàng đặt hàng thông qua website của công ty, và hóa đơn được gửi đi dưới dạng
XML tới địa chỉ
2. Giao thức HTTP nhận hóa đơn dạng XML và gói nó vào thông điệp Mule. Enpoint của
Inbound router của dịch vụ Customer Data được đặt là và
inbound router của nó chỉ ra rằng thông điệp phải gửi tới dạng Java object, nhu vậy
23
HTTP transport sẽ được sắp xếp để chuyển hóa đơn dạng XML và gửi thông điệp tới
dịch vụ.
3. XML to Object Transformer sẽ chuyển hóa đơn dạng XML thành đối tượng Java. Chú
ý rằng dịch vụ kế tiếp và ứng dụng cuối cũng chờ đợi các đối tượng Java, như vậy sẽ
không cần sự chuyển đổi sau này, trong ví dụ này.
4. Bộ truyền dẫn (transport) sẽ chuyển thông điệp với nội dung đã được chuyển đổi tới
dịch vụ Customer Data.
5. Thành phần dịch vụ Customer Data truy vấn cơ sở dữ liệu khách hàng để điền thêm
thông tin về khách hàng và cập nhật nội dung của hóa đơn
6. Bộ truyền dẫn HTTP sử dụng cấu hình của outbound router để xác định nơi sẽ chuyển
tiếp thông điệp tới là
7. Bộ truyền dẫn HTTP sử dụng cấu hình inboud router của dịch vụ Inventory
Verification để nhận thông điệp và gửi nó tới thành phần dịch vụ.
8. Thành phần dịch vụ cập nhật hóa đơn với mã code của kho hàng có mặt hàng ghi trong
hóa đơn.
9. Endpoint của outbound router chỉ ra địa chỉ JMS, như vậy bộ truyền dẫn JMS sẽ
chuyển thông điệp tới ứng dụng hoàn tất hóa đơn, nó sẽ nhận được hóa đơn tại địa chỉ
đó.
7. Kết luận

Mẫu ESB mở rộng các khả năng của công nghệ ảo hóa của SOA. Các thành phần hòa giải có
thể được hợp thành từ các đơn vị chức năng tiêu chuẩn và được triển khai để tạo điều kiện
thuận lợi cho các tương tác giữa những bên yêu cầu dịch vụ và bên cung cấp dịch vụ không ăn
khớp với nhau. ESB cũng cung cấp một mô hình chung để triển khai, quản lý và quản trị các
dịch vụ. Các khái niệm ESB cho phép tách biệt các mối quan tâm theo vai trò của người sử
dụng, làm giảm bớt gánh nặng thiết kế khái niệm đối với bất kỳ người sử dụng nào, cải thiện
khả năng sử dụng kiến trúc. Các công cụ đã thành phần hóa, mô hình lập trình toàn
24