Ứng dụng mô hình hàng đợi thông điệp trong kiến trúc khách - chủ

Tóm tắt cô đọng các luận điểm cơ bản của luận văn Trong quyển luận văn này, tác giả xin tóm tắt lại một số luận điểm cơ bản và đóng góp của tác giả như sau:  Khảo sát và nghiên cứu các

ĐẠI HỌC QUỐC GIA HÀ NỘI

ĐẠI HỌC QUỐC GIA HÀ NỘI

Hà Nội 06 – 2011

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn: “ỨNG DỤNG MÔ HÌNH HÀNG ĐỢI THÔNG ĐIỆP TRONG KIẾN TRÚC KHÁCH – CHỦ” là kết quả nghiên cứu của riêng tôi,

không sao chép của riêng ai Các số liệu và bảng biểu là hoàn toàn chính xác và nội dung luận văn có tham khảo và sử dụng các tài liệu, thông tin đuợc đăng tải trên các tác phẩm, tạp chí và các trang web theo danh mục tài liệu của luận văn

Hà nội ngày 28 tháng 06 năm 2011

Tác giả luận văn

Nguyễn Quang Dũng

LỜI CÁM ƠN

Trước tiên tôi xin chân thành cảm ơn PGS.TS Đỗ Trung Tuấn, người thầy đã hướng dẫn tận tình, chỉ bảo thẳng thắn và đã động viên tôi rất nhiều để tôi hoàn thành bản luận văn này

Tôi xin chân thành cảm ơn các thầy, cô giáo của Trường Đại học Công nghệ đặc biệt là các thầy, cô giáo trong bộ môn Công nghệ phần mềm đã giảng dạy, động viên và tạo điều kiện thuận lợi cho tôi trong quá trình học tập và làm luận văn

Tôi xin chân thành cám ơn lãnh đạo, các bạn đồng nghiệp tại Phòng Phát triển công nghệ, Công ty Đầu tư và phát triển công nghệ VTC Intecom đã giúp đỡ tôi trong quá trình học tập và làm luận văn

Sau cùng, tôi xin đuợc gửi lời cám ơn sâu sắc đến gia đình, người thân, bạn

bè - những người đã động viên, giúp đỡ tôi cả trong học tập và cuộc sống

Hà nội ngày 28 tháng 06 năm 2011

Tác giả luận văn

Nguyễn Quang Dũng

Mục lục

Mục lục i

Bảng ký hiệu các chữ viết tắt iii

Danh mục các bảng iv

Danh mục hình vẽ v

Danh mục hình vẽ v

Mở đầu 1

Lý do chọn đề tài 1

Tóm tắt cô đọng các luận điểm cơ bản của luận văn 1

Nội dung của luận văn 1

Chương 1 Tổng quan về kiến trúc khách – chủ và hàng đợi thông điệp 3

1.1 Kiến trúc khách – chủ 3

1.1.1 Mô hình khách – chủ 3

1.1.2 Máy khách 5

1.1.3 Máy chủ 5

1.1.4 Đồng bộ – Không đồng bộ 6

1.2 Hàng đợi thông điệp 7

1.2.1 Thông điệp 7

1.2.2 Hàng đợi thông điệp 7

1.2.3 Hạn chế 8

1.3 Kết luận 8

Chương 2 Hàng đợi thông điệp trong kiến trúc khách – chủ 10

2.1 Kiến trúc hàng đợi thông điệp 10

2.1.1 Ứng dụng khách 10

2.1.2 Ứng dụng chủ 11

2.1.3 Thành phần định tuyến 11

2.2 Lý do sử dụng hàng đợi thông điệp 12

2.1.1 Các chương trình có thể chạy ở các thời điểm khác nhau 13

2.1.2 Không rằng buộc về cấu trúc chương trình 13

2.1.3 Các chương trình được tách riêng biệt khỏi sự phức tạp của mạng 16

2.1.4 Chương trình có thể được sắp xếp, lên lịch để sử dụng tài nguyên một cách tốt nhất 17

2.1.5 Sự phối hợp giữa các tài nguyên 17

2.1.6 Dễ dàng di chuyển và sử dụng lại mã chương trình 19

2.1.7 Khi nào sử dụng hàng đợi thông điệp 19

2.1.8 Lợi ích của hàng đợi thông điệp so với cơ sở dữ liệu 20

2.3 Vòng đời của một thông điệp 20

2.4 Quá trình kết nối 21

2.5 Các thuộc tính của một hàng đợi thông điệp 22

2.5.1 Tên 22

2.5.2 Tính duy nhất 22

2.5.3 Tính duy trì 22

2.5.4 Tự động xóa 22

2.5.5 Một số thuộc tính khác 23

2.6 Các yêu cầu của một hàng đợi thông điệp 23

2.6.1 Yêu cầu chức năng 23

2.6.2 Yêu cầu khác 25

2.7 Một số hệ thống hàng đợi thông điệp phổ biến 27

2.7.1 CORBA 27

2.7.2 IBM WebSphere MQ 28

2.7.3 Microsoft Message Queueing 29

2.8 Kết luận 29

Chương 3 Thiết kế hàng đợi thông điệp 30

3.1 Mô hình hàng đợi 31

3.1.1 Hàng đợi vào trước ra trước 31

3.1.2 Hàng đợi có ưu tiên 31

3.2 Mô hình luồng thời gian 31

3.3 Hiệu năng của hệ thống 33

3.3.1 Một số định nghĩa 33

3.4 Thông lượng hệ thống 34

3.4.1 Mô hình giao tiếp đồng bộ 34

3.4.2 Mô hình hàng đợi thông điệp vào trước ra trước 34

3.4.3 Mô hình hàng đợi thông điệp có độ ưu tiên 36

Chương 4 Thử nghiệm về áp dụng hàng đợi thông điệp để phân tải trong ứng dụng kiến trúc khách – chủ 39

4.1 Bài toán thử nghiệm 39

4.1.1 Mô tả bài toán 39

4.1.2 Lý do sử dụng hàng đợi thông điệp 42

4.2 Lựa chọn hàng đợi thông điệp cho hệ thống 44

4.2.1 Hệ thống lưu thông điệp tạm thời 44

4.2.2 Hệ thống lưu thông điệp bền vững 45

4.3 Cài đặt và tích hợp thử hệ thống 46

4.3.1 Thành phần GameClient 47

4.3.2 Thành phần GameGuard 48

4.4 Kết quả thử nghiệm 48

4.4.1 Kết quả thử nghiệm truyền dữ liệu 48

4.4.2 Kết quả khi tích hợp với hệ thống 49

Chương 5 Kết luận 52

5.1 Đánh giá kết quả 52

5.2 Kết luận 52

Tài liệu tham khảo 53

Bảng ký hiệu các chữ viết tắt

Tên viết tắt Tiếng Viê ̣t Tiếng Anh

XML Ngôn ngữ đánh dấu mở rộng eXtensible Markup Language

thông điệp của Microsoft

