soufan

转载
摘要：本文介绍了 Web Services 的起源和基本原理，分析了在企业应用中 Web Services 带来的冲击和变革，指出了 Web Services 的一些优缺点以及如何正确地应用 Web Services.

无论是在计算机杂志还是在 Internet 上，目前最热门的话题莫过于“ Web Services” 。各个平台之间的锋争，各个新产品的发布，众多新标准的制订，大都和 Web Services 有关。

我的一些朋友是这样的一些人，他们总是用着最新的平台，尝试着最新的技术，他们喜欢变化，喜欢流行，用他们自己的话说，新技术创造新生活！可是，当我的一个朋友，带领他们一个部门的开发人员，花了两个月的，将他们内部的管理系统用 Web Services 重新设计和实现了一遍，却发现在实际使用的情况下，系统性能非常糟糕。他提出了这样一个问题：是不是 Web Services 现在还处于实验和市场炒作时期，根本没有进入实用的阶段？简单的回答是： Web Services 不是万能的，它有它的应用范围和优势劣势。

Web Services 的起源

Web 应用的巨大成功和不断发展，使其渗透到商业领域和个人生活的各个方面。人们只要使用浏览器，就可以享受到各种各样的 Web 服务，例如网上购物，网上交易，网络游戏，预定车票，网上聊天和交友等等。与此同时，由于 Web 技术所带来的优势（统一的客户端和较好的维护性），使一些传统的应用纷纷转型到 BS 结构上。

然而，在发展中，逐步暴露了一些问题。所有这些 Web 页面都是为人准备的，是让人去阅读，去输入，去判断。因此各种反映视觉效果的内容占用了大量的网络带宽，例如各种图片，字体信息，文字排版样式等。而真正含有高价值的一些信息，被深深埋在这些显示信息中，很难被其他应用和程序所使用。更重要的是，各种 web 服务之间缺少交互和通讯的机制。

程序之间的互相通讯很重要吗？简单举一个例子。

假设你经常去国外出差，在你回国以后，第一件事就是费用报销了。而你们公司有这样的财务规定，所有的报销款，都按报销当天的外汇比价进行结算。因此在你填写报销单的时候必须先填写每一笔在各个国家的花消，然后上网查出当天的外汇比价，填写到报销单上。剩下的事情也许不用你做了，你的报销单填写工具会自动进行换算和统计。

觉得有什么不妥吗？作为 IT 公司的员工，也许都有一个特点，计算机能做的事情，尽量要计算机去做。外汇比价的查询可以让计算机自动去做嘛！然而，让你的程序自动去网页上查找指定的外汇比价可不是一件容易的事。因为这些网页是给人阅读的，人眼和大脑的反应速度有多快，它们可以从一整页信息中快速定位到你所要的内容，而且无论网页怎样变化和改版都不会带来太大的影响。而应用程序想要做同样的事就差得太远了。因此，现在需要的是专门为应用程序制定的 Web 服务。

随着应用程序之间通讯的需求越来越大，这就需要制定统一的标准和协议。 HP 公司是最先提出这个观点的公司，他们制定了有关“ e-Speak” 的标准来保证应用程序之间的交互，并声称将成为下一代 Internet 信息交互的标准。而随后， MicroSoft 意识到此计划的美好前景，便推出了 .Net 战略； IBM 很快就发布了 Web Services Toolkit(WSTK) ，和 Web Services Development Environment(WSDE) ，申明对 Web Services 的全力支持。与此同时， Oracle 也开发出自己的 Dynamic Services ，并和 Oracle 8i Release 2 集成在一起。在这以后， W3C 统一制定了 Web Services 的各种标准。而 SUN 公司在宣布了自己的 Web Services 的框架以后，将 Web Services 的标准溶入 J2EE 的环境，使 Web Services 有了广泛支持的基础和平台。

Web Services 的基本原理

Web Services 是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括： SOAP, WSDL, UDDI

