Một trong những sản phẩm của chúng tôi thực hiện một cách cơ cấu dịch vụ web sau:Yêu cầu-trả lời cho SOAP lai qua HTTP/JMS qua middleware
Server <--------------------- Middleware <---------------- Client
SOAP over JMS (queue) SOAP over HTTP
Trong mô hình này, khách hàng gửi tin nhắn SOAP trên HTTP để middleware của chúng tôi (Tiến trình SonicMQ). Các tin nhắn được đẩy vào hàng đợi JMS bởi SonicMQ và máy chủ của chúng tôi tìm nạp chúng từ đó. Tuy nhiên, như bạn có thể thấy, máy chủ không gửi phản hồi tới máy khách (JMS không đồng bộ).
Chúng tôi muốn triển khai kênh phản hồi cho mô hình này. Giải pháp thường được đề xuất là tạo một hàng đợi trả lời tạm thời (trên bay) trong phần mềm trung gian, cho phép máy chủ gửi phản hồi đến hàng đợi đó. Sau đó, máy khách có thể tìm nạp phản hồi và trả lời hàng đợi. Điều này nghe có vẻ thuận tiện, nhưng tiếc là khách hàng của chúng tôi hoạt động trên HTTP đơn giản và không qua JMS, vì vậy khách hàng của họ không thể dễ dàng thiết lập hàng đợi trả lời.
Một cách tiếp cận để đạt được kênh phản hồi trong mô hình SOAP lai HTTP/JMS như vậy là định cấu hình phần mềm trung gian để mở hàng đợi trả lời trên mỗi lần nhận SOAP thành công, thêm thông tin trả lời hàng đợi và người gửi vào thông điệp SOAP và đẩy thư đến hàng đợi, nơi nó sẽ được máy chủ tìm nạp. Sau khi nhận và xử lý tin nhắn, máy chủ có thể gửi một phản hồi đến trả lời được chỉ định cho hàng đợi trong phần mềm trung gian. Cuối cùng, phần mềm trung gian sẽ gửi phản hồi (SOAP) qua HTTP trở lại máy khách gốc bằng cách sử dụng dữ liệu từ thông báo SOAP (dữ liệu được chèn vào đó trong các thủ tục phần mềm trung gian khi yêu cầu được nhận lần đầu tiên).
Trong khi có thể, điều này nghe có vẻ giống như một kẻ tấn công. Vì vậy, câu hỏi đặt ra là: bất kỳ cách nào sạch hơn để đạt được mô hình yêu cầu/phản ứng như vậy đối với trường hợp của chúng tôi? Kết thúc máy chủ đã được triển khai trong Java.
Giải pháp:
Progress SonicMQ hỗ trợ "Nội dung trả lời Send" HTTP người chấp nhận, cho phép dễ dàng gửi JMS trả lời. Trả lời nội dung Gửi tác phẩm chấp nhận một cách sau:
- người chấp nhận nhận được thông điệp HTTP một khách hàng gửi
- người chấp nhận tạo ra một hàng đợi JMS tạm
- người chấp nhận xây dựng một thông điệp JMS, chứa cơ thể HTTP, và bổ sung xác định hàng đợi tạm thời để thông điệp mới được tạo ra JMS
- người chấp nhận đẩy thông điệp JMS vào hàng đợi đích của nó (không phải là hàng đợi tạm thời)
- người chấp nhận bắt đầu tiêu thụ tạm thời trả lời-To xếp hàng
- Khi khách hàng lấy về thông điệp từ hàng đợi điểm đến ban đầu, nó có chứa các thiết lập trả lời-To xếp hàng xác định
- Khách hàng tiêu thụ nhắn
- Client gửi trả lời cho câu trả lời-To xếp hàng
- người chấp nhận nhận được thông điệp từ hàng đợi
- Người chấp nhận gửi thông báo dưới dạng HTTP tới ứng dụng khách ban đầu đã gửi thông báo HTTP
Nếu người tiêu dùng ("máy chủ" trong trường hợp này không thành công và không gửi thời gian chờ trả lời, Trình chấp nhận HTTP của Sonic sẽ gửi thông báo HTTP đến máy khách cho biết thời gian ut. Đây là một tính năng rất chuẩn trong SonicMQ. Tôi cho rằng nó tồn tại trong các sản phẩm khác.
Điều này cho phép sử dụng SOAP tiêu chuẩn trên JMS (xem câu trả lời của người quản lý) ở đầu "máy chủ" để tránh bất kỳ chương trình tùy chỉnh nào trong phần mềm trung gian.
Tôi vẫn thấy một số vấn đề trong mô hình JMS, nhưng điều này chắc chắn là một sự cải tiến.
Cập nhật 2009/11/05:
Sau khi nghiên cứu vấn đề này hơn nữa, nó quay ra nghi ngờ của tôi chống lại HTTP < -> middleware < -> JMS đã có liên quan.
Có một số vấn đề nghiêm trọng trong mô hình này. Mô hình đồng bộ-không đồng bộ với phần mềm trung gian đơn giản là không thuận tiện. Hoặc có cả hai đầu thực hiện kết nối JMS (mà nên đá) hoặc đi với HTTP ở cả hai đầu. Trộn chúng chỉ trong đau đầu. Trong số này, SOAP-over-HTTP đơn giản hơn và được hỗ trợ tốt hơn SOAP-over-JMS.
Một lần nữa: nếu bạn đang thiết kế loại hệ thống này ... KHÔNG.
Hỗ trợ gốc cho SOAP trên JMS có vẻ tốt đẹp. Tôi không biết điều đó tồn tại. Ngoài Spring, có vẻ như việc triển khai Metro JAX-WS cũng hỗ trợ SOAP trên JMS. Tôi cho rằng một trong hai cấu hình này cho phép cấu hình hàng đợi và cấu hình hàng đợi JMS tùy chỉnh? Tôi đang cân nhắc điều đó, bởi vì chúng ta cần thiết lập một vài đặc tính riêng của SonicMQ. Ngoài ra, SonicMQ gửi một phản hồi OK/lỗi theo mặc định, vì vậy tôi cần phải ghi đè lên đó trong phần mềm trung gian. Tuy nhiên, tôi đoán điều đó sẽ dễ dàng. Có vẻ như tôi có một số nghiên cứu để làm ... –
Nghe có vẻ như bạn có một số kỹ thuật thú vị để làm :) Tôi đoán rằng hỗ trợ JMS Spring của Spring-WS sử dụng, điều này khá tốt và sẽ cho phép bạn tùy chỉnh mọi thứ tùy theo nhu cầu của bạn. – skaffman