문서 스타일과 RPC 스타일 통신의 차이점은 무엇입니까?

문서 스타일과 RPC 스타일 통신의 차이점은 무엇입니까?

---

누군가 문서와 RPC 스타일 웹 서비스의 차이점을 설명 할 수 있습니까? JAX-RPC와 별도로 다음 버전은 JAX-WS로 Document 및 RPC 스타일을 모두 지원합니다. 또한 문서 스타일 웹 서비스는 응답이 수신 될 때까지 클라이언트가 차단되지 않는 비동기 통신을위한 것임을 이해합니다.

어느 쪽이든 JAX-WS를 사용하여 현재 @Webservice로 서비스에 주석을 달고 WSDL을 생성하고 해당 WSDL에서 클라이언트 측 아티팩트를 생성합니다.

아티팩트가 수신되면 두 스타일 모두에서 포트에서 메소드를 호출합니다. 이제 이것은 RPC 스타일과 문서 스타일에서 다르지 않습니다. 그렇다면 차이점은 무엇이며 그 차이점은 어디에 있습니까?

마찬가지로 SOAP over HTTP는 XML over HTTP와 어떤 점에서 다릅니 까? 결국 SOAP는 SOAP 네임 스페이스가있는 XML 문서이기도합니다.

---

어떤 본문이 문서 스타일과 RPC 스타일 웹 서비스의 차이점을 설명 할 수 있습니까?

WSDL 바인딩을 SOAP 메시지 본문으로 변환하는 데 사용되는 두 가지 통신 스타일 모델이 있습니다. 그들은 다음과 같습니다 : 문서 및 RPC

문서 스타일 모델 사용 의 장점은 SOAP 메시지 본문의 내용이 임의의 XML 인스턴스 인 한 원하는 방식으로 SOAP 본문을 구조화 할 수 있다는 것입니다. 문서 스타일은 메시지 지향 스타일 이라고도합니다 .

그러나 RPC 스타일 모델 의 경우 SOAP 요청 본문의 구조에는 작업 이름과 메서드 매개 변수 집합이 모두 포함되어야합니다. RPC 스타일 모델은 메시지 본문에 포함 된 XML 인스턴스에 대한 특정 구조를 가정합니다 .

또한 WSDL 바인딩을 SOAP 메시지로 변환하는 데 사용되는 두 가지 인코딩 사용 모델이 있습니다. 그들은 : 리터럴 및 인코딩

리터럴 사용 모델을 사용할 때 본문 내용은 사용자 정의 XML 스키마 (XSD) 구조를 따라야합니다 . 장점은 두 가지입니다. 우선 사용자 정의 XML 스키마로 메시지 본문의 유효성을 검사 할 수 있으며 XSLT와 같은 변환 언어를 사용하여 메시지를 변환 할 수도 있습니다.

(SOAP) 인코딩 된 사용 모델 을 사용하는 경우 메시지는 XSD 데이터 유형을 사용해야하지만 메시지 구조는 사용자 정의 XML 스키마를 준수 할 필요가 없습니다. 이로 인해 메시지 본문의 유효성을 검사하거나 메시지 본문에서 XSLT 기반 변환을 사용하기가 어렵습니다.

다른 스타일과 사용 모델의 조합은 WSDL 바인딩을 SOAP 메시지로 변환하는 네 가지 방법을 제공합니다.

Document/literal
Document/encoded
RPC/literal
RPC/encoded

어떤 스타일의 WSDL을 사용해야합니까? 라는 제목의이 기사를 읽어 보는 것이 좋습니다 . 러셀 부텍 (Russell Butek)에 의해 서로 다른 스타일에 대한 좋은 토론이 있고 모델을 사용하여 WSDL 바인딩을 SOAP 메시지로 변환하고 상대적인 강점과 약점이 있습니다.

아티팩트가 수신되면 두 가지 유형의 통신 모두에서 포트에서 메소드를 호출합니다. 이제 이것은 RPC 스타일과 문서 스타일에서 다르지 않습니다. 그렇다면 차이점은 무엇이며 그 차이점은 어디에 있습니까?

차이점을 찾을 수있는 곳은 "RESPONSE"입니다!

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); 
}

두 번째 작업에 대한 SOAP 메시지는 빈 출력을 가지며 다음과 같이 표시됩니다.

RPC 스타일 응답 :

<ns2:getStockPriceListResponse 
       xmlns:ns2="http://sample.com/">
    <return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>

문서 스타일 :

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);
}

위의 SEI에 대해 클라이언트를 실행하면 출력은 다음과 같습니다.

123 [123, 456]

이 출력은 ArrayList 요소가 웹 서비스와 클라이언트간에 교환되고 있음을 보여줍니다. 이 변경은 SOAPBinding 주석의 스타일 속성을 변경함으로써 만 수행되었습니다. 데이터 유형이 더 풍부한 두 번째 메소드에 대한 SOAP 메시지는 참조를 위해 아래에 표시됩니다.

문서 스타일 응답 :

<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>

결론

