实现XML和Web服务时要避免的三种常见错误
IBM的Kyle Brown在其评论文章开始描述了一种常见的情景：“许多人因以不恰当的方式使用Web服务和XML而给他们自己挖了一个坑”。在他的评论中，Kyle介绍了三个常见的痛点，解释了它们为何会发生并提供了一些替代方法。
我的消息吃了我的服务器！Kyle指出，通常，Web服务开发者开始经历“内存溢出”的错误或者奇怪的“性能问题”时，总是会发现服务器拥有极高的处理负载，CPU使用率接近100%，以及较低的吞吐量和高网络延迟。导致这些症状的典型原因是非常大的（有时会达到50 MB或者更大）消息。而且，这些大消息往往包含了非常大的、作为XML消息主体的、采用base-64编码的二进制编码信息。导致其发生的原因通常是：
……开发者不理解技术的局限性：XML处理对解决许多问题都有用， 但是你必须认识到消息是要被解析的――并且在大多数……产品中， 这就意味着许多或者所有的消息都会驻留在内存中。 |
Kyle建议采用如下方法来改善这种情况：
不要发送冗余信息。在许多情况下，发送二进制数据时，你可能会 发现消息高度重复。如果是这样，你可能就要考虑在HTTP层面使用 压缩技术来改善你的网络延迟。虽然这不会帮助你处理负载，但可 能有助于减轻其中一个问题。 在XML消息体中，根本不要嵌入二进制信息。这是较好的解决方法， 还有几种不同的途径可以实现这一效果。比如，你可以使用带有附件 的SOAP或者消息传输优化机制（MTOM）绕过解析开销，尽管这无助于 网络延迟问题。 ……还有一个更好的办法，使用SOAP根本不发送大的二进制blob。 替代方法，通过受控的文件传输系统，使用一个“带外数据 ”传输……或者“声明标签（claim Check，参见《EIP模式》或这里）” 模式，避免在SOAP和HTTP上发送大的二进制文件。 |
不好意思，你的数据正在显示。根据Kyle所说，另一个典型的Web服务的“性能问题” 是，使用Web服务的层面非常、非常低――通常Web服务跟一个SQL语句相关，这是因为：
误解了SOA架构原则。一个优秀SOA架构的关键原则是你的服务 应该具有高复用性。 |
根据Kyle所说，这些情况通常发生在：
……如果设计是根据现有代码“自上而下”衍生出服务，这类服务 就会出现；通常，开发者会看着他们现有的架构图并且决定将 架构中的每一层（包括表现层）转变成服务集。 相反，在SOA架构的正确位置使用粗粒度的Web服务会更好。再次 强调，检查一个架构的标准分层模型，通常在架构中会有一个 明确定义的地方已经封装了系统业务逻辑。可以使用“远程门面 模式（Remote Facade Pattern）”来包装这些服务，以便用合适 的方式来暴露基于模型的服务。 |
模式（Schema）？我们不需要任何发臭的模式！ Kyle指出，通常开发者试图重用现有代码来生成和解析作为Web服务实现基础的XML。这些实现通常使用XML解析器来编组/解组消息，同时使用Java HTTP类来发送和接收XML文档。使用Web服务时，通用的方法是，创建使用模式元素的WSDL文档，使XML不受阻地通过，然后在现有代码中对它们进行解析。
这个问题的症状是组织没有看到SOA承诺的好处，而且维护他们的 解决方案似乎比以前使用Web服务的时候更难（而不是更容易） |
简单的解决方案是，每当写Web服务时，不管使用WS-*标准还是使用REST方法，都要确保你创建了代表你文档结构的完整准确的XML模式。
相关推荐
与卿画眉共浮生 2020-10-14
xiyang 2020-08-21
baijinswpu 2020-07-29
leonranri 2020-07-26
zhongliwen 2020-07-05
麋鹿麋鹿迷了路 2020-07-05
zengyu00 2020-07-05
XGQ 2020-07-04
CoderBoy 2020-06-28
whbing 2020-06-28
绝望的乐园 2020-06-27
wellfly 2020-06-26
菇星獨行 2020-06-25
草原孤狼 2020-06-25
坚持着执着 2020-06-16
wcqwcq 2020-06-14
yuanye0 2020-06-14
zhongliwen 2020-06-13
MrFuWen 2020-06-09