本文将详细解释在实现XML和Web服务时要避免的常见错误。边肖觉得挺实用的，分享给大家参考。希望你看完这篇文章能有所收获。
Kyle指出，通常情况下，当Web服务开发人员开始遇到“内存溢出”错误或奇怪的“性能问题”时，他们总会发现服务器具有极高的处理负载，CPU利用率接近100%，低吞吐量和高网络延迟。这些症状的典型原因是非常大(有时高达50 MB或更多)的消息。此外，这些大消息通常包含由base-64编码的非常大的二进制编码信息，作为XML消息的主体。原因通常是：
……开发人员不理解技术的局限性：XML处理对于解决许多问题是有用的，
但是您必须意识到，要解析的消息是——，在大多数情况下.产品，
这意味着许多或所有消息将驻留在内存中。凯尔建议采用以下方法来改善这种情况：
不要发送多余的信息。在许多情况下，发送二进制数据时，您可能
发现该消息高度重复。如果是这样，您可能希望考虑在HTTP级别使用它。
压缩技术改善您的网络延迟。虽然这无助于您处理负载，但它可以
可以帮助缓解其中一个问题。在XML消息体中，根本不要嵌入二进制信息。这是一个更好的解决方案，
有几种不同的方法可以达到这种效果。例如，您可以将与附件一起使用。
的SOAP或消息传输优化机制(MTOM)绕过了解析开销，尽管它没有帮助
网络延迟问题。……有一种更好的方法可以使用SOAP完全不发送大的二进制blob。
相反，通过受控的文件传输系统使用“带外数据”。
“传输.或“索赔检查(见《EIP模式》或此处)”
模式，以避免在SOAP和HTTP上发送大的二进制文件。根据不好意思，你的数据正在显示。凯尔的说法，网络服务的另一个典型的“性能问题”是使用网络服务的水平非常非常低。——通常，网络服务与一条SQL语句相关，因为：
误解了SOA架构的原理。优秀的SOA架构的关键原则是你的服务。
它应该是高度可重用的。根据凯尔的说法，这些情况通常发生在：
……如果设计是从现有代码“自上而下”派生的服务，则此类服务
会出现；通常，开发人员会查看他们现有的架构图，并决定将
架构中的每一层(包括表示层)都被转换成一个服务集。相反，在SOA架构的正确位置使用粗粒度的Web服务更好。再一次
强调，检查一个架构的标准层次模型，通常架构中会有一个。
明确定义的地方封装了系统业务逻辑。你可以使用远程外观
模式(RemoteFacadePattern)”来包装这些服务，以便使用适当的
以的方式公开基于模型的服务。模式（Schema）？我们不需要任何发臭的模式！凯尔指出，开发人员通常试图重用现有的代码来生成和解析XML，作为网络服务实现的基础。这些实现通常使用XML解析器对消息进行分组/解分组，使用Java HTTP类发送和接收XML文档。使用Web服务时，一般的方法是使用模式元素创建WSDL文档，使XML不受阻碍地传递，然后在现有代码中解析它们。
这个问题的症状是组织未能看到SOA承诺的好处并维护它们
解决方案似乎比以前使用网络服务时更困难(而不是更容易)。简单的解决方案是，每当您编写Web服务时，无论您使用WS-*标准还是REST方法，都要确保您已经创建了一个完整而准确的XML模式来表示您的文档结构。
如果您正在构建WS-*网络服务，那么应该包含这个XML。
在描述你的网络服务的WSDL。即使您使用的是REST方法，
拥有一个可访问的XML模式将鼓励您的服务被重用。避开凯尔描述的陷阱似乎是常识。不幸的是，我们的行业已经证明，除非很好地理解和管理SOA实现，否则我们将一次又一次地犯同样的错误。
这篇关于“实现XML和Web服务时应该避免哪些常见错误”的文章将在这里分享。希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/73733.html