• As you would have noticed in the two SOAP response messages that it is possible to validate the SOAP response message in case of DOCUMENT style but not in RPC style web services.
• The basic disadvantage of using RPC style is that it doesn’t support richer data types and that of using Document style is that it brings some complexity in the form of XSD for defining the richer data types.
• The choice of using one out of these depends upon the operation/method requirements and the expected clients.

Similarly, in what way SOAP over HTTP differ from XML over HTTP? After all SOAP is also XML document with SOAP namespace. So what is the difference here?

Why do we need a standard like SOAP? By exchanging XML documents over HTTP, two programs can exchange rich, structured information without the introduction of an additional standard such as SOAP to explicitly describe a message envelope format and a way to encode structured content.

SOAP provides a standard so that developers do not have to invent a custom XML message format for every service they want to make available. Given the signature of the service method to be invoked, the SOAP specification prescribes an unambiguous XML message format. Any developer familiar with the SOAP specification, working in any programming language, can formulate a correct SOAP XML request for a particular service and understand the response from the service by obtaining the following service details.

• Service name
• Method names implemented by the service
• Method signature of each method
• Address of the service implementation (expressed as a URI)

Using SOAP streamlines the process for exposing an existing software component as a Web service since the method signature of the service identifies the XML document structure used for both the request and the response.

---

An RPC style web service uses the names of the method and its parameters to generate XML structures representing a method’s call stack. Document style indicates the SOAP body contains an XML document which can be validated against pre-defined XML schema document.

A good starting point : SOAP Binding: Difference between Document and RPC Style Web Services

---

In WSDL definition, bindings contain operations, here comes style for each operation.

Document : In WSDL file, it specifies types details either having inline Or imports XSD document, which describes the structure(i.e. schema) of the complex data types being exchanged by those service methods which makes loosely coupled. Document style is default.

• Advantage:
  • Using this Document style, we can validate SOAP messages against predefined schema. It supports xml datatypes and patterns.
  • loosely coupled.
• Disadvantage: It is a little bit hard to get understand.

In WSDL types element looks as follows:

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

The schema is importing from external reference.

RPC :In WSDL file, it does not creates types schema, within message elements it defines name and type attributes which makes tightly coupled.

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

• Advantage: Easy to understand.
• Disadvantage:
  • we can not validate SOAP messages.
  • tightly coupled

RPC : No types in WSDL
Document: Types section would be available in WSDL

---

The main scenario where JAX-WS RPC and Document style are used as follows:

• The Remote Procedure Call (RPC) pattern is used when the consumer views the web service as a single logical application or component with encapsulated data. The request and response messages map directly to the input and output parameters of the procedure call.

  Examples of this type the RPC pattern might include a payment service or a stock quote service.

• The document-based pattern is used in situations where the consumer views the web service as a longer running business process where the request document represents a complete unit of information. This type of web service may involve human interaction for example as with a credit application request document with a response document containing bids from lending institutions. Because longer running business processes may not be able to return the requested document immediately, the document-based pattern is more commonly found in asynchronous communication architectures. The Document/literal variation of SOAP is used to implement the document-based web service pattern.

---

I think what you are asking is the difference between RPC Literal, Document Literal and Document Wrapped SOAP web services.

Note that Document web services are delineated into literal and wrapped as well and they are different - one of the primary difference is that the latter is BP 1.1 compliant and the former is not.

Also, in Document Literal the operation to be invoked is not specified in terms of its name whereas in Wrapped, it is. This, I think, is a significant difference in terms of easily figuring out the operation name that the request is for.

In terms of RPC literal versus Document Wrapped, the Document Wrapped request can be easily vetted / validated against the schema in the WSDL - one big advantage.

I would suggest using Document Wrapped as the web service type of choice due to its advantages.

SOAP on HTTP is the SOAP protocol bound to HTTP as the carrier. SOAP could be over SMTP or XXX as well. SOAP provides a way of interaction between entities (client and servers, for example) and both entities can marshal operation arguments / return values as per the semantics of the protocol.

If you were using XML over HTTP (and you can), it is simply understood to be XML payload on HTTP request / response. You would need to provide the framework to marshal / unmarshal, error handling and so on.

A detailed tutorial with examples of WSDL and code with emphasis on Java: SOAP and JAX-WS, RPC versus Document Web Services

---

Document
Document style messages can be validated against predefined schema. In document style, SOAP message is sent as a single document. Example of schema:

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

Example of document style soap body message

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

Document style message is loosely coupled.

RPC RPC style messages use method name and parameters to generate XML structure. messages are difficult to be validated against schema. In RPC style, SOAP message is sent as many elements.

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

Here each parameters are discretely specified, RPC style message is tightly coupled, is typically static, requiring changes to the client when the method signature changes The rpc style is limited to very simple XSD types such as String and Integer, and the resulting WSDL will not even have a types section to define and constrain the parameters

Literal By default style. Data is serialized according to a schema, data type not specified in messages but a reference to schema(namespace) is used to build soap messages.

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

Encoded Datatype specified in each parameter

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

Schema free

참고URL : https://stackoverflow.com/questions/9062475/what-is-the-difference-between-document-style-and-rpc-style-communication