MicroSoft Message Queue

SAFMQ Tên một hệ thống hàng đợi

Danh mục các bảng

Bảng 1: Tham số thời gian hệ thống 34Bảng 2: Kết quả truyền dữ liệu 49

Danh mục hình vẽ

Hình 1: Kiến trúc hàng đợi thông điệp 10

Hình 2: Sự thực thi của các chương trình trong hệ thống 13

Hình 3: Quan hệ một - nhiều 14

Hình 4: Quan hệ nhiều – một 15

Hình 5: Mối quan hệ độc lập của các chương trình 16

Hình 6: Quan hệ giữa các chương trình 16

Hình 7: Thay đổi chương trình 18

Hình 8: Hàng đợi thông điệp 30

Hình 9: Mô hình luồng thời gian của hệ thống giao tiếp thông thường 31

Hình 10: Thời gian xử lý không đồng bộ lớn hơn thời gian phục vụ của hàng đợi 32 Hình 11: Thời gian xử lý không đồng bộ nhỏ hơn thời gian phục vụ của hàng đợi 33 Hình 12: Chương trình Guard trong hệ thống trò chơi trực tuyến 40

Hình 13: Tổng quan hệ thống Guard 42

Hình 14: Mô hình cài đặt hệ thống GameGuard với GameClient tại VTC 47

Hình 15: Hệ thống chạy ổn định khi tích hợp với Audition 50

Hình 16: Thông tin tài khoản người chơi sử dụng công cụ lừa dối 51

Hình 17: Thông tin các công cụ lừa dối được sử dụng 51

Mở đầu

Lý do chọn đề tài

Ngày nay, kiến trúc khách – chủ là một kiến trúc phổ biến, được áp dụng nhiều trong các hệ thống phần mềm Với các hệ thống sử dụng kiến trúc này, việc giao tiếp giữa chương trình khách và chương trình chủ là một thành phần quan trọng, chiếm nhiều thời gian và công sức phát triển Việc lựa chọn sử dụng một phương thức cho phù hợp với yêu cầu của từng hệ thống có thể mang lại nhiều lợi ích, tiết kiệm chi phí phát triển cũng như chi phí triển khai và nâng cấp

Đề tài này nghiên cứu việc áp dụng mô hình hàng đợi thông điệp vào kiến trúc khách – chủ, tìm hiểu xem áp dụng hàng đợi thông điệp vào hệ thống nào sẽ mang lại độ tin cậy cũng như hiệu quả cao hơn các cách giao tiếp thông thường

Tóm tắt cô đọng các luận điểm cơ bản của luận văn

Trong quyển luận văn này, tác giả xin tóm tắt lại một số luận điểm cơ bản và đóng góp của tác giả như sau:

 Khảo sát và nghiên cứu các cách truyền thông điệp trong kiến trúc khách – chủ

 Đánh giá hiệu suất của hệ thống khi sử dụng hàng đợi thông điệp là phương thức giao tiếp khách – chủ

 Ứng dụng thực thế: Ứng dụng hàng đợi thông điệp vào một hệ thống

cụ thể - Hệ thống phần mềm bảo vệ trò chơi trực tuyến trên nền Windows chống lại các hacker Hàng đợi thông điệp sẽ được sử dụng làm giải pháp cho việc giao tiếp giữa khách – chủ của hệ thống Từ đó đưa ra kết quả và các đánh giá cho hệ thống

Nội dung của luận văn

Luận văn sẽ nghiên cứu về hàng đợi thông điệp trong kiến trúc khách – chủ gồm 5 chương:

Chương 1: Tổng quan về kiến trúc khách – chủ và hàng đợi thông điệp

Chương 1 trình bày các kiến thức chung nhất về kiến trúc khách – chủ và các

Chương 2: Hàng đợi thông điệp trong kiến trúc khách – chủ

Chương 2 tìm hiểu chi tiết về hàng đợi thông điệp, các lý do tại sao việc áp dụng mô hình hàng đợi thông điệp trong kiến trúc khách chủ mang lại những lợi ích nhất định Đồng thời, chương này cũng tìm hiểu và đánh giá về một số loại hệ thống

cụ thể nên áp dụng hàng đợi thông điệp làm cơ chế giao tiếp khách – chủ

Chương 3: Thiết kế hàng đợi thông điệp

Chương 3 tìm hiểu về các thành phần của một hệ thống hàng đợi thông điệp Trong chương này, chúng ta cũng đưa ra một số đánh giá, nhận xét về hiệu suất của

hệ thống khi sử dụng hàng đợi thông điệp so với khi không sử dụng hàng đợi thông điệp, cũng như việc lựa chọn loại hàng đợi thông điệp nào sẽ có những lợi ích và chi phí cụ thể

Chương 4: Thử nghiệm về áp dụng hàng đợi thông điệp để phân tải trong ứng dụng kiến trúc khách – chủ

Chương 4 trình bày về thử nghiệm việc áp dụng mô hình hàng đợi thông điệp

để phân tải trong kiến trúc khách – chủ Trong chương này, mô hình hàng đợi thông điệp sẽ được đưa vào một hệ thống phần mềm cụ thể, trong đó hàng đợi thông điệp đóng vai trò giao tiếp khách – chủ trong hệ thống để chuyển tải các thông tin cần thiết lên máy chủ

Chương 5: Kết luận

Chương 5 đưa ra một số đánh giá về kết quả thử nghiệm và kết luận

Chương 1 Tổng quan về kiến trúc khách – chủ và hàng đợi thông điệp

1.1 Kiến trúc khách – chủ

Thuật ngữ ứng dụng chủ được dùng cho những chương trình thi hành như một dịch vụ trên toàn mạng Các máy chủ này chấp nhận tất cả các yêu cầu hợp lệ đến từ mọi nơi trên mạng, sau đó nó thi hành dịch vụ và trả kết quả về máy yêu cầu Một chương trình được coi là khách khi nó gửi các yêu cầu tới máy có chương trình chủ

và chờ đợi câu trả lời từ chương trình chủ Chương trình chủ và khách nói chuyện với nhau bằng các thông điệp thông qua một cổng truyền thông liên tác Để một chương trình chủ và một chương trình khách có thể giao tiếp được với nhau thì giữa chúng phải có một chuẩn để nói chuyện, chuẩn này được gọi là giao thức Nếu một chương trình khách nào đó muốn yêu cầu lấy thông tin từ chương trình thì nó phải tuân theo giao thức mà chương trình chủ đó đưa ra Bản thân chúng ta khi cần xây dựng một mô hình khách – chủ cụ thể thì ta cũng có thể tự tạo ra một giao thức riêng nhưng thường chúng ta chỉ làm được điều này ở tầng ứng dụng của mạng Với

