【IT168 技术文章】

    深入洞悉 Web service 有助于解决问题

    构建面向服务的架构 （ SOA ， Service-Oriented Architecture ） 包含创建支持业务实践的多个服务。其优点是使用多个服务可以让企业更加灵活，并且能更好地对快速变化的竞争条件作出响应。构建服务可以提高现有应用程序的效率，并使得构建新的应用程序更容易。

    许多企业（大约 70% ，据 Gartner 统计）都是既使用 Java 平台又使用 Microsoft 平台。理想情况下，这种平台的混合不应该影响 SOA 。可在一个平台编写服务，而客户应用程序可以使用同一平台或另一种平台。这是用 SOA 方法构建应用程序的最重要优点之一，即可将许多不同技巧应用于创建服务，而且甚至还可修改遗留应用程序组件，将它作为服务运行。

    理论上这无疑是正确的。在客户应用程序和服务之间惟一需要的公共元素是发送、接收和解码 SOAP 消息的能力。当然，还有比这更多一点的要求，即客户和服务都必须在这些消息的模式上达成协议，或者提供像 Web service 描述语言（ WSDL ， Web Services Description Language ）这样的机制，让客户来确定合适的模式。 但通常，松耦合的应用程序组件概念很少要求协作。假设已经协商好了模式，那么客户应用程序与服务之间的通信就可以进行。

    除非它不行时。这听起来可能有点矛盾，但是实际上它是指对事物完全了解的一种状态。应用程序里的许多东西可能会出错，通常源于拙劣的需求分析、糟糕的设计、编码中的错误和导致性能或可扩展问题的无效的东西。所有这些问题以及更多的问题都可能在将服务与一个或多个客户结合时发生。

    这里仅仅是客户应用程序开发人员在使用 Web service 时可能会遇到的一些问题的几个例子：彻底失效——这可能意味着它有 Bug 或对象泄漏；返回错误回答——这可能是逻辑错误或意外行为；返回结果时太慢——它是 Web service 还是数据库；进一步缩小范围对应用程序开发人员而言太困难了；它不能扩展——在许多情况下，这是由于直到加载应用程序之前才发现的低效代码或瓶颈造成的。

    当 Web service 采用与客户应用程序不同的平台时，这些问题更加复杂。如前所述， Web service 的一个关键优点是其概念是平台是不可知的。可以用任何语言在任何平台上编写 Web service ，这使得 Web service 存在以下问题：构建客户应用程序的任何开发人员小组都要能理解和评估其应用程序所调用服务的强度和限制。

    即使客户平台和服务平台是不同的，除了 Web service 通常由构建应用程序之外的一组人员开发和维护以外，这些听起来仍像是围绕应用程序开发的普通问题。使用 Web service 的一些应用程序开发人员缺少对应用程序细节的洞察，甚至不了解构建服务的平台。

    当然，可以就这样假定它，但实际上，那些构建客户应用程序的人对于 Web service 的工作细节也的确有很好的技术鉴赏力。这可能有助于解决如何调用服务以及调用服务的频率等有关问题，比如，或者它能够帮助开发人员解决服务本身所固有的问题。

    后一个原因代表真正的问题——在除了知道所需的输入和期望的输出以外不了解 Web service 其他任何东西的情况下使用 Web service 。应用程序开发人员经常对分析和诊断他们所遇到的 Web service 问题感到迷茫。如果很少看见或根本看不见 Web service ，并且应用程序不能像预期的那样工作或者执行的话，那么开发人员可能只能分析他们自己编写的代码，而不是分析整个应用程序。对应用程序开发人员而言， Web service 就是暗面。

    窥探 Web service

    让我们近距离看一下企业中的典型场景可能是怎样的。一种情况是当 Web service 在 Java 平台上运行，同时客户机应用程序使用 Microsoft .Net 技术的时候。在这个例子中，客户应用程序无法扩展到需要的用户数。实际上，在实际使用中，它只同时支持 10 个用户，而要求是同时支持 100 个用户。特别是，在只有 10 个用户时，它最终还是瘫痪了。

    解决这样的问题应该遵循标准过程。这个过程看起来可能是这样的：遇到一个问题，描述问题的特点，分析问题参数，对问题进行一些诊断，然后将分析和诊断移交给 Web service 的拥有者。

    一旦遇到这种可伸缩性问题，初始任务是将它定位到客户应用程序或 Web service 。合理的做法是将这二者分开来单独测试。比如，比较合理的做法是编写一个作为客户应用程序后端的测试装置模块，并产生类似的期望从 Web service 那里获得的批量应答。同样，可直截了当地编写一个演习 Web service 的测试装置模块。
   
    虽然这些测试装置模块可生成适当的应答，但是它们不会去模仿应用程序上多个用户的特性。除测试装置模块以外，还需要一个用于负载测试的载体。虽然在许多企业中，负载测试仍是手工过程，还是有一些方法可自动化这个过程。可以使用商业测试装载工具，该工具实际上可以减少所涉及的人工干预，并获得 Web service 响应时间和系统特性的真实数据。

    图 1 显示了用商业测试负载产品执行负载测试所产生的结果。数据显示 Java 虚拟机（ JVM ， Java Virtual Machine ）上下文中的内存使用在随着时间推移而增加，而且在模拟用户退出系统后并没有减少。

    图 1. 用像 Compuware QACenter Performance Edition 这样的商业化自动负载测试工具使负载测试自动化，从而允许应用程序开发人员无需大量工作就能够收集数据