Web Services是何物？

Web Services是何物？(转自csdn)

摘要：本文介绍了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的生命周期是：

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

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

将此WSDL发布到UDDI上。

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

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

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

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

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

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

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

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

Web service到底是什么；在什么情况下你应该使用Web service。

分布式应用程序和浏览器

研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。

传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是Web Service

对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：

http://host.company.com/weather.asp?zipcode=20171

返回的数据就应该是这样：

21,晴

这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。

下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

新平台

Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。

XML和XSD

可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。

XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。

SOAP

Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。

WSDL

你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web

service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。