信息技术应用之Web服务最佳实践之路

申请免费试用、咨询电话：400-8352-114

一、Web 服务是什么？

在挑选一组最佳实践时，最重要的首要步骤之一是要确保用于描述各种核心概念的语言是清楚、简炼且准确的。例如，SOAP 协议本身就是 Web 服务领域中命名不恰当的技术的“典范”：尽管该首字母缩写代表简单对象访问协议（Simple Object Access Protocol），但是它描述的却是一个与对象没有多大关系并且实现起来也远非那么简单的消息传递协议规范。

W3C Web Services Architecture 小组达成一致意见的 Web 服务的暂行定义如下所示：

Web 服务是由 URI 标识的软件应用程序，其接口和绑定可以通过 XML 构件进行定义、描述和发现，Web 服务支持通过基于因特网的协议使用基于 XML 的消息与其他软件应用程序直接交互。

还要注意到，W3C 的定义尽管提到了服务发现，但并未提到 UDDI 或其他任何特定的发现机制。具体来说，尽管关于Web服务体系结构的早期文献断言 UDDI 要扮演一个核心的、至关重要的角色，但使用 Web 服务的业务解决方案的实际实现却证明，UDDI 实际上仅在目前这个时候能起到最重要的作用；事实上，人们构建了许多并未以任何方式使用 UDDI 的 Web 服务解决方案。在当前的绝大多数业务案例中，可以有把握地说，这些发现机制还不是用于集成业务伙伴之间的流程的核心组件。

W3C 的 Web 服务定义具有深远的影响，这表现在字面上可以被称作 Web 服务的东西的范围包括可以使用 XML 语法唯一地标识和描述的任何软件组件。这个范围可能是无限的，对我们概述一组最佳实践根本没有任何帮助。术语 Web 服务本身难以表示符合宽泛的 W3C 定义的应用程序的整个范围，因为许多这样的应用程序可能永远不会涉及 Web 或构建 Web 时所依托的技术。尽管如此，我还是必须以某种方式将术语 Web 服务包括在我们的术语集中，因为它已经与我们的讨论所涉及的技术领域联系在一起了。

Web 服务（Web services）是使用以下三个主要技术类别中的一些特定技术开发的软件组件：

基于 XML 的描述格式（例如，WSDL）

应用程序消息传递协议（例如，SOAP）

一组传输协议（例如，HTTP）

在上述每个类别中，都有专有（特定于供应商或平台的）技术和开放（与供应商或平台无关的）技术可供使用。

面向服务的应用程序（Service-oriented application）包括可能利用 Web 服务技术（如 SOAP）但可能不包括 WSDL 或其他基于 XML 的描述的应用程序。这样的应用程序被看作是类似于 Web 服务的，但从技术上讲它们不是 Web 服务。

根据对web服务的定义，我们可以得出web服务的大致分类：

企业 Web 服务（Enterprise Web services）是肯定提供了 WSDL 描述但可能使用专有应用程序消息传递协议或传输协议的 Web 服务。使用 JMS 通过 IBM MQSeries 发送 SOAP 消息的 Web 服务就是这种服务的一个示例。

因特网 Web 服务（Internet Web services）是必须仅使用开放的应用程序消息传递协议或传输协议的企业 Web 服务。通过 HTTP 发送 OTA XML 消息的企业 Web 服务就是这种服务的一个示例。

XML Web 服务（XML Web services）表示因特网 Web 服务的一个很小的子集，这类服务必须使用已经被 W3C 采用的、通过为数不多的几种传输协议进行传递的、基于 XML 的消息传递协议。具体来说，XML Web 服务将只发送 SOAP 消息，并且只能通过 HTTP、SMTP 或原始 TCP/IP 连接来发送这些 SOAP 消息。

二、使用web服务
 
1、确认 Web 服务的使用

在解决方案组件之间的边界上使用 Web 服务是不合适的。实际上，需要有意识地作出在什么地方利用 Web 服务的决定，而且应该基于处理业务需要的技术需求来作出这些决定。在某些情况下，这些决定将包括折衷方案，但是通过收集适当的需求并对其确定优先级，这些选择中的许多都将是明显的、容易证明其合理性。 例如，与 Internet 之上的业务合作伙伴的应用程序之间的互操作性可能具有比达到最佳性能更高的优先级；因而，XML Web 服务是合理的。同样地，从安全性的角度考虑，使用 SSL 来确保在 Internet 上交换消息的真实性和机密性可能就足够了。与之相对的是，当您考虑对后者的性能影响时，就需要在应用程序终端本身之间通过使用 XML 加密（XML Encryption）和 XML 数字签名（XML Digital Signatures）来提供这个级别的保护。
 
Web 服务应该只使用在具有明确的需求来证明它们是合理的地方。这种合理性本质上可以是定量的（互操作性可能存在于具有不同程序设计模型的异构系统之间），也可以是定性的，比如，根据公司的策略来配置您的企业资产将为以后带来可度量的好处（例如，重用遗留代码以使 J2EE、.Net 和 Web 应用程序能够提供集成服务）。很容易证明在内联网 Java 应用程序之间使用企业 Web 服务是合理的，因为通过使用现在的 J2EE 运行时和解析器，RMI/IIOP 提供了比 SOAP/HTTP 更好的性能。
 
