Web 服务最佳实践: 第 9 -10部分
2009-07-22 22:38
465 查看
Web 服务最佳实践:Web 服务性能方面需要考虑的问题，第 1 部分 |
 | 级别： 初级 Holt Adams (rhadams@us.ibm.com ), 资深解决方案顾问, IBM jStart 2004 年 2 月 01 日 开发解决方案体系结构以及在开发和部署阶段成功地实现它的过程，需要从一开始就考虑性能。随着 Web 服务作为一种用于企业应用程序集成（Enterprise Application Integration，EAI）和企业到企业（Business to Business，B2B）集成的开放标准集成技术的引入，您能够做很多的事情来提高运行效率，因而确保体系结构的成功和解决方案的部署。本文将与您分享如何最好地设计体系结构、开发和部署基于 Web 服务的解决方案的实际经验和建议。 Web 应用程序的性能通常是通过它响应 URL 请求的速度来度量的。然而，更广泛的性能评估应该同样包括对同时发生的请求的影响、响应请求的等待时间、处理按需增长的解决方案的可伸缩性、以及由于事务负载的增加而造成操作性能退化的程度。 任何项目的需求收集过程都应该结合操作方面，它们量化了解决方案的可接受性能标准。这些标准需要用可测量的参数来定义，比如所能够支持的特定用户数目、同时发生的请求的特定数目、或者在特定的时间段内所能完成的事务。解决方案的 IT 架构师必须确保通过总体的设计、技术的选择、解决方案组件的部署和部署的配置来满足这些非功能性的需求。 体系结构应该保证应用程序的行为和它的系统运行在一个可接受的度量范围内；同样它也必须确保解决方案的全部行为是可预测的。例如，对于解决方案的需求随着越来越多的请求而增加时，在最坏的情况下，它处理请求的时间应该随着需求的增加逐渐地增加，而不是处理请求的解决方案突然变得不可用。 基于本文的范围和篇幅所限，我主要集中在考虑如何简化 Web 服务函数的处理时间来改善用于处理 SOAP 请求和响应消息的全部响应时间。
