在实现 XML 和 Web 服务时要避免的三种常见错误

阅读数:992 2009 年 3 月 15 日

话题:SOA设计模式架构

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 模式。

如果你正在构建 WS-* Web 服务,那么这个 XML 应该被包含在描述你的 Web 服务的 WSDL 之中。即使你在使用 REST 方法,拥有易于访问的 XML 模式将鼓励你的服务被重用。

避免 Kyle 描述的陷阱似乎是个常识。不幸的是,我们的业界证明了,除非很好的理解和治理 SOA 实现,否则我们会继续一次又一次地重复犯同样错误。

查看英文原文Avoiding Three Common Mistakes when Implementing XML and Web Services