sự phát triển mạng như hiện này thì có rất nhiều giao thức chuẩn trên mạng ra đời nhằm đáp ứng nhu cầu phát triển này Các giao thức chuẩn (ở tầng mạng và vận chuyển) được sử dụng rộng rãi nhất hiện nay như: giao thức TCP/IP, giao thức SNA của IBM, OSI, ISDN, X.25 hoặc giao thức LAN-to-LAN NetBIOS Một máy tính chứa chương trình chủ được coi là một máy chủ hay máy phục vụ và máy chứa chương trình khách được coi là máy khách Mô hình mạng trên đó có các máy chủ

và máy khách giao tiếp với nhau theo một hoặc nhiều dịch vụ được gọi là mô hình khách – chủ Thực tế thì mô hình khách – chủ là sự mở rộng tự nhiên và tiện lợi cho việc truyền thông liên tiến trình trên các máy tính cá nhân Mô hình này cho phép xây dựng các chương trình khách – chủ một cách dễ dàng và sử dụng chúng để liên tác với nhau để đạt hiệu quả hơn

1.1.1 Mô hình khách – chủ

Mô hình khách – chủ là mô hình tổng quát nhất, trên thực tế thì một máy chủ

yêu cầu vừa nhận được cho chương trình chủ khác ví dụ như cơ sở dữ liệu vì bản thân nó không thể xử lý yêu cầu này được Máy chủ có thể thi hành các nhiệm vụ đơn giản hoặc phức tạp Ví dụ như một máy chủ trả lời thời gian hiện tại trong ngày, khi một máy khách yêu cầu lấy thông tin về thời gian nó sẽ phải gửi một yêu cầu theo một tiêu chuẩn do ứng dụng chủ định ra, nếu yêu cầu được chấp nhận thì ứng dụng chủ sẽ trả về thông tin mà ứng dụng khách yêu cầu Có rất nhiều các dịch vụ chủ trên mạng nhưng nó đều hoạt động theo nguyên lý là nhận các yêu cầu từ chương trình khách sau đó xử lý và trả kết quả cho chương trình khách yêu cầu Thông thường chương trình chủ và khách được thi hành trên hai máy khác nhau Cho dù lúc nào chương trình chủ cũng ở trạng thái sẵn sàng chờ nhận yêu cầu từ chương trình khách nhưng trên thực tế một tiến trình liên tác qua lại giữa khách và chủ lại bắt đầu ở phía máy khách, khi mà ứng dụng khách gửi tín hiệu yêu cầu tới ứng dụng chủ Các chương trình chủ thường đều thi hành ở mức ứng dụng (tầng ứng dụng của mạng) Sự thuận lợi của phương pháp này là nó có thể làm việc trên bất cứ một mạng máy tính nào có hỗ trợ giao thức truyền thông chuẩn cụ thể ở đây là giao thức TCP/IP Với các giao thức chuẩn này cũng giúp cho các nhà sản xuất có thể tích hợp nhiều sản phẩm khác nhau của họ lên mạng mà không gặp phải khó khăn

gì Với các chuẩn này thì các chương trình chủ cho một dịch vụ nào đấy có thể thi hành trên một hệ thống chia sẻ thời gian với nhiều chương trình và dịch vụ khác hoặc nó có thể chạy trên chính một máy tính các nhân bình thường Có thể có nhiều chương trình chủ cùng làm một dịch vụ, chúng có thể nằm trên nhiều máy tính hoặc một máy tính Với mô hình trên chúng ta nhận thấy rằng mô hình khách – chủ chỉ mang đặc điểm của phần mềm không liên quan gì đến phần cứng mặc dù trên thực

tế yêu cầu cho một máy chủ là cao hơn nhiều so với máy khách Lý do là bởi vì máy chủ phải quản lý rất nhiều các yêu cầu từ các máy khách khác nhau trên mạng

1.1.1.1 Ưu và nhược điểm chính

Có thể nói rằng với mô hình khách – chủ thì mọi thứ dường như đều nằm trên bàn của người sử dụng, nó có thể truy cập dữ liệu từ xa (bao gồm các công việc như gửi và nhận tệp, tìm kiếm thông tin, ) với nhiều dịch vụ đa dạng mà mô hình cũ không thể làm được Mô hình khách – chủ cung cấp một nền tảng lý tưởng cho phép tích hợp các kỹ thuật hiện đại như mô hình thiết kế hướng đối tượng, hệ chuyên gia,

hệ thông tin địa lý Một trong những vấn đề nảy sinh trong mô hình này đó là tính

an toàn và bảo mật thông tin trên mạng, do phải đảm bảo an toàn trong việc trao đổi

dữ liệu giữa hai máy ở hai khu vực khác nhau

1.1.2 Máy khách

Trong mô hình khách – chủ, người ta còn định nghĩa cụ thể cho một máy khách là một máy trạm mà chỉ được sử dụng bởi một người dùng với để muốn thể hiện tính độc lập cho nó Máy khách có thể sử dụng các hệ điều hành bình thường như Windows, DOS, Linux, OS/2 Bản thân mỗi một ứng dụng chủ cũng đã được tích hợp nhiều chức năng trên hệ điều hành mà nó chạy, nhưng khi được nối vào một mạng LAN, WAN theo mô hình khách – chủ thì nó còn có thể sử dụng thêm các chức năng do hệ điều hành mạng cung cấp với nhiều dịch vụ khác nhau (cụ thể

là các dịch vụ do các chương trình chủ trên mạng này cung cấp), ví dụ như nó có thể yêu cầu lấy dữ liệu từ một máy chủ hay gửi dữ liệu lên máy chủ đó Thực tế trong các ứng dụng của mô hình khách – chủ, các chức năng hoạt động chính là sự kết hợp giữa khách và chủ với sự chia sẻ tài nguyên, dữ liệu trên cả hai máy

Vai trò của chương trình khách

Trong mô hình khách – chủ, chương trình khách được coi như là người sử dụng các dịch vụ trên mạng do một hoặc nhiều máy chủ cung cấp và chương trình chủ được coi như là người cung cấp dịch vụ để trả lời các yêu cầu của các chương trình khách Điều quan trọng là phải hiểu được vai trò hoạt động của nó trong một

mô hình cụ thể, một máy khách trong mô hình này lại có thể là máy chủ trong một

mô hình khác Ví dụ cụ thể như một máy trạm làm việc như một máy chủ bình thường trong mạng LAN nhưng đồng thời nó có thể đóng vai trò như một máy in chủ cung cấp dịch vụ in ấn từ xa cho nhiều ứng dụng khác (ứng dụng khách) sử dụng Chương trình khách được hiểu như là bề nổi của các dịch vụ trên mạng, nếu

có thông tin vào hoặc ra thì chúng sẽ được hiển thị trên máy khách

1.1.3 Máy chủ

Máy chủ còn được định nghĩa như là một máy tính nhiều người sử dụng Vì một máy chủ phải quản lý nhiều yêu cầu từ các chương trình khách trên mạng cho nên nó hoạt động sẽ tốt hơn nếu hệ điều hành của nó là đa nhiệm với các tính năng

