评论专栏: Andre Tost：我的 10 大 Web 服务问题

引言

在为 IBM WebSphere® 开发者技术期刊撰写专栏之前，我花费了大量的时间与架构师、开发人员谈论了他们在基于 Web 服务和 SOA 设计以及构建解决方案时所面临的问题。有一些问题和主题一再成为讨论的焦点，因此，我把我个人认为是与 Web 服务相关的 10 大问题列出来与大家分享。

注意，我没有把它们称为最佳实践，是因为其中有许多问题并不太容易回答。相反，别人对这些问题已经回答过许多次，对于这些内容，我只是想指导您了解一下我比较喜欢的资源，这些资源对该主题进行了较为详细的说明（当然这些资源大多数是一些 developerWorks 文章）。我认为这些主题涉及的领域非常广泛，对于我的某些观点，您可以完全赞同也可以完全不赞同；您也可以添加其他主题。这里为您敞开了一扇大门，欢迎您对我的看法提出意见。

回页首

1. 文档/文本 Web 服务到底是什么？

这无疑是我听到的首要问题。事实上，我们在数年前就听到这一问题，令人感到有些惊奇的是，到目前为止仍有人时常提出这一问题，而且对这一问题仍存在一些误解。您可能知道，您可以在 WSDL 定义中定义 Web 服务的调用样式和编码样式。尽管这对构建网络 SOAP 消息的确切方式存在影响，但对整体解决方案、交互样式或编程模型几乎毫无效果。因此我的建议始终是：

• 不要将使用某个特定的样式作为整个企业范围的规则。使用不同的样式有各种各样的原因，而且您很可能会碰到所有这些样式。
• 将该主题看作是一种实现细节，不要让该主题推动或影响您的系统设计。
• 请阅读 Russ Butek 撰写的优秀文章 我应该采用哪一种 WSDL 样式？，我认为这篇文章对这些不同之处做出了最好的解释。

回页首

2. Web 服务非常慢，或者 Web 服务是否非常慢？

众所周知，使用 Web 服务在性能上会受到一定程度的影响。这几乎不会令人感到惊奇，因为使用 Web 服务时通常会涉及到把使用某种本机格式设置的数据构建为 XML 文档，并在网络中发送此文档。尽管交叉处理（甚至是跨网络处理）始终比本地调用要慢得多，但是如果听到已经对 Web 服务的性能进行了一些改进，您可能会感到惊奇。

有许多技术可以实现这一点；例如，智能 XML 解析器技术（为处理 SOAP 和 XML 构件而进行了高级优化）或 XML 应用程序的出现（如 IBM DataPower®，该应用程序支持硬件级别的 XML 处理）。还有 WebSphere Application Server 中的 Web 服务缓存支持功能，该功能也有助于大大提高性能。事实上，在某些情况下，在最新 WebSphere Application Server 运行时上的 SOAP over HTTP 调用比使用 RMI over IIOP 调用相同的功能要快。

因此，我的建议是应继续对分布式计算应用基本的最佳实践（例如，减少网络通信量等），但开始考虑使用 Web 服务，甚至是用在对性能要求关键的情况中。

回页首

3. 我的 XML 模式不适用于您的产品

在经过了开发 Hello World 样式的测试应用程序之后，您可能会注意到，在您的工具中，XML 模式规范中的某些更高级别的元素或者不受支持或者不能很好地 支持。例如，在 WebSphere 工具中，不存在对 <xsd:choice> 元素的映射，该元素在模式中非常通用。对于 <xsd:group> 也是这种情况。在这些情况下，您可以选择更改模式，也可以选择开发自己的代码来处理基于此模式的 XML。请注意，可能需要手动干预才能将您的模式映射到 Web 服务实现。我建议的两篇文章是：

• Web 服务技巧: 将多态性作为 xsd:choice 的备选方法
• 如何为 Web 服务选择一种自定义映射技术

