Sự khác biệt giữa kiểu tài liệu và giao tiếp kiểu RPC là gì?


92

Ai đó có thể giải thích cho tôi sự khác biệt giữa dịch vụ web kiểu Document và RPC không? Ngoài JAX-RPC, phiên bản tiếp theo là JAX-WS, hỗ trợ cả kiểu Document và RPC. Tôi cũng hiểu các dịch vụ web kiểu tài liệu dành cho giao tiếp Không đồng bộ trong đó máy khách sẽ không chặn cho đến khi nhận được phản hồi.

Dù bằng cách nào, bằng cách sử dụng JAX-WS, tôi hiện chú thích dịch vụ bằng @Webservice , tạo WSDL và từ WSDL đó, tôi tạo các tạo tác phía máy khách.

Sau khi nhận được các hiện vật, trong cả hai kiểu, 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?

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.


Câu trả lời:


97

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.


Đặc biệt cảm ơn vì "Tôi nên sử dụng kiểu WSDL nào?" liên kết bài viết.
Boolean_Type

23

Dịch vụ web kiểu RPC sử dụng tên của phương thức và các tham số của nó để tạo cấu trúc XML đại diện cho ngăn xếp cuộc gọi của phương thức. Kiểu tài liệu cho biết phần thân SOAP chứa tài liệu XML có thể được xác thực dựa trên tài liệu lược đồ XML được xác định trước.

Một điểm khởi đầu tốt: SOAP Binding: Sự khác biệt giữa Dịch vụ Web kiểu Tài liệu và RPC


20

Trong định nghĩa WSDL, các ràng buộc chứa các thao tác, ở đây là kiểu cho từng thao tác.

Tài liệu: Trong tệp WSDL, nó chỉ định chi tiết các loại hoặc có nội tuyến Hoặc nhập tài liệu XSD, tài liệu này mô tả cấu trúc (tức là lược đồ) của các kiểu dữ liệu phức tạp đang được trao đổi bằng các phương thức dịch vụ được kết hợp lỏng lẻo. Kiểu tài liệu là mặc định.

  • Lợi thế :
    • Sử dụng kiểu Tài liệu này, chúng tôi có thể xác thực các thông báo SOAP dựa trên lược đồ được xác định trước. Nó hỗ trợ các kiểu và mẫu dữ liệu xml.
    • ghép nối lỏng lẻo.
  • Nhược điểm : Có một chút khó hiểu.

Trong loại WSDL, phần tử trông như sau:

<types>
 <xsd:schema>
  <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/>
 </xsd:schema>
</types>

Lược đồ đang nhập từ tham chiếu bên ngoài.

RPC : Trong tệp WSDL, nó không tạo lược đồ kiểu, bên trong các phần tử thông báo, nó xác định các thuộc tính tên và kiểu để kết hợp chặt chẽ với nhau.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>  
  • Ưu điểm : Dễ hiểu.
  • Bất lợi :
    • chúng tôi không thể xác nhận các thông báo SOAP.
    • liên kết chặt chẽ

RPC: Không có loại nào trong
Tài liệu WSDL : Phần Loại sẽ có sẵn trong WSDL


Chỉ lặp lại những gì có trong tài liệu tham khảo. Lời giải thích này không giúp tôi hiểu được sự khác biệt.
kinunt

1
điều này chắc chắn không phải từ tài liệu tham khảo hoặc tài liệu - nó đầy những lỗi ngữ pháp
specializt

7

Kịch bản chính trong đó kiểu JAX-WS RPCDocument được sử dụng như sau:

  • Mẫu Cuộc gọi Thủ tục Từ xa (RPC) được sử dụng khi người tiêu dùng xem dịch vụ web như một ứng dụng hoặc thành phần logic duy nhất với dữ liệu được đóng gói. Các bản tin yêu cầu và phản hồi ánh xạ trực tiếp đến các tham số đầu vào và đầu ra của lệnh gọi thủ tục.

    Ví dụ về loại này, mẫu RPC có thể bao gồm dịch vụ thanh toán hoặc dịch vụ báo giá cổ phiếu.

  • Mẫu dựa trên tài liệu được sử dụng trong các tình huống mà người tiêu dùng xem dịch vụ web như một quy trình kinh doanh chạy lâu hơn trong đó tài liệu yêu cầu đại diện cho một đơn vị thông tin hoàn chỉnh. Loại dịch vụ web này có thể liên quan đến sự tương tác của con người, chẳng hạn như với tài liệu yêu cầu cấp tín dụng với tài liệu phản hồi có chứa hồ sơ dự thầu từ các tổ chức cho vay. Bởi vì các quy trình nghiệp vụ đang chạy lâu hơn có thể không thể trả lại tài liệu được yêu cầu ngay lập tức, mẫu dựa trên tài liệu thường được tìm thấy hơn trong các kiến ​​trúc truyền thông không đồng bộ. Biến thể Tài liệu / chữ của SOAP được sử dụng để triển khai mẫu dịch vụ web dựa trên tài liệu.


