Làm thế nào để thực hiện các cuộc gọi dịch vụ web tạm thời


8

Tôi đang phát triển giải pháp dựa trên wcf cho lớp dịch vụ web mà các thiết bị di động "thỉnh thoảng được kết nối" sẽ sử dụng. Dịch vụ sẽ không được sử dụng hàng đợi (ở giai đoạn này) do sự phức tạp bổ sung và do đó, thay vào đó, nó sẽ vận hành một cách tiếp cận Yêu cầu / Phản hồi đơn giản.

Tất nhiên, là một thiết bị di động, có thể các thiết bị có thể bị mất tín hiệu giữa chèn / cập nhật. Bản thân dịch vụ web có thể đã hoàn thành giao dịch, nhưng khách hàng sẽ không bao giờ nhận được thông báo này. Do đó, nó sẽ gửi lại yêu cầu, tại thời điểm đó, máy chủ cần nhận ra đây là một yêu cầu trùng lặp và trả về cùng một phản hồi mà nó đã thử trong trường hợp đầu tiên.

Do đó tôi đang cố gắng để làm cho các dịch vụ Idempotent. Để đạt được điều này, tôi đang triển khai các đối tượng DTO của Param Paramter, bao gồm RequestID, cộng với các tham số cần thiết để hoàn thành cuộc gọi.

Tuy nhiên, khó khăn của tôi là trong việc thực hiện một cách theo dõi id yêu cầu. SInce dịch vụ hiện không trạng thái, cách duy nhất hiện tại tôi có thể hình dung là có một bảng ServiceRequest trong cơ sở dữ liệu, sẽ lấy RequestID làm chính. Rõ ràng truy vấn về điều này sẽ cho biết liệu yêu cầu đã được thực hiện hay chưa, vì khách hàng sẽ gửi cùng một RequestID. Nhưng dịch vụ cũng cần biết tin nhắn nào để gửi lại. Trong trường hợp chèn / cập nhật, id gốc tổng hợp bị ảnh hưởng cũng sẽ cần được lưu trữ ở đâu đó, cho dù trực tiếp trên bảng yêu cầu hoặc trong bảng RequestToObjectLookup

Vì vậy, tôi tự hỏi nếu có một cách thực hành tốt nhất để thực hiện điều này? Suy nghĩ của tôi là có (các) bảng ServiceRequest (cụ thể cho dịch vụ), lưu trữ các yêu cầu, thông tin bổ sung và cũng là tra cứu id đối tượng kết quả (trên lưu / chèn / cập nhật). Vì vậy, khi có yêu cầu mới, bảng này có thể được tham khảo trước khi tiếp tục với phần còn lại của yêu cầu, cho dù đó là để thực hiện lưu hay chỉ trả lại đối tượng được cập nhật trước đó (đã được xử lý trong lần thử yêu cầu đầu tiên).

Tôi cũng đang suy nghĩ (như đã nêu) rằng tôi chỉ cần giữ id tổng hợp gốc được tham chiếu với yêu cầu, vì tôi chỉ có thể sử dụng các mối quan hệ để đạt được phần còn lại của thông tin.

Câu trả lời:


2

Xóa có thể được thực hiện idempotent bằng cách chỉ cho phép xóa dựa trên ID. Bạn sẽ cần phải có một số cách để ID vẫn được "sử dụng" và có thể hết hạn.

Với hệ thống đặt phòng như vậy; việc tạo một đối tượng có thể được thực hiện bằng cách trước tiên đặt ID và sau đó là cuộc gọi thứ hai để tạo đối tượng có ID đó (về cơ bản là cập nhật trên đối tượng trống mới). Khi một ID được yêu cầu, máy chủ sẽ lấy bất kỳ ID miễn phí nào và tạo một đối tượng chưa được khởi tạo với ID đó, cuộc gọi thứ hai để khởi tạo sẽ bao gồm ID được trả về trước đó (cộng với tất cả dữ liệu được yêu cầu). Điều này có nghĩa là cuộc gọi thứ hai về bản chất là một cuộc gọi cập nhật có khả năng là chính idem (gọi nó với cùng một dữ liệu nhiều lần sẽ cho kết quả giống nhau).

Nếu bảo lưu xảy ra nhiều lần thì nhiều ID được trả về và đối tượng khởi tạo sẽ vẫn còn. Những vật thể chưa được khởi tạo này có thể được dọn sạch bởi một rhoomba sau một thời gian tự động.

Điều này đặt trách nhiệm cho khách hàng để đảm bảo rằng nếu họ nhận được ID thì họ có trách nhiệm gọi khởi tạo. Nếu khách hàng rơi vào giao dịch giữa, nó sẽ giữ nhật ký riêng cho các hoạt động để nó biết ví dụ rằng anh ta có ID và đang bận rộn với việc khởi tạo đối tượng.

Cập nhật khó khăn hơn để tạo idempotent nhưng thao tác so sánh và thiết lập (với kết quả đúng / sai) sẽ giúp ích.


Bạn có thể giải thích thêm một chút về hệ thống đặt phòng? Bạn có nghĩa là trước tiên khách hàng cần yêu cầu id từ dịch vụ, trước khi thực hiện cuộc gọi thứ hai, theo đó đối tượng đã nói id được đặt?
Milambardo
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.