2、服务的粒度

一旦需求表明 Web 服务是一项可行的集成技术，下一步就是确定如何最好地利用它们来获取最多的好处。这包括决定作为 Web 服务公开的函数的粒度来避免跨 Internet 的不必要的消息交换。作为一条性能规则，应该努力发布本身接受所有必需的参数和信息的粗粒度服务，从而使得服务提供者能够代表消费应用程序（consuming application）提供尽可能多的服务。目的是将顾客为了完成一组业务任务所发出的请求数目减到最少。这将确保网络延时、系统 I/O 以及线程/进程等待状态所带来的影响（当多个请求同时发出时，它们共同产生的延时可能是很大的）最小。例如，可能会通过允许消费者在单个请求中指定产品 SKU 编号、数量、信贷卡信息、配送地址信息以及折扣卷等所有信息来考虑支持购买订单服务。请求本身可能在服务提供者处开始多个原子事务（信用卡授权、费用提交、库存查询和更新、以及订购完成）。在支持整个业务流程的同时，如果需要，每个事务都可以被取消或撤销。
 
三、Web 服务的性能瓶颈

无疑地，目前基于 Web 服务的解决方案中的三个最普遍的瓶颈涉及：

·SOAP 消息的解析。消息越大，解析它所需要的时间就越长。

·对象到 XML 以及 XML 到对象的编组和解组。消息的结构越复杂，程序设计的对象和 XML 元素之间的映射需要的时间就越长。

·包括 XML 数字签名（XML Digital Signatures）和 XML 加密（XML Encryption）的 Web 服务安全性（WS-Security）功能的处理。应用程序终端之间的安全性并不是不受任何事情影响的，并且可能会惊人地延长处理服务请求的时间。

表示这些功能的 Web 服务组件如图 1 所示，它们用于处理 Web 服务请求。

 
2、文档/文字与 RPC/SOAP 编码

只要可能，就应该将文档/文字消息传递方式用于您的 Web 服务，原因有二。首先，它促进了符合 Web 服务互操作性（WS-I）基本概要 1.0 的互操作性。第二个原因与本文所讨论的性能有关。文档/文字会产生更小、更简单的消息：在 SOAP 消息体中 的 XML 数据不必用方法名称元素来封装，并且没有数据类型属性被嵌入到 XML 元素中去。文档/文字消息传递方式的另一个好处是目前的集成开发环境（WebSphere Application Studio Development）和运行时（WebSphere Application Server）支持用于对象和 XML 元素编组的 JAX-RPC 序列化器和反序列化器例程，这些例程是专门根据基于 WSDL 所包含 的 XML Schema 进行最优化的，同与 SOAP 编码相关联的序列化器和反序列化器相对。
 
3、 SOAP 消息的解析
 
3.1 最小化 XML 数据的解析

如果业务功能以 XML Web 服务的形式公开，并且 Web 服务对于内部消费（EAI）和业务合作伙伴的外部消费（B2B）都利用 SOAP，那么像网关或服务代理这样的中介就应该避免或最小化 SOAP Body 的解析。如果使用网关组件来将对 Web 服务的访问集中到 Internet，而又不需要网络传输或消息处理（比如 SOAP/HTTP 到 RMI/IIOP），那么网关就不应该执行 SOAP 体的解析。目前，许多系统管理供应商提供实际的 Web 服务的前端服务代理。这些组件在提供它们的系统管理功能时依赖于 SOAP 体内部的业务上下文信息，比如业务伙伴 ID、事务相关器、消息 ID、以及授权代码。通过使用业务上下文，服务代理可以提供关于业务事件的统计，执行加强业务政策以及路由请求来兑现服务质量承诺。最近，WebSphere Application Server V5.1 中的 Web Services Gateway 开始支持 SOAP 消息的部分解析。同样地，系统管理供应商经销商近来也开始提供可以部分地解析 SOAP 消息的功能，以将它们对性能的影响降到最小，因此利用这些功能是至关重要的。
 
3.2 DOM 与 SAX 解析

文档对象模型（Document Object Model，DOM）是由万维网联盟（World Wide Web Consortium，W3C）开发的基于对象的编程接口。它使程序员能够访问以节点树的形式存储在 XML 文档中的数据。另一方面，SAX（Simple API for XML）是基于事件的编程接口，它是由 XML-DEV 邮件发送列表的成员提供的。SAX 使程序员能够访问在 XML 文档中作为事件序列的数据。因为 Apache Xerces2 Java parser 支持这两个编程模型，所以您可以轻松地为您的程序员从中选择最适合您的需求的模型。两个接口都可以使程序员能够处理 XML；然而，它们执行任务的方式却相差很多。DOM 在内存中创建一个对象树，不考虑 XML 元素的数据类型。整个 XML 文档都在内存中表示。因此，这种方法需要更大的内存，对于非常大的 XML 文档来说，它并不认为是最好的方法。相反，SAX 是事件驱动的，并且不要求整个文档都在内存中。然而，程序员必须创建他们自己的对象模型并管理 SAX 事件。因此，虽然最后得到的对象模型很简单，但是 SAX 比 DOM 的解析速度快。如果您使用的是 Xerces parser，推荐您确保使用的是最新的版本（V2.6.0 与 1.4.0），因为在过去的一年里加进了重要的性能增强。
 
