Performance 为什么HTTP/SOAP被认为是；厚的；_Performance_Http_Soap

Performance 为什么HTTP/SOAP被认为是；厚的；

performance http soap

Performance 为什么HTTP/SOAP被认为是；厚的；,performance,http,soap,Performance,Http,Soap,我听过一些观点认为SOAP/HTTPWeb服务调用堆栈“厚”或“重”，但我不能真正指出原因。是否会因为SOAP信封和消息的序列化/反序列化而被认为很厚？那真的是一个沉重的手术吗或者与通过固定连接进行的原始/二进制数据传输相比，它被认为是“厚”的还是其他原因？有人能解释一下吗？首先，这在很大程度上取决于您的服务是如何实现的（也就是说，只要注意方法签名是如何实现的，您就可以在很大程度上减少负载）这就是说，不仅soap信封，而且消息本身在xml中可能比简化的二进制格式大得多。只要选择正确的类和成

我听过一些观点认为SOAP/HTTPWeb服务调用堆栈“厚”或“重”，但我不能真正指出原因。是否会因为SOAP信封和消息的序列化/反序列化而被认为很厚？那真的是一个沉重的手术吗

或者与通过固定连接进行的原始/二进制数据传输相比，它被认为是“厚”的

还是其他原因？有人能解释一下吗？

首先，这在很大程度上取决于您的服务是如何实现的（也就是说，只要注意方法签名是如何实现的，您就可以在很大程度上减少负载）

这就是说，不仅soap信封，而且消息本身在xml中可能比简化的二进制格式大得多。只要选择正确的类和成员名称，就可以大大减少

考虑以下从返回一组内容的方法返回序列化方法的示例。如果您返回重复数据（例如列表/集合/数组），那么只需为类/包装器和成员选择正确的[序列化]名称，序列化soap请求/响应的详细程度就会有很大的不同

简短/简短的名称：

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ShortIDName>
    <id>0</id>
    <name>foo 0</name>
  </ShortIDName>
  <ShortIDName>
    <id>1</id>
    <name>foo 1</name>
  </ShortIDName>
  <ShortIDName>
    <id>2</id>
    <name>foo 2</name>
  </ShortIDName>
  ...
</ArrayOfShortIDName>

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  ...
</ArrayOfThisClassHasALongClassNameIDName>


0
富0
1.
富1
2.
富2
...

长名称：

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ShortIDName>
    <id>0</id>
    <name>foo 0</name>
  </ShortIDName>
  <ShortIDName>
    <id>1</id>
    <name>foo 1</name>
  </ShortIDName>
  <ShortIDName>
    <id>2</id>
    <name>foo 2</name>
  </ShortIDName>
  ...
</ArrayOfShortIDName>

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  ...
</ArrayOfThisClassHasALongClassNameIDName>


0
富0
1.
富1
2.
富2
...

我认为主要是SOAP信封在构建消息时增加了大量开销，特别是对于只有少量非深层结构参数的简单请求的常见情况。将其与REST样式的web服务进行比较，其中参数仅包含在URL查询中

再加上WSDL的复杂性和典型的“企业”库实现…

我认为它“厚”，因为打包和解包消息（序列化和反序列化）所涉及的开销相对较大

考虑一个web服务，它有一个名为

Add

的web方法，该方法接受两个32位整数。调用者打包两个整数，并收到一个整数作为回复。在真正只有96位信息被传输的地方，添加SOAP数据包可能会在每个方向上增加大约3000或更多的额外位。增加30倍

此外，将消息序列化和反序列化为UTF-8（或任何形式）XML的相关性能相对较慢。诚然，现在的速度相当快，但肯定不是微不足道的。

SOAP的信噪比太低了。对于一个简单的对话，有太多的没有数据值的结构开销；而且需要太多的显式配置（与隐式配置（如JSON）相比）

一开始它不是这样的，但最终它成为了一个海报，展示了当一个标准委员会参与进来时，一个好主意会发生什么。

SOAP的设计足够抽象，可以使用HTTP之外的其他传输。这意味着，除其他外，它没有利用HTTP的某些方面（主要是URL和方法的RESTful使用，例如

PUT/customers/1234

或

GET/customers/1234

）

出于同样的原因，SOAP也绕过了现有的TCP/IP机制——独立于传输。同样，这意味着它不能利用传输，例如序列管理、流控制、服务发现（例如，

accept（）

在已知端口上建立连接意味着服务存在）等

SOAP使用XML进行所有的序列化—这意味着数据只需一个XML解析器就可以“普遍可读”，但它引入了太多的样板文件，因此您确实需要一个SOAP解析器才能有效地运行。在这一点上，您（作为软件消费者）已经失去了XML的好处；如果您需要

libSOAP

以任何方式处理负载，谁会在乎负载在网络上的样子呢

SOAP需要WSDL来描述接口。WSDL本身不是问题，但它往往被宣传为比实际情况更“动态”。在许多情况下，只创建一个WSDL，并自动生成生产者/消费者代码，而且从不更改。总的来说，这需要大量的工具，但实际上没有更好地解决原始问题（如何在不同服务器之间通信）。由于大多数SOAP服务都是在HTTP上运行的，最初的问题基本上已经解决了。

1-XML模式是WSDL规范的关键部分，非常非常庞大和复杂。实际上，将XML模式映射到编程语言构造之类的工具最终只支持部分XML模式功能

2-WS-*规范，例如WS-Security和WS-SecureConversation，同样庞大而复杂。它们的设计几乎使任何人都不会比微软或IBM更少的资源来完全实现它们。

SOAP和WSDL是极其复杂的标准，它们有许多支持不同标准子集的实现。SOAP与简单的外部函数接口的映射方式不同。相反，您必须了解XML名称空间、信封、标题、WSDL、XML模式等，才能生成正确的SOAP消息。调用XML-RPC服务所需要做的就是定义和终止点，并在其上调用一个方法。例如，在Ruby中：

require 'xmlrpc/client'

server = XMLRPC::Client.new2("http://example.com/api")
result = server.call("add", 1, 2)

除了XML-RPC之外，还有其他一些技术也可以更加简单和轻量级，例如纯XML或HTTP（通常称为，尽管这意味着某些其他设计考虑）。类似于XML或JSON而非HTTP的优点是，它很容易从JavaScript使用，甚至只是一个提交表单的哑网页。也可以编写脚本