



 !"#
$%&'($
)
'*%+,-.
/%
0-1234
56756
 89:;< TP.HCM, ngày … tháng … năm
Giáo viên hướng dẫn
2
 89:=


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

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

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

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

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

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

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ả

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ề