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

Báo cáo java message service ( JMS ) đầy đủ được tham khảo từ sách java message service của tác giả O''''''''''''''''''''''''''''''''Reilly và nhiều tài liệu khác

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐH KHOA HỌC TỰ NHIÊN TP.HCM

KHOA CÔNG NGHỆ THÔNG TIN

-OOO -BÁO CÁO THỰC TẬP TỐT NGHIỆP CỬ NHÂN CNTT

NGHIÊN CỨU JMS VÀ VIẾT ỨNG DỤNG

TRAO ĐỔI THÔNG TIN

SINH VIÊN THỰC HIỆN: NGUYỄN CHÍ THANH –

LÊ MINH TRUNG

TP HỒ CHÍ MINH - 2014

Mục lục

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

TP.HCM, ngày … tháng … năm

Giáo viên hướng dẫn

NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

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

Chương 1: Giới thiệu đề tài

1.1 Lời mở đầu

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ếnthứ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

1.2 Mục tiêu và nhiệm vụ đề tài trong giai đoạn thực tập tốt nghiệp

• 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

Chương 2: Tổng quan về gởi nhận thông điệp

2.1 Khái niệm gởi nhận thông điệp

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ácvấ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ởinhậ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

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áchriê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ùngmộ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

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

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

2.2 Lợi ích của việc gởi nhận thông điệp

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ể

2.2.1 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

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.

2.2.2 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ácyê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

2.2.3 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ácyêu cầu đồng thời 1 cách giới hạn

2.2.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ằngcá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

2.2.5 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

2.3 Gởi nhận thông điệp trong doanh nghiệp

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

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

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

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ánhoạt động như một logical unit

Hình 2.4: Kiến trúc tập trung hub-and-spoke

2.3.2 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ậptrung 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

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

2.3.3 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

Chương 3: Các mô hình gởi nhận thông điệp

JMS hỗ trợ hai loại mô hình gởi nhận thông điệp: point-to-point và 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

publish-và publish-and-subscribe thường được viết tắt là p2p publish-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

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ợpnà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

3.2 Publish-and-Subscribe

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

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

Chương 4: JMS API

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ếtnố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

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:

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

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.1 RPC và gởi nhận thông điệp bất đồng bộ

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.1.1 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

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

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.1.2 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ảncủ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ộ

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ốnggở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 đượctắ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ộ

Đả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ấpkhả 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

• Mô hình nghiệp vụ ứng dụng cho phép một thành phần có thể gửi thôngtin 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.

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 mô tả cách mà các bộ phận tương tác Các công cụ quản trị cho phépbạn kết nối (bind) với các đích (destinations) và connection factories bên trong không gian tên JNDI (Java Naming and Directory Interface) API Một JMS client có thể tra cứu (lookup) các đối tượng quản lí trong không gian tên rồi sau đó thiết lập kết nối logic tới các đối tượng này thông qua JMS

Hình 4.7: Point-to-point API

Mỗi thông điệp chỉ có một người nhận

Người gửi và người nhận thông điệp không phụ thuộc thời điểm Người nhận

có thể lấy thông điệp dù nó có hoạt động khi thông điệp được gửi hay không.Người nhận xác nhận (ackowledges) xử lí thành công thông điệp

Sử dụng p2p gởi nhận thông điệp khi mọi thông điệp bạn gửi đi phải được xử

lí thành công bởi người nhận

Truyền thông điệp pub/ sub có những đặc điểm sau:

Từng thông điệp có thể có nhiều bên nhận

Publisher và subscribers có phụ thuộc vào thời điểm (timing dependency) Subscribers chỉ có thể xử lí các thông điệp sau khi nó đăng kí với topic và subscribers phải tiếp tục hoạt động khi đang xử lí thông điệp

Hình 4.8: Pub/sub API

4.3.3 Mô hình cài đặt JMS API

Các thành phần cơ bản của một ứng dụng JMS bao gồm:

• Các đối tượng được quản trị: connection factories và các đích

(destinations)

• Sessions (Các phiên)

• Message producers (gửi thông điệp)

• Message consumers(nhận thông điệp)

• Messages (các thông điệp)

Connection factory

