Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin





 !"#
$%&'($
)
'*%+,-.
/%
0-1234
56756
 89:;<








TP.HCM, ngày … tháng … năm
Giáo viên hướng dẫn
2
 89:=

Khóa luận đáp ứng yêu cầu của Khóa luận cử nhân CNTT.
TP. HCM, ngày … tháng … năm …
Giáo viên phản biện
3
>?@AB3*CDCE>CFGHIEJC
33 /KCLMHNG
Trong những năm qua, hệ thống đã phát triển đáng kể về độ phức tạp và sự
tinh tế. Sự cần thiết phải có một hệ thống với độ tin cậy tốt hơn, tăng khả
năng mở rộng, và linh hoạt hơn trước đã làm nảy sinh những kiến trúc phức
tạp và tinh vi hơn. Để đáp ứng với nhu cầu gia tăng này để cho ra đời các hệ
thống tốt hơn và nhanh hơn, các nhà thiết kế và phát triển đã tận dụng gởi
nhận thông điệp như một cách để giải quyết những vấn đề phức tạp này.
Java Message Service là một phần mềm trung gian hướng thông điệp để gởi
nhận thông điệp giữa hai hay nhiều client. Java Message Service đã tận dụng
tối đa khái niệm gởi nhận thông điệp, cho phép các thành phần ứng dụng xây
dựng trên Java Enterprise Edition tạo, gởi, nhận và đọc thông điệp, cho phép
các thành phần khác nhau của ứng dụng phân tán giao tiếp hiệu quả và bất
đồng bộ.
Sự giảng dạy của các thầy cô khoa Công Nghệ Thông Tin và sự hướng dẫn
nhiệt tình, chân thành của thầy hướng dẫn Lăng Uy Tín đã cho chúng em kiến
thức và động lực để có thể hoàn thành đề tài này.Nhóm em chân thành cảm
ơn và kính chúc sức khỏe các quý thầy.
31 56ECOGPJA>CFLP5HIEJCEQRABBCSCHRTAE>U6EVWEXEAB>CFW

