Khả năng tương thích ngược và Dịch vụ Web

Question

Vì vậy, tôi là một chút mới đối với dịch vụ web và một tình huống gần đây đã xuất hiện nơi chúng tôi đã thêm phần tử vào loại dữ liệu được trả lại cho khách hàng. Các khách hàng phàn nàn rằng điều này đã phá vỡ việc thực hiện của họ bởi vì nó nghẹn ngào về yếu tố mới mà nó không mong đợi. (chúng tôi đang cung cấp các dịch vụ qua Axis2).

Với tôi, điều này có vẻ như một thay đổi vô hại mà khách hàng có thể xử lý một cách duyên dáng (tôi đã làm việc với một số khung công tác phi dịch vụ web, nơi thêm thông tin tùy chọn hoàn toàn có thể chấp nhận được). Tôi có thể hiểu nếu chúng tôi đã xóa hoặc đổi tên một số trường có thể gây ra sự cố cho khách hàng.

Về cơ bản, tôi mong đợi wsdl hoạt động như một giao diện. Nếu chúng ta thực hiện một sự thay đổi về cơ bản các kiểu con của giao diện đó, tôi sẽ mong đợi khách hàng vui vẻ bỏ qua các phần tử không liên quan. Đây có phải chỉ là một dịch vụ web ngắn hay có cách tạo thay đổi thụ động cho các dịch vụ để khách hàng mới có thể nhận được dữ liệu bổ sung trong khi khách hàng cũ có thể cập nhật khi rảnh rỗi?

Answer 1

WSDL thực sự hoạt động như một hợp đồng nhiều hơn một giao diện. WSDL mô tả chính xác những gì hoạt động dự kiến ​​sẽ "nhận" và những gì nó dự kiến ​​sẽ "trở lại". Sự tương tự gần nhất với điều này sẽ là trong C thay đổi nguyên mẫu cho một hàm mà không thay đổi chính hàm đó, chúng sẽ không khớp và gây ra vấn đề.

WSDL cụ thể hơn là hành vi bạn đang "đảm bảo" càng tốt.

Nếu bạn cần sự linh hoạt trong dữ liệu trả về của bạn (ví dụ: thêm/gỡ bỏ các lĩnh vực vv), bạn có thể làm một trong các cách sau: định nghĩa WSDL của bạn

1. Phiên bản và công bố dịch vụ có thể chuyển hướng các phiên bản cũ với các phiên bản mới hơn
2. Sử dụng nhiều loại dữ liệu trừu tượng hơn, chẳng hạn như XML để ẩn sự phức tạp hoặc thay đổi dữ liệu.

2 có nhiều rủi ro hơn, nhưng có thể được quản lý bằng XSD hoặc các công nghệ khác. Yêu cầu dự án cụ thể của bạn sẽ quyết định những gì có thể chấp nhận được.

Answer 2

Trong quá khứ, khi xử lý các API WebService được tiếp xúc, tôi đã luôn đi với triết lý phiên bản ngày. Thật không may, bạn phải đối phó với khả năng tương thích ngược đối với bất kỳ API nào bạn phát hành ra công chúng khi bạn đã ra khỏi chế độ "beta" (và đôi khi thậm chí sau đó).

Điều chúng tôi đã làm thật sự đơn giản; vào ngày API mới được phát hành, chúng tôi muốn tạo ra một cấu trúc thư mục như sau:

http://mydomain.com/path/to/service/2009/12/17/servicename.svc 

Bằng cách đó chúng ta sẽ biết được phiên bản mới nhất là chỉ bằng cách kiểm tra cấu trúc thư mục, và các khách hàng của chúng tôi sẽ không có lo lắng về việc phá vỡ các thay đổi cho đến khi chúng sẵn sàng nâng cấp. Làm việc như một nhà vô địch cho chúng tôi; điều duy nhất tôi có thể đã thay đổi là sử dụng một thư mục duy nhất để họ dễ dàng xem tất cả hơn:

http://mydomain.com/path/to/service/2009-12-17/servicename.svc 

Answer 3

WSDL là giao diện SOAP được xuất bản hiệu quả của dịch vụ web của bạn. Nhiều khách hàng sử dụng điều này để tạo các proxy khách hàng của họ để lộ tất cả các phương thức webservice của bạn bằng ngôn ngữ lập trình mà họ lựa chọn. Hầu hết các khách hàng được tạo mã này rất mong manh và sẽ chọn ném một ngoại lệ nếu họ thấy một phần tử mà họ không nhận ra (nghĩa là nó không có trong WSDL) thay vì bỏ qua nó. Một số thì thoải mái hơn và nó thực sự phụ thuộc vào công nghệ của khách hàng mà họ sử dụng, tức làDataContract mới của Microsoft có giao diện IExtensibleData trên máy khách của họ để lưu giữ dữ liệu cụ thể mà họ không nhận ra, vì vậy họ sẽ bỏ qua phần lớn các yếu tố không rõ.

Các proxy khách hàng tạo mã và SOAP tự vay với các loại vấn đề này vì chúng tạo ra các khách hàng muốn hiểu 'toàn bộ lược đồ' thay vì chỉ các bit mà họ quan tâm. Trình phân tích cú pháp và chỉ cần rút ra các bit mà họ cần.

Nếu dịch vụ web của bạn đang được phát triển hoặc thay đổi liên tục thì SOAP thực sự không phải là lựa chọn tốt nhất của bạn vì nó sẽ có nghĩa là mọi thay đổi họ sẽ phải tạo lại, xây dựng lại và triển khai lại dịch vụ khách hàng của họ. Tùy thuộc vào tình huống của bạn, bạn có thể xem xét việc cung cấp các dịch vụ web REST + POX (Plain Old Xml) thay vì đơn giản hơn để phân tích vì nó không có chi phí SOAP, có thể được gọi thông qua một URL bình thường và không có thư viện SOAPClient (ví dụ: trực tiếp trong trình duyệt, sử dụng AJAX)

Answer 4

Một câu trả lời có thể là sử dụng các nhóm thay thế để bật mô hình trừu tượng trong XSD bạn nhập. Khả năng xử lý một nhóm thay thế như vậy vẫn phải được xác thực với các khung công tác mà bạn đang sử dụng để gọi các dịch vụ đó.