• Một connection factory là một đối tượng được client sử dụng để tạo một kết nối tới provider Một connection factory đóng gói một tập các tham số cấu hình kết nối được định nghĩa bởi tên quản trị Mỗi

connection factory là một thể hiện của giao diện

QueueConnectionFactory hoặc TopicConnectionFactory

• Bắt đầu của 1 ứng dụng JMS client, bạn thường tiến hành tìm kiếm connection factory

Destination

• Một đích là một đối tượng được client sử dụng như nơi đến của thông điệp nó tạo ra và nguồn của các thông điệp nó xử lí Với mô hình PTP, các đích được gọi là các hàng đợi còn trong mô hình pub/sub, các đích được gọi là topics

• Một ứng dụng JMS có thể sử dụng nhiều queues và topics

Ví dụ sau: Các dòng code sau biểu diễn việc tra cứu topic được tạo ra từ trước

đó là MyTopic và gán nó cho một đối tượng Topic

Topic myTopic = (Topic) ctx.lookup("MyTopic");

Dòng code sau tra cứu một hàng đợi có tên MyQueue và gán cho đối tượng Queue

Queue myQueue = (Queue) ctx.lookup("MyQueue");

4.3.5 Connection

Một đối tượng connection đóng gói trong nó một kết nối ảo tới một JMS provider Một kết nối có thể mô tả một socket TCP/IP được mở giữa client và một provider Bạn sử dụng session để tạo ra một hoặc nhiều sessions

Connections có 2 dạng, cài đặt giao diện QueueConnection hoặc

TopicConnection Ví dụ khi bạn đã có QueueConnectionFactory hoặc

TopicConnectionFactory, bạn có thể dùng nó để tạo kết nối:

QueueConnection queueConnection =

queueConnectionFactory.createQueueConnection();

TopicConnection topicConnection = topicConnectionFactory.createTopicConnection();

Khi ứng dụng đã hoàn thành, bạn cần đóng kết nối bạn vừa tạo Không đóng kết nối thì sẽ gây lãng phí tài nguyên Đóng kết nối cũng đóng sessions của nó

và những bên gửi và nhận thông điệp trong sessions đó

queueConnection.close();

topicConnection.close();

Trước khi ứng dụng có thể xử lí thông điệp, bạn phải gọi phương thức start.Nếu bạn muốn tạm ngưng phân phát thông điệp mà không cần đóng kết nối bạn có thể gọi phương thức stop

4.3.6 Session

Một session là một bối cảnh (context) đơn luồng để gửi và nhận các thông điệp Bạn sử dụng session để tạo: người gửi thông điệp, người nhận thông điệp, và thông điệp

Session giống như connection có 2 dạng, cài đặt giao diện QueueSession hoặcTopicSession

Ví dụ: nếu bạn đã tạo ra 1 đối tượng TopicConnection, hãy dùng nó để tạo ra TopicSession:

TopicSession topicSession =

topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);

Tương tự, bạn dùng một QueueConnection để tạo QueueSession

Ví dụ: Sử dụng QueueSession để tạo một bên gửi cho hàng đợi myQueue, và dùng TopicSession để tạo ra publisher cho topic myTopic :

4.3.8 Consumer

Một bên xử lí thông tin (message consumer) là một đối tượng được tạo ra bởi một session và được sử dụng để nhận các thông điệp được gửi tới đích Một bên xử lí thông điệp cho phép một client JMS đăng kí đích mà nó quan tâm với một JMS provider JMS provider quản lí việc phân phối thông điệp từ đích tới một bên xử lí của đích đó

Ví dụ:

QueueReceiver queueReceiver = queueSession.createReceiver(myQueue);

TopicSubscriber topicSubscriber = topicSession.createSubscriber(myTopic);

Bên xử lí thông điệp dạng p2p cài đặt giao diện QueueReceiver Dạng

pub/sub cài đặt giao diện TopicSubscriber

Với cả QueueReceiver và TopicSubscriber bạn có thể dùng phương thức receiver để nhận thông điệp một cách đồng bộ Bạn có thể dùng phương thức này bất cứ khi nào sau khi đã gọi phương thức start

• Thuộc tính (tùy chọn)

