2.3.1 Hệ thống gửi nhận thông điệp (messaging system)
Trong những năm qua, các hệ thống thông tin đã 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. Đá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.
Hệ thống gởi nhận thông điệp giữa ứng dụng và ứng dụng thường được gọi chung là hệ thống gởi nhận thông điệp hoặc phần mềm trung gian hướng thông điệp (Message - Oriented Middleware (MOM)) (Hình 2-12). Hệ thống gởi nhận thông điệp cho phép hai hay nhiều ứng dụng trao đổi thông tin dưới dạng thông điệp (message). 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. Trong hệ thống gởi nhận thông điệ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.
38 Trong tất cả các hệ thống gởi nhận thông điệp hiện đại, các ứng dụng trao đổi thông tin thông qua kênh ảo được gọi là các điểm đến (destination). Khi tin nhắn được gửi đi, nó được gửi đến một điểm đến (ví dụ như queue hoặc topic), không phải là một ứng dụng cụ thể. Bất kỳ ứng dụng nào đăng ký “quan tâm” đến điểm đến cũng có thể nhận được thông báo. Bằng cách này, các ứng dụng nhận tin nhắn và các ứng dụng gửi tin nhắn được tách riêng. Bên gửi và bên nhận không bị ràng buộc với nhau trong bất kỳ hoàn cảnh nào và có thể gửi và nhận thông điệp theo bất kỳ cách nào phù hợp.
Hay nói một cách khác 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 mô hình 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 agent cung cấp công cụ truyền thông để tạo, gởi,nhận và đọc thông điệp.
Ngoài ra, gởi nhận thông điệp cho phép truyền thông phân tán. Một thành phần có thể gửi một thông điệp cho một đích (destination), và bên nhận có thể thu được thông điệp này từ đích. Tuy nhiên, bên gửi và bên nhận không cần sẵn sàng cùng lúc để truyền thông. Thực tế, bên gửi không cần biết bất kì điều gì về bên nhận; hay bên nhận không cần biết bất kì điều gì về bên gửi. Bên gửi và bên nhận chỉ cần biết khuôn dạng thông điệp và đích (destination) để sử dụng.
2.3.2 Tổng quan về JMS
JMS là một 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.
Trong 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. 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.
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: - ConnectionFactory - Destination - Connection - Session - Message - MessageProducerMessageConsumer
39 ConnectionFactory và Destination phải được lấy từ provider qua JNDI. Các interface khác được tạo ra bằng factory method trong nhiều API interface. Ví dụ: khi đã có ConnectionFactory, chúng ta có thể tạo Connection. Khi đã có Connection, có thể tạo Session. Khi đã có Session, chúng ta có thể tạo Message, Message Producer và Message Receiver.
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ư 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” mà còn không đồng bộ.
2.3.3 Các mô hình gửi nhận thông điệp trong JMS
JMS hỗ trợ hai loại mô hình gởi nhận thông điệp: point – to - point và publish – subscribe. Những mô hình gởi nhận thông điệp đôi khi được gọi là “miền gởi nhận thông điệp” (messaging domain). Gởi nhận thông điệp point – to - point và publish – subscribe thường được viết tắt là p2p và pub/sub. Hiểu theo nghĩa đơn giản nhất, publish – 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.
40 2.3.3.1 Point – to – point
Mô hình point – to – point (Hình 2-15) 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 (hàng đợi). Trong mô hình point – to - point, 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 point – to - point 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.
Point – to - point 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ộ. Point – to - point có xu hướng chặt chẽ hơn mô hình publish – subscribe 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ó.
Mô hình point – to - point 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.
2.3.3.2 Publish - subscribe
Trong mô hình publish – subscribe (Hình 2-16), các thông điệp được publish 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 point – to - point, thông điệp được publish 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.
Hình 2.15: Hai mô hình gửi nhận message trong JMS
41 Thông điệp trong mô hình publish - subscribe đượ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ô hình publish - subscribe có xu hướng thiếu chặt chẽ hơn mô hình point – to - point 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 publish vào topic mỗi khi ứng dụng có exception. Publisher chỉ có trách nhiệm publish 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 publish - subscribe. Subscriber không lâu dài là những subscriber đăng ký tạm, chỉ nhận thông điệp khi chủ động nghe topic. Subscriber lâu dài 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.