Web 服务最佳实践: 第 9 -10部分

Web 服务最佳实践: 第 9 部分 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 服务解决方案的性能方面需要考虑的问题。首先，让我认为您所作出的使用 Web 服务作为集成技术的决定从未基于它的性能来证明它的合理性（至少在可预知的未来之内没有这样做）。Web 服务提议的价值在于它实现了互操作性、灵活性和资产的重用，减少了开发和运行成本，改善了与业务合作伙伴和顾客的关系。 本系列的 第一篇文章 概述了三种类型的 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 编号、数量、信贷卡信息、配送地址信息以及折扣卷等所有信息来考虑支持购买订单服务。请求本身可能在服务提供者处开始多个原子事务（信用卡授权、费用提交、库存查询和更新、以及订购完成）。在支持整个业务流程的同时，如果需要，每个事务都可以被取消或撤销。   无疑地，目前基于 Web 服务的解决方案中的三个最普遍的瓶颈涉及： 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 服务的性能，部分是经验，部分是艺术，部分是您用于度量标准、分析信息以及合理调整的方法的系统训练。首先，正如前面所描述的，您必须在您的体系结构和设计阶段作出合适的决定。然后，一旦您拥有了可操作的解决方案，您就需要从模拟负载中获取度量标准、作出调整、再次度量以理解它们的影响，从而精细地地调整您的解决方案，这是一个反反复复的过程。 本专栏的下一篇文章将讨论与 Web 服务交互有关的其他性能问题。   Web 服务最佳实践，第 10 部分: Web 服务性能方面需要考虑的问题，第 2部分 其他影响性能的需要考虑的问题   级别： 初级 Holt Adams (rhadams@us.ibm.com ), 资深解决方案顾问, jStart 2004 年 3 月 01 日 随着 Web 服务作为一种用于企业应用程序集成（Enterprise Application Integration，EAI）和企业到企业（Business to Business，B2B）集成的开放标准集成技术的引入，您能够做很多的事情来提高运行效率，因而确保体系结构的成功和解决方案的部署。接着前一篇关于 Web 服务相关性能问题的文章，本文将解释基于现实经验的影响 Web 服务性能的其它次要的问题，并就如何最佳地架构、开发和部署基于 Web 服务解决方案提供建议。 在 Web 服务最佳实践专栏的上一期中（查阅参考资料 ），我解释了像 SOAP 消息解析、XML 和对象之间的编组和解组、以及 WS-Security 特征的处理这些服务相关的问题可能如何影响任何特定的 Web 服务的整体性能。在本期中，我将讨论其他一些可能对有效的 Web 服务交互造成类似阻碍的问题。     您的解决方案将需要处理三个主要的瓶颈（第 1 部分所涉及的），它们能够潜在地占用您的 Web 服务调用处理时间的 50% 到 75%。可能受到这种程度影响的服务的一个示例就是对具有良好索引的关系数据库进行简单的查询，在这里服务实现做了最小的处理。当执行您的服务的业务逻辑更加复杂并且与后台系统相连接时，由于这三个主要的瓶颈，对于您的服务响应时间的总体影响在某些情况下可以忽略不计。现在，让我们评估其他几个次要的需要考虑的问题，它们同样也会提高您的解决方案的性能。   现在您必须为您的 Web 服务提供者选择是使用 JavaBean 还是使用 EJB 组件。这个决定与您设计其他的 J2EE 应用程序时所做的决定没有什么区别。如果您的解决方案不需要 J2EE 运行环境对于事务、安全性和管理的支持（这些是通过使用 EJB 组件和 EJB 容器来启用的），那么 JavaBean 就足够了，并且可能提供更好的性能。如果您正在使用 EJB 组件，并且将它们作为 SOAP 引擎部署在相同的 JVM 中本地部署它们，请确保部署它们,这样就可以通过引用传递（pass by reference） 来调用它们。通过引用传递，方法的参数没有被复制到每个远程调用的堆栈中，而这个复制过程可能是代价高的。当 SOAP 引擎（EJB 客户端）和 Web 服务提供者（EJB 服务器）安装在同一个应用程序服务器实例中并且使用远程接口时，启用引用传递能够将性能提高 50%。   很多解析器能够验证 SOAP 消息的结构来确保它们是结构良好的并且遵守特定的 XML Schema。这使 Web 服务的实现代码能够朝着业务逻辑的方向得到最优化，而且只能通过有效的请求才能被调用。不幸的是，在大部分的时间里，由于它对于性能方面的影响，解析器的消息验证函数不能被启用。 如果您正在使用 Apache Xerces 解析器，您能够同时启用对 DOM 和 SAX 的解析。然而，记住启动验证将不会使 Xerces 报告任何显示出来的错误。您将不得不实现 org.xml.sax.ErrorHandler 接口，并且使用 setErrorHandler 方法同解析器一起注册您的实现。 如果性能具有很高的优先级，推荐您不通过解析器启用消息验证，而是作为好的标准编程实践，用处理参数的代码来验证它们的值。   对于支持 HTTP 的 Web 服务（XML Web 服务和 Internet Web 服务），实际上您可以高速缓存它们的处理结果以用于将来的请求。运行时间可以节省 Web 服务的响应，并且自动地为普遍的请求提供它们，显著地加速处理器密集型的服务请求。当然，实际上高速缓存仅适用于只读型服务，这些服务执行对于数据库的查询或者提供对相对静态内容的访问（例如，产品目录、销售信息、历史财务数据以及定价数据）。SOAP 消息的不同部分能够被用来惟一地验证对于高速缓存的请求。 高速缓存的能力是根据下列因素定义高速缓存策略和构造 cache-id 来提供的： SOAP 动作 SOAP 封套 Port 组件 SOAP 操作 SOAP 操作参数。 策略包括规则和到期间隔来确保存储信息的有效性。不需要对 SOAP Envelope 解析的组件将提供最佳的性能收益。例如，在 SOAP 规范中定义了请求中的 SOAPAction HTTP 信息头，HTTP 代理服务器使用它来向特定的 HTTP 服务器分发请求。可以在高速缓冲存储器策略中使用这个信息头来构建 ID，而不必解析 SOAP 消息。然后，可以使用 cache-id 从高速缓冲存储器中检索服务响应信息来使性能最优化。   UDDI 注册中心被用来为动态发现发布 Web 服务信息。服务访问点的延迟绑定（late binding）是目前 UDDI 注册中心的常见用途之一。在客户端的服务调用期间，查询 UDDI 注册中心来获得服务的访问点（URL）。通常使用这种方法启用执行故障排除支持的备份服务器（backup server）的使用来改善服务的可用性。同样地，为了在维护的同时又不干扰对现有的服务请求的处理，它向服务提供者提供了从一个系统迁移到另一个系统的能力。然而，UDDI 查询可能向请求中添加很长的路径，如果对每个请求都这样做，那么就可能降低客户端的性能。一种方法就是前置本地的服务代理，它是由服务提供者的 WSDL 和一个通用代理一起创建的。这个通用的代理查询 UDDI 注册中心，并且将访问点保存在高速缓冲存储器里一段特定的时间内。客户端应用程序调用通用代理（由它调用服务代理）来调用服务提供者。   如果由于状态代码为 200 的非 HTTP 而导致调用服务代理产生故障，那么通用代理会重新查询 UDDI 注册中心，看是否有可用的替代处理方法用于对服务代理的后续调用。这可以使客户端应用程序代码更简单、将 UDDI 注册中心的查询减少到最少、并且动态地将客户端绑定到服务以便确保最佳性能具有更高的可用性。 除了已经讨论过的瓶颈和需要考虑的问题之外，大部分其他的运行性能问题和 Web 服务解决方案的这样的问题的决定与其他的应用程序之间没有什么区别。这是因为 Web 服务提供业务函数的通用接口。如何描述接口（WSDL）、如何发布和发现接口（UDDI 或者 WSIL）以及如何调用它（SOAP）的定义是 Web 服务所特有的，但是执行业务逻辑的服务的实际实现通常是基于现有的基础架构（例如，J2EE、.NET、CICS、IMS）。 当在 J2EE 环境中使用 JavaBean、Enterprise JavaBean、或 Message Driven Bean 来实现 Web 服务时，需要以相同的方式调整应用程序服务器，而不管这些组件是否被作为 Web 服务来部署。例如，每个 WebSphere Application Server 进程都有几个影响应用程序（请考虑 Web 服务）性能的参数。您可以调整应用程序、Web 容器、EJB 容器以及应用程序服务器。 看一看下面所列出的，被视为基于 WebSphere 的解决方案中的调整参数热点列表（Tuning Parameter Hot List） ，您能够了解对于大多数其他的 Web 解决方案所需要评估的问题： 硬件和能力设置 Java 虚拟机的堆的大小 应用程序装配性能清单 数据源连接池和事先声明的高速缓存 Solaris 操作系统 TCP_TIME_WAIT_INTERVAL 值传递/引用传递 IBM HTTP Server 访问日志 HTTP 持续（keep alive）连接 事务日志 对象请求代理片段大小（Object Request Broker FragmentSize）。 一旦您的解决方案开始实施，您将需要对上面的大部分进行评估，您可以捕获测量的结果，以便使您能够理解您的解决方案的行为中的改变――作为应用的改变的结果。您可以在 WebSphere 信息中心中查看这些主题的详细资料（请参见参考资料 ）。 成功地最优化 Web 服务的性能，部分是经验，部分是您用于度量标准、分析信息以及合理调整的方法的系统训练。首先，正如前面所描述的，您必须在您的体系结构和设计阶段作出合适的决定。然而，一旦您拥有了可操作的解决方案，您就必需从模拟负载中获取度量标准、作出调整、再次度量以理解它们的影响，从而精确地调整您的解决方案，这是一个反反复复的过程。 IBM 已经在最优化 SOAP 的解析方面取得了重大的进步。与 Apache 和 WebSphere Application Server V5.0 所交付的 Web 服务实现的 Tech Preview 相比，WebSphere Application Server V5.02 通过一组原始工作负载提供了两到三倍的性能改善。同样地，WebSphere 对具有文档/文字消息传递类型的 JSR 109 和 101 的支持也包括序列化器和反序列化器例程，它们是基于 XML Schema 数据类型的，因而可以通过 SOAP 编码来提供增强的性能。 您可以参阅本文在 developerWorks 全球站点上的 英文原文 . 参与关于本文的 论坛 。（您也可以单击文章顶部或者底部的 讨论 来访问论坛。） 查阅整个 最佳实践专栏系列 。 在 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） 的详细资料。   Holt Adams 目前是支持 IBM 的 jStart 计划的高级 IT 设计师，他与客户和业务伙伴合作采用 Web 服务和其他新兴技术。他于1982 年从 University of Tennessee 获得电子工程学位，毕业后加入了 IBM 位于北卡罗来纳州的 Research Triangle Park。他具有开发通信和网络产品的软件和硬件的经验、移动和无线解决方案的技术销售方面的经验以及基于因特网的解决方案的体系架构和集成方面的经验。在过去三年间，他致力于把 Web 服务提升为 IBM 的战略性集成技术，起初是和客户一起进行概念的证明，而最近在为生产环境开发解决方案。您可以通过 rhadams@us.ibm.com 与 Holt 联系。