• Thân (tùy chọn)

Header

Minh họa: cách thức cài đặt các thành phần tiêu đề

Nội dung Thông điệp

Ví dụ để tạo ra thông điệp và gửi TextMessage tới một hàng đợi, bạn có thể dùng:

TextMessage message =

queueSession.createTextMessage();

message.setText(msg_text);//msg_text is a StringqueueSender.send(message);

Ở bên nhận Thông điệp sẽ có kiểu Message và phải được ép thành kiểu chính xác của nó

Message m = queueReceiver.receive();

if (m instanceof TextMessage) { TextMessage message = (TextMessage) m;

System.out.println("Reading message: " + message.getText());

} else { // Handle error

}

Chương 5: Cấu tạo của một JMS message

Chương này tập trung vào giải phẫu của một thông điệp : các bộ phận riêng lẻtạo nên thông điệp (headers, properties, và các loại khác nhau của tải trọng thông điệp)

Message là phần quan trọng nhất của toàn bộ đặc điểm kỹ thuật JMS Tất cả

dữ liệu và sự kiện trong một ứng dụng JMS đều giao tiếp bằng những thông điệp , trong khi phần còn lại của JMS tồn tại để tạo thuận lợi cho việc chuyển giao các thông điệp Thông điệp cũng giống như mạch máu của hệ thống.Một thông điệp JMS mang dữ liệu ứng dụng và cung cấp các thông báo sự kiện Vai trò của nó là độc nhất trong điện toán phân tán Trong hệ thống dựa trên RPC (CORBA, Java RMI , DCOM), tin nhắn là một lệnh để thực hiện một phương pháp hoặc thủ tục, nó chặn bên gửi cho đến khi nhận được trả lời Một thông điệp JMS không phải là một lệnh , nó truyền dữ liệu và nói cho người nhận biết có một điều gì đó đã xảy ra Một thông điệp không ra lệnh cho người nhận nên làm gì và người gửi không chờ đợi phản hồi Điều này tách riêng người gửi và người nhận , làm cho hệ thống nhắn tin và thông điệp của chúng năng động và linh hoạt hơn rất nhiều so với mô hình yêu cầu /trả lời

Một Message object có ba phần : message header, properties, và cuối cùng là

dữ liệu của thông điệp, được gọi là tải trọng hoặc phần thân thông điệp (xem hình 5.1)

Thông điệp có nhiều loại được xác định bởi tải trọng chúng mang theo tải trọng tự nó có thể rất được cấu trúc, như với StreamMessage và

BytesMessage objects, hoặc khá vô cấu trúc , như với TextMessage ,

ObjectMessage , và MapMessage Thông điệp có thể mang dữ liệu quan trọnghoặc đơn giản là hoạt động như thông báo của các sự kiện trong hệ thống Trong hầu hết các trường hợp, các thông điệp vừa là thông báo vừa là các phương tiện để mang dữ liệu

Hình 5.1: Cấu tạo một JMS message

Các message header cung cấp siêu dữ liệu về thông điệp mô tả người hoặc những gì tạo ra các thông báo, khi nào nó được tạo ra, bao lâu các dữ liệu có giá trị, v.v… Header cũng chứa thông tin định tuyến mô tả các điểm đến của các thông điệp (topic hoặc queue), làm thế nào một thông điệp có thể được công nhận, và nhiều hơn nữa Ngoài header, thông điệp có thể mang đặc tính

có thể được định nghĩa và thiết lập bởi JMS client JMS consumer có thể chọn

để nhận thông điệp dựa trên các giá trị nhất định của header và properties, sử dụng một cơ chế lọc đặc biệt gọi là bộ chọn tin nhắn

5.1 Header

Mỗi thông điệp JMS có một bộ các header tiêu chuẩn Mỗi header được xác định bởi một tập hợp các method accessor và mutator theo các thành ngữ setJMS <HEADER> (), getJMS < HEADER > () Đây là một định nghĩa một phần của Message interface cho thấy tất cả các method của JMS header:

public interface Message {

public Destination getJMSDestination()throws JMSException;

public void setJMSDestination(Destination

public void setJMSExpiration(long

public Destination getJMSReplyTo()throws