• SOAP: 是“ Simple Object Access Protocol” 的缩写， SOAP 是消息传递的协议，它规定了 Web Services 之间是怎样传递信息的。简单的说， SOAP 规定了：
  1. 传递信息的格式为 XML 。这就使 Web Services 能够在任何平台上，用任何语言进行实现。
  2. 远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。
  3. 参数类型和 XML 格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个 Person 对象。怎样用 XML 来表示一个对象参数，也是 SOAP 所定义的范围。
  4. 异常处理以及其他的相关信息 .

• WSDL: 是“ Web Services Description Language” 的缩写 . 意如其名 ,WSDL 是 Web Services 的定义语言。当你实现了某种服务的时候 ( 如 , 股票查询服务 ), 为了让别的程序调用 , 你必须告诉大家你的服务的接口 . 例如 , 服务名称，服务所在的机器名称，监听端口号，传递参数的类型 , 个数和顺序 , 返回结果的类型等等 . 这样别的应用程序才能调用你的服务。 WSDL 协议就是规定了有关 Web Services 描述的标准。

• UDDI: 是 Universal Description, Discovery, and Integration 的缩写。简单说， UDDI 用于集中存放和查找 WSDL 描述文件，起着目录服务器的作用。

如上图，一个 Web Services 的生命周期是：

1. 实现一个 Web Services ，使其能够接受和响应 SOAP 消息（现在有很多工具都可以帮助实现）。

2. 撰写一个 WSDL 文件用于描述此 Web Services 。（现在有很多工具可以自动生成 WSDL 文件）。

3. 将此 WSDL 发布到 UDDI 上。

4. 其他的应用程序（客户端）从 UDDI 上搜索到你的 WSDL 。

5. 根据你的 WSDL ，客户端可以编写程序（现在有很多工具可以自动生成调用程序）调用你的 Web Services 。

Web Services 的缺点

由于是基于 XML 的应用， Web Services 与生俱来地在拥有 XML 带来的一切优势的同时，不可避免地继承了 XML 所带来的一些限制。

• Web Services 通常需要大量的 CPU 资源。因为 XML 数据要经过多步处理才能被系统使用。首先是效验（ validate ），检查它的格式是否符合 XML 的规范，以及根据应用程序定义（ DTD 或 Schema ）检查是否符合语义上的规范；然后还要进行解析（ parse ），从 XML 文档分解出单个的元素；最后还要转换成应用程序所需要的二进制表达（例如，把“ 12” 转换成整型 12 的二进制表示）。

• Web Services 还意味着占用较多的内存资源。在进行 XML 解析的时候，会产生大量的临时内存对象。特别是在处理 DOM 对象的时候。这些大量的临时对象对于象 JAVA 这类自动回收内存的语言和系统其实是一种负担，大量的临时对象将会使系统每隔一段时间就会进行内存回收，从而降低系统的性能。当然，现在有的 Web Services 的产品（如 axis ）采用了 SAX 技术，大大减少了内存的占用量。详细信息请参考：（ http://xml.apache.org/axis/index.html ）。

• 网络资源的消耗也是 Web Services 应用的一些限制。因为基于 XML 数据的传递通常数据量要比二进制的协议（如 RMI/IIOP ）要大的多。这种额外的消耗在网络资源比较紧张或网络传输比较频繁的应用中会产生一定的影响。

除了 XML 带来的限制， Web Services 本身也具有一些缺点：

