文档样式和RPC样式通信有什么区别？
有人可以向我解释文档和RPC风格的Web服务之间的区别吗？ 除了JAX-RPC，下一个版本是JAX-WS，它支持Document和RPC样式。 我也理解文档样式的webservices是为了asynchronous通信的客户端不会阻止，直到收到响应。
无论哪种方式，使用JAX-WS我目前使用@Webservice注释该服务，生成WSDL，并从该WSDL生成客户端工件。
一旦收到工件，在这两种风格中，我调用端口上的方法。 现在，这在RPC样式和文档样式中没有区别。 那么有什么区别，差异在哪里可见？
同样，基于HTTP的SOAP与通过HTTP的XML的区别是什么？ 毕竟SOAP也是SOAP命名空间的XML文档。
有人可以解释一下Document style和RPC style webservices之间的区别吗？
有两种通信风格模型用于将WSDL绑定转换为SOAP消息主体。 它们是： 文档和RPC
使用文档样式模型的优点是，只要SOAP消息主体的内容是任意的XML实例，就可以以任何您想要的方式来构造SOAP主体。 文档样式也被称为面向消息的样式 。
但是，对于RPC样式模型 ，SOAP请求体的结构必须同时包含操作名称和方法参数集。 RPC样式模型假设消息正文中包含的XML实例的特定结构。
此外，还有两种编码使用模型，用于将WSDL绑定转换为SOAP消息。 它们是： 文字和编码
使用文字使用模型时 ，正文内容应符合用户定义的XML模式（XSD）结构 。 优点是双重的。 首先，您可以使用用户定义的XML模式validation消息正文，此外，还可以使用XSLT等转换语言来转换消息。
使用（SOAP） 编码的使用模型 ，消息必须使用XSD数据types，但是消息的结构不需要符合任何用户定义的XML模式。 这使得validation邮件正文或在邮件正文上使用基于XSLT的转换变得困难。
不同风格和使用模型的组合为我们提供了四种不同的方法来将WSDL绑定转换为SOAP消息。
Document/literal Document/encoded RPC/literal RPC/encoded 我build议你阅读这篇题为“ 我应该使用哪种WSDL风格的文章？ 由Russell Butek对不同风格和使用模型进行了很好的讨论，将WSDL绑定转换为SOAP消息，以及它们的相对优缺点。
一旦收到工件，在两种通讯方式中，我都调用端口上的方法。 现在，这在RPC样式和文档样式中没有区别。 那么有什么区别，差异在哪里可见？
你可以find差异的地方是“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元素正在Web服务和客户端之间交换。 这个改变只能通过改变SOAPBinding注解的style属性来完成。 下面显示了更丰富数据types的第二种方法的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>
结论
- 正如您在两个SOAP响应消息中所注意到的那样，在DOCUMENT风格的情况下可以validationSOAP响应消息，而在RPC风格的Web服务中不可以。
- 使用RPC风格的基本缺点是它不支持更丰富的数据types，使用Document风格的缺点是它以XSD的forms为定义更丰富的数据types带来了一些复杂性。
- 使用其中之一取决于操作/方法要求和预期的客户。
同样，HTTP上的SOAP与HTTP上的XML有什么不同？ 毕竟SOAP也是SOAP命名空间的XML文档。 那么这里有什么区别呢？
为什么我们需要像SOAP这样的标准？ 通过HTTP交换XML文档，两个程序可以交换丰富的结构化信息，而不需要引入诸如SOAP之类的附加标准来明确描述消息信封格式和对结构化内容进行编码的方式。
SOAP提供了一个标准，以便开发人员不必为每个想要提供的服务创build自定义的XML消息格式。 鉴于要调用的服务方法的签名，SOAP规范规定了明确的XML消息格式。 熟悉SOAP规范的任何使用任何编程语言的开发人员都可以为特定服务制定正确的SOAP XML请求，并通过获取以下服务详细信息来理解服务的响应。
- 服务名称
- 由服务实现的方法名称
- 每种方法的方法签名
- 服务实现的地址（以URI表示）
使用SOAP简化了将现有软件组件公开为Web服务的过程，因为服务的方法签名标识用于请求和响应的XML文档结构。
RPC样式的Web服务使用方法及其参数的名称来生成表示方法调用堆栈的XML结构。 文档样式表示SOAP正文包含一个可以根据预定义的XML模式文档进行validation的XML文档。
一个好的起点： SOAP绑定：文档和RPC风格的Web服务之间的区别
在WSDL定义中，绑定包含操作，每个操作的样式如下。
Document：在WSDL文件中，它指定了具有inline的types细节，或者导入XSD文档，该文档描述了由松散耦合的那些服务方法交换的复杂数据types的结构（即模式）。 文档样式是默认的。
- 优点 ：
- 使用这种文档样式，我们可以根据预定义的模式validationSOAP消息。 它支持XML数据types和模式。
- 松散耦合。
- 缺点 ：理解起来有点难。
在WSDLtypes元素看起来如下所示：
<types> <xsd:schema> <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/> </xsd:schema> </types>
模式是从外部引用导入的。
RPC ：在WSDL文件中，它不创buildtypes模式，在消息元素中它定义使得紧密耦合的名称和types属性。
<types/> <message name="getHelloWorldAsString"> <part name="arg0" type="xsd:string"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="return" type="xsd:string"/> </message>
- 优点 ：易于理解。
- 缺点 ：
- 我们无法validationSOAP消息。
- 紧密耦合
tldr：
RPC： WSDL中没有types
文档：types部分将在WSDL中可用
使用JAX-WS RPC和Document样式的主要场景如下：
-
当消费者将Web服务视为单个逻辑应用程序或具有封装数据的组件时，将使用远程过程调用（RPC）模式。 请求和响应消息直接映射到过程调用的input和输出参数。
这种RPC模式的例子可能包括支付服务或股票报价服务。
-
基于文档的模式用于消费者将Web服务视为更长时间运行的业务stream程，其中请求文档表示完整的信息单元。 这种types的networking服务可能涉及人与人之间的交互， 例如信用申请请求文件与包含来自贷款机构的投标的响应文件。 由于较长时间运行的业务stream程可能无法立即返回请求的文档，因此基于文档的模式在asynchronous通信体系结构中更常见。 SOAP的Document / literal变体用于实现基于文档的Web服务模式。
我认为你所要问的是RPC Literal，Document Literal和Document Wrapped SOAP Web服务之间的区别。
请注意，文档Web服务被划分为文字和包装，它们是不同的 – 主要区别之一是后者符合BP 1.1，前者不符合。
而且，在文字文字中，被调用的操作不是用名字来指定的，而是在被包装的情况下。 我认为，这是一个重要的区别，轻松搞清楚请求的操作名称。
就RPC文本与Wrapped文档而言，Document Wrapped请求可以很容易地根据WSDL中的模式进行审查/validation – 这是一个很大的优势。
由于其优点，我build议使用Document Wrapped作为Web服务types的select。
HTTP上的SOAP是绑定到HTTP的SOAP协议的载体。 SOAP也可以通过SMTP或XXX。 SOAP提供了实体（例如客户端和服务器）之间的交互方式，两个实体可以根据协议的语义来封送操作参数/返回值。
如果您通过HTTP使用XML（也可以），则可以简单地理解为HTTP请求/响应中的XML负载。 您将需要提供编组/解组的框架，error handling等等。
一个详细的教程，其中包含WSDL和代码，重点介绍Java： SOAP和JAX-WS，RPC与Document Web Services
