SOA/Dịch vụ Web Pagination

Question

Trong SOA, chúng ta không nên xây dựng hoặc giữ trạng thái (hoặc thiết kế các phụ thuộc) giữa máy khách và máy chủ. Điều này được hiểu. Nhưng những gì các mẫu có thể được theo sau trong trường hợp một khách hàng muốn tiêu thụ một dịch vụ thời gian thực có thể trả lại một số kết thúc mở của 'hàng'?

Các ứng dụng web, tương tự như SOA nhưng cho phép trạng thái (phiên) đã giải quyết vấn đề này với phân trang. Yêu cầu phân trang (trong hầu hết các trường hợp, đặc biệt là với SQL) mà máy chủ lưu trữ dữ liệu và máy khách yêu cầu dữ liệu theo khối.

Nếu chúng ta xem xét các kịch bản giống như pagination cho các dịch vụ web, các mẫu sẽ tuân theo những gì sẽ vẫn cho phép các nguyên lý SOA được tuân thủ (hoặc càng gần càng tốt).

Một số quy tắc cho các nhà tư tưởng: 1) Được hỗ trợ bởi cơ sở dữ liệu SQL (do đó không có khái niệm về số hàng trong tập hợp chọn) 2) Điều quan trọng là không bỏ qua hàng hoặc sao chép hàng trong đặt trong quá trình phân trang 3) Dữ liệu có thể được chèn vào và xóa bất kỳ lúc nào vào cơ sở dữ liệu của các khách hàng khác 4) Không cần xem xét tập dữ liệu một bộ dữ liệu sống (cập nhật-có thể)

Cá nhân, tôi nghĩ rằng 1 và 2 ở trên đã đánh vần giải pháp của chúng tôi bằng cách hạn chế không gian giải pháp với các yêu cầu.

Giải pháp được đề xuất của tôi sẽ có dữ liệu (nhiều như được chọn) được lưu trữ trong một cửa hàng chỉ đọc/bộ nhớ cache, nơi nó có thể được gán một số hàng trong tập kết quả và cho phép phân trang xuất hiện trên ảnh chụp nhanh dữ liệu này. Tôi đã có cơ sở hạ tầng để lưu trữ ảnh chụp nhanh (máy chủ, bộ nhớ cache bên ngoài, memcached hoặc ehcache - điều này phải quy mô khá lớn). Kết quả của truy vấn như vậy sẽ là ID chụp nhanh và khách hàng có thể truy xuất dữ liệu từ ảnh chụp nhanh bằng API chụp nhanh (dịch vụ web) và ID chụp nhanh. Kết quả sẽ được xử lý theo cách chỉ đọc, chuyển tiếp cho các bản ghi x tại thời điểm x là một cái gì đó hợp lý.

Suy nghĩ và ý tưởng cạnh tranh, phê bình hoặc giải thưởng sẽ được đánh giá cao.

Answer 1

Kết quả được phân trang trong Dịch vụ web thực sự khá dễ thực hiện.

Tất cả những gì bạn phải làm là thêm hai tham số vào cuộc gọi dịch vụ web: Kích thước trang, Số trang.

Kích thước trang là số lượng kết quả cần đưa vào một trang. Số trang là số trang kết quả bạn đang tìm kiếm.

Dịch vụ web của bạn sau đó quay trở lại cơ sở dữ liệu (hoặc bộ nhớ cache), truy xuất kết quả, tìm ra kết quả nào phù hợp trên trang được yêu cầu và chỉ trả về các kết quả đó.

Khách hàng sau đó phải thực hiện một yêu cầu duy nhất trên mỗi trang kết quả họ muốn từ dịch vụ.

Answer 2