3

Tôi nghĩ những gì bạn đang hỏi là sự khác biệt giữa các dịch vụ web RPC Literal, Document Literal và Document Wrapped SOAP.

Lưu ý rằng các dịch vụ web Tài liệu cũng được mô tả theo nghĩa đen và gói và chúng khác nhau - một trong những điểm khác biệt chính là dịch vụ sau tuân thủ BP 1.1 và dịch vụ trước thì không.

Ngoài ra, trong Document Literal, thao tác được gọi không được chỉ định về tên của nó trong khi trong Wrapped, nó là như vậy. Tôi nghĩ đây là một sự khác biệt đáng kể về mặt dễ dàng tìm ra tên hoạt động mà yêu cầu dành cho.

Về mặt chữ RPC so với Document Wrapped, yêu cầu Document Wrapped có thể dễ dàng được kiểm tra / xác nhận dựa trên lược đồ trong WSDL - một lợi thế lớn.

Tôi đề xuất sử dụng Document Wrapped làm loại dịch vụ web được lựa chọn do những ưu điểm của nó.

SOAP trên HTTP là giao thức SOAP được liên kết với HTTP như là nhà cung cấp dịch vụ. SOAP cũng có thể qua SMTP hoặc XXX. SOAP cung cấp một cách tương tác giữa các thực thể (ví dụ: máy khách và máy chủ) và cả hai thực thể có thể điều phối các đối số hoạt động / trả về giá trị theo ngữ nghĩa của giao thức.

Nếu bạn đang sử dụng XML qua HTTP (và bạn có thể), nó được hiểu đơn giản là tải trọng XML trên yêu cầu / phản hồi HTTP. Bạn sẽ cần cung cấp khuôn khổ để điều khiển / không quản lý, xử lý lỗi, v.v.

Hướng dẫn chi tiết với các ví dụ về WSDL và mã nhấn mạnh vào Java: SOAP và JAX-WS, RPC so với Dịch vụ Web Tài liệu


2

Tài
liệu Thông báo kiểu tài liệu có thể được xác thực dựa trên lược đồ xác định trước. Theo kiểu tài liệu, thông báo SOAP được gửi dưới dạng một tài liệu duy nhất. Ví dụ về lược đồ:

  <types>  
   <xsd:schema> <xsd:import namespace="http://example.com/" 
    schemaLocation="http://localhost:8080/ws/hello?xsd=1"/>  
   </xsd:schema>  
  </types>

Ví dụ về thông báo thân xà phòng kiểu tài liệu

  <message name="getHelloWorldAsString">   
     <part name="parameters" element="tns:getHelloWorldAsString"/>   
  </message> 
  <message name="getHelloWorldAsStringResponse">  
     <part name="parameters"> element="tns:getHelloWorldAsStringResponse"/>   
  </message>

Thông báo kiểu tài liệu được ghép nối lỏng lẻo.

RPC Thông báo kiểu RPC sử dụng tên phương thức và các tham số để tạo cấu trúc XML. thông báo khó được xác thực dựa trên lược đồ. Trong kiểu RPC, thông điệp SOAP được gửi bao nhiêu phần tử.

  <message name="getHelloWorldAsString">
    <part name="arg0"> type="xsd:string"/>   
   </message> 
  <message name="getHelloWorldAsStringResponse">   
    <part name="return"
   > type="xsd:string"/>   
  </message>

Ở đây mỗi tham số được chỉ định riêng biệt, thông báo kiểu RPC được kết hợp chặt chẽ, thường là tĩnh, yêu cầu thay đổi đối với máy khách khi chữ ký phương thức thay đổi Kiểu rpc được giới hạn ở các kiểu XSD rất đơn giản như Chuỗi và Số nguyên, và kết quả là WSDL sẽ không thậm chí có một phần loại để xác định và ràng buộc các tham số

Literal Theo phong cách mặc định. Dữ liệu được tuần tự hóa theo một lược đồ, kiểu dữ liệu không được chỉ định trong các thông báo nhưng một tham chiếu đến lược đồ (không gian tên) được sử dụng để xây dựng các thông điệp xà phòng.

   <soap:body>
     <myMethod>
        <x>5</x>
        <y>5.0</y>
     </myMethod>
   </soap:body>

Loại dữ liệu được mã hóa được chỉ định trong mỗi tham số

   <soap:body>
     <myMethod>
         <x xsi:type="xsd:int">5</x>
         <y xsi:type="xsd:float">5.0</y>
     </myMethod>
   </soap:body>

Giản đồ miễn phí

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.