webservices原理 收藏

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

Web Services 的起源

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

然而，在发展中，逐步暴露了一些问题。所有这些Web 页面都是为人准备的，是让人去阅读，去输入，去判断。因此各种反映视觉效果的内容占用了大量的网络带宽，例如各种图片，字体信息，文字排版样式等。而真正含有高价值的一些信息，被深深埋在这些显示信息中，很难被其他应用和程序所使用。更重要的是，各种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 得到更加广泛的应用，使得各种服务可以动态查找和定位，这样就提供了不同设备之间各种各样的信息交互方式，将会大大改变商业运做的模式和信息交流的风格。