文档样式和RPC样式的通信有什么不同?

Can somebody explain to me the differences between Document and RPC style webservices? Apart from JAX-RPC, the next version is JAX-WS, which supports both Document and RPC styles. I also understand document style webservices are meant for Asynchronous communication where a client would not block until the response is received.

有人能给我解释一下文档和RPC样式的web服务之间的区别吗?除了JAX-RPC之外，下一个版本是JAX-WS，它支持文档和RPC样式。我还理解文档样式的webservices是用于异步通信的，在接收到响应之前，客户端不会阻塞。

Either way, using JAX-WS I currently annotate the service with @Webservice, generate the WSDL and from that WSDL I generate the client side artifacts.

不管怎样，使用JAX-WS我现在用@Webservice来注释服务，生成WSDL，从这个WSDL中生成客户端工件。

Once the artifacts are received, in both styles, I invoke the method on the port. Now, this does not differ in RPC style and Document style. So what is the difference and where is that difference visible?

在收到工件之后，我以两种样式调用端口上的方法。现在，这在RPC样式和文档样式上没有区别。那么它们的区别是什么呢?区别在哪里?

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

类似地，HTTP上的SOAP与HTTP上的XML有什么不同?毕竟，SOAP也是带有SOAP名称空间的XML文档。

5 个解决方案

#1

Can some body explain me the differences between a Document style and RPC style webservices?

有人能解释一下文档样式和RPC样式的web服务之间的区别吗?

There are two communication style models that are used to translate a WSDL binding to a SOAP message body. They are: Document & RPC

有两个通信样式模型用于将WSDL绑定转换到SOAP消息体。它们是:文档和RPC

The advantage of using a Document style model is that you can structure the SOAP body any way you want it as long as the content of the SOAP message body is any arbitrary XML instance. The Document style is also referred to as Message-Oriented style.

使用文档样式模型的好处是，只要SOAP消息体的内容是任意的XML实例，您就可以任意构造SOAP消息体。文档样式也称为面向消息的样式。

However, with an RPC style model, the structure of the SOAP request body must contain both the operation name and the set of method parameters. The RPC style model assumes a specific structure to the XML instance contained in the message body.

但是，使用RPC样式模型，SOAP请求体的结构必须包含操作名和方法参数集。RPC样式模型假定消息体中包含的XML实例具有特定的结构。

Furthermore, there are two encoding use models that are used to translate a WSDL binding to a SOAP message. They are: literal, and encoded

此外，有两个编码使用模型用于将WSDL绑定转换为SOAP消息。它们是:字面的和编码的

When using a literal use model, the body contents should conform to a user-defined XML-schema(XSD) structure. The advantage is two-fold. For one, you can validate the message body with the user-defined XML-schema, moreover, you can also transform the message using a transformation language like XSLT.

在使用文字使用模型时，主体内容应该符合用户定义的XML-schema(XSD)结构。优点是双重的。首先，可以使用用户定义的xml模式验证消息体，此外，还可以使用XSLT之类的转换语言转换消息。

With a (SOAP) encoded use model, the message has to use XSD datatypes, but the structure of the message need not conform to any user-defined XML schema. This makes it difficult to validate the message body or use XSLT based transformations on the message body.

使用(SOAP)编码的使用模型，消息必须使用XSD数据类型，但是消息的结构不需要符合任何用户定义的XML模式。这使得验证消息体或使用基于消息体的XSLT转换变得困难。

The combination of the different style and use models give us four different ways to translate a WSDL binding to a SOAP message.

不同样式和使用模型的组合为我们提供了将WSDL绑定转换为SOAP消息的四种不同方法。

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

I would recommend that you read this article entitled Which style of WSDL should I use? by Russell Butek which has a nice discussion of the different style and use models to translate a WSDL binding to a SOAP message, and their relative strengths and weaknesses.

我建议您阅读这篇题为“我应该使用哪种WSDL风格”的文章。作者Russell Butek对不同的样式进行了很好的讨论，并使用模型将WSDL绑定转换为SOAP消息，以及它们的相对优缺点。

Once the artifacts are received, in both styles of communication, I invoke the method on the port. Now, this does not differ in RPC style and Document style. So what is the difference and where is that difference visible?

在接收到工件之后，在两种通信方式中，我调用端口上的方法。现在，这在RPC样式和文档样式上没有区别。那么它们的区别是什么呢?区别在哪里?

The place where you can find the difference is the "RESPONSE"!

你能找到区别的地方是“回应”!

RPC Style:

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

The SOAP message for second operation will have empty output and will look like:

第二次操作的SOAP消息输出为空，将如下所示:

RPC Style Response:

RPC样式的回应:

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

如果我们为上述SEI运行客户端，输出为:

123 [123, 456]

123(123、456)

This output shows that ArrayList elements are getting exchanged between the web service and client. This change has been done only by the changing the style attribute of SOAPBinding annotation. The SOAP message for the second method with richer data type is shown below for reference:

