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 的生命周期是：

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 是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括： 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 描述文件，起着目录服务器的作用。