总之，这里没有一次性解决所有问题的万能方法。不过，我们有理由期望这些标准和产品的未来版本也能够提供对高级模式不断增强的支持。

回页首

4. UDDI 是什么情况？还有人在使用它吗？

在 Web 服务首次开始流行之后，人们始终指出在任何 SOA 环境中都存在以下三种主要角色：

• 服务请求程序
• 服务提供程序
• 服务代理程序

代理程序角色一般由遵循 UDDI 标准的注册中心表示。提供公共注册中心可让您创建自己的项和重复使用其他项。WebSphere Application Server 还附带了一个专用 UDDI 注册中心。

不过，在实际情形中我仍没有看到 UDDI 有多大用处（如果有）。大多数 IT 组织或者构建自己的方式来获取服务定义和连接端点（例如使用 LDAP），或者弃用 UDDI，等待注册中心的新标准。其他还有将专有扩展添加到 UDDI。公共 UDDI 注册中心由 IBM 支持，其他组织已经放弃。

我的预测是，在这一领域，随着时间的推移 UDDI 将由未来的新技术代替。

回页首

5. Web 服务的同步

另一个经常讨论的主题是，服务是同步的还是异步的，与编程模型相比，使用的通信协议充当什么角色。例如，假设使用 SOAP over JMS 绑定提供了 Web 服务。使用 JMS（支持异步交互）好像意味着这是一个异步 Web 服务。不过，如果在 WebSphere Application Server 中使用 JAX-RPC 支持，则服务使用者将在返回控制之前等待返回响应。这一原因是，无论是否使用了该协议，JAX-RPC 1.1 都在请求程序和提供程序之间强制执行了一个同步交互。换句话说，用来调用 Web 服务的编程模型通常确定调用的同步性，而不是网络协议。

要构建真正的异步交互，您有两个主要选项。第一个选项是构建一系列交换信息的单向服务，例如使用 WebSphere Application Server V6.1 中的 WS-Addressing 支持。我推荐的一篇 developerWorks 上的文章对此内容进行了详细说明：Web 服务寻址（WS-Addressing）对 SOAP 的隐式影响。

另一个选项是对异步调用使用服务组件体系结构 (SCA) 支持。SCA 提供了一个客户端 API，后者可以将发送的请求与接收的响应分离开。将来，新的 JAX-WS 2.0 标准将提供类似的支持。

回页首

6. ESB 或非 ESB

有许多问题都与企业服务总线 (ESB) 这一主题相关：

1. ESB 究竟是什么？它是一种产品还是一种模式，或者二者兼具？
2. 每个 SOA 实现是否都需要 ESB？
3. 假设 ESB 集线器，它是否有可能存在瓶颈问题？
4. ESB 中 是什么，ESB 上 是什么？

在尝试回答这些问题之前，先为您提供一项关键资源，该资源很好地解释了 IBM 对 SOA 编程模型上下文中的 ESB 的看法：IBM 企业服务总线介绍。

回答上述问题涉及到整个系列文章，因此我在这里仅提供一些主要解答要点，让您有个初步了解；它们分别是：

1. 企业服务总线是一种体系结构模式。产品可以方便创建该模式的特定实例。
2. ESB 的关键特性是分离关注点。像通信协议差异、路由和审核交互、安全性之类的内容可以在实际的服务请求程序和提供程序之外处理。如果不使用此分离方法就能够开始您的解决方案，则不需要立即使用 ESB。不过，在大多数项目中都不会出现这种情况。
3. ESB 是一种概念上的集线器，在几乎所有实例中都以分布式方式物理地部署。
4. 尽管这有时很难说清楚（而且通常由您使用的产品驱动），但谈论的一个较好切入点是考虑基础结构 逻辑和业务 逻辑。与基础结构相关的内容在总线中发生，而与业务相关的内容则不是。

而且，我不主张这些简单的解答就是对该主题的正当解释，但它们也许为您的理解提供一些帮助。

回页首

7. 标头和其他上下文数据