ứng dụng chạy trên máy chủ phải được tách rời nhau để một lỗi của ứng dụng này không làm hỏng ứng dụng khác Tính đa nhiệm đảm bảo một tiến trình không sử dụng toàn bộ tài nguyên hệ thống Chương trình chủ có vai trò như là một nhà cung cấp dịch vụ cho các chương trình khách yêu cầu tới khi cần, các dịch vụ như cơ sở

dữ liệu, in ấn, truyền tệp, hệ thống Các ứng dụng chủ cung cấp các dịch vụ mang tính chức năng để hỗ trợ cho các hoạt động trên các máy khách có hiệu quả hơn Sự

hỗ trợ của các dịch vụ này có thể là toàn bộ hoặc chỉ một phần thông qua IPC

1.1.4 Đồng bộ – Không đồng bộ

Rất nhiều giao thức giao tiếp đang được phổ biến hiện tại là các giao tiếp đồng

bộ hóa Một ví dụ là giao thức HTTP – sử dụng trong World Wide Web và các dịch

vụ web, ở đó người dùng gửi một yêu cầu tới một trang web và chờ đợi cho đến khi trang web phục vụ

Tuy nhiên, trong nhiều trường hợp, việc đồng bộ hóa là không cần thiết Một

ví dụ là AJAX, việc truyền dữ liệu (dữ liệu thuần hoặc XML) để cập nhật một phần của trang web với nhiều thông tin có liên quan hơn Các ứng dụng AJAX có thể gửi yêu cầu tới các máy chủ để nhận về chỉ những dữ liệu cần thiết Google sử dụng giải pháp này trong ứng dụng Google Suggest của họ, một tính năng tìm kiếm cho phép trình duyệt gửi dữ liệu đang được gõ bởi người dùng lên máy chủ Google và trả lại một danh sách những truy vấn đầy đủ mà có thể phù hợp với từ khóa của người dùng Danh sách này được cập nhật không đồng bộ trong quá trình gõ của người sử dụng

Một vài ví dụ khác của việc sử dụng giao tiếp không đồng bộ

 Một ứng dụng cần thông báo tới một ứng dụng khác rằng có một sự kiện xảy ra, nhưng không cần đợi phản hồi

 Trong một hệ thống thông báo, một ứng dụng sẽ công bố thông tin cho rất nhiều máy khách có thể truy cập thông báo đó

Trong cả hai ví dụ trên, ứng dụng gửi thông tin đều không phải quan tâm xem ứng dụng cần nhận thông tin có nhận được thông tin đó hay không hay ứng dụng đó

có hoạt động bình thường hay không? Trong thực tế, hệ thống có rất nhiều giao tiếp giữa các tiến trình Một số trong đó cần được giao tiếp đồng bộ hóa, một số không

Vì vậy, chúng ta có thể xem xét để sử dụng hàng đợi thông điệp như một phần của

hệ thống (cho các giao tiếp không cần đồng bộ hóa) để tăng hiệu suất chung của hệ thống

1.2 Hàng đợi thông điệp

1.2.2 Hàng đợi thông điệp

Hàng đợi thông điệp là một cơ chế cho phép tiến trình gửi và tiến trình nhận trao đổi thông điệp Tiến trình gửi sẽ đặt thông điệp vào hàng đợi, trong khi tiến trình nhận lấy thông điệp từ hàng đợi để xử lý

Một hệ thống hàng đợi thông điệp có thể được xem là một phần của hệ phân tán, khi mà các ứng dụng phân tán trao đổi thông tin qua hàng đợi Hàng đợi thông điệp chứa thông tin (còn được gọi là thông điệp) trên bộ nhớ hoặc ổ cứng, sau đó điều phối chúng theo thứ tự tới một hoặc nhiều ứng dụng để xử lý Một hàng đợi thông điệp là một thực thể dùng để lưu trữ và điều phối thông tin, và vì vậy hiển nhiên đó là một đối tượng

Một hàng đợi thông điệp có rất nhiều thuộc tính như: thông điệp trong hàng đợi là riêng tư hay được chia sẻ, thông điệp mang tính lâu dài hay tạm thời, các thuộc tính về tên khách, tên chủ … Hàng đợi thông điệp cung cấp một giao thức giao tiếp không đồng bộ, có nghĩa là người gửi và người nhận thông điệp không cần giao tiếp với hàng đợi tại cùng một thời điểm Thông điệp đươc đặt vào một hàng đợi và được lưu trữ cho tới khi nó được chuyển tới người nhận Hầu hết các hàng đợi thông điệp đều quy định giới hạn về kích cỡ của dữ liệu có thể được truyền đi như một thông điệp đơn lẻ

Trong thực tế, một số hàng đợi thông điệp được thiết kế chuyên biệt, phục vụ cho một hệ thống cụ thể nào đó với chỉ chức năng truyền thông điệp bên trong một

hệ điều hành hoặc một chương trình cụ thể nào đó Tuy nhiên, hầu hết các hàng đợi thông điệp cho phép chuyển thông điệp giữa các hệ thống khác nhau, kết nối các chương trình và các hệ điều hành khác nhau Các hệ thống hàng đợi thông điệp thường được thiết kế theo hướng mềm dẻo, để đảm bảo thông điệp không bị mất ngay cả khi hệ thống mạng bị lỗi

Có rất nhiều lựa chọn cho việc sử dụng hệ thống hàng đợi thông điệp như Jboss Messaging, JORAM, Apache ActiveMQ, Sun Open Message Queue, ApacheQpid hay HTTPSQS

Thông thường, các hệ thống hàng đợi thông điệp cho phép truyền thông điệp giữa các hệ thống khác nhau, kết nối các ứng dụng và các hệ điều hành khác nhau Chúng cũng thường đảm bảo ràng thông điệp không bị mất mát ngay cả khi hệ thống gặp lỗi

1.2.3 Hạn chế

Điểm hạn chế lớn nhất của các hệ thống hàng đợi thông điệp là nó yêu cầu rất nhiều các thành phần khác nhau trong một hệ thống Với bất kỳ hệ thống nào, việc thêm vào một thành phần có thể dẫn tới việc giảm hiệu suất và tính tin cận, và có thể

là khó nâng cấp, bảo trì

Hơn nữa, việc có nhiều chương trình giao tiếp không đồng bộ, nếu nhiều chương trình khách muốn đợi phản hồi từ máy chủ trước khi tiếp tục xử lý (ví dụ trong các việc tính toán thời gian thực) sẽ gây ra nhiều vấn đề Bởi vì hàng đợi thông điệp vốn dĩ là không đồng bộ, nên thường nó không thích hợp trong các trường hợp này

Thiếu chuẩn hóa: Việc thiếu một sự chuẩn hóa cho các hàng đợi thông điệp có thể gây ra nhiều vấn đề khác nhau Mỗi nhà phát triển (IBM, Microsoft và nhiều nhà phát triển khác) có một kiến trúc khác nhau, có giao diện (API) khác nhau và có những công cụ quản lý khác nhau