需要说明的是，在 WebSphere Application Server 的 SOAP 解析方面的改进（如图 2 所示）部分地源于向 SAX parsing 转变的结果。
如果您的解决方案利用处理时间的 35% 以上来解析 SOAP 消息，不要感到惊讶。记住，您正使用 Web 服务来支持互操作性并改进运行成本和资产重用。
 
4、 编组和解组对象和 XML

用于消息的对象和 XML Schema 越复杂，客户端和服务提供者所需的处理就越多。客户端在发布请求之前将不得不把它们的编程对象编组成 XML 元素，而服务提供者不得不在处理请求的过程中将 XML 元素映射到编程对象。如果在为请求和响应消息设计您的数据时不作出有意识的决定，那些用数组的数组构造的对象或者由嵌套元素的嵌套元素组成的 XML 元素将必定成为瓶颈。目前，很多公司都在使开放式应用程序组信息系统（Open Application Group Information System，OAGIS）的业务对象文档（Business Object Document，BOD） 的使用标准化。用于这些 XML 文档的 XML Schema 包含几个层次的嵌套 XML 元素，因此当使用这些 BOD 时，您需要估计它们对整体性能可能造成的影响，这一点很重要。推荐选择在您的解决方案中使用什么 BOD。
 
设计消息以便最大化正在交换的实际信息的数量同样重要。具有很多元素和属性以及很少数据的消息常常导致复杂的 XML Schema。最常见的是，SOAP 消息的解析被看作是造成 Web 服务中的性能问题的主要方面。然而，一个复杂的消息结构同样也可能导致多于 50% 的处理时间与 Object 和 XML 元素的编组和解组相关联。
 
5、 选择安全性方法

在实际解决方案中，所有机密的或者具有市场价值的信息在开放的 Internet 上传输时都必须被小心地保护。这常常通常意味着，信息的发送者和接收者都必须经过验证（双方的检验），确保消息的真实性和完整性（检验消息是否已经更改），并且保持消息的机密性（进行加密以防其内容为预定的接收者以外的人所获悉）。提供消息的安全性可能涉及非常复杂的过程，但是目前在业界有一些可用的方案。对于 IT 架构师和 IT 专业人员来说，问题就是决定哪种方法可以最好地满足他们的需求，然后配置中间件和基础架构组件来启用这些安全特征。
 
传统上，网络节点之间的安全性是通过在 Web 服务器和应用程序服务器中使用 HTTP（HTTPS）之上的 SSL 来提供的。通过使用 HTTPS，您可以执行消息的发送者和接收者的相互认证，从而确保消息的机密性。这个过程涉及及 X.509 证书，它是在连接的两端配置的，并且一般与网络节点相关联（部署消费者和服务提供者的系统或者托管 SOAP 中介的网关系统）。

当从一端到另一端直到整个应用程序栈都需要安全性的时，或者当安全性必须独立于网络传输协议时，就必须考虑其他的方法。Web 服务安全性（WS-Security）通过 XML 数字签名（XML Digital Signature）提供验证和消息的完整性，通过 XML 加密（XML encryption）提供消息的机密性，在这两个实例中都使用 X.509 认证。然而，必须根据全部的需求来理解和评估性能的权衡。或许这样说比较保险，通过Web 服务安全性（WS-Security）技术来支持安全性的成本至少是使用传统的用 HTTP 的 SSL 提供相似功能的两倍。然而，如果在处理您的请求中使用的业务逻辑和数据库也占您的执行时间的大部分（解析和序列化除外），那么这两个安全性方法的差别就不足以担保任何的利害关系了。
 
常见的实践是结合这两种方法，使用 SSL 来加密，然后使用 XML 数字签名（XML Digital Signature）来验证应用程序端点并确保消息的完整性。请谨记，SSL 将至少包括对消息要发送到的服务器的一项验证，因而就会产生一些冗余。您的业务和技术的需求以及利弊权衡的评估都将指导您从这三个可选方案中找到一个可行的方案。
 
成功地最优化 Web 服务的性能，部分是经验，部分是艺术，部分是您用于度量标准、分析信息以及合理调整的方法的系统训练。首先，正如前面所描述的，您必须在您的体系结构和设计阶段作出合适的决定。然后，一旦您拥有了可操作的解决方案，您就需要从模拟负载中获取度量标准、作出调整、再次度量以理解它们的影响，从而精细地地调整您的解决方案，这是一个反反复复的过程。

来源：AMT