Một số cơ quan có thể giải thích cho tôi sự khác biệt giữa kiểu tài liệu và dịch vụ web kiểu RPC được không?
Có hai mô hình kiểu giao tiếp được sử dụng để dịch một liên kết WSDL sang nội dung bản tin SOAP. Đó là:
Tài liệu & RPC
Các lợi thế của việc sử dụng một mô hình phong cách tài liệu là bạn có thể cấu trúc cơ thể SOAP bất kỳ cách nào bạn muốn nó như là miễn là nội dung của cơ thể thông điệp SOAP là bất kỳ trường hợp XML tùy ý. Kiểu tài liệu còn được gọi là kiểu hướng thông báo .
Tuy nhiên, với mô hình kiểu RPC , cấu trúc của phần thân yêu cầu SOAP phải chứa cả tên hoạt động và tập hợp các tham số phương thức. Mô hình kiểu RPC giả định một cấu trúc cụ thể cho thể hiện XML có trong nội dung thông báo.
Hơn nữa, có hai mô hình sử dụng mã hóa được sử dụng để dịch một liên kết WSDL sang một thông báo SOAP. Chúng là: theo nghĩa đen và được mã hóa
Khi sử dụng mô hình sử dụng theo nghĩa đen , nội dung phần thân phải tuân theo cấu trúc XML-schema (XSD) do người dùng xác định . Ưu điểm là gấp đôi. Đối với một, bạn có thể xác thực nội dung thư bằng lược đồ XML do người dùng xác định, hơn nữa, bạn cũng có thể chuyển đổi thư bằng ngôn ngữ chuyển đổi như XSLT.
Với mô hình sử dụng được mã hóa (SOAP) , thông báo phải sử dụng kiểu dữ liệu XSD, nhưng cấu trúc của thông báo không cần tuân theo bất kỳ lược đồ XML nào do người dùng xác định. Điều này gây khó khăn cho việc xác thực nội dung thư hoặc sử dụng các phép biến đổi dựa trên XSLT trên nội dung thư.
Sự kết hợp của các kiểu và mô hình sử dụng khác nhau cung cấp cho chúng ta bốn cách khác nhau để dịch một liên kết WSDL sang một thông báo SOAP.
Document/literal
Document/encoded
RPC/literal
RPC/encoded
Tôi khuyên bạn nên đọc bài viết này có tiêu đề Tôi nên sử dụng kiểu WSDL nào? của Russell Butek, trong đó có một cuộc thảo luận thú vị về các kiểu khác nhau và sử dụng các mô hình để dịch một ràng buộc WSDL sang một thông điệp SOAP, và các điểm mạnh và điểm yếu tương đối của chúng.
Sau khi nhận được hiện vật, trong cả hai kiểu giao tiếp, tôi gọi phương thức trên cổng. Bây giờ, điều này không khác nhau trong kiểu RPC và kiểu Tài liệu. Vậy sự khác biệt là gì và sự khác biệt đó có thể nhìn thấy ở đâu?
Nơi mà bạn có thể tìm thấy sự khác biệt chính là "SỰ PHẢN BIỆN"!
Phong cách RPC:
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
@WebService
@SOAPBinding(style=Style.RPC)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
Thông báo SOAP cho thao tác thứ hai sẽ có đầu ra trống và sẽ giống như sau:
Phản hồi kiểu RPC:
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
Kiểu tài liệu:
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
@WebService
@SOAPBinding(style=Style.DOCUMENT)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
Nếu chúng tôi chạy ứng dụng khách cho SEI ở trên, đầu ra là:
123 [123, 456]
Kết quả này cho thấy rằng các phần tử ArrayList đang được trao đổi giữa dịch vụ web và ứng dụng khách. Thay đổi này chỉ được thực hiện bằng cách thay đổi thuộc tính style của chú thích SOAPBinding. Thông báo SOAP cho phương pháp thứ hai với kiểu dữ liệu phong phú hơn được hiển thị bên dưới để tham khảo:
Phản hồi kiểu tài liệu:
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">123</return>
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">456</return>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
Phần kết luận
- Như bạn đã nhận thấy trong hai thông báo phản hồi SOAP rằng có thể xác thực thông báo phản hồi SOAP trong trường hợp kiểu DOCUMENT nhưng không phải trong các dịch vụ web kiểu RPC.
- Nhược điểm cơ bản của việc sử dụng kiểu RPC là nó không hỗ trợ các kiểu dữ liệu phong phú hơn và việc sử dụng kiểu Tài liệu là nó mang lại một số phức tạp ở dạng XSD để xác định các kiểu dữ liệu phong phú hơn.
- Việc lựa chọn sử dụng một trong số này phụ thuộc vào yêu cầu hoạt động / phương pháp và khách hàng mong đợi.
Tương tự, SOAP qua HTTP khác với XML qua HTTP ở điểm nào? Xét cho cùng thì SOAP cũng là tài liệu XML với không gian tên SOAP. Vậy sự khác biệt ở đây là gì?
Tại sao chúng ta cần một tiêu chuẩn như SOAP? Bằng cách trao đổi tài liệu XML qua HTTP, hai chương trình có thể trao đổi thông tin có cấu trúc, phong phú mà không cần đưa ra tiêu chuẩn bổ sung như SOAP để mô tả rõ ràng định dạng phong bì thư và cách mã hóa nội dung có cấu trúc.
SOAP cung cấp một tiêu chuẩn để các nhà phát triển không cần phải phát minh ra một định dạng thông báo XML tùy chỉnh cho mọi dịch vụ mà họ muốn cung cấp. Với chữ ký của phương thức dịch vụ sẽ được gọi, đặc tả SOAP quy định một định dạng thông báo XML rõ ràng. Bất kỳ nhà phát triển nào quen thuộc với đặc tả SOAP, làm việc trong bất kỳ ngôn ngữ lập trình nào, đều có thể tạo yêu cầu SOAP XML chính xác cho một dịch vụ cụ thể và hiểu phản hồi từ dịch vụ bằng cách lấy các chi tiết dịch vụ sau.
- Tên dịch vụ
- Tên phương pháp được dịch vụ triển khai
- Chữ ký phương thức của mỗi phương thức
- Địa chỉ triển khai dịch vụ (được thể hiện dưới dạng URI)
Sử dụng SOAP hợp lý hóa quy trình để hiển thị thành phần phần mềm hiện có dưới dạng dịch vụ Web vì chữ ký phương thức của dịch vụ xác định cấu trúc tài liệu XML được sử dụng cho cả yêu cầu và phản hồi.