1.3 Kết luận

Như vậy, sử dụng hàng đợi thông điệp trong ứng dụng như là một thành phần giao tiếp khách – chủ sẽ mang lại nhiều lợi ích Trước hết, chúng ta có thể chia nhỏ

hệ thống thành nhiều chương trình nhỏ Các chương trình này có thể giao tiếp với nhau (thông qua hàng đợi thông điệp) và cùng chia sẻ tài nguyên hệ thống Nhờ đó, chúng ta có thể dễ dàng quản lý các thành phần của hệ thống Đồng thời, khi chương trình cần nâng cấp, sửa chữa, việc nâp cấp cũng chỉ diễn ra ở một số chương trình cục bộ mà không ảnh hưởng quá nhiều tới hệ thống Sử dụng hàng đợi thông điệp giúp chúng ta có thể xây dựng nhanh các ứng dụng mới bằng cách sử dụng lại tài nguyên cũ của hệ thống Khi nghiệp vụ thay đổi, chỉ các thành phần chương trình liên quan tới nghiệp vụ mới cần thay đổi Chương trình sử dụng hàng đợi thông điệp không bị ảnh hưởng khi hàng đợi thông điệp thay đổi cách thức làm việc (vẫn sử dụng các giao diện ứng dụng như cũ)

Một ưu điểm nữa của hàng đợi thông điệp là chương trình đón nhận thông điệp không cần phải chạy ở cùng một thời điểm với chương trình gửi ứng dụng Trong trường hợp đó, thông điệp vẫn được lưu lại trên hàng đợi và chờ được xử lý Hơn nữa, việc sử dụng hàng đợi thông điệp còn giúp làm giảm thiểu thời gian và công sức phát triển hệ thống đo thành phần giao tiếp đã sẵn sàng

Chương 2 Hàng đợi thông điệp trong kiến trúc khách – chủ

2.1 Kiến trúc hàng đợi thông điệp

Hàng đợi thông điệp hoạt động dựa trên nguyên tắc truyền thông điệp và sử dụng hàng đợi để lưu thông điệp Nó được tạo nên bởi ba thành phần chính như hình

2.1.2 Ứng dụng chủ

Là một máy chủ tiếp nhận thông điệp và xử lý thông điệp theo yêu cầu nghiệp

vụ Máy chủ này sẽ gửi trả kết quả tới thành phần định tuyến để nó được truyền lại cho ứng dụng khách

2.1.3 Thành phần định tuyến

Là thành phần chính của một hệ thống hàng đợi thông điệp Nhiệm vụ của thành phần định tuyến là định tuyến thông điệp Nó tiếp nhận thông điệp được gửi lên từ ứng dụng khách và định tuyến nó tới máy chủ mà thông điệp cần được chuyển tới Trong phần này, chúng ta sẽ xem xét một số nhiệm vụ và thành phần chính của bộ định tuyến trong một hệ thống hàng đợi thông điệp

2.1.3.1 Nhiệm vụ của thành phần định tuyến

Định tuyến thông điệp và truyền thông điệp

Việc định tuyến thông điệp có thể dựa vào các tham số khác nhau Các tham số này được thiết lập bởi ứng dụng khách Đích đến của thông điệp có thể được quyết định dựa vào các tham số như định danh của ứng dụng gửi, kiểu thông điệp, nội dung thông điệp hoặc loại ứng dụng

Điều khiển luồng thông điệp

Người quản trị hàng đợi thông điệp có thể đề ra một tập hợp các quy tắc để điều khiển luồng các thông điệp Các quy tắc này có thể được sử dụng là một yếu tố

để ngăn quá tải hàng đợi

Lưu trữ thông điệp

Thành phần định tuyến hỗ trợ việc lưu trữ thông điệp khi mà chúng không thể chuyển tới máy đích Khi mà máy chủ sẵn sàng, nó sẽ lấy thông điệp từ thành phần định tuyến

2.1.3.2 Cấu tạo của thành phần định tuyến

Thành phần định tuyến chứa ba thành phần chính là:

Thành phần logic

Có nhiệm vụ định tuyến, lọc và truyền thông điệp

Hàng đợi phục vụ chương trình khách

Lưu trữ thông tin cho các nhà cung cấp dịch vụ (chương trình chủ) Thông thường, mỗi nhà cung cấp dịch vụ có một hàng đợi riêng Tuy nhiên thành phần định tuyến cũng có thể nhóm các thông điệp có thể được thực thi bởi nhiều nhà cung cấp dịch vụ trong một hàng đợi đơn để tiết kiệm tài nguyên

Giao tiếp giữa các ứng dụng khách và chủ là không đồng bộ Chúng không cần phải chạy tại cùng một thời điểm, hàng đợi thông điệp sẽ gửi thông điệp tới chúng (ứng dụng khách hoặc chủ) khi mà chúng đã sẵn sàng Hệ thống vì thế mà yêu cầu nhiều tài nguyên, đặc biệt là tài nguyên bộ nhớ để lưu trữ các hàng đợi đã nhận nhiều thông điệp nhưng chưa được xử lý

2.2 Lý do sử dụng hàng đợi thông điệp

Hàng đợi thông điệp là lựa chọn phù hợp trong trường hợp chúng ta khó có thể thiết lập một kết nối ổn định, sự kết nối giữa khách và chủ là không chặt chẽ Nó cũng rất thích hợp trong trường hợp chúng ta chỉ muốn chương trình từ máy khách gửi dữ liệu tới máy chủ và kết thúc chương trình, không cần đợi tới khi máy chủ xử

lý xong dữ liệu đó Sử dụng hàng đợi giúp cho dữ liệu không bị mất mát và không mất thời gian chờ đợi của ứng dụng máy khách Hiển nhiên là không phải ứng dụng nào cũng thích hợp để sử dụng hàng đợi thông điệp Ví dụ các ứng dụng thời gian thực không nên sử dụng giải pháp này Tuy nhiên để lưu trữ và đón nhận dữ liệu từ máy khách, việc sử dụng hàng đợi thông điệp là thích hợp

Từ định nghĩa về thông điệp và hàng đợi, chúng ta có thể thấy được ba đặc điểm chính khi sử dụng hàng đợi thông điệp để truyền tin trong kiến trúc khách chủ là:

 Các chương trình tương tác với nhau nhưng có thể chạy ở các thời điểm khác nhau

 Không yêu cầu rằng buộc về cấu trúc chương trình

 Các chương trình trong hệ thống không phụ thuộc chặt chẽ vào tính ổn định của đường truyền mạng

Sau đây, chúng ta sẽ lần lượt phân tích từng đặc tính

2.1.1 Các chương trình có thể chạy ở các thời điểm khác nhau

Thông

Hình 2: Sự thực thi của các chương trình trong hệ thống