本系列的 第一篇文章 概述了三种类型的 Web 服务： 企业Web 服务 是提供了 WSDL 描述但是 可能 使用专有的应用程序消息传递或传输协议的 Web 服务。这种服务的一个实例就是使用 JMS 在 IBM MQSeries 消息系统上发送 SOAP 消息的 Web 服务。 Internet Web 服务 是必须仅仅使用公开的应用程序消息或传输协议的企业 Web 服务。这种服务的一个例子就是通过 HTTP 协议发送 XML 消息的 Web 服务。 XML Web 服务 代表 Internet Web 服务的一个很小的部分，它 必须 使用 W3C 所采用的很有限的传输协议之上的基于 XML 的消息传递协议。具体来说，XML Web 服务将只发送 SOAP 消息，并且只通过 HTTP、SMTP、或者原始的 TCP/IP 连接来发送它们。 建议您在决定在您的解决方案中利用哪种类型的 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 更好的性能。 一旦需求表明 Web 服务是一项可行的集成技术，下一步就是确定如何最好地利用它们来获取最多的好处。这包括决定作为 Web 服务公开的函数的粒度来避免跨 Internet 的不必要的消息交换。作为一条性能规则，您应该努力发布本身接受所有必需的参数和信息的粗粒度服务，从而使得服务提供者能够代表消费应用程序（consuming application）提供尽可能多的服务。目的是将顾客为了完成一组业务任务所发出的请求数目减到最少。这将确保网络延时、系统 I/O 以及线程/进程等待状态所带来的影响（当多个请求同时发出时，它们共同产生的延时可能是很大的）最小。例如，您可能会通过允许消费者在单个请求中指定产品 SKU 编号、数量、信贷卡信息、配送地址信息以及折扣卷等所有信息来考虑支持购买订单服务。请求本身可能在服务提供者处开始多个原子事务（信用卡授权、费用提交、库存查询和更新、以及订购完成）。在支持整个业务流程的同时，如果需要，每个事务都可以被取消或撤销。
SOAP 消息的解析。消息越大，解析它所需要的时间就越长。 对象到 XML 以及 XML 到对象的编组和解组。消息的结构越复杂，程序设计的对象和 XML 元素之间的映射需要的时间就越长。 包括 XML 数字签名（XML Digital Signatures）和 XML 加密（XML Encryption）的 Web 服务安全性（WS-Security）功能的处理。应用程序终端之间的安全性并不是不受任何事情影响的，并且可能会惊人地延长处理服务请求的时间。 表示这些功能的 Web 服务组件如 图 1 所示，它们用于处理 Web 服务请求。  存在一个类似的组件栈，它通过更底层的在顾客和服务提供者之间交换的可堆栈功能（stacked function）来处理 Web 服务响应。 下面是一组通用的实践，这些实践针对上面列举的三个性能瓶颈来指导您的设计，以最优化您的解决方案的效率。大部分的建议都涉及对提高性能的利弊权衡，但是也应该考虑您的整体需求。 用于最优化您的 Web 服务性能的规则中显而易见的一条就是保持小且单的有效负载。然而，在您正尝试解决实际业务问题的现实世界中，您并不总是具有遵守这条规则的宽松条件。长期运行的业务流程可能要求交换的 XML 文档不仅捕获相关的业务信息，而且也捕获流程的状态。较大的消息会产生较长的解析时间，而带有嵌套元素的复杂 XML 结构会使编组和解组对象和 XML 元素的时间更长。目的应该了解这些影响，并且花时间来设计您的编程对象，以便使 XML 消息结构的大小和复杂性减到最小。然而，您应该选择支持单一的调用，其中包括与支持分离的单个消息事务相比在一定程度上更大且更复杂的消息。如果业务函数或执行的任务确实是独立的，或者当一个任务可能严重地延缓处理其他的组合任务，就应该考虑多消息。  图 2 表示流行的 SOAP 运行时、Apache SOAP 和 IBM WebSphere Application Server 的性能（IBM 资料来源：Harvey Gunther 的性能分析）。它以图表的形式来表示解析 XML 消息的影响，平均来说，它占简单业务功能处理时间的 20% 到 35%。应该注意到，最近在最优化解析器方面取得了很大的进步，正如 WebSphere Application Server V5.02 SOAP 运行时所展示的。然而，它们依然占特定于 Web 服务的处理的大部分。 只要可能，就应该将文档/文字消息传递方式用于您的 Web 服务，原因有二。首先，它促进了符合 Web 服务互操作性（WS-I）基本概要 1.0 的互操作性。第二个原因与本文所讨论的性能有关。文档/文字会产生更小、更简单的消息：在 SOAP 消息体中的 XML 数据不必用方法名称元素来封装，并且没有数据类型属性被嵌入到 XML 元素中去。文档/文字消息传递方式的另一个好处是目前的集成开发环境（WebSphere Application Studio Development）和运行时（WebSphere Application Server）支持用于对象和 XML 元素编组的 JAX-RPC 序列化器和反序列化器例程，这些例程是专门根据基于 WSDL 所包含的 XML Schema 进行最优化的，同与 SOAP 编码相关联的序列化器和反序列化器相对。 最小化 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 消息的功能，以将它们对性能的影响降到最小，因此利用这些功能是至关重要的。 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 服务来支持互操作性并改进运行成本和资产重用。 您用于消息的对象和 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 元素的编组和解组相关联。 请参考 图 2 ，其中的示例展示了编程对象和 XML 元素的编组和反编组（也称为序列化（serialization）和反序列化（de-serialization））是如何影响您的整体处理时间。 在实际解决方案中，所有机密的或者具有市场价值的信息在开放的 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 服务交互有关的其他性能问题。
. 参与关于本文的 论坛 。（您也可以单击文章顶部或者底部的 讨论 来访问论坛。） 查阅整个 最佳实践专栏系列 。 在 IBM Patterns for e-business 中查找更多的信息。 您可以在 Patterns for e-business Redbooks from IBM 找到更多的信息。 用于电子商务首席架构师的 IBM Pattern 回顾了 Web 服务的影响并 记录了他们的发现 （PDF）。 其他关于 IBM Patterns for e-business 的报告、白皮书和资料 也可以获得 ，包括 WebSphere Technical Exchange presentation （ZIP，PDF）（它讨论了 Web 服务和用于电子商务的 Pattern 的关系。 与 Web 服务互操作性组织（Web Services Interoperability Organization）的 基本概要（Basic Profile）V1.0 相关联的需求。 阅读 Web 服务安全性（WS-Security ）规范可以获得 Web 服务安全性方面的信息。 获得更多关于 Apache Xerces parser 的信息。 在 InfoCenter 可以找到关于 Performance Tuning of WebSphere Applications 的更多的信息。 您可以从 UDDI.org 站点上找到关于 invocation Pattern for UDDI Inquiry 更多的信息。 搜集 Web Services for J2EE （JSR109） 的详细资料。
|
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Web 服务的最佳实践: 回到基础部分，第 1 部分
- 安全模式：J2EE、Web服务和身份管理最佳实践与策略
- 构建基于JSON的Web服务最佳实践
- MSDN Webcast - 微软SDLC最佳实践系列课程（3）- 报表服务
- MSDN Webcast - 微软SDLC最佳实践系列课程（3）- 报表服务
- MS CRM 2011的自定义和开发（10）——CRM web服务介绍(第二部分)——IOrganizationService（一）
- Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性
- SOA 中的服务接口设计最佳实践，第 2 部分：使用服务向服务使用者应用程序报告错误
- Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性
- REST Service 的最佳实践，第 1 部分: 重新解析 REST Service(http://www.ibm.com/developerworks/cn/webservices/1101_)
- Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性
- Web 服务最佳实践
- MS CRM 2011的自定义和开发（10）——CRM web服务介绍(第二部分)——IOrganizationService（二）
- MS CRM 2011的自定义和开发（10）——CRM web服务介绍(第二部分)——IOrganizationService（四）
- Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性
- MS CRM 2011的自定义和开发（10）——CRM web服务介绍(第二部分)——IOrganizationService（三）
- 把 SOAP 服务转化为 REST 服务(REST Service 的最佳实践，第 3 部分)
- Web服务最佳实践（翻译）
- Hibernate4实战 之第七部分：最佳实践
- RESTful服务最佳实践——（十）