Can any authority explain the differences between document style and RPC style web services?
There are two communication style models that are used to translate the WSDL binding to the body of the SOAP message. They are: Document and RPC
The advantage of using a document style model is that you can structure the SOAP body in any way you want, as long as the content of the SOAP message body is an arbitrary XML instance. The document style is also called the Message Oriented Style .
However, when using the RPC style model, the SOAP request body structure must contain both the operation name and a set of method parameters. The RPC style model assumes the specific structure of the XML instance contained in the message body.
In addition, there are two coding usage models that are used to convert the WSDL binding to a SOAP message. It is: literal and encoded
When using the literal use model, the body content must conform to the user-defined XML Schema (XSD) structure. The advantage is doubled. Firstly, you can check the body of the message using a custom XML schema, moreover, you can also convert the message using a conversion language such as XSLT.
Using a (SOAP) coded usage model, a message should use XSD data types, but the message structure should not conform to any custom XML schema. This makes it difficult to validate the message body or use XSLT-based transformations in the message body.
The combination of different styles and uses models gives us four different ways to translate a WSDL binding to a SOAP message.
Document/literal Document/encoded RPC/literal RPC/encoded
I would recommend you read this article titled What style should WSDL use? from Russell Butek, who has a good discussion of the different styles and patterns of use to translate the WSDL binding to the SOAP message and their relative strengths and weaknesses.
Once the artifacts are received, in both communication styles, I will call the method on the port. Now it is no different in RPC style and document style. So what is the difference and where is the difference visible?
The place where you can find the difference is “ANSWER”!
RPC Style:
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); }
The SOAP message for the second operation will have empty output and will look like this:
RPC style reaction:
<ns2:getStockPriceListResponse xmlns:ns2="http://sample.com/"> <return/> </ns2:getStockPriceListResponse> </S:Body> </S:Envelope>
Document Style:
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); }
If we run the client for the above SEI, the output will look like this:
123 [123, 456]
This conclusion shows that ArrayList elements are exchanged between the web service and the client. This change was made only by changing the style attribute of the SOAPBinding annotation. The SOAP message for the second method with a richer data type is given below for reference:
Answer to document style:
<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>
Conclusion
- As you noticed in the two SOAP response responses, you can check the SOAP response message in the case of the DOCUMENT style, but not in the RPC style web services.
- The main disadvantage of using the RPC style is that it does not support richer data types, and using the Document style is that it brings some complexity in the form of an XSD to define richer data types.
- The choice of using one of them depends on the requirements for work / methods and the expected clients.
Similarly, how is SOAP over HTTP different from XML over HTTP? After all, SOAP is also an XML document with a SOAP namespace. So what's the difference here?
Why do we need a standard like SOAP? By exchanging XML documents via HTTP, the two programs can exchange rich structured information without introducing an additional standard, such as SOAP, to explicitly describe the message envelope format and the encoding method of structured content.
SOAP provides a standard so that developers do not have to invent a custom XML message format for each 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 who works in any programming language can formulate the correct XML SOAP request for a particular service and understand the response from the service by receiving the following service data.
- Service name
- Method Names Implemented by the Service
- Method signature for each method
- Service implementation address (expressed as a URI)
Using SOAP simplifies the process of displaying an existing software component as a web service because the signature of the service method identifies the structure of the XML document used for both the request and the response.