Các chương trình không giao tiếp trực tiếp mà thông qua việc đặt các thông điệp vào hàng đợi Vì vậy mà chúng không cần phải chạy ở cùng một thời điểm Chương trình đích có thể bận trong khi chương trình đích đang đưa thông điệp vào một hàng đợi thích hợp Việc thông điệp đã tới được chương trình đích hay chưa không ảnh hưởng tới quá trình xử lý của chương trình gửi thông điệp, và chương trình đích cũng không cần thiết phải xử lý thông điệp đó ngay lập tức, trong thực tế,

nó có thể được khởi động sau đó vài giờ hoặc thậm chí vài ngay sau khi chương trình từ máy khách gửi thông điệp tới hàng đợi

2.1.2 Không rằng buộc về cấu trúc chương trình

Trong kiến trúc khách – chủ, mối quan hệ một – một giữa các chương trình (dữ liệu từ một chương trình A được truyền tới chương trình B, và có thể được truyền theo hướng ngược lại) là tương đối đơn giản Tuy nhiên hàng đợi thông điệp cung cấp một cơ chế để thiết kế các ứng dụng phức tạp hơn, với các mối quan hệ một – nhiều hoặc nhiều – nhiều giữa các chương trình

từ một trong các chương trình B, C hoặc D về chương trình A

Trong ví dụ này, các chương trình B, C hoặc D có thể là:

 Ba bản sao của một chương trình cùng được chạy độc lập với mục đích cân bằng tải Điều này có thể được cân nhắc khi chương trình A có thể hoàn tất công việc nhanh hơn một chương trình (B, C hoặc D) ở trên máy chủ có thể thực hiện

 Ba chương trình khác nhau lấy dữ liệu từ một hàng đợi duy nhất Như vậy, các chương trình sử dụng chung nguồn dữ liệu, xử lý dữ liệu này theo các cách khác nhau nhưng các chương trình lại có thể thực thi cùng một lúc Điều này giúp giảm tổng thời gian xử lý của hệ thống

Chưưng trình B

Hàng đưi thôngđiưp

Chưưng trình E Chưưng trình C

Chưưng trình D

Hình 4: Quan hệ nhiều – một

Trong hình vẽ trên, các chương trình B, C, D có thể là các chương trình khách kết nối tới một chương trình chủ (chương trình E) Tuy nhiên, bởi vì không có kết nối trực tiếp giữa chương trình khách tới chương trình chủ nên chương trình chủ có thể lấy thông điệp từ hàng đợi một cách đơn giản thông qua cơ chế FIFO (vào trước

ra trước) hoặc thông qua độ ưu tiên của các thông điệp (được gán bởi các chương trình khách) Nhờ vậy, nếu chương trình của máy chủ biết thông điệp từ một chương trình khác (chẳng hạn chương trình C) có độ ưu tiên cao hơn các chương trình khác,

nó sẽ quyết định đưa các thông điệp này tới đầu hàng đợi Nếu không có hàng đợi thông điệp, các chương trình khách trong kiến trúc khách – chủ thông thường sẽ chỉ được xử lý một cách tuần tự (tuy nhiên, không phải hàng đợi thông điệp nào cũng

hỗ trợ việc thiết lập độ ưu tiên cho mỗi thông điệp)

Mối quan hệ giữa các chương trình trong hệ thống cũng có thể là độc lập nhau trong một hệ thống thống nhất Ba mối quan hệ giữa các chương trình phổ biến là quan hệ một – một, một – nhiều và nhiều – một có thể cùng được sử dụng trong cùng một hệ thống, và mỗi mối quan hệ này cũng có thể là một chiều hoặc hai chiều

mà không phụ thuộc vào các mối quan hệ khác

Chưưng trình A Chưưng trình C Chưưng trình E Chưưng trình F

Chưưng trình D Chưưng trình B

Hình 5: Mối quan hệ độc lập của các chương trình

Bất kỳ mối quan hệ nào cũng có thể được áp dụng trong hệ thống Điều này cũng có nghĩa là giữa các chương trình không có rằng buộc

Chưưng trình F Chưưng trình J

Hình 6: Quan hệ giữa các chương trình

Hơn nữa, các chương trình trong hình trên có thể được đặt ở bất kỳ chỗ nào trong mạng, không phụ thuộc vào vị trí địa lý mà các chương trình được đặt Hàng đợi thông điệp cho phép các chương trình giao tiếp sử dụng các công nghệ tương tự nhau mà không cần quan tâm nhiều tới vị trí của các chương trình

2.1.3 Các chương trình được tách riêng biệt khỏi sự phức tạp của mạng

Chương trình A giao tiếp với chương trình B bằng việc đặt một thông điệp vào hàng đợi của chương trình B Chương trình B nhận thông tin bằng cách lấy thông điệp trong hàng đợi Mọi công việc liên quan tới quá trình này như hàng đợi thông điệp, giao tiếp giữa chương trình và hàng đợi hay di chuyển thông điệp trong mạng đều được cung cấp bởi hàng đợi thông điệp Các chương trình không giao tiếp trực

tiếp với nhau, bởi vậy mà chúng có thể được thiết kế độc lập với sự phức tạp của mạng máy tính

2.1.4 Chương trình có thể được sắp xếp, lên lịch để sử dụng tài

nguyên một cách tốt nhất

Các chương giao tiếp thông qua việc truyền và nhận thông điệp, do đó mà rằng buộc về thời gian thường là không khắt khe như các cách giao tiếp khác Bởi vậy, các chương trình khác nhau trong cùng một hệ thống có thể chạy với các tốc độ khác nhau, thậm chí ở các thời gian khác nhau (nếu cần thiết) Các chương trình có khả năng thực thi độc lập vì nếu như logic chương trình là đúng, nó sẽ không cần đợi phản hồi từ chương trình khác mà có thể tiếp tục chạy ngay Điều này giúp chúng ta có thể thiết kế và sắp xếp các chương trình phù hợp với logic của hệ thống

và phù hợp với nghiệp vụ chứ không phải quan tâm tới sự phù hợp về logic của các phương thức giao tiếp Vì vậy, các chương trình có thể chạy đồng thời, một phần các chương trình chạy đồng thời hoặc hoàn toàn tách rời nhau Điều này mang lại nhiều ưu điểm cho hệ thống, như ví dụ đơn giản sau đây:

Một hệ thống có hai chương trình, một chương trình đưa ra 20 câu hỏi khác nhau, chương trình kia có nhiệm vụ trả lời các câu hỏi này

 Hai chương trình có thể chạy xem kẽ, nghĩa là một câu hỏi sẽ được trả lời trước khi câu hỏi khác được đặt ra

 Hai chương trình có thể chạy cùng một lúc Cả hai mươi câu hỏi có thể được đưa ra mà không cần chờ câu trả lời từ chương trình thứ hai Cách này giúp thời gian xử lý tổng thể của hệ thống giảm đi nhiều

 Một các tiếp cận khác giảm thời gian xử lý tổng thể của hệ thống rất nhiều, đó là các câu hỏi có thể được trả lời bằng hai mươi chương trình khác nhau, hoặc hai mươi phiên bản của cùng một chương trình, được chạy đồng thời Với cách này, việc xử lý các câu hỏi là có thể trùng lên nhau, nhờ thế mọi câu hỏi có thể được trả lời đồng thời