Web 服务设计的一个关键部分是定义进出服务的消息。可以保险地说消息始终有两个关键部分：与业务功能相关的实际负载和上下文数据（如消息 ID、事务或会话 ID、安全信息等）。每个消息协议都为此上下文信息（SOAP 标头、JMS 标头、WebSphere“工作区”等）提供一个位置。问题是没有一个一致的方法或 API 来处理这些不同的机制，而且在大多数实际的 SOA 环境中，您会遇到多个消息传递协议。

最适于您处理这种不同、而且实际上可让您将一个标头结构映射到另一个结构的位置是 ESB（这是使用 ESB 的又一好处；下文至少还会提供一个这样的示例）。此映射很可能需要一些手工工作。

无论您是如何处理的，关键是要为其尽早规划和设计一个策略，并尽量在您的所有项目中保持一致。

回页首

8. 最终需要使用多少 (Web) 服务？

我对该问题的第一反应始终是建议采用一种方法，以便在确定服务的过程中作为指导。其中一个这样的示例是由 IBM 全球业务服务部提倡的面向服务的建模和体系结构 (SOMA) 方法。与 IBM Rational® Unified Process (RUP) 联合在一起通常可促使您使用 SOA 的方法。

第二，不要因为能够包装而将每项 IT 功能都包装在 Web 服务中。有时会使您对此采用整个“自下而上”的方法并使用富工具支持。在大多数（甚至是所有）情况下，采用此方法会导致服务太多，分得太细，没有重用而且与业务不相关。

而且，对此也没有很好的方法！业务分析师和 IT 架构师以适当的细分级别定义和创建适当的服务相当不容易。

回页首

9. 作为 Web 服务使用者的遗留应用程序

我们对通过 Web 服务支持现有功能给予了较多的关注。我所了解到的谈论得比较少（即使也同等重要）的是现有应用程序利用新服务的能力。例如，假设公司在对 SOA 采用发展的方法，随着时间的推移创建新服务，并将它们集成到现有环境中。其中一个现有应用程序是使用 RPG 编写的，并运行于 IBM iSeries 系统。现在需要将此应用程序更改为调用其中一个新服务。但负责此系统的开发人员对 SOAP 或 XML 不太熟悉，而且没有基于 RPG 的 Web 服务包。

对此问题的最通用的解决方法是将 SOAP 和 XML 处理委托给 ESB。例如，使用 COBOL 或 RPG 编写的应用程序可以容易地与 WebSphere MQ 队列交换记录格式的消息。已经建立了对这种方法的很好支持，而且已经并且经常使用。像 WebSphere ESB 或 WebSphere Message Broker 之类 ESB 产品可以从 MQ 接收数据，将其转换为 XML，然后处理新 Web 服务的调用。

换句话说，通常较为可取的方法是，将新服务对现有应用程序的影响保持在最低限度，并将协议和消息格式的细节委托给 ESB。

回页首

10. “困难在于具体实施”

最近，我访问了法国的 IBM 工业解决方案中心。该中心展示了针对不同行业（如零售业、卫生保健业或银行业）的基于 IBM 的解决方案。展示人员并没有提及任何特定的 IT 产品，而且重点说明了解决方案的实际（业务）功能。但是他不经意地指出一点：“当然，您在这里看到的一切都基于 SOA”。尽管我认为他不是太关注如何针对异步交互在多个协议之间维护 WS-Addressing 标头。

不过，构建、设计和实现 Web 服务和 SOA 会带来许多详细的 IT 技术问题。我们在使用新标准、新编程模型，而且经常使用新产品。创建支持诸如异类平台之间交互的应用程序、企业范围重用 IT 服务并按业务线需求不断更改系统的功能要求，通常会导致不可预见的问题。

因此，下次您的经理进入您的办公室说：“我希望构建一个每个人都说非常容易做到的这种 SOA 解决方案”时，您可以按照我的同事 Greg Flurry 这时爱讲的一句话说：“困难在于具体实施！”