Tại sao chọn JMS cho giải pháp không đồng bộ? Tại sao nó tốt hơn đậu thực thể đơn giản?

Question

Trong hầu hết các dự án tôi đã tham gia, lựa chọn giải pháp không đồng bộ đã là một nguồn của nhiều cuộc thảo luận ...

Mỗi khi một đơn thực hiện đủ để quản lý hàng đợi: chúng tôi chỉ lưu trữ một tin nhắn (vé) trong một bảng và một cron xử lý unstacks hàng đợi. Giải pháp đơn giản này có lợi thế là rất đơn giản, nó dựa trên bối cảnh giao dịch của cơ sở dữ liệu và chúng ta có thể quản lý trạng thái của thông báo nhận được trong quá trình thực hiện nó.

do đó tôi hỏi những câu hỏi sau đây:

1) lợi ích gì chúng ta phải sử dụng JMS? Những lợi ích của JMS là gì?

2) Trong trường hợp nào thích JMS so với đậu thực thể?

Cảm ơn bạn đã trả lời và phản hồi!

Answer 1

1) Quan tâm nào chúng tôi phải sử dụng JMS? Các lợi ích của JMS là gì? 2) Trong tình huống nào thích JMS so với đậu thực thể?

Bạn tiếp cận hoạt động tốt miễn là có chỉ một người tiêu dùng. Nếu không, nó sẽ yêu cầu lược đồ khóa để cùng một thông điệp không được gửi hai lần, vv Đây là những gì JMS đưa ra khỏi hộp: sản xuất và tiêu thụ giao dịch với nhà môi giới JMS quản lý tất cả các vấn đề giao hàng với nhiều người tiêu dùng/nhà sản xuất.

Các ưu điểm khác của JMS là chất lượng dịch vụ và quản lý, ví dụ: nỗ lực phân phối lại, hàng đợi thông báo đã chết, quản lý tải, khả năng mở rộng, phân cụm, giám sát, v.v.

JMS cũng hỗ trợ xuất bản-subsribe hoặc point-to-point.

Giống như so sánh câu lệnh JDBC để chèn một hàng vào cơ sở dữ liệu so với ORM toàn bộ. Cả hai đều làm việc để chèn một hàng vào db, nhưng ORM sẽ cung cấp nhiều hơn nữa, cộng với bạn không tái phát minh ra bánh xe để đối phó với các vấn đề cấp thấp ... (tương tự không phải là tuyệt vời nhưng tốt)

Tôi đề nghị bạn xem FAQ.

Answer 2

Trong Java EE về cơ bản có 3 cơ chế để đối phó với asynchronicity:

1. JMS
2. CDI xe buýt kiện
3. phương pháp chú thích @Asynchronous đậu stateless session

ewernli đã đưa ra một lời giải thích rất tốt về những lợi thế mà JMS có. Đó là một hệ thống rất đầy đủ tính năng, nhưng tất cả các tính năng này đều có chi phí một chút ở trên cao và phức tạp, ví dụ: quản lý các đối tượng hành chính có liên quan.

Ngoài ra, đặc điểm kỹ thuật của JMS chưa được cập nhật trong gần một thập kỷ. Nó vẫn đang được thực sự hữu ích cho thấy rất nhiều tầm nhìn xa mà đi vào thiết kế của API, nhưng đôi khi nó có thể cảm thấy một chút phức tạp. Cách thức mà các đối tượng quản trị như đích phải được xác định, cách mà bạn cần để có được kết nối, tạo một phiên, v.v., tất cả đều cảm thấy một chút thấp, cũ và phức tạp. Nhận tin nhắn mặc dù đã được đơn giản hóa rất nhiều với các tin nhắn điều khiển đậu, nhưng gửi có không.

Sau đó, vì một số lý do kỳ lạ kế thừa, các mô-đun web bị cấm nghe các điểm đến của JMS. Tất nhiên không có lý do gì cho điều đó nữa, nhưng nó nằm trong J2EE 1.3 và các thông số kỹ thuật sau này. Các máy chủ ứng dụng tương thích vẫn duy trì quy tắc này, nhưng tất cả chúng đều cung cấp cấu hình cụ thể cho nhà cung cấp để cho phép nó. Tuy nhiên điều này làm cho ứng dụng của bạn kém di động hơn.

Một tập con của các trường hợp sử dụng mà JMS đã được sử dụng trong lịch sử là lập trình dựa trên sự kiện rất đơn giản trong một ứng dụng duy nhất. Cho rằng xe buýt sự kiện CDI được cho là phù hợp hơn bây giờ, vì nó là một cách tiếp cận trọng lượng nhẹ hơn, hiện đại hơn và tổng thể nhẹ hơn.

Một nhóm nhỏ các trường hợp sử dụng khác mà JMS đã được sử dụng chỉ đơn giản là làm bất kỳ công việc nào một cách không đồng bộ. Đối với những người đó đôi khi được sử dụng để thực hiện một MDB mà sau đó sẽ chỉ unwrap các thông số từ tin nhắn và gọi một số phương pháp đậu phiên không trạng thái trực tiếp đi qua trong các thông số đó. Trong trường hợp này, mô hình nhắn tin là hoàn toàn không cần thiết và chỉ cần gọi một phương thức chú thích @Asynchronous là một cách tiếp cận đơn giản và trực tiếp hơn.