2.1.5 Sự phối hợp giữa các tài nguyên

Trong nhiều trường hợp, hai hay nhiều dữ liệu được cập nhật, cần chắc chắn rằng những dữ liệu khác cũng được cập nhật Một ví dụ là nếu một tài khoản chuyển

tài khoản nhận cũng phải được tăng lên với số tiền tương ứng Các chương trình thực thi nhiệm vụ này cần phải đảm bảo rằng: khi một thao tác (cộng hoặc trừ tiền tài khoản) phải được hủy bỏ nếu thao tác kia không thành công Sử dụng hàng đợi thông điệp cho phép người thiết kế trì hoãn các thao tác cho tới khi sẵn sàng để thực thi cả hai thao tác cùng một lúc

Giữ tính ổn định của hệ thống khi có chuyển đổi

Trong thực tế, một hệ thống bất kỳ luôn cần thay đổi để thỏa mãn yêu cầu mới hoặc phù hợp với nghiệp vụ mới Trong trường hợp này, một yêu cầu khó được đặt

ra là duy trì tính ổn định của hệ thống trong quá trình thay đổi Với hàng đợi thông điệp, chúng ta có thể sử dụng một số giải pháp sau đây để thực hiện yêu cầu đó:

 Giả sử trong ví dụ về hai mươi câu hỏi ở trên, chúng ta có một chương trình để trả lời hai mươi câu hỏi đó, trong khi chúng ta không có mã nguồn của chương trình đó Chương trình thứ mười hai thay đổi, và chúng ta cải tiến đoạn mã trả lời câu hỏi đó

20 câu hưi

Hư thưng đang tưn tưi

Trư lưi câu hưi

bư thay đưi

1 - 11

13 - 20

12

Hình 7: Thay đổi chương trình

Chúng ta sẽ viết một chương trình mới chỉ trả lời câu hỏi thứ mười hai, sau đó thay đổi chương trình tạo ra câu hỏi, chuyển việc truyền câu hỏi thứ mười hai về cho chương trình mới, sử dụng hàng đợi Chúng ta có thể lặp lại kỹ thuật này cho tới khi toàn bộ câu hỏi được chuyển về chương trình mới

 Để thay đổi hoặc mở rộng chức năng cho một chương trình, chúng ta có thể viết một chương trình sử dụng hàng đợi thông điệp cùng tồn tại với chương trình đang có Chương trình mới và cũ có thể cần được liên kết, nhưng không cần tạo thêm sự thay đổi nào

 Chúng ta có thể chọn ra một số điểm của hệ thống cần thay thế, thành phần giao tiếp tiến trình của hệ thống sử dụng hàng đợi thông điệp Cách tiếp cận này có thể dẫn tới sự thay đổi về logic của hệ thống, vì

các chương trình của hệ thống có khả năng chạy độc lập với các chương trình khác trong hệ thống

 Chúng ta có thể thiết kế và xây dựng lại hệ thống hoàn toàn mới sử dụng hàng đợi thông điệp

2.1.6 Dễ dàng di chuyển và sử dụng lại mã chương trình

Vì việc sử dụng hàng đợi thông điệp là sử dụng một giao thức giao tiếp độc lập, và có giao diện thống nhất trong mọi môi trường, các chương trình có thể dễ dàng di chuyển giữa các nút trong mạng, hoặc nhân bản tại các nút này, dễ dàng hơn với các chương trình sử dụng các phương thức giao tiếp khác

2.1.7 Khi nào sử dụng hàng đợi thông điệp

Ở trên, chúng ta đã chỉ ra rất nhiều lý do để sử dụng hàng đợi thông điệp trong kiến trúc khách – chủ Trong phần này, chúng ta sẽ đưa ra một số trường hợp cụ thể

mà nếu sử dụng hàng đợi thông điệp sẽ có rất nhiều lợi thế:

 Lưu những dữ liệu không quan trọng trong hàng đợi khi hệ quản trị cơ

sở dữ liệu bận phục vụ những ứng dụng khác hoặc xử lý những thông tin khác Dữ liệu trong hàng đợi sẽ được lấy ra và xử lý khi cơ sở dữ liệu sẵn sàng Ý tưởng này có thể được áp dụng khi hệ thống xử lý các yêu cầu thời gian thực ngay lập tức và lưu trữ các yêu cầu khác vào hàng đợi và xử lý sau đó

 Trường hợp yêu cầu một kết nối tới hệ quản trị cơ sở dữ liệu, tuy nhiên

vì một vài lý do mà kết nối có thể không liên tục ở một vài thời điểm Trong trường hợp này, chúng ta có hai cách để sử dụng hàng đợi thông điệp cho ứng dụng Thứ nhất, chúng ta thiết lập cho ứng dụng truy cập vào cơ sở dữ liệu một cách thông thường, và khi kết nối vào cơ sở dữ liệu bị lỗi, các yêu cầu sẽ được đưa vào một hàng đợi Hệ thống sẽ khởi động việc kiểm tra tính sẵn sàng của cơ sở dữ liệu Khi cơ sở dữ liệu đã sẵn sàng, hàng đợi sẽ chuyển các yêu cầu tới cơ sở dữ liệu Khi đó, hệ thống khôi phục lại trạng thái hoạt động bình thường và hệ thống có thể ngắt thành phần hàng đợi (và khởi động lại khi có lỗi kết nối sau đó) Cách thứ hai có thể là hệ thống sẽ chuyển toàn bộ yêu cầu từ ứng dụng

máy khách vào hàng đợi, việc chuyển yêu cầu tới ứng dụng máy chủ sẽ

do hàng đợi thực hiện

2.1.8 Lợi ích của hàng đợi thông điệp so với cơ sở dữ liệu

Khi sử dụng hệ quản trị cơ sở dữ liệu quan hệ, nó sẽ là các hệ thống đồng bộ hóa, trong khi sử dụng hàng đợi thông điệp, các ứng dụng là không đồng bộ hóa Điều đó cũng có nghĩa truy cập vào hàng đợi thường sẽ nhanh hơn truy cập vào bảng của cơ sở dữ liệu quan hệ Lý do là vì với các ứng dụng đồng bộ hóa, ứng dụng khách sẽ phải đợi đến khi máy chủ phản hồi, trong khi với các truy cập không đồng bộ hóa, sau khi truyền thông điệp tới máy chủ, ứng dụng khách sẽ tiếp tục xử

lý mà không cần chờ đợi Ngay khi máy chủ xử lý xong thông điệp đó, nó sẽ gửi kết quả cho máy khách