这个输出显示了在web服务和客户机之间交换的ArrayList元素。此更改仅通过更改SOAPBinding注释的样式属性完成。数据类型更丰富的第二种方法的SOAP消息如下所示，以供参考:

Document Style Response:

文档样式的回应:

<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 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.
正如您在这两个SOAP响应消息中所注意到的，可以在文档样式而不是RPC样式的web服务中验证SOAP响应消息。
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.
使用RPC样式的基本缺点是它不支持更丰富的数据类型，而使用文档样式的缺点是它以XSD的形式为定义更丰富的数据类型带来了一些复杂性。
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?

类似地，HTTP上的SOAP与HTTP上的XML有什么不同?毕竟SOAP也是带有SOAP名称空间的XML文档。这里有什么区别呢?

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这样的标准?通过通过HTTP交换XML文档，两个程序可以交换丰富的结构化信息，而无需引入额外的标准，如SOAP，以显式地描述消息信封格式和编码结构化内容的方法。

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.

SOAP提供了一个标准，因此开发人员不必为他们想要提供的每个服务发明定制的XML消息格式。给定要调用的服务方法的签名，SOAP规范规定了一种明确的XML消息格式。任何熟悉SOAP规范的开发人员(使用任何编程语言)都可以为特定的服务制定正确的SOAP XML请求，并通过获取以下服务细节了解服务的响应。

Service name
服务名称
Method names implemented by the service
由服务实现的方法名称
Method signature of each method
每个方法的方法签名
Address of the service implementation (expressed as a URI)
服务实现的地址(表示为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.

使用SOAP简化了将现有软件组件公开为Web服务的过程，因为服务的方法签名标识了用于请求和响应的XML文档结构。

#2

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.

RPC样式的web服务使用方法的名称及其参数生成表示方法调用堆栈的XML结构。文档样式表明SOAP主体包含一个XML文档，可以根据预定义的XML模式文档进行验证。

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

一个很好的出发点:SOAP绑定:文档和RPC样式的Web服务之间的区别

#3

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

在WSDL定义中，绑定包含操作，这里为每个操作提供样式。

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.

文档:在WSDL文件中，它指定具有内联或导入XSD文档的类型细节，这些文档描述了结构(例如。模式)指由那些使松散耦合的服务方法交换的复杂数据类型。文档样式是违约。

Advantage:
- Using this Document style, we can validate SOAP messages against predefined schema. It supports xml datatypes and patterns.
- 使用这种文档样式，我们可以根据预定义的模式验证SOAP消息。它支持xml数据类型和模式。
- loosely coupled.
- 松散耦合。
优点:使用这种文档样式，我们可以根据预定义的模式验证SOAP消息。它支持xml数据类型和模式。松散耦合。
Disadvantage: It is a little bit hard to get understand.
缺点:理解起来有点困难。

In WSDL types element looks as follows:

在WSDL类型元素中，元素如下所示:

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

RPC:在WSDL文件中，它不创建类型模式，在消息元素中，它定义名称和类型属性，使它们紧密耦合。

<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.
- 我们不能验证SOAP消息。
- tightly coupled
- 紧耦合的
缺点:我们不能验证SOAP消息。紧耦合的

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

RPC:在WSDL文档中没有类型:类型部分将在WSDL中可用。

#4

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

使用JAX-WS RPC和文档样式的主要场景如下:

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.

当使用者将web服务视为具有封装数据的单个逻辑应用程序或组件时，将使用远程过程调用(RPC)模式。请求和响应消息直接映射到过程调用的输入和输出参数。

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

这种类型的RPC模式可能包括支付服务或股票报价服务。
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.

当使用者将web服务视为一个运行时间较长的业务流程时，使用基于文档的模式，其中请求文档表示一个完整的信息单元。这种类型的web服务可能涉及人工交互，例如与包含贷款机构投标的响应文档的信用应用程序请求文档进行交互。由于较长时间运行的业务流程可能无法立即返回所请求的文档，因此基于文档的模式在异步通信体系结构中更为常见。SOAP的文档/文字变体用于实现基于文档的web服务模式。

#5

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

我认为您要问的是RPC文字服务、文档文字服务和文档包装的SOAP web服务之间的区别。

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.

请注意，文档web服务也被划分为文字和包装，它们是不同的——主要的区别之一是后者是BP 1.1兼容的，而前者不是。

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.

就RPC文字和文档包装而言，文档包装请求可以很容易地根据WSDL中的模式进行检查/验证——这是一个很大的优势。

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

我建议使用包装好的文档作为web服务类型，因为它的优点。

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.

HTTP上的SOAP是作为载体绑定到HTTP的SOAP协议。SOAP也可以超过SMTP或XXX。SOAP提供了实体(例如客户端和服务器)之间的交互方式，并且两个实体都可以根据协议的语义来封送操作参数/返回值。

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.

如果您正在通过HTTP使用XML(您可以)，那么可以简单地理解为HTTP请求/响应上的XML有效负载。您需要为封送/解封、错误处理等提供框架。

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

一个详细的教程，其中有WSDL和代码示例，重点是Java: SOAP和JAX-WS、RPC和文档Web服务

#1