313 Mục tiêu
• Tìm hiểu về công nghệ Java Message Service.
• Tìm hiểu về cách lập trình cũng như sử dụng JMS.
• Xây dựng ứng dụng để minh họa các hoạt động cơ bản của JMS.
311 Nhiệm vụ
• Tìm kiếm và bổ sung kiến thức lập trình JMS và ActiveMQ cơ bản.
• Hoàn thành những chức năng chính cơ bản của ứng dụng.
4
>?@AB1*YABZGSAPIBMCA>VAE>[ABHCFW
13 >\CACFLBMCA>VAE>[ABHCFW
Gởi nhận thông điệp được sử dụng rộng rãi để giải quyết những vấn đề về độ
tin cậy và khả năng mở rộng, nó cũng được sử dụng để giải quyết một loạt các
vấn đề khác mà nhiều ứng dụng doanh nghiệp và không doanh nghiệp gặp
phải.
Tích hợp không đồng nhất là một trong những lĩnh vực chính mà gởi nhận
thông điệp đóng vai trò quan trọng. Cho dù đó là thông qua sáp nhập, mua lại,
yêu cầu kinh doanh, hoặc chỉ đơn giản là một sự đổi hướng công nghệ, ngày
càng nhiều công ty đang phải đối mặt với vấn đề tích hợp hệ thống không
đồng nhất và các ứng dụng bên trong và giữa các doanh nghiệp. Không phải
là bất thường khi gặp phải vô số các công nghệ và nền tảng trong một công ty
hoặc bộ phận bao gồm Java EE, Microsoft. NET, Tuxedo, và thậm chí cả
CICS trên mainframe.
Gởi nhận thông điệp cũng cung cấp khả năng xử lý các yêu cầu không đồng
bộ, cung cấp các kiến trúc sư và các nhà phát triển để tìm ra giải pháp giảm
thiểu hoặc loại bỏ tắc nghẽn hệ thống, tăng năng suất người dùng cuối và khả
năng mở rộng tổng thể hệ thống. Vì gởi nhận thông điệp cung cấp một mức
độ cao sự tách riêng các thành phần, các hệ thống sử dụng gởi nhận thông
điệp cũng cung cấp một mức độ cao tính linh hoạt kiến trúc và sự nhanh nhẹn.
Hệ thống gởi nhận thông điệp giữa ứng dụng và ứng dụng , khi được sử dụng
trong các hệ thống kinh doanh, thường được gọi chung là hệ thống gởi nhận

thông điệp doanh nghiệp, hoặc phần mềm trung gian hướng thông điệp
(Message-Oriented Middleware (MOM)) . Hệ thống gởi nhận thông điệp
doanh nghiệp cho phép hai hay nhiều ứng dụng trao đổi thông tin dưới dạng
thông điệp. Một thông điệp, trong trường hợp này, là một gói dữ liệu nghiệp
vụ (business data) khép kín và các header định tuyến mạng . Các dữ liệu
nghiệp vụ có trong thông điệp có thể là bất cứ cái gì, tùy thuộc vào tình huống
và thường chứa thông tin về một số giao dịch kinh doanh . Trong hệ thống gởi
nhận thông điệp doanh nghiệp, thông điệp thông báo cho một ứng dụng về
một số sự kiện hoặc sự cố trong hệ thống khác.
5
Sử dụng MOM, các thông điệp được truyền đi từ một ứng dụng này sang một
ứng dụng khác qua mạng. Sản phẩm phần mềm trung gian doanh nghiệp đảm
bảo rằng thông điệp được phân phối hợp lý giữa các ứng dụng . Ngoài ra, các
sản phẩm này thường cung cấp sức chịu lỗi, cân bằng tải, khả năng mở rộng ,
và hỗ trợ giao dịch cho các doanh nghiệp cần phải trao đổi số lượng lớn các
thông điệp một cách tin cậy.
Các nhà cung cấp gởi nhận thông điệp doanh nghiệp sử dụng các định dạng
thông điệp và các giao thức mạng khác nhau cho việc trao đổi thông điệp,
nhưng ngữ nghĩa cơ bản là giống nhau. Một API được sử dụng để tạo ra một
thông điệp, tải các dữ liệu ứng dụng (tải trọng thông điệp), gán thông tin định
tuyến, và gửi thông điệp. Cùng một API được sử dụng để nhận thông điệp
được tạo ra bởi các ứng dụng khác.
Trong tất cả các hệ thống gởi nhận thông điệp doanh nghiệp hiện đại, các ứng
dụng trao đổi thông tin thông qua kênh ảo được gọi là các điểm đến
(destination). Khi tin nhắn được gửi đi, nó được gửi đến một điểm đến (ví dụ
như queue hoặc topic), không phải là một ứng dụng cụ thể . Bất kỳ ứng dụng
nào đăng ký quan tâm đến điểm đến cũng có thể nhận được thông báo. Bằng
cách này, các ứng dụng nhận tin nhắn và các ứng dụng gửi tin nhắn được tách
riêng. Bên gửi và bên nhận không bị ràng buộc với nhau trong bất kỳ hoàn
cảnh nào và có thể gửi và nhận thông điệp theo bất kỳ cách phù hợp nào .

Tất cả các nhà cung cấp gởi nhận thông điệp doanh nghiệp cung cấp cho các
nhà phát triển ứng dụng một API cho việc gởi và nhận thông điệp. Nhà cung
cấp cài đặt giao thức mạng, định tuyến, và cơ sở quản trị riêng của mình, ngữ
nghĩa cơ bản của API dành cho nhà phát triển được cung cấp bởi các nhà
cung cấp khác nhau là như nhau. Sự tương đồng trong các API này làm cho
Java Message Service tồn tại được.
JMS là một Java API độc lập với nhà cung cấp, có thể được sử dụng với
nhiều các nhà cung cấp gởi nhận thông điệp doanh nghiệp khác nhau. JMS
tương tự như JDBC ở chỗ các nhà phát triển ứng dụng có thể sử dụng lại cùng
một API để truy cập nhiều hệ thống khác nhau . Nếu một nhà cung cấp cung
cấp dịch vụ phù hợp cho JMS, JMS API có thể được sử dụng để gửi và nhận
thông điệp cho nhà cung cấp đó. Ví dụ, bạn có thể sử dụng cùng một JMS
6
API để gửi thông điệp sử dụng SonicMQ như sử dụng WebSphere MQ của
IBM.
Phần còn lại của chương này đi sâu về tìm hiểu gởi nhận thông điệp doanh
nghiệp và chi tiết hơn về JMS.
Kết luận:
Gởi nhận thông điệp (messaging) là cách thức để giao tiếp giữa các thành
phần phần mềm hoặc các ứng dụng. Một hệ thống gởi nhận thông điệp là một
phương tiện thông tin ngang hàng (peer-to-peer): Một máy khách có thể gởi
thông điệp đi và nhận thông điệp về từ bất kì máy khách nào. Từng máy
khách kết nối tới một đại lí (agent) cung cấp công cụ truyền thông để tạo, gởi,
nhận và đọc thông điệp.
Hình 2.1: Phần mềm trung gian hướng thông điệp
Ngoài ra, gởi nhận thông điệp cho phép truyền thông phân tán. Một thành
phần có thể gửi một thông điệp cho một đích (destination), và bên nhận có thể
thu được thông điệp này từ đích. Tuy nhiên, bên gửi và bên nhận không cần
sẵn sàng cùng lúc để truyền thông. Thực tế, bên gửi không cần biết bất kì điều
gì về bên nhận; hay bên nhận không cần biết bất kì điều gì về bên gửi. Bên

gửi và bên nhận chỉ cần biết khuôn dạng thông điệp và đích (destination) để
7
sử dụng. Theo khía cạnh này, truyền thông điệp khác với các công nghệ khác,
như Remote Method Invocation (RMI), RMI yêu cầu ứng dụng phải biết rõ
các phương thức của ứng dụng ở xa.
Hình 2.2: Tính liên kết chặt chẽ của RMI
11 /]C^6>6_SPCF6BMCA>VAE>[ABHCFW
Gởi nhận thông điệp giải quyết được nhiều thách thức về mặt kiến trúc như
việc tích hợp không đồng nhất, khả năng mở rộng, tắc nghẽn hệ thống, xử lý
đồng thời, sự linh hoạt và nhanh nhẹn của kiến trúc tổng thể.
113 Tích hợp không đồng nhất
Sự giao tiếp và tích hợp giữa các nền tảng không đồng nhất là trường hợp
kinh điển nhất cần phải sử dụng gởi nhận thông điệp. Sử dụng gởi nhận thông
điệp, ta có thể gọi các service từ ứng dụng và hệ thống của một nền tảng hoàn
toàn khác. Nhiều hệ thống gởi nhận thông điệp cung cấp kết nối liền mạch
giữa Java và các ngôn ngữ khác, các nền tảng khác bằng cách tận dụng một
8
message bridge đã được tích hợp sẵn, nó sẽ chuyển 1 thông điệp gởi bằng
JMS sang 1 định dạng nội bộ chung cho thông điệp.
111 Giảm tắc nghẽn hệ thống
Việc nghẽn cổ chai trong hệ thống và ứng dụng xảy ra khi có process không
đáp ứng kịp yêu cầu được gửi đến process đó. Việc gởi nhận thông điệp có
thể được dùng để giảm thiểu hoặc triệt tiêu tắc nghẽn hệ thống. Thay vì để các
yêu cầu dồn lại trong lúc một thành phần đồng bộ xử lý chúng, các yêu cầu
được gởi đến 1 hệ thống gởi nhận thông điệp để phân phát các yêu cầu tới
nhiều thành phần message listener. Bằng cách này các nút cổ chai gặp phải
trong kết nối point-to-point đồng nhất sẽ được giảm thiểu hoặc triệt tiêu hoàn
toàn.
11` Tăng khả năng mở rộng
Cũng giống như việc giảm tắc nghẽn hệ thống, gởi nhận thông điệp cũng có

thể được sử dụng để tăng khả năng mở rộng và băng thông hệ thống, đồng
thời giảm thiểu thời gian phản hồi 1 cách hiệu quả. Khả năng mở rộng trong
hệ thống gởi nhận thông điệp được thực hiện bằng cách sử dụng nhiều
message receiver để có thể xử lý nhiều thông điệp đồng thời. Khi các thông
điệp được dồn lại chờ xử lý, số lượng thông điệp trong hàng đợi (được gọi là
độ sâu hàng đợi) tăng dần. Khi độ sâu hàng đợi tăng, thời gian phản hồi của
hệ thống cũng tăng theo và băng thông giảm. 1 cách để tăng khả năng mở
rộng của hệ thống là thêm các message listener đồng thời cho hàng đợi để xử
lý được nhiều yêu cầu cùng lúc hơn.
1 cách khác để tăng khả năng mở rộng của hệ thống là tạo ra càng nhiều hệ
thống bất đồng bộ càng tốt. Tách các thành phần ra theo cách này cho phép hệ
thống phát triển theo chiều ngang, chỉ có tài nguyên phần cứng là yếu tố giới
hạn. Tuy nhiên, middlewarer chỉ có thể được mở rộng theo chiều ngang trong
phạm vi của database. Ta có thể có hàng ngàn message listener trong 1 hàng
đợi cho phép xử lý nhiều thông điệp 1 lúc nhưng database chỉ có thể xử lý các
yêu cầu đồng thời 1 cách giới hạn.
9
114 Tăng hiệu suất người dùng cuối
Việc gởi nhận thông điệp bất đồng bộ cũng có thể tăng hiệu năng người dùng
cuối. Chẳng hạn như khi người dùng cuối gởi yêu cầu đến hệ thống từ một
giao diện người dùng trên web hoặc destop mất đến vài phút. Trong khoảng
thời gian đó người dùng phải đợi kết quả trả về, không thể làm việc tiếp. Bằng
cách gởi nhận thông điệp bất đồng bộ, nguời dùng có thể gửi yêu cầu lên hệ
thống và nhận được ngay phản hồi báo rằng yêu cầu đã được chấp nhận.
Người dùng có thể tiếp tục làm việc khác trên hệ thống trong khi yêu cầu
được thực thi. Khi yêu cầu đã hoàn tất, người dùng được thông báo rằng yêu
cầu đã được xử lý và kết quả được trả về cho người dùng. Bằng việc gởi nhận
thông điệp, người dùng có thể hoàn thành nhiều việc hơn với thời gian chờ ít
hơn, dẫn đến năng suất cao hơn.
11a Sự linh hoạt và nhanh nhẹn của kiến trúc

Việc sử dụng gởi nhận thông điệp làm 1 phần giải pháp kiến trúc doanh
nghiệp nâng cao sự linh hoạt và nhanh nhẹn của kiến trúc. Những ưu điểm
này đạt được thông qua việc sử dụng trừu tượng hóa và tách biệt các thành
phần. Bằng cách gởi nhận thông điệp, các subsystem, thành phần và cả dịch
vụ đều có thể được trừu tượng hóa tới mức chúng có thể được thay thế bằng
thành phần của client mà không cần biết về chúng.
Sự nhanh nhẹn của kiến trúc là khả năng đáp ứng nhanh trong 1 môi trường
thay đổi liên tục. Bằng việc gởi nhận thông điệp để trừu tượng hóa và tách
biệt các thành phần, ta có thể nhanh chóng đáp ứng các thay đổi trong phần
mềm, phần cứng và cả thay đổi về doanh nghiệp. Khả năng thay thế 1 hệ
thống này bằng hệ thống khác, thay đổi 1 nền tảng công nghệ, hoặc thay đổi
giải pháp từ nhà cung cấp mà không làm ảnh hưởng ứng dụng client có thể
đạt được thông qua việc trừu tượng hóa bằng gởi nhận thông điệp.
10
1` MCA>VAE>[ABHCFWEQRABbRSA>AB>CFW
Việc gởi nhận thông điệp trong doanh nghiệp không phải là một khái niệm
mới. IBM WebSphere MQ, SonicMQ, MSMQ đã có từ nhiều năm. Gần đây,
những sản phẩm gởi nhận thông điệp như ActiveMQ đã xâm nhập vào thị
trường và đang được sử dụng trong môi trường sản xuất doanh nghiệp. Ngoài
ra, sự ra đời của kiến trúc hướng dịch vụ (SOA - Service-Oriented
Architecture) đã đẩy mạnh một loại sản phẩm gởi nhận thông điệp mới gọi là
Enterprise Service Bus (ESB). Mặc dù hầu hết các ESB cho phép giao tiếp
thông qua HTTP, giao tiếp bằng việc gởi nhận thông điệp vẫn còn là tiêu
chuẩn trong hầu hết các hệ thống doanh nghiệp sản xuất.
Một khái niệm chính của việc gởi nhận thông điệp trong doanh nghiệp là các
thông điệp được phân phối bất đồng bộ từ hệ thống này sang hệ thống kia
trong cùng mạng lưới. Phân phối bất đồng bộ nghĩa là bên gửi không cần phải
đợi bên nhận nhận và xử lý thông điệp; bên gửi có thể gửi thông điệp và tiếp
tục xử lý. Các thông điệp bất đồng bộ được xem như các đơn vị tự chủ - mỗi
thông điệp đều khép kín và chứa tất cả dữ liệu cũng như trạng thái mà

business logic xử lý nó cần đến.
Trong gởi nhận thông điệp bất đồng bộ, ứng dụng sử dụng một API đơn giản
để tạo ra thông điệp, rồi chuyển qua phần mềm trung gian hướng thông điệp
(MOM - Message-Oriented Middleware) để phân phối tới một hay nhiều bên
nhận đã định trước. Một thông điệp là một gói dữ liệu nghiệp vụ được gửi từ
ứng dụng này sang ứng dụng khác qua mạng lưới. Thông điệp phải chứa tất
cả ngữ cảnh cần thiết để bên nhận tiếp tục thực thi một cách độc lập.
11
Hình 2.3: Phần mềm trung gian hướng thông điệp
Các kiến trúc MOM khác nhau ở cách thực thi, từ kiến trúc tập trung sử dụng
message server để định tuyến, đến kiến trúc phân tán chia phần xử lý server
cho máy khách. Nhiều giao thức khác nhau như TCP/IP, HTTP, SSL và IP
multicast được sử dụng ở tầng network transport. Một vài sản phẩm gởi nhận
thông điệp sử dụng phiên bản lai của cả hai cách tiếp cận, tùy vào mô hình sử
dụng.
1`3 Kiến trúc tập trung
Các hệ thống gởi nhận thông điệp trong doanh nghiệp sử dụng kiến trúc tập
trung phụ thuộc vào một message server. Một message server (còn được gọi
là message broker hay router) chịu trách nhiệm phân phối thông điệp từ một
messaging client đến các messaging client khác. Message server này tách
riêng client gửi ra khỏi các client nhận khác. Client chỉ có thể thấy messaging
server chứ không phải các clients khác. Điều này cho phép các client có thể
được thêm vào hoặc xóa đi mà không ảnh hưởng đến toàn hệ thống.
Thông thường, kiến trúc tập trung sử dụng cấu trúc liên kết hub-and-spoke.
Trong trường hợp đơn giản, có một message server tập trung và các clients
kết nối vào nó. Kiến trúc hub-and-spoke cho phép chỉ cần một số kết nối tối
12
thiểu trong khi các phần khác của hệ thống vẫn có thể giao tiếp với nhau
được.
Trong thực tế, message server tập trung có thể là một cụm các server phân tán

hoạt động như một logical unit.
Hình 2.4: Kiến trúc tập trung hub-and-spoke
1`1 Kiến trúc phân tán
Tất cả kiến trúc phân tán hiện tại đều đang sử dụng IP multicast ở tầng
network. Hệ thống gởi nhận thông điệp dựa trên multicast không có server tập
trung. Một số tính năng của server (tính bền bỉ, tính bảo mật, các giao dịch)
được nhúng vào như một phần local của client, còn việc định tuyến thông
điệp được giao cho tầng network bằng cách sử dụng giao thức IP multicast.
IP multicast cho phép các ứng dụng gia nhập một hay nhiều nhóm IP
multicast; mỗi nhóm sử dụng một địa chỉ IP để tái phân phối bất kỳ thông
điệp nào mà nó nhận được cho tất cả thành viên trong cùng nhóm. Bằng cách
13
này, ứng dụng có thể gửi thông điệp cho một địa chỉ IP multicast để tầng
network tái phân phổi các thông điệp một cách hợp lý. Không như kiến trúc
tập trung, kiến trúc phân tán không cần phải có server để định tuyến thông
điệp – tầng network xử lý việc định tuyến một cách tự động. Tuy nhiên, các
tính năng giống của server vẫn cần phải được bao gồm trong từng client, như
tính bền bỉ của thông điệp và phân phối một và chỉ một lần.
Hình 2.5: Kiến trúc phân tán IP multicast
1`` Kiến trúc lai
Một kiến trúc phân tán thường sử dụng giao thức IP multicast. Một kiến trúc
tập trung thường sử dụng giao thức TCP/IP như một cơ sở cho việc giao tiếp
giữa nhiều thành phần. Kiến trúc của một nhà cung cấp gởi nhận thông điệp
có thể kết hợp cả hai cách tiếp cận trên. Client có thể kết nối tới một deamon
process bằng TCP/IP, sau đó nó sẽ lần lượt giao tiếp với các daemon process
khác bằng các nhóm IP multicast.
14
>?@AB`*\6L[>cA>BMCA>VAE>[ABHCFW
JMS hỗ trợ hai loại mô hình gởi nhận thông điệp: point-to-point và publish-
and-subscribe. Những mô hình gởi nhận thông điệp đôi khi được gọi là miền

gởi nhận thông điệp (messaging domain). Gởi nhận thông điệp point-to-point
và publish-and-subscribe thường được viết tắt là p2p và pub/sub.
Hiểu theo nghĩa đơn giản nhất, publish-and-subscribe là việc gởi thông điệp
từ một tới nhiều, còn point-to-point là việc gởi thông điệp một-một.
Hình 3.1: JMS messaging domains
Theo góc nhìn của JMS, các client gởi nhận thông điệp được gọi là JMS
client, và hệ thống gởi nhận thông điệp được gọi là JMS provider. Một ứng
dụng JMS là một business system gồm nhiều JMS client và thường là một
JMS provider.
Ngoài ra, JMS client tạo ra thông điệp được gọi là message producer, còn
JMS client nhận thông điệp được gọi là message consumer. Một JMS client
có thể vừa là message producer vừa là message consumer.
`3 RCAEERWRCAE
15
Mô hình p2p cho phép các JMS client gởi và nhận thông điệp đồng bộ lẫn bất
đồng bộ qua các kênh ảo gọi là queue. Trong mô hình p2p, message producer
được gọi là sender và message consumers được gọi là receivers. Một điểm
đặc trưng của mô hình p2p là các thông điệp được gửi tới queue chỉ được
nhận bởi một và chỉ một receiver, mặc dù có thể có nhiều receiver cùng nghe
trên một queue để nhận cùng thông điệp.
P2p hỗ trợ gởi nhận thông điệp bất đồng bộ theo kiểu “fire and forget” cũng
như gởi nhận thông điệp đồng bộ. P2p có xu hướng chặt chẽ hơn mô hình
pub/sub vì sender thường biết thông điệp sẽ được sử dụng như thế nào và ai
nhận được nó. Ví dụ, một sender có thể gửi stock trade order đến một queue
và chờ được trả lời bằng số xác nhận. Trong trường hợp này, sender biết
receiver sẽ xử lý trade order. Một ví dụ khác là một yêu cầu bất đồng bộ để
tạo ra một báo cáo trong thời gian dài. Sender sẽ gửi yêu cầu lấy báo cáo, khi
báo cáo đã sẵn sàng, một thông báo sẽ được gửi đến sender. Trong trường hợp
này, sender biết receiver sẽ nhận message và tạo báo cáo.
Mô hình p2p hỗ trợ cân bằng tải, cho phép nhiều receiver cùng nghe trên một

queue, phân tán được tải trọng. JMS provider quản lý queue, đảm bảo rằng
một message chỉ được tiêu thụ một và chỉ một lần bởi receiver tiếp theo trong
nhóm. Đặc tả kỹ thuật của JMS không bắt buộc quy định phân phối thông
điệp trong queue phải như thế nào, mặc dù vài nhà cung cấp JMS cài đặt điều
này như một khả năng cân bằng tải. P2p cũng cung cấp các tính năng khác,
như trình duyệt queue cho phép client xem nội dung của queue trước khi tiêu
thụ thông điệp – khái niệm trình duyệt này không có trong pub/sub.
`1 Gd7Ce>SAb'Gde6QCdf
Trong mô hình pub/sub, các thông điệp được đăng vào một kênh ảo gọi là
topic. Message producer được gọi là publisher và message consumers được
gọi là subsciber. Không như mô hình p2p, thông điệp được đăng vào topic có
thể được nhiều subscriber nhận. Kỹ thuật này đôi khi được gọi là “phát sóng”
một thông điệp. Mỗi subscriber sẽ nhận được một bản sao của từng thông
điệp. Thông điệp trong mô hình pub/sub được phát tự động tới các consumer
mà không cần chúng yêu cầu thông điệp mới.
16
Mô hình pub/sub có xu hướng thiếu chặt chẽ hơn mô hình p2p vì publisher
thường không biết có bao nhiêu subscriber hoặc subscriber sẽ làm gì với
thông điệp. Ví dụ, giả sử một thông điệp được đăng vào topic mỗi khi ứng
dụng Java có exception. Publisher chỉ có trách nhiệm phát mỗi khi có
exception. Publisher không biết và thường không quan tâm thông điệp sẽ
được sử dụng như thế nào.
Có nhiều loại subscriber khác nhau trong mô hình pub/sub. Subscriber không
lâu dài là những đăng ký tạm chỉ nhận thông điệp khi chủ động nghe topic.
Subscriber lâu dài là sẽ nhận bản sao của tất cả thông điệp được đăng, kể cả
khi chúng “offline” lúc thông điệp được đăng.
17
>?@AB4*&'
JMS là 1 API dùng cho việc gởi nhận thông điệp được Sun phát triển từ JSR-
914. JMS không phải là một hệ thống gởi nhận thông điệp mà chỉ là một trừu

tượng hóa (abstraction) của những interface và class được dùng bởi
messaging client khi giao tiếp với messaging system. Giống như cách JDBC
trừu tượng hóa truy cập tới CSDL quan hệ và JNDI trừu tượng hóa truy cập
tới dịch vụ đặt tên và đường dẫn (naming and directory services), JMS cũng
trừu tượng hóa truy cập tới các messaging provider. Các messaging clients
của 1 ứng dụng có thể được mang tới nhiều sản phẩm messaging server bằng
cách sử dụng JMS.
Việc tạo ra JMS là một nỗ lực của cà ngành công nghiệp . Sun Microsystems
vượt lên dẫn trước về spec và làm việc rất chặt chẽ với các nhà cung cấp gởi
nhận thông điệp trong suốt quá trình. Mục tiêu ban đầu là để cung cấp một
Java API để kết nối với hệ thống gởi nhận thông điệp doanh nghiệp. Tuy
nhiên , điều này làm hướng tới một mục tiêu rộng lớn hơn là hỗ trợ gởi nhận
thông điệp như là một mô hình điện toán phân phối Java hàng đầu tương
đương với các hệ thống dựa trên RPC như CORBA và Enterprise JavaBeans .
Mark Hapner , trường JMS spec tại Sun Microsystems, giải thích rằng:
“Đã có một số nhà cung cấp MOM đã tham gia vào việc tạo ra các JMS. Đó
là một nỗ lực ngành công nghiệp chứ không phải là của riêng Sun. Sun chỉ là
spec dẫn đầu và đã trông nom công việc nhưng nó sẽ không có được thành
công mà không có sự tham gia trực tiếp của các nhà cung cấp gởi nhận thông
điệp. Mặc dù mục tiêu ban đầu của chúng tôi là cung cấp một Java API để kết
nối các hệ thống MOM , điều này đã thay đổi trong quá trình làm việc cho
một mục tiêu rộng lớn hơn là hỗ trợ gởi nhận thông điệp như một mô hình
điện toán phân phối Java hàng đầu bằng vị thế với RPC.”
Kết quả là một đặc điểm kỹ thuật mạnh mẽ nhất-của-giống bao gồm một tập
hợp phong phú về ngữ nghĩa phân phối thông điệp, kết hợp với một API đơn
giản nhưng linh hoạt để kết hợp gởi nhận thông điệp vào các ứng dụng. Mục
đích là ngoài các nhà cung cấp mới, các nhà cung cấp thông điệp hiện có cũng
sẽ hỗ trợ các API JMS.
JMS API có thể được chia làm 3 phần chính: API tổng quát, API P2P và API
pub/sub. API tổng quát có thể được dùng để gởi nhận message từ queue hoặc

18
topic. API P2P chỉ được dùng với queue còn API pub/sub chỉ được dùng với
topic.
Trong API tổng quát có 7 interface chính để gởi nhận JMS message:
• ConnectionFactory
• Destination
• Connection
• Session
• Message
• MessageProducer
• MessageConsumer
ConnectionFactory và Destination phải được lấy từ provider qua JNDI. Các
interface khác được tạo ra bằng factory method trong nhiều API interface. Ví
dụ: khi đã có ConnectionFactory, bạn có thể tạo Connection. Khi đã có
Connection, bạn có thể tạo Session. Khi đã có Session, bạn có thể tạo
Message, MessageProducer và MessageReceiver.
Trong JMS, đối tượng Session chứa đơn vị giao dịch công việc cho việc gởi
nhận thông điệp, Session không chứa đối tượng Connection. Đối với JDBC,
đối tượng Connection chứa đơn vị giao dịch công việc. Điều này có nghĩa là
khi sử dụng JMS, 1 ứng dụng sẽ thường có 1 đối tượng Connection nhưng
nhiều đối tượng Session.
19
Hình 4.1: Interface chính của API tổng quát
Nói chung:
• JMS cho phép các ứng dụng tạo, gửi, nhận và đọc các thông điệp, JMS
API định nghĩa một tập những interface và các ngữ nghĩa liên quan
chung cho phép các chương trình viết bằng Java truyền thông được với
nhau.
• JMS API tối thiểu hóa các khái niệm mà lập trình viên phải học để có
thể sử dụng được các sản phẩm gởi nhận thông điệp nhưng cung cấp đủ

tính năng để hỗ trợ các ứng dụng gởi nhận thông điệp phức tạp.
• JMS API cho phép gởi nhận thông điệp không chỉ liên kết lỏng lẻo
(loosely coupled) mà còn:
• Không đồng bộ: nhà cung cấp JMS có thể phân phát thông điệp cho
máy khách khi có thông điệp; máy khách không cần yêu cầu các thông
điệp mới nhận được chúng.
• Tin cậy: JMS API có thể đảm bảo một thông điệp được phân phát một
và chỉ một lần.
43 PJBMCA>VAE>[ABHCFWdgEHhABdi
RPC (Remote Procedure Call) là một thuật ngữ thường được dùng để mô tả
một mô hình điện toán phân tán hiện đang được nền tảng Java và .NET sử
dụng. Những kiến trúc dựa trên thành phần như Enterprise JavaBeans được
xây dựng dựa trên mô hình này. Công nghệ dựa trên RPC đã, đang và sẽ là
một giải pháp hữu hiệu với nhiều ứng dụng. Tuy nhiên, mô hình gởi nhận
thông điệp doanh nghiệp lại ưu việt hơn trong các loại ứng dụng phân tán nhất
định.
433 RPC liên kết chặt chẽ
Một trong những lĩnh vực thành công nhất của mô hình RPC liên kết chặt chẽ
là xây dựng ứng dụng 3 tầng hay n tầng. Trong mô hình này, một lớp trình
20
bày (presentation layer) (tầng thứ nhất) giao tiếp với business logic (tầng thứ
hai) bằng RPC, business logic có thể truy cập dữ liệu ở phía backend (tầng
thứ ba). Nền tảng J2EE của Sun và .NET của Microsoft là hai ví dụ nổi bật
nhất của kiến trúc này.
Trong J2EE, JSP và servlet đại diện cho tầng trình bày còn Enterprise
JavaBeans (EJB) là tầng thứ hai. Bất kể nó là nền tảng nào, công nghệ cốt lõi
được sử dụng trong những hệ thống này đều là phần mềm trung gian dựa trên
RPC. Trong đó, RPC là mô hình thông tin liên lạc xác định.
RPC cố gắng mô phỏng hành vi của một hệ thống chỉ chạy một process. Khi
một thủ tục từ xa được gọi, bên gọi bị chặn cho tới khi thủ tục hoàn tất và trả

quyền điều khiển về cho bên gọi. Mô hình đồng bộ này cho phép developer
xem hệ thống như đang chạy trong một process. Công việc được thực hiện
tuần tự, đảm bảo rằng các tác vụ được hoàn thành theo thứ tự định trước. Bản
chất đồng bộ của RPC liên kết chặt chẽ client (phần mềm thực hiện cuộc gọi)
với server (phần mềm nhận cuộc gọi). Vì client bị chặn nên nó không thể tiếp
tục cho tới khi server đáp ứng.
Bản chất liên kết chặt chẽ của RPC tạo ra những hệ thống có tính phụ thuộc
lẫn nhau rất cao, khi một hệ thống bị lỗi sẽ gây ảnh hưởng ngay lập tức tới
các hệ thống khác. Ví dụ như EJB server trong EJB phải hoạt động nếu muốn
servlet hoạt động.
RPC hoạt động hiệu quả trong nhiều trường hợp, nhưng tính đồng bộ và liên
kết chặt chẽ của nó là một điểm yếu nghiêm trọng trong việc xử lý hệ thống
với hệ thống khi các ứng dụng theo chiều dọc được tích hợp cùng nhau.
Trong trường hợp này, đường dây liên lạc giữa các hệ thống theo chiều dọc
nhiều và đa hướng.
21
Hình 4.2: RPC đồng bộ liên kết chặt chẽ
Khi triển khai hệ thống này sử dụng cơ chế RPC liên kết chặt chẽ sẽ nảy sinh
vấn đề quản lý kết nối many-to-many giữa các hệ thống. Khi thêm mới một
ứng dụng, ta phải quay về báo cho toàn bộ các hệ thống khác biết. Ngoài ra,
các hệ thống có thể bị sụp đổ, thời gian ngưng hoạt động dự kiến cần phải
thực thi, các interface cần phải được nâng cấp.
Khi một phần hệ thống ngưng hoạt động, tất cả sẽ bị đình trệ. Nguyên nhân
do bản chất đồng bộ, liên kết chặt chẽ và phụ thuộc lẫn nhau của hệ thống
RPC. Khi RPC liên kết chặt chẽ không phù hợp, như trong trường hợp
system-to-system, gởi nhận thông điệp cung cấp một giải pháp khác.
431 Gởi nhận thông điệp trong doanh nghiệp
Những vấn đề nảy sinh với sự tồn tại của hệ thống con có thể được giải quyết
bằng phần mềm trung gian hướng thông điệp (MOM). Một khái niệm căn bản
của gởi nhận thông điệp là giao tiếp giữa các ứng dụng phải bất đồng bộ.

22
Code để kết nối các thành phần lại với nhau giả định rằng có một thông điệp
một chiều không cần được phản hồi tức thì từ ứng dụng khác. Nói cách khác,
nó không bị chặn. Một khi thông điệp đã được gởi, client có thể làm tiếp các
tác vụ khác mà không cần đợi phản hồi. Đây là điểm khác biệt chính giữa
RPC và gởi nhận thông điệp bất đồng bộ, hiểu được ưu điểm của các hệ thống
gởi nhận thông điệp là rất quan trọng.
Trong hệ thống gởi nhận thông điệp bất đồng bộ, mỗi hệ thống con được tách
từ các hệ thống khác. Chúng giao tiếp thông qua server gởi nhận thông điệp,
nên khi một hệ thống bị lỗi không cản trở hoạt động của các hệ thống khác.
Hình 4.3: JMS cung cấp một môi trường liên kết lỏng lẻo để khi thành phần
hệ thống bị lỗi cục bộ không cản trở hoạt động chung của hệ thống
Một trong các hệ thống có thể bị lỗi không dự đoán trước được hoặc cần được
tắt một lúc nào đó trong quá trình hoạt động. JMS cung cấp sự đảm bảo phân
phối, đảm bảo rằng bên nhận sẽ nhận được thông điệp ngay cả khi có lỗi cục
bộ.
23
Đảm bảo phân phối sử dụng cơ chế store-and-forward, nghĩa là server sẽ ghi
thông điệp tới vào một vùng nhớ nếu bên nhận chưa sẵn sàng nhận. Khi ứng
dụng nhận có thể nhận thông điệp một lúc sau đó, cơ chế store-and-forward sẽ
giao tất cả thông điệp bị bên nhận bỏ lỡ lúc chưa sẵn sàng.
Hình 4.4: Cơ chế store-and-forward đảm bảo thông điệp được phân phối
Nói chung, JMS không chỉ là một dịch vụ sự kiện. Nó được thiết kế để bao
hàm diện rộng các ứng dụng doanh nghiệp như EAI, B2B, v.v… Qua quá
trình xử lý bất đồng bộ, store-and-forward và đảm bảo phân phối, nó cung cấp
khả năng sẵn sàng cao để giữ ứng dụng doanh nghiệp hoạt động liên tục
không bị gián đoạn. Nó cho phép linh hoạt trong cài đặt bằng cách cung cấp
tính năng p2p và pub/sub
Nhà cung cấp ứng dụng sẽ chọn JMS thay vì RPC trong các trường hợp sau:
• Nhà cung cấp muốn các thành phần không phụ thuộc vào thông tin về

interface của thành phần khác, do vậy các thành phần có thể được thay
thế dễ dàng.
• Nhà cung cấp muốn ứng dụng có thể chạy mà không cần mọi thành
phần phải hoạt động cùng lúc.
24
• Mô hình nghiệp vụ ứng dụng cho phép một thành phần có thể gửi thông
tin tới thành phần khác và tiếp tục xử lí không cần nhận phản hồi ngay
lập tức.
41 CjAEQk6&'
JMS provider: là hệ thống truyền thông điệp cài đặt các giao diện JMS và
cung cấp các tính năng kiểm soát và quản trị.
JMS clients: là các chương trình hoặc các thành phần tạo ra và xử lí các
Thông điệp.
Các thông điệp (message): là các đối tượng mang thông tin trao đổi giữa các
JMS clients.
Các đối tượng được quản trị (administered objects) được cấu hình từ ban đầu.
Đó là các đối tượng JMS được tạo bởi quản trị hệ thống cho clients sử dụng.
Có 2 loại đối tượng được quản trị là đích (destinations) và connection
factories.
Native clients: không sử dụng JMS API và được chỉnh sửa tương thích với
JMS
Hình 4.6: Kiến trúc JMS
25