Khi sử dụng hệ quản trị cơ sở dữ liệu, chúng ta sẽ phải tuân theo các chuẩn dữ liệu của hệ quản trị (mặc dù thông thường, các kiểu dữ liệu được hỗ trợ là tương đối phổ biến và đầy đủ) Tuy nhiên, nếu muốn thêm dữ liệu vào bảng mà kiểu dữ liệu này không được hỗ trợ là tương đối khó khăn Trong khi nếu sử dụng hàng đợi thông điệp thì các yêu cầu về chuẩn dữ liệu là tương đối dễ dàng hơn

2.3 Vòng đời của một thông điệp

Từ ý tưởng chung về một hàng đợi thông điệp, thực tế có rất nhiều cách cài đặt một hàng đợi thông điệp trên nhiều nền tảng công nghệ với thêm nhiều tính năng khác Có rất nhiều hàng đợi thông điệp được phát triển bởi cách hãng danh tiếng như Microsoft Message Queuing, IBM Message Queue … Tuy nhiên, chúng ta sẽ xem xét một vòng đời đơn giản của một thông điệp trong mô hình hàng đợi

Ban đầu, máy khách sẽ tạo ra một thông điệp Tiến trình gửi sẽ đóng gói nội dung cần gửi thành một thông điệp, có thể lưu thêm một số thuộc tính như tên thông điệp, quyền truy cập thông điệp …, đồng thời gán thêm một số thông tin như địa chỉ, sau đó gửi cho thành phần chủ của hàng đợi thông điệp

Khi thông điệp đã được truyền tới thành phần chủ của hàng đợi thông điệp trên máy chủ, thành phần này sẽ định tuyến thông điệp này tới một tập hợp các hàng đợi trên máy chủ Nếu máy chủ không thể định tuyến được một thông điệp, nó có thể sẽ xóa ngay thông điệp hoặc phản hồi lại cho chương trình khách Thông thường, ứng dụng khách của hệ thống sẽ quyết định từ trước xem trong trường hợp này, thành

phần chủ của hàng đợi thông điệp sẽ xóa ngay hay phản hồi lại cho máy khách (ví

dụ bằng cách thiết lập giá trị cho một thuộc tính nào đó của thông điệp)

Tùy theo mỗi cách cài đặt, một thông điệp có thể tồn tại ở một hoặc nhiều hàng đợi (máy chủ có thể quản lý bằng cách copy thông điệp hoặc sử dụng tham chiếu …) Dù có thể tồn tại trên nhiều hàng đợi nhưng thông điệp đó vẫn là hoàn toàn đồng nhất Khi một thông điệp ở trong hàng đợi, hàng đợi sẽ cố gắng chuyển

nó tới ứng dụng xử lý thông điệp đó Nếu không được, hàng đợi sẽ lưu trữ thông điệp đó (trên bộ nhớ hoặc ổ đĩa) và đợi cho đến khi ứng dụng dùng để xử lý thông điệp là sẵn sàng Sau đó, nó sẽ loại bỏ thông điệp đó (ra khỏi bộ nhớ, ổ đĩa) Việc loại bỏ này có thể được thực hiện ngay lập tức hoặc sau khi tiến trình xử lý thông điệp thông báo nó đã xử lý thành công thông điệp đó

2.4 Quá trình kết nối

Hàng đợi thông điệp là một giao thức để truyền tin giữa ứng dụng khách và ứng dụng chủ Quá trình kết nối từ chương trình khách tới chương trình chủ của hệ thống hàng đợi thông điệp như sau:

Khởi đầu, chương trình khách mở một kết nối TCP/IP tới chương trình chủ Đồng thời nó cũng gửi thông tin về phương thức tới chương trình chủ Chương trình chủ phản hồi lại thông tin về phiên bản giao thức của nó và một số thông tin khác như danh sách các cơ chế bảo mật mà nó hỗ trợ Nhận được các thông tin này, chương trình khách sẽ lựa chọn một cơ chế bảo mật phù hợp với nó và thông báo cho chương trình chủ Chương trình chủ khởi động tiến trình xác thực và gửi lại cho chương trình khách một yêu cầu (bảo mật) Sau đó, chương trình khách phản hồi cho chương trình chủ thông tin bảo mật Ví dụ, khi sử dụng cơ chế bảo mật đơn giản, thông tin phản hồi sẽ là tên đăng nhập và mật khẩu Sau khi kiểm tra tính chính xác của các thông tin bảo mật trên, chương trình chủ gửi tới chương trình khách một số thông số, ví dụ thông tin dung lượng lớn cao nhất của khung thông điệp Chương trình khách có thể chấp nhận các thông số về dung lượng này hoặc giảm chúng xuống nếu thấy thông số này lớn hơn mức mong muốn của nó Sau đó, chương trình khách mở kết nối tới chương trình chủ Chương trình chủ chấp nhận kết nối đó

Khi đó, các thông điệp được truyền qua lại giữa khách và chủ một cách bình

Khi một phía (khách hoặc chủ) không muốn tiếp tục quá trình trao đổi thông điệp nữa, nó sẽ đóng kết nối Nhận biết được tín hiệu này, phía còn lại cũng sẽ kết thúc kết nối Cả khách và chủ đóng kết nối Quá trình giao tiếp khách – chủ được kết thúc

2.5 Các thuộc tính của một hàng đợi thông điệp

Trong phần này, chúng ta sẽ xem xét một số thuộc tính quan trọng của hàng đợi thông điệp, bao gồm:

2.5.1 Tên

Nếu tên không được định nghĩa từ ứng dụng khách, máy chủ sẽ tạo ra một tên

và gán cho nó Thông thường, nếu hàng đợi được tạo ra với thuộc tính được chia sẻ,

nó sẽ được đặt tên trước Nếu không được định nghĩa trước, việc đặt tên sẽ do máy chủ quyết định

2.5.2 Tính duy nhất

Là thuộc tính xác định tính chất kết nối khách – chủ của hàng đợi thông điệp Nếu thuộc tính được thiết lập, hàng đợi sẽ chỉ thuộc về kết nối hiện thời, và sẽ bị xóa khi kết nối bị đóng

2.5.3 Tính duy trì

Nếu thuộc tính được thiết lập, hàng đợi vẫn tồn tại và được kích hoạt khi máy chủ khởi động lại Nếu không thiết lập thuộc tính này, hàng đợi đó sẽ bị mất đi khi máy chủ khởi động lại

2.5.4 Tự động xóa

Sau khi khởi tạo và sử dụng hàng đợi, chúng ta cần xóa nó đi khi không còn ứng dụng nào sử dụng hàng đợi đó nữa Chúng ta có thể sử dụng chính các ứng dụng để xóa hàng đợi đó đi sau khi nó kết thúc quá trình làm việc với hàng đợi đó Tuy nhiên, điều này khó khả thi vì ứng dụng sẽ không biết chính xác là còn ứng dụng nào sử dụng hàng đợi đó nữa không để xóa nó Vì vậy, hệ thống cung cấp một

cơ chế để sau khi dịch vụ cuối cùng sử dụng một hàng đợi, máy chủ sẽ xóa hàng đợi

đó