Những gì bạn đề xuất với memcached cũng sẽ hoạt động với bảng lưu trong bộ nhớ cache. Cuộc gọi dịch vụ đầu tiên sẽ (1) kết quả INSERT Vào bảng lưu trữ đệm với một ID chụp nhanh (2) trả về trang đầu tiên từ bảng lưu trữ và ID chụp nhanh. Các cuộc gọi tiếp theo sẽ trả về các trang dựa trên kích thước trang và số trang bằng cách truy vấn bảng lưu trữ bằng cách sử dụng ID chụp nhanh. Tôi nên nghĩ rằng điều này cũng có thể được tối ưu hóa bằng cách sử dụng bảng bộ nhớ đệm trong bộ nhớ, nhưng điều đó phụ thuộc vào việc cơ sở dữ liệu của bạn có hỗ trợ INSERT-INTO từ bảng đĩa đến bảng trong bộ nhớ hay không. Điều đó có thể trở nên phức tạp trong môi trường nhóm.

Bộ nhớ cache như vậy là rất quan trọng nếu bạn giữ lại bản sao dành riêng cho khách hàng giữa các yêu cầu, cho dù bộ nhớ nằm trong đối tượng phiên, bảng cơ sở dữ liệu hoặc lưu trữ dữ liệu ghi nhớ. Tuy nhiên, với các yêu cầu, bạn không có lựa chọn nào khác ngoài việc lưu trữ kết quả ở dạng nào đó hoặc dạng khác, ngoại trừ bạn có nguy cơ trả lại các hồ sơ đã xóa hoặc không còn liên quan như kết quả hợp pháp.

Answer 3

SOA không dành cho chức năng cấp thấp như vậy.

SOA có nghĩa là dán các khu vực kinh doanh với nhau, chứ không phải là giao diện người dùng cho các chương trình phụ trợ. Không phải vì ứng dụng của bạn nói chuyện với phía sau bằng cách sử dụng các dịch vụ web mà bạn có một ứng dụng "SOA". Điều này là không có ý nghĩa vì SOA là vô nghĩa trong bối cảnh của 1 hệ thống bị cô lập. Từ quan điểm đó, sau đó rõ ràng rằng, trong SOA, người gọi không nên biết về bảng SQL mà bạn đang phân trang, đó là một chi tiết triển khai mà SOA nên ẩn đi. Mặt khác, máy chủ không nên biết về trạng thái của máy khách, bởi vì nó sẽ là bất khả tri đối với các chi tiết của các máy khách, để thực sự mở.

Vì vậy, chỉ cần hiểu rằng phân trang không phải là SOA. Làm như bạn muốn, chỉ cần hiểu rằng webservice bạn đang sử dụng để phân trang là một tạo phẩm nội bộ của ứng dụng của bạn, không được sử dụng cho các máy khách bên ngoài trong một bus SOA. Cũng nên nhớ rằng nó không thể được giao dịch phù hợp với nhà nước trong máy chủ. Có thể vấn đề là bạn chỉ có một lớp dịch vụ cho giao diện người dùng của ứng dụng và bus SOA, bạn cần tách chúng ra.

Sử dụng dịch vụ web này trong một bus SOA sẽ là xấu. Tôi không thể nhất quán khi người dùng phân loại và khi các ứng dụng khác treo vào nó, họ trở nên gắn với SQL cụ thể.

... thì bạn cũng có thể đã cấp quyền truy cập SQL trực tiếp vào bảng cho tất cả những vấn đề đó.

SOA là dành cho thông điệp doanh nghiệp giữa các hệ thống, không phải để dán giao diện người dùng của ứng dụng vào chương trình phụ trợ.

Answer 4

Cùng một sự cố, được giải quyết bằng cách sử dụng phương pháp Navision.

$ws->getList($first_record_id, $limit) 

này trả về một trang của nguyên tố $ giới hạn đó bắt đầu từ id qua

select * from collection where collection.id > $first_record_id ASC limit $limit 

lệnh của id ASC

Navision sử dụng chính (mỗi phần tử có một chìa khóa) nhưng trong MySQL một id autoincrement là tốt hơn.

Trong trường hợp này pagination dành cho xử lý bộ kết quả lớn và không cho một pagination frontend ...

Answer 5

Tôi không chắc chắn nếu SOA là mối quan tâm ở đây. Vấn đề bạn có vẻ là với việc phân trang API của bạn. Tôi sẽ chỉ cho bạn cách twitter xử lý pagination của họ dev.twitter.com/rest/public/timelines