WebService 技术

 

一、什么是Web Service？ 

    Web Service是构建互联网分布式系统的基本部件。Web Services 正成为企业应用集成（Enterprise Application Integration）的有效平台。你可以使用互联网中提供的Web Service构建应用程序，而不必考虑这些Web Service是怎样运行的。

二、Web Service 三个基本技术 

        Web Service通过标准通信协议，在互联网上发布有用的程序模块（以服务的方式），目前大部分是用SOAP来作通信协议。

        Web Service提供一份详细的接口说明书，来帮助用户构建应用程序，这个接口说明书叫作WSDL（Web Service Description Language）。

        通常已发布的Web Service要注册到管理服务器，这样便于使用者查询和使用。这个是通过UDDI（Universal Discovery Description and Integration）来完成的。 

 

三、为什么要用Web Service？

    Web Servcie最主要的优点是，使用不同程序和在不同系统平台上开发出来的程序，都可以相互通信。现在很多人在问：“不是CORBA和DCE也有那些优点吗？跟它们有什么不同呢？”。第一个不同点是，SOAP作为Web Service的基本通信协议，比它们简单地多，所以投入和使用的代价也是小的。现在不仅有很多大公司发布的Web Service，也有个人发布的。另一个不同点是，Web Service使用标准的互联网协议-XML、HTTP和TCP/IP。很多公司已经从实践当中对这些协议积累了丰富的经验，所以相比CORBA和DCE要交的学费要少地多。 

    如果把现有的应用程序以Web Service部件形式发布，可以帮助其他的公司（人）构件功能强大的应用程序。举个例子，你要开发一个采购系统，可以自动地获得供应商的报价，而且可以实时追踪送货过程。如果供应商已经发布了报价和送货这两个Web Service，那么你就可以直接使用它们，而不必自己开发这些功能了。

 在未来，会出现更有趣的Web Service（现在做不到的），来帮助我们构建应用程序。

四、SOAP 

    SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问：“SOAP是怎样激活对象的？”或“SOAP在使用什么命名服务（Naming Service）？”。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？ 

    SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。 

    最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。

    很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。

    现在SOAP的很多另人瞩目的特性已成为现实（SOAP已经运行于不同的硬件和软件平台），而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术（CORBA、DCE）简单易用。

    安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢？对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp）。

五、WSDL  

     WSDL是一种XML文档，它定义SOAP消息和这些消息是怎样交换的。IDL（Interface Description Language）是用于COM和CORBA的，WSDL是用于SOAP的。WSDL是一种XML文档，所以我们可以阅读和编辑，但很多时候是用工具来创建、由程序来阅读。

    举个例子，你要使用供应商的Web Service构建应用程序。你可以向供应商索取使用Web Service的范例，然后按照范例来构建应用程序。这样可能出现意料不到的错误，比如说，你在程序中使用的客户代码的数据类型是integer，而供应商使用的数据类型是string.。WSDL详细定义客户端消息的格式，需要什么样的参数，这样可以避免不必要的错误。 

六、UDDI 

    UDDI可以比喻成电话本，电话本里记录的是电话信息，而UDDI记录的是Web Service信息。你可以不把Web Service注册到UDDI。但如果要让全球的人知道你的Web Service，最好还是注册到UDDI。 

    UDDI目录说明文件也是一个XML文档，它包括三个部分。“白页（White Paper）”说明提供Web Service的公司（人）信息，比如说名称、地址和联系方式等等。“黄页（Yellow Paper）”说明UDDI目录的分类，比如说金融、服务和印刷等等。“绿页（green Paper）”说明接口（Web Service 提供的）的详细信息。 

   UDDI提供多种查询方式，来帮助你找到需要的Web Service。如果你查询与财务有关的Web Service，那么UDDI会提供详细的信息。

 

Web Services的基本原理

如上图，一个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应用的性能，需要对整个系统做全盘的考虑。一般来说，有以下几点需要注意：

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