什么是Web Service <br /><br /><br /><br /><br />（ccidnet 可乐　2001年11月01日）<br /><br />你可能早就听说过Web service了，你也可能已经对Web service有一些概念了。一时间，好像所有的计算机期刊、书籍和网站都开始提及Web service。然而，当前大多数对Web service的介绍都没能清楚的说明Web service到底是什么。他们只是鼓吹Web service是多么多么的好，简直就像是在做广告。在本文中会讲清楚两件事：Web service到底是什么；在什么情况下你应该使用Web service。<br /><br />分布式应用程序和浏览器 <br /><br /><br />研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。 <br />传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。<br />关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。 <br />许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的&quot;高级程序到程序交流(APPC)&quot;等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。<br /><br />什么是Web Service <br /><br /><br />对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：<br /><a href='http://host.company.com/weather.asp?zipcode=20171' target='_blank'>http://host.company.com/weather.asp?zipcode=20171</a><br /><br />返回的数据就应该是这样：<br />21,晴<br /><br />这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。<br />下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。<br />Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。<br /><br />新平台 <br /><br /><br />Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。<br /><br />XML和XSD <br /><br /><br />可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。<br />XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。<br /><br />SOAP <br /><br /><br />Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。<br /><br />WSDL <br /><br /><br />你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

典型的Web Service结构 <br /><br /><br /><br /><br />（ccidnet 可乐　2001年11月01日）<br /><br />典型的Web Service结构 <br /><br />不管你的Web service是用什么工具，什么语言写出来的，只要你用SOAP协议通过HTTP来调用它，总体结构都应如下图所示。 <br /><br />通常，你用你自己喜欢的语言(如VB 6或者VB.NET)来构建你的Web service，然后用SOAP Toolkit或者.NET的内建支持来把它暴露给Web客户。于是，任何语言，任何平台上的客户都可以阅读其WSDL文档，以调用这个Web service。客户根据WSDL描述文档，会生成一个SOAP请求消息。Web service都是放在Web服务器 (如IIS) 后面的，客户生成的SOAP请求会被嵌入在一个HTTP POST请求中，发送到Web服务器来。Web服务器再把这些请求转发给Web service请求处理器。对VB 6程序来说，Web service请求处理器是一个与SOAP Toolkit组件协同工作的ASP页面或ISAPI extension。而对VB.NET程序来说，Web service请求处理器则是一个.NET Framework自带的ISAPI extension。请求处理器的作用在于，解析收到的SOAP请求，调用Web service，然后再生成相应的SOAP应答。Web服务器得到SOAP应答后，会再通过HTTP应答的方式把它送回到客户端。<br /><br /><img src='http://www.sawin.com.cn/doc/SA/NewTech/webservice3-1.gif' border='0' alt='user posted image' /><br />典型的Web service结构<br /><br /><br />远程过程调用(RPC)与消息传递 <br /><br /><br />Web service本身实际是在实现应用程序间的通信。我们现在有两种应用程序通信的方法：RPC(远程过程调用)和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC强调的是远程对象和它的界面，即属性、方法和调用时的参数。DCOM和.NET远程访问都是RPC的例子。 <br />消息传递一般是在耦合度更低的系统中。消息传递的概念是，客户端向服务器发送消息，然后等待服务器的回应。消息传递系统强调的是消息的发送和回应，而不是远程对象的界面。由于是基于消息的系统，客户端和服务器之间的耦合度比RPC方法更低。<br />RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在使用本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。例如，你在VB 6中通过DCOM调用一个远程对象，你的代码看起来就与调用本地对象一样。而消息传递则不同，它强调传递的东西是什么，但不管消息传递过去后干什么。客户不需要知道服务器是怎么实现的，以及消息是怎么被处理的。<br />我们已经说过，你可以建立一个消息服务器，根据收到的消息来调用对象。这是通过消息传递方式有效的实现了RPC。如果客户仍然以消息的思维方式来进行操作，那么你可以把它叫做消息传递。但如果客户以远程对象的思维方式来进行操作，那么你就应该把它叫做RPC。 <br />如果你想实现一个基于XML的消息传递系统，大量的工作将集中在处理XML请求和应答消息上。虽然VB 6和VB.NET中，帮助你建立Web Service的工具已经做了许多对XML消息进行处理的工作，但毕竟所有的数据都是用XML的形式收发的，许多情况下你还是需要对消息进行一些自己的处理。深入理解XML和XML Schema对于有效地实现XML消息系统是至关重要的。<br /><br /><br />建立Web Service <br /><br /><br />我知道你现在已经很心急的想要写点代码，看看Web service到底是什么样的了。那么我们现在就介绍怎样用VB 6和VB.NET实际做出一个Web service来。本节的目的只是向你展示一下这些工具的功能，而不是深入地讲解Web service的工作原理。本书后面的章节会向你慢慢说明Web service以及Microsoft SOAP Toolkit和.NET等工具的内部原理的。<br /><br />使用SOAP Toolkit <br /><br /><br />Microsoft的SOAP Toolkit V2帮助你把COM组件变成Web service。这套工具分为三大主要部分：SoapClient是一个用于调用Web service的COM组件；SoapServer 是一个处理SOAP请求和返回SOAP应答的组件；还有一个WSDL向导，它可以把你的type library转换成WSDL文档，以暴露给Web service的客户。<br />假设你有一个COM组件，暴露出一个GetTemperature方法：<br />Public Function GetTemperature(ByVal zipcode As String, _<br />ByVal celsius As Boolean) As Single<br /><br />要把这个组件变成一个Web service，你可以使用WSDL向导。给出你要转换的组件后，向导会要你选择你想暴露出的方法，指出生成的Web service所在的URL(如http://localhost/Temperature/)，以及你希望用ASP还是ISAPI做你的请求处理器(如图1-2)。然后向导还会问你生成的WSDL和ASP文件应该放在那个目录下。<br /><br /><img src='http://www.sawin.com.cn/doc/SA/NewTech/webservice3-2.gif' border='0' alt='user posted image' /><br />使用SOAP Toolkit向导来转换COM组件<br /><br /><br />现在该调用这个Web service了。方法是在VB或其他任何可以使用COM的语言里调用SoapClient组件。下面这段代码演示了怎样调用Webservice中的GetTemperature方法：<br />Dim soap As MSSOAPLib.SoapClient<br />Set soap = New MSSOAPLib.SoapClient<br />soap.mssoapinit _<br />&quot;http://localhost/Temperature/Temperature.wsdl&quot;<br />MsgBox (&quot;气温是： &quot; &amp; _<br />soap.GetTemperature(&quot;20171&quot;, False)) <br /><br />首先调用mssoapinit，把WSDL文档的URL传给SoapClient。WSDL文档的URL就是你在WSDL向导中给出的URL加上〈Service名字.wsdl〉。一旦初始化完成，SoapClient就得到了Web service的所有方法，你就可以直接调用这些方法了。

什么时候应该使用Web Service <br /><br /><br /><br />（ccidnet 可乐　2001年11月01日）<br /><br /><br />现在我将列举三种情况，在这三种情况下，你将会发现使用Web service会带来极大的好处。此后，我还会举出不应该使用Web service的一些情况。<br /><br />跨越防火墙的通信 <br /><br /><br />如果你的应用程序有成千上万的用户，而且他们都分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。那是因为客户端和服务器之间通常都会有防火墙或者代理服务器。在这种情况下，你想使用DCOM就不是那么简单了，而且，通常你也不愿意把你的客户端程序发布到如此庞大数量的每一个用户手中。于是，你最终选择了用浏览器作为客户端，写下一堆ASP页面，把应用程序的中间层暴露给最终用户。结果呢？运气好的话，只是开发难度大了一些，运气不好的话，就会得到一个根本无法维护的应用程序。  <br /><br /><br />想象一下你应该怎么在你的应用程序里面加入一个新的页面：你必须先建立好用户界面(Web页面)，以及在这个页面后面，包含相应商业逻辑的中间层组件。这还不够，你还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把&quot;结果页&quot;送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程不就简单多了吗？还有，建立ASP页面的那一步可以省略掉吗？  <br /><br /><br />当然。如果你的中间层组件是Web service的话，你完全可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web service，你可以直接使用Microsoft SOAP Toolkit或.NET这样的SOAP客户端，也可以使用你自己开发的SOAP客户端，然后把它和你的应用程序连接起来。这样做，不仅可以缩短开发周期，还可以减少代码的复杂度，并增强整个应用程序的可维护性。同时，你的应用程序也不再需要在每次调用中间层组件时，都跳转到相应的&quot;结果页&quot;了。 <br /><br /><br />以我的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web service这种结构，可以轻松的节省花在用户界面编程上的20%的开发时间。这样做还有另一个好处，就是你将得到一个由Web service组成的中间层，这一层是完全可以在应用程序集成或其他场合下被重用的。最后，通过Web service把你的应用程序的逻辑和数据暴露出来，还可以让其它平台上的客户重用你的应用程序。<br /><br />应用程序集成 <br /><br /><br />企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发的力量。你的应用程序经常都需要从运行在古老的IBM主机上的程序中获取数据；或者再把数据发送到主机或UNIX应用程序中去。即使是在同一个平台上，不同的软件厂商生产的各种软件也常常需要集成起来。通过Web service，应用程序可以用标准的方法把功能和数据暴露出来，供其它的应用程序使用。<br />例如，你有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等信息。同时，你还有一个订单执行程序，用于实际货物发送的管理。这两个程序是来自不同软件厂商的。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web service，订单执行程序可以把&quot;AddOrder&quot;函数暴露出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。如下图。<br /><br /><img src='http://www.sawin.com.cn/doc/SA/NewTech/webservice2-1.gif' border='0' alt='user posted image' /><br />通过Web service集成应用程序<br /><br />B2B的集成 <br /><br /><br />用Web service集成应用程序，可以使你公司内部的商务处理更加自动化。但当交易跨越了你的供应商和客户，突破了公司的界线时又会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。<br />Web service是B2B集成成功的关键。通过Web service，你的公司可以把关键的商务应用暴露给指定的供应商和客户。例如，把你的电子下单系统和电子发票系统暴露出来，你的客户就可以以电子的方式向你发送购货订单，而你的供应商则可以以电子的方式把原料采购的发票发送给你。当然，这并不是一个新的概念：电子文档交换(EDI)早就是这样了。Web service和EDI之间的主要区别在于，Web service的实现要比EDI简单得多，而且Web service是运行在Internet上的，在世界任何地方都可轻易实现，这样其运行成本就相对较低。不过，Web service并不像EDI那样，是文档交换或B2B集成的一套完整的解决方案。Web service只是B2B集成的一个关键部分，还需要许多其它的部分才能完成这个集成。<br />用Web service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把你的商务逻辑暴露出来，成为Web service，你就可以让任何指定的合作伙伴轻松的调用你的商务逻辑，而不管他们的系统在什么平台上运行，使用的是什么开发语言。这样就大大减少了花在B2B集成的上的时间和成本。这样的低成本让许多原本无法承受EDI的投资成本的中小企业也能实现B2B集成。<br /><br />软件重用 <br /><br /><br />软件重用是一个很大的主题，它有很多的形式和程度。最基本的形式是源代码模块或者类一级的重用。另一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这样的可重用软件组件在市场上都占有很大的份额。但这类软件的重用都有一个很严重的限制：重用仅限于代码，而数据不能被重用。原因在于你可以很轻易的发布组件甚至源代码，但要发布数据就没那么容易了，除非那些数据都是不会经常变化的静态数据。 <br /><br /><br />而Web service允许你在重用代码的同时，重用代码后面的数据。使用Web service，你不再像以前那样，要先从第三方购买、安装软件组件，再从你的应用程序中调用这些组件。你只需要直接调用远端的Web service就可以了。举个例子，你想在你的应用程序中确认用户输入的邮件地址，那么，你只需把这个地址直接发送给相应的Web service，这个Web service 就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址的确在相应的邮政编码区域。Web service 的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不现实的，因为那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。<br />另一种软件重用的情况是把好几个应用程序的功能集成起来。例如，你想要建立一个局域网上的门户站点应用，让用户既可以查询他们的联邦快递包裹，察看股市行情，又可以管理他们的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了上面的这些功能。一旦他们把这些功能都通过Web service 暴露出来，你就可以非常轻易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。如下图。<br /><br /><br /><img src='http://www.sawin.com.cn/doc/SA/NewTech/webservice2-2.gif' border='0' alt='user posted image' /><br />用Web service来集成各种应用中的功能，为用户提供一个统一的界面<br />许多应用程序都会利用Web service，把当前基于组件的应用程序结构扩展为组件和Web service 的混合结构。你也可以在应用程序中使用第三方的Web service 提供的功能。你还可以把你自己的应用程序的功能通过Web service 提供给别人。所有这些情况下，你都可以重用代码和代码后面的数据。总之，Web service 将是软件重用的一种非常有力的形式。<br /><br />什么时候不应该使用Web Service <br /><br /><br />一个对Web service的完整介绍还应该包括什么时候不该用Web service。经过前面的介绍，我们知道了Web service 在通过Web进行互操作或远程调用的时候是最有用的。不过，还有许多情况，Web service根本不能给你带来任何好处。<br /><br />单机应用程序 <br /><br /><br />目前，我们还有很多桌面应用程序是供商用和个人使用的。其中一些只需要与运行在本机上的其他程序通信。在这种情况下，我们最好就不要再用Web service ，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在一台服务器上的服务器软件也是这样：最好直接用COM或其他本地的API来进行应用程序间的调用。当然Web service 也能用在这些情况下，但那样不仅消耗太大，而且不会给你带来任何好处。<br /><br />局域网上的同构应用程序 <br /><br /><br />在许多应用中，你所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，你有两个服务器应用程序需要相互通信，或者你有一个Win32或WinForm的客户程序要连接到局域网上的另一个服务器程序。在这些程序里使用DCOM会比SOAP/HTTP有效的多。类似的，如果你的一个.NET程序要连接到LAN上的另一个.NET程序，那么你应该使用.NET remoting。有趣的是，在.NET remoting中，你也可以指定使用SOAP/HTTP来进行Web service 调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。总之，只要你从应用程序结构的角度看来，有别的方法比Web service 更有效，更可行，那就不要再用Web service。<br /><br />总结 <br /><br /><br />Web service是创建可互操作的分布式应用程序的新平台。Web service 的主要目标是跨平台的可互操作性。为了达到这一目标，Web service 是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。  <br /><br /><br />Web service在应用程序跨平台和跨网络进行通信的时候是非常有用的。Web service适用于应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。 <br /><br /><br />当然，Web service也不是万能的，你不能到处滥用Web service。在有些情况下，Web service 会降低应用程序的性能，而不会带来任何好处。例如，一台机器或一个局域网里面运行的同构应用程序就不应该用Web service 进行通信。