• 到目前为止， Web Services 还可以说是一种无状态（ stateless ）的服务。
  所谓 stateless 就意味着不保存客户端服务调用者的任何信息。这是由 Web Services 的本质所决定的。 Web Services 在本质上是要为应用程序之间提供数据通讯的标准，为企业应用之间动态地提供大颗粒度的服务，所以 Web Services 并不适合于非常精细的基于会话的方法调用以及复杂的事务（ transaction ）处理之中。
  也许有人会对我这点提出异议！因为，现在有很多 Web Services 的产品（如 WASD ），不但可以保存 session 的信息，使服务成为有状态（ stateful ）的服务，而且还实现了 remote interface ，可以在 Web Services 的会话中传递远程对象的句柄，让客户端可以操纵递远程对象（详细信息请参考： http://www.systinet.com ）。原理上说，这并不难实现，因为在 XML 数据中，可以互相传送任何数据，包括 sessionID 和 transactionID ，有了这些 ID ，从技术角度上说，实现有状态（ stateful ）的服务和事务处理并不复杂。但是，这样功能缺少标准的支持，当前版本的 WSDL 还无法表示这些复杂的服务。在企业内部，你可以任意使用这些特殊的功能，可以自己定义会话状态的交互协议，因为服务者和服务调用者之间的通讯都在你的控制之中；然而要将这些服务发布到 Internet 上，其他的应用程序是无法根据标准去识别这些特殊功能。

• 数据绑定也存在一些不足。
  因为所有的数据传递都用 XML 格式，因此，需要在二进制数据和 XML 数据之间有个转换。但是，并不是所有的二进制数据都能方便地用 XML 来表示，并不是所有的 JAVA 对象都能被 XML 所表示。因此，经常在转换过程中会出现语义丢失的情况。

• 技术要求高，学习曲线较长。
  每一个 Web Services 的产品，都有丰富的工具，能够根据 Web Services 的定义（如 WSDL 文件）方便地生成客户端的程序；能够将一般的服务程序，很容易就包装成 Web Services 服务。因此，各个 Web Services 的产品都声称自己的平台容易使用，根本不需要了解 XML ，也不需要了解什么 WSDL ， UDDI ， SOAP 就能使用发布 Web Services 。特别是一个朋友告诉我，他在什么都不了解的情况下，用 .NET 花了 15 分钟就发布了一个 Web Services ！
  千万不要醉心于这种简便，这对于简单的 Demo 也许是对的，可是对于真正意义上严肃的应用，一定要了解 Web Services 的各个方面，设计整体结构和解决方案，还要根据具体的应用调整性能。所有这些都需要对 Web Services 知识的全面掌握。

什么应用适合Web Services

Web Services 这么多的缺点是不是让你很泄气？其实，已经有很多成功的 Web Services 的应用和越来越多的开发商的加盟，证明 Web Services 一定会成为新一代 WEB 信息通讯的主流。经过不断的发展， Web Services 一定能克服自身的弱点，得到更广泛的应用。但就目前来说， Web Services 比较适合用于下列形式的应用：

• 基于 WAN 和 Internet 的应用

要在 Internet 上创建基于二进制协议的 RMI/IIOP 的应用，一般都会遇上一个大麻烦 -- 防火墙。客户端浏览器极大可能在 ISP 防火墙后，大多数防火墙都只能允许和外部的 HTTP 连接，因此想要 ISP 防火墙后的客户端能和防火墙外的 RMI/IIOP 的应用端口进行连接的话，就要改变 ISP 的安全策略，让客户端能够连接除了 80 以外的其他端口。可是当运行 RMI/IIOP 的应用的服务器为了安全也在防火墙之后的 DMZ 中的话，那这个连接就更加复杂了，要跨越两个防火墙。
而 Web Services 由于使用的是 HTTP 协议，传递的是纯文本的 XML 数据，因此拥有穿透防火墙的良好性能。

• 基于异构平台的应用

XML 语言本身就是跨平台、跨语言的数据表示方法，在加上通用的 HTTP 等协议，使得 Web Services 天生就适用于基于异构平台的应用。如果你的客户端包含了各种不同的平台，例如，你希望你的服务即可以被 JAVA 程序所调用，又可以由 VB 和 COM 程序所调用。你有两种选择：一种是为不同的平台提供相应的 API ，还要为不同的语言提供 API ；如果提供 Web Services ，所有平台和语言都可以调用了！

• 需要强安全特性的应用

很多人都认为，安全性是 Web Services 的弱项。其实不然，经过不断的完善和各种新的协议的出台， Web Services 完全可以用于安全性很强的应用环境下。并且，由于 Web Services 使用 HTTP 协议进行传输，所以可以和容易就使用已经很成熟的基于 HTTP 的各种安全技术。

• EAI （企业应用集成）
  这是目前 Web Services 应用最看好的方向之一。大多数企业内部都有着各种各样的应用系统，它们是在不同的领导在任期间，由不同的软件开发商开发，因此运行在不同的平台和系统上，系统的开发语言也各不相同。由于现代企业信息自动化要求的提高，各个系统之间的互动和相互通讯便提到日程上。因此，保护原有投资，重用遗留系统是当前很多中大型企业的重要任务。
  由于遗留系统的运行平台是异构环境，因此企业应用集成的代价一般来说是很高的。但如果使用 Web Services 作为应用集成的手段，将会大大降低集成的消耗。 Web Services 与平台和语言无关的特性，以及各种平台和环境下的开发工具都是企业应用集成的利器。
  另外，在开发新的应用系统的时候，仍然需要考虑和其他系统的集成，需要考虑调用其他系统的功能，和被其他系统所调用。使用 Web Services 作为系统与外部交流的接口，能够使新的系统和别的系统之间保持松耦合的关系，保持较高的可扩展性。

• 行业内部 B2B 应用
  行业内部的应用是 Web Services 的另外一个方向。因为在一个行业中，商业业务是很相似的，因此在行业内部很容易形成服务的标准，使所有的业内企业共同遵守；但怎样实现服务和使用什么样的系统，决定权在于各个企业自己。例如，电信运营商之间的结算服务，银行之间的转帐服务等都可以形成行业标准，以 WSDL 的形式公布出来。各个企业之间可以选择不同的平台进行服务的实现。

提高Web Services的性能

要想提高 Web Services 应用的性能，需要对整个系统做全盘的考虑。一般来说，有以下几点需要注意：

1. Web Services 的颗粒度
   选择 Web Services 的颗粒度是提高 Web Services 应用的性能的主要手段。因为 Web Services 使用的传输协议为 HTTP 或 SMTP 等，这些协议都是面向无状态的连接协议，每一个请求都要建立一个新的连接。因此 Web Services 的调用不能象数据库 JDBC （ ODBC ）接口一样可以进行精细而复杂的方法调用（例如，先获得 Connection ，再获得结果集，然后一行一行获取结果）。 Web Services 比较适用于大颗粒度的应用，在一个调用中便获得所有的信息（比如说银行之间的转帐，在一次调用中就将包括金额和认证等所有的信息都传输过去）。

2. 谨慎使用 XML 接口
   系统之间的接口可以使用 XML ，这样可以增加系统的灵活性；但不要使用 XML 作为系统内部的接口，因为这不会带来任何好处，尽量使用二进制作为系统内部的接口，避免不必要的 XML 文档的解析和效验；在处理 XML 的时候，尽快将 XML 转换成内部对象， XML 的传递只会增加系统的开销。

3. 最大可能性使用 CACHE
   当有些信息是只读的，或者在一段时间内保持不变，就可以使用 CACHE 。无论是客户端的 CACHE 还是服务器端的 CACHE ，都能大大提高系统的性能

总结

一旦 Web Services 得到更加广泛的应用，使得各种服务可以动态查找和定位，这样就提供了不同设备之间各种各样的信息交互方式，将会大大改变商业运做的模式和信息交流的风格。

你可以使用别人已经成熟的功能来使自己提供更好的服务，例如 google ，它的搜索引擎可以通过 Web Services 来访问。这就意味着在你的系统中可以方便的嵌入使用 google 的强大搜索功能，而不论你的系统是运行在什么平台上，使 google 的搜索引擎成为你系统的一部分，（请参考 http://www.google.com/apis/ ）。站在别人的肩膀上，毕竟要看得远些！

面对 Web Services ， 你现在可以不行动，但你一定要准备好！