此文章的发表时间相对较早，现在web service技术已经得到了广泛的应用，本帖请大家共同学习

Web Service“四长两短”
（中国计算机报 陈友　2001年11月01日 17:42）

当前，Web Service是一个热门话题。但是，Web Service究竟是什么？什么情况下应该用Web Service？什么情况下不应该用Web Service？是需要我们正确认识的。

实际上，Web Service的主要目标是跨平台的可互操作性。为了达到这一目标，Web Service 完全基于XML（可扩展标记语言）、XSD（XML Schema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用Web Service会带来极大的好处。

长项一： 跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。


图1 通过Web Service集成应用程序
举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。

如果中间层组件换成Web Service的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web Service，可以直接使用Microsoft SOAP Toolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。

从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web Service这种结构，可以节省花在用户界面编程上20%的开发时间。另外，这样一个由Web Service组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过Web Service把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。

长项二： 应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。

例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web Service，订单执行程序可以把“Add Order”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。

长项三： B2B的集成
用Web Service集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。

Web Service是B2B集成成功的关键。通过Web Service，公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念， EDI(电子文档交换)早就是这样了。但是，Web Service的实现要比EDI简单得多，而且Web Service运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。不过，Web Service并不像EDI那样，是文档交换或B2B集成的完整解决方案。Web Service只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。

用Web Service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来，成为Web Service，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。

长项四： 软件和数据重用
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。


图2 用Web Service集成各种应用中的功能，为用户提供一个统一的界面
当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。

Web Service在允许重用代码的同时，可以重用代码背后的数据。使用Web Service，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的Web Service就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的Web Service，这个Web Service 就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。Web Service 的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过Web Service “暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

将来，许多应用程序都会利用Web Service，把当前基于组件的应用程序结构扩展为组件/Web Service 的混合结构，可以在应用程序中使用第三方的Web Service 提供的功能，也可以把自己的应用程序功能通过Web Service 提供给别人。两种情况下，都可以重用代码和代码背后的数据。

从以上论述可以看出，Web Service 在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，Web Service根本不能带来任何好处。

短处一： 单机应用程序
目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用Web Service，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然Web Service 也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。

短处二： 局域网的同构应用程序
在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NET remoting。有趣的是，在.NET remoting中，也可以指定使用SOAP/HTTP来进行Web Service 调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。

总之，只要从应用程序结构的角度看，有别的方法比Web Service 更有效、更可行，那就不要用Web Service。

什么是Web Service？


什么是Web Service？
作者：可乐 本文选自：赛迪网 2002年03月07日

你可能早就听说过Web service了，你也可能已经对Web service有一些概念了。一时间，好像所有的计算机期刊、书籍和网站都开始提及Web service。然而，当前大多数对Web service的介绍都没能清楚的说明Web service到底是什么。他们只是鼓吹Web service是多么多么的好，简直就像是在做广告。在本文中会讲清楚两件事：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的代码。

典型的Web Service结构
（可乐　2001年11月01日 18:35）

典型的Web Service结构。

不管你的Web service是用什么工具，什么语言写出来的，只要你用SOAP协议通过HTTP来调用它，总体结构都应如下图所示。通常，你用你自己喜欢的语言(如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应答的方式把它送回到客户端。

典型的Web service结构，点击小图放大

远程过程调用(RPC)与消息传递
Web service本身实际是在实现应用程序间的通信。我们现在有两种应用程序通信的方法：RPC(远程过程调用)和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC强调的是远程对象和它的界面，即属性、方法和调用时的参数。DCOM和.NET远程访问都是RPC的例子。
消息传递一般是在耦合度更低的系统中。消息传递的概念是，客户端向服务器发送消息，然后等待服务器的回应。消息传递系统强调的是消息的发送和回应，而不是远程对象的界面。由于是基于消息的系统，客户端和服务器之间的耦合度比RPC方法更低。
RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在使用本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。例如，你在VB 6中通过DCOM调用一个远程对象，你的代码看起来就与调用本地对象一样。而消息传递则不同，它强调传递的东西是什么，但不管消息传递过去后干什么。客户不需要知道服务器是怎么实现的，以及消息是怎么被处理的。
我们已经说过，你可以建立一个消息服务器，根据收到的消息来调用对象。这是通过消息传递方式有效的实现了RPC。如果客户仍然以消息的思维方式来进行操作，那么你可以把它叫做消息传递。但如果客户以远程对象的思维方式来进行操作，那么你就应该把它叫做RPC。
如果你想实现一个基于XML的消息传递系统，大量的工作将集中在处理XML请求和应答消息上。虽然VB 6和VB.NET中，帮助你建立Web Service的工具已经做了许多对XML消息进行处理的工作，但毕竟所有的数据都是用XML的形式收发的，许多情况下你还是需要对消息进行一些自己的处理。深入理解XML和XML Schema对于有效地实现XML消息系统是至关重要的。


建立Web Service
我知道你现在已经很心急的想要写点代码，看看Web service到底是什么样的了。那么我们现在就介绍怎样用VB 6和VB.NET实际做出一个Web service来。本节的目的只是向你展示一下这些工具的功能，而不是深入地讲解Web service的工作原理。本书后面的章节会向你慢慢说明Web service以及Microsoft SOAP Toolkit和.NET等工具的内部原理的。

使用SOAP Toolkit
Microsoft的SOAP Toolkit V2帮助你把COM组件变成Web service。这套工具分为三大主要部分：SoapClient是一个用于调用Web service的COM组件；SoapServer 是一个处理SOAP请求和返回SOAP应答的组件；还有一个WSDL向导，它可以把你的type library转换成WSDL文档，以暴露给Web service的客户。
假设你有一个COM组件，暴露出一个GetTemperature方法：

代码:

Public Function GetTemperature(ByVal zipcode As String, _
ByVal celsius As Boolean) As Single

要把这个组件变成一个Web service，你可以使用WSDL向导。给出你要转换的组件后，向导会要你选择你想暴露出的方法，指出生成的Web service所在的URL(如http://localhost/Temperature/)，以及你希望用ASP还是ISAPI做你的请求处理器(如图1-2)。然后向导还会问你生成的WSDL和ASP文件应该放在那个目录下。

使用SOAP Toolkit向导来转换COM组件，点击小图放大

现在该调用这个Web service了。方法是在VB或其他任何可以使用COM的语言里调用SoapClient组件。下面这段代码演示了怎样调用Webservice中的GetTemperature方法：

代码:

Dim soap As MSSOAPLib.SoapClient
Set soap = New MSSOAPLib.SoapClient
soap.mssoapinit _
"http://localhost/Temperature/Temperature.wsdl"
MsgBox ("气温是： " & _
soap.GetTemperature("20171", False))

首先调用mssoapinit，把WSDL文档的URL传给SoapClient。WSDL文档的URL就是你在WSDL向导中给出的URL加上〈Service名字.wsdl〉。一旦初始化完成，SoapClient就得到了Web service的所有方法，你就可以直接调用这些方法了。

Web 服务互操作性和 SOAP


摘要：本文概要说明了在通过 SOAP 进行 RPC 调用时当前实际存在的互操作性问题，同时讨论了导致互操作性问题的三个
因素：HTTP 问题、XML 问题和 SOAP 间断性。

目录

简介
什么是 SOAP？
常见的互操作性问题
传输问题
XML 问题
SOAP 问题
后续话题

简介
当前有多种创建应用程序的平台。但每种平台都习惯于使用自身的协议（本质上通常是二进制代码）来实现机器间的集
成。因此，跨平台的应用程序在数据共享方面的能力相当有限。认识到这些限制后，人们一直在致力于建立有关数据格式
和数据交换方面的标准，藉此以实现“不论服务采用何种软件，使用何种硬件，都能够跨越这一传统的界限以 Web 的形式
无缝地将它们集成在一起”这一远景目标。目前，这一目标已迅速发展成为一种新的计算范例。

该目标的核心是互操作性概念，即不同系统能够无缝地进行通信和共享数据。这也是 Web 服务追求的目标。Web 服务是一
种可以用标准 Internet 协议来访问的可编程应用逻辑；从另一个角度来说，Web 服务是有关机器间和应用程序间透明通
信的、借助于 Web 的标准的具体实现。

目前，实现机器间消息传递的 Web 服务技术多种多样，例如简单对象访问协议 (Simple Object Access Protocol,
SOAP)、Web 服务说明语言 (Web Service Description Language, WSDL) 和超文本传输协议 (HyperText Transfer
Protocol, HTTP)。这些消息的复杂程度各不相同，既有简单的方法调用，也有复杂的订单提交。在 Web 服务的功能中，
最一般但又较高级的功能是实现 RPC（远程过程调用）形式的通信（通过 RPC，一台计算机上的程序可以执行另一台计算
机的程序。）本文从实用的角度介绍了在使用 SOAP 进行 RPC 形式的通信时当前常见的互操作性问题，以后还将撰文探讨
有关通过 SOAP、WSDL 以及其它协议传送消息的问题。


图 1：Web 服务路线图：有线协议元素、服务说明和发现

什么是 SOAP？
SOAP 是 Simple Object Access Protocol（简单对象访问协议）的缩写。该协议的当前版本为 1.1，其具体规范发布在下
列站点上： www.w3.org/tr/soap （英文）。SOAP 以 XML 为基础，说明了机器间通信的消息传送格式。此外，它还包括几
个可选部分，用于描述方法调用 (RPC) 和详细说明通过 HTTP 发送 SOAP 消息的方法。（有关 SOAP 和 Web 服务的详细
背景知识，请参见 Web 服务的平台（英文）。）

以下是一个典型的 SOAP 请求（包括 HTTP 标头），它请求名为 EchoString 的 RPC 方法调用，并将一个字符串当作参
数：

POST /test/simple.asmx HTTP/1.1
Host: 131.107.72.13
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://soapinterop.org/echoString"

代码:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:tns="http://soapinterop.org/"
               xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body  soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <tns:echoString>
                        <inputString>string</inputString>
                </tns:echoString>
        </soap:Body>
</soap:Envelope>
如上所示，该请求将方法名编码为 XML : <tns:echoString>，将字符串参数编码为 <inputString>。它所代表的 C# 方法
类似于以下内容：

代码:

public String echoString(String inputString);
以下是来自服务器的响应：

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

代码:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:tns="http://soapinterop.org/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <tns:echoStringResponse>
                        <Return>string</Return>
                </tns:echoStringResponse>
        </soap:Body>
</soap:Envelope>
有关序列化字符串数据类型以及方法调用形状的规则在 SOAP 1.1 的第 5 节和第 7 节 (www.w3.org/tr/soap（英文）)
中定义。

常见的互操作性问题
当执行 RPC 形式的 SOAP 消息传送时，可能会因为多种原因导致互操作性问题。有趣的是，许多互操作性问题都不是
SOAP 本身的问题，而是基本传输引擎或 XML 引擎所导致的互操作性问题。也就是说，互操作性问题可能是：

HTTP 问题


XML 问题，或


SOAP 间断性
还应指出的是，这些规范的制定者也有考虑不周的地方，他们有时可能会模棱两可，这样就很难确定唯一正确的行为。

传输问题
XML Web 服务消息的核心在于发送消息的传输机制。当通过 SOAP 进行 RPC 调用时，HTTP 是目前最为常用的传输机制。
这意味着 SOAP 堆栈之间必然存在 HTTP 互操作性问题。

HTTP 互操作性问题的一个简单示例就是 SOAPAction 的使用。SOAPAction 是一种 HTTP 标头，它必须存在于通过 HTTP
传送的 SOAP 消息中。此标头可以赋以多个不同的值，例如：

SOAPAction: "http://tempuri.org/"

SOAPAction 的值虽然可以完全为空，但必须用引号引起来：

SOAPAction:

问题就在这儿：如果服务器要求空值 SOAPAction，有些客户端将无法满足这一要求，因为并非所有 HTTP 客户端 API 都
具有设置空 HTTP 标头值的方法。这种问题可能存在两种解决方法：修正客户端 API 和/或确保服务器不要求空值
SOAPAction。通常，避免这类问题的唯一方法是确保所使用的 HTTP API 稳定强壮，并且已知可以在 Web 上工作。即便如
此，这类问题仍可能出现；要彻底消除它们，测试可能是唯一的方法。

XML 问题
这是可能存在的第二类互操作性问题，它们涉及到 XML 语法分析和 XSD 架构处理。SOAP 使用 XML 和 XML 架构作为核
心，因此这两者的互操作性是 SOAP 互操作性的基础。

有一个有趣的互操作性问题示例，它同时涉及到 XML 语法分析和 HTTP 传输，并且与字节顺序标记 (Byte Order Mark,
BOM) 相关。当通过 HTTP 发送数据时，您可以在 Content-Type 标头中指定数据的编码形式，如 UTF-16 或 UTF-8。也可
以通过插入一组用来指定编码形式的字节来表示某一段 XML 的编码形式。当发送 UTF-16 时，即使 Content-Type 标头中
指定了编码形式，也仍需要 BOM 来指示是 big-endian 还是 little-endian；但对于 UTF-8，BOM 则是不必要的。例如：

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

代码:

n++<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:tns="http://soapinterop.org/"
               xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <tns:echoStringResponse>
                        <Return>string</Return>
                </tns:echoStringResponse>
        </soap:Body>
</soap:Envelope>
示例中的前三个字符是字节顺序标记的十六进制代码，用于指示编码形式为 UTF-8，不过，您可以看到，Content-Type 也
指出了这点。即使不需要，但是有些实现方案仍会为 UTF-8 发送 BOM。而其它实现方案有了 BOM 反而无法处理 XML。为
了解决这一问题，应避免在不需要的时候发送 BOM，并且应正确处理 BOM。由于在处理 UTF-16 消息时需要 BOM，所以在
这种情况下务必要正确处理 BOM。虽然没有任何单一的方法可以提早解决这些问题，不过当发现问题时，最好的方法就是
参考描述标准的具体规范（通常在 W3C 上可以找到），然后应用这些规范来评判遇到的问题。

SOAP 问题
现在，我们将讨论问题的核心：SOAP 问题本身。如上所述，SOAP 的互操作性首先要求解决传输（通常是 HTTP）和 XML
问题。解决这两个问题之后，再来解决 SOAP 问题。

SOAP 本身的问题相对简单。它要求将消息装入信封，并将消息的实际内容放在正文元素中。SOAP 使标头等元素成为可选
项，对正文元素中可包含的内容允许存在一定的灵活性。以下是一个简单的 SOAP 消息示例，大多数堆栈与它进行互操作
时不会存在问题：

代码:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body >
                <foo />
        </soap:Body>
</soap:Envelope>
虽然这个示例不是十分有趣，但是 SOAP 还提供一种对常见数据类型进行编码的方法（请参见 SOAP 规范的第 5 节），它
进一步说明了如何对 RPC 方法调用进行编码。您可能已注意到，在前面的示例中，方法名是正文的子标记，参数则是方法
名的子标记。

即使不用这么麻烦，您也可以找到许多有趣的互操作性问题。例如，SOAP 规范规定，如果您收到 mustUnderstand 属性设
置为“1”的 SOAP 标头，就必须理解它，否则将出错。但许多实现方案并没有做到这点。以下是 mustUnderstand 标头的
示例：

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

代码:

n++<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:tns="http://soapinterop.org/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <SOAP-ENV:Header>
                <Foo SOAP-ENV:mustUnderstand="1">Hello!</Foo>
        </SOAP-ENV:Header>
        <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                <tns:echoStringResponse>
                        <Return>string</Return>
                </tns:echoStringResponse>
        </soap:Body>
</soap:Envelope>
这个示例是通过 SOAP 互操作性测试发现的众多问题之一。有关现已发现的互操作性问题的更多示例，请参见
http://groups.yahoo.com/group/soapbuilders （英文）中的档案。总之，为了确保 SOAP 在实现 RPC 形式通信时的互操
作性，全世界的 SOAP 构建者已经做了很多工作，并取得了丰硕的成果。从 5 月 8 日到 5 月 10 日，在拉斯维加斯将举
行 Networld+Interop 会议，到时，SOAP 团体的许多成员将在会上将充分展示这方面的成果。如果您在使用 SOAP 堆栈或
对其感兴趣，欢迎惠顾这次演示会。

另外，有关 XML Web 服务的许多讨论和测试已经在 http://groups.yahoo.com/group/soapbuilders （英文）、
http://www.mssoapinterop.org/ （英文）和 http://www.xmethods.net/ilab/ （英文）等站点上进行。这些站点包含到许
多互操作性测试端点的链接。构建 SOAP 堆栈的所有人员都应该阅读这些档案并参与互操作性测试。

后续话题
本文简要概括了在 XML Web 服务领域中发现的一些早期互操作性问题。不过，这方面的讨论并不会就此停止。除了通过
HTTP 进行 RPC 调用之外，SOAP 还有许多更为有趣的情况需要讨论。其中包括“document”形式的消息传递、基于 SMTP
和其它传输机制的 SOAP、WSDL 以及各种 SOAP 标头测试 － 所有这些都值得在今后的文章中进行讨论。

面对Web Services


Web Services：惊世未了缘

(2002.05.14) 来自：每周电脑报
　文/丁晔

　　“我们应该离开，这样能活下来！”面对英格兰铁甲骑兵，一个怯懦的苏格兰士兵用尽全力向威廉华莱士(苏格兰民族英雄)说到。

　　“是的！作战，你可能会丧命；逃跑，可苟存性命，起码有一段安宁。”威廉华莱士
望着那些由各怀鬼胎的苏格兰贵族所率领的散兵游勇，喊道“苏格兰的子孙们，将来在你们寿终正寝的时候，你们是否愿意……，用这苟且偷生的日子，来换取一个机会……，仅仅是这么一次机会，就是回到这里……，告诉敌人……，他们也许能夺走我们的生命，但永远也不能夺走……，我们的自由！”—《勇敢的心》场景

　　Scott McNealy，Sun公司CEO，面对Bill Gates和他的公司——微软，多么希望也能够象威廉华莱士一样，向站在Java阵营的IBM、Oracle、BEA等“伙伴”以及那些心存疑虑的IT厂商们，大声疾呼“今天！互联网给我们这样一个机会，你可以跟从于微软，皈依.NET，去安享一生。但你是否愿意用这苟且偷生的日子，来换取一个机会，仅仅是这么一次机会，告诉微软你们可以赢得过去，但永远也夺走不了，我们对自由的渴望！”

　　能够让Scott McNealy给予如此厚重希望的机遇到底是什么？是什么能够让IBM、BEA等公司感觉到自己能够有机会，去撼动微软这样一个“伟大”的公司。它就是——Web Services(Web服务)。

　　-Web Services微软的蓝图

　　当微软在2000年6月22日，Tech·Ed 2000论坛上正式宣布了名为Microsoft .NET的新一代平台时，很少有人能够理解微软所诠释给人们的.NET是何物。不过有一些“精明”的人发现了一个有意思的现象。正是在这个论坛上，只不过是将时间回转到6月5日，Bill Gates在他担任首席软件设计师(CSA)半年之后，向与会的开发者描绘了Web Services的前景，同时承诺微软将在这个领域动用20亿美金。

　　在微软的眼中.NET是一个战略，是一个对未来的憧憬，在现实中，他们要打的仗只有一个就是Web Services。此后微软在人们的观望和不解中发展。而当时的Scott McNealy曾嘲笑微软的.NET只不过是.NOT，对于Bill Gates所推崇备至的Web Services，他却认为那是对Sun公司所提出“网络就是计算机”口号的移花接木。“他们(微软)给一个我们(Sun)已经谈论多年的事情，起了一个名字。好像这件事情，是他们提出的。我想如果你每年有2亿美元的市场预算，你一样可以改写历史。”Scott McNealy用这样话来形容微软的.NET策略。

　　在Scott McNealy的冷笑中，微软经历了有史以来最痛苦的一段时间。连续20个财年收入保持36%的增长，停步于2000年，此时微软的年收入增长为8%。由于受到垄断案件的纠缠，公司市值缩水2500亿美元。公司亟需振奋低迷的士气，微软CEO Steven A. Ballmer在一年一度的员工大会上，用一段阿里拳赛的录像，将萦绕在微软头上的乌云，挥之而去。1974年，Muhammad Ali(阿里)同George Foreman(富尔曼)进行了一场拳王争霸赛。年轻阿里7岁的富尔曼，赛前极被看好。但是阿里的6万名支持者在赛场上大声地叫喊“阿里杀死他！阿里杀死他！”最后，阿里以一个强有力的直拳，将富尔曼打入了地狱。在影片即将结束的时候，整个会场的扩音器里突然传出“微软，杀死他们！微软，杀死他们！”瞬间微软的员工沸腾了。

　　是什么能够给Steven Ballmer如此的勇气，在公司身处有史以来最大困境的时候，还能杀气腾腾。答案只有一个.NET，Steve Ballmer和Bill Gates已经不止一次的在各种场合讲到，.NET战略是他们下的一个最大赌注。Web Services，正是.NET战略中一个举足轻重的棋子。

　　面对这样的杀气，Scott McNealy也不得不意识到，Sun在互联网新的一轮竞争中已经不是领跑者了。时隔.NET发布8个月，2001年2月5日Sun宣布，公司推出SunONE软件框架，这是一个开放性网络环境，是为开放的Web Services所推出的新一代软件框架。“有些人认为我们只不过是为了回应微软的.NET。”Scott McNealy面对记者们指出“而我认为这个产品---SunONE，是我们多年事业的一个顶点。”

　　-Web Services将改变软件产业

　　Scott McNealy认为Web Services是Sun公司事业发展的一个顶峰，Bill Gates认为Web Services是微软.NET的一个核心。为什么他们对Web Services如此看重，因为它很有可能会改变现有的软件产业。Web Services作为新兴的，一种依赖于Internet，为用户或其他Web Services提供单一服务功能的组件，将成为软件未来的存在形态。而谁能够在这个领域胜出，谁就有可能成为未来软件业的主导。回想软件产业的发展，从最初，根据需求定制的软件产品，到今天已经发展到了商用的、模块化的软件产品。软件产业逐渐向单一化、规模化方向发展。而当Internet出现之后，起初并没有给软件产业带来多大的冲击，仅仅是催生出一批新型的软件产品。

　　但是当ASP出现之后，一些专家开始大声呼叫到，“软件就是服务”这个真理终于被人们肯定了。但现实就是这么惨酷，曾经被认为是继电子邮件出现之后，对企业用户影响最大的应用--ASP，今天却面临风雨飘摇的窘境。究其原因，主要是因为ASP仍然是一个以集中式计算模型的产物，只不过是披着一层互联网的外衣。但Web Services却是一个迥然不同的精灵，它秉承“软件就是服务”的真言，同时顺应分布式计算模式大兴其道的潮流。而它的存在形式又与以往软件不同。这种组件模式，小巧、单一，对于开发人员来讲，开发成本较低。

　　Web Services在某种意识上就是结合了ASP和组件产品两方面的特性，通过标准协议，在互联网上，提供单一特定的服务。区别在于Web Services面对的用户群更广，而且更加通用，更加松散。而不象ASP服务的对象，需要签订一定的合作协约。Web Services的出现，给软件产业又一次带来新的商业模式。Web Services的供应商，既可以将Web Services一次卖断给软件开发商，也可以通过租赁的方式，按月收取服务费用。试想一下，如果你开发的Web Services被微软选中应用在Windows XP平台里，那你很有可能将一夜成为百万富翁的美梦变为现实。

　　-微软感觉Web Services有点儿甜Web Services的魔力就在于，微软深信其可以将自己在PC上的统治地位延续到互联网上。没有人怀疑微软在PC上的成功，但是当面对互联网，这个靠后端高性能计算所支撑的体系，微软的发展前景受到了人们的质疑。而Web Services恰巧能够成为微软手中一个制胜法宝。想要探究其中的原因，首先一点就是要弄清Web Services到底是什么。

　　人们为Web Services下的定义是通过标准的Web协议可编程访问的Web组建。如果不加进任何解释，没有多少人能够明白它讲的是什么东西。你是否有过这样的经历，就是在使用MS Word编写报告的时候，当需要调用一个MS EXCEL制作好的报表时，你可以使用对象嵌入功能。你在执行这个操作的时候，实际上是在使用MS Word的过程中，去调用另外一个应用程序。而Web Services的功能也与此十分相近。只不过它不是发生在一个单一的PC上，而是发生在客户端(Client)与服务器(Server)之间，或是服务器(Server)之间。例如用户在浏览一个英文网页，随着鼠标指针的移动，屏幕上显示出相应的中文解释，不要以为这个用户正在使用金山词霸，他没有。这个用户只不过是通过网络去调用一个提供即时翻译的Web Services。此时的即时翻译程序，变成了一个远在异地的应用组件。这些基于后端的Web Services被微软认为将会成为未来互联网的主导。而抢占了这个阵地也就赢得了互联网的明天。由此引发出很多新的标准、协议，以便让这些Web Services组件能够顺利地被调用。

　　-到底是谁的胜利

　　其实Web Services是一场分布式计算体系的跃进，真正的胜利是分布式计算模式对集中式计算模式的胜利。它强调的是不同组件协同工作，来为用户提供服务。分布式对象结构，是将标准化的组件对象放在远端的电脑上。客户端在调用对象时，使用分布式对象结构的调用标准来获取对象。在这里人们要清楚一点，此时的客户端，其内涵已经被扩大，不是我们平时眼里的PC，而是任何一个对调用对象提出服务请求的组件。面对互联网这个广义的分布式计算体系，Web Services实际上更像是一种远程访问的标准。

　　还记得那个令人晦涩难懂的词汇CORBA，它是最热门的分布式对象结构。它的优势就在于可以跨平台，跨开发语言，来调运服务器端某个对象模块提供的服务。Web Services和CORBA这些分布式应用技术的目的都是要解决远程目标之间的通讯问题。和其它的解决方案不同，Web Services提供基于开放式标准上的完全终端对终端的解决方案。对于Web Services解决方案的用户来说，没有任何特殊的要求。

　　面对Web Services这样的发展前景，微软坚信打赢Web Services这场战斗，将确立起在整个互联网中的霸主地位，而那时再来回味公司在PC领域的辉煌，微软的感觉也只不过像是品味饭后的一道甜点。

　　为了能够实现这个梦想，微软做出了很多的努力，首先是力推XML。因为Web Services所要涉及到的信息，已经不仅是简单的文本，而是数据。此外Web Services需要跨平台，而原有的HTML都是无法满足需要的。通过XML可以使得程序之间更容易进行沟通。微软对XML的支持力度表现在，Internet Explorer 5.0是最早支持XML的浏览器，早在XML标准尚未确定之前，微软就推出了XML Notepad编辑器。

　　接下来，微软对Web Services的核心SOAP也大费心计。SOAP是对象间信息交换的通信协议。可以把SOAP看成是用户端与服务器端之间进行沟通的特殊语言。在按照SOAP协议封装的信息里，包含了用户端申请Web Services所必要的内容，例如该Web Service所涉及到的名称、参数等。当然服务器端也会按照SOAP通信协议返回相应的结果。

　　但新的一个问题又出现了，就是用户端的程序要如何才能知道Web Services提供了什么可以进行调用的服务呢？这时WSDL(Web Services Description Language，Web Services描述语言)出现了，它是用来描述Web Services的相关信息。现在一切就绪，可那些Web Services开发商需要一个方法将自己开发的Web Services进行发布，广而告之。于是UDDI(Universal Description，Discovery and Integration)应运而生。UDDI是一个跨产业、跨平台的开放性架构。其可以帮助Web Services开发商在Internet上公布自己推出的Web Services。

　　微软在Web Services标准的确定上已经抢占了先机，但这说不清谁能赢得Web Services战役的胜利。Sun告诉人们，什么XML、SOAP、WSDL、UDDI等标准，SunONE全部支持。Sun坚信的只有一条，就是能够真正跨平台的技术只有一个，它就是Java。用户只有选择了拥有开放性的开发平台，才能够让其开发出的Web Services应用遍布整个互联网。

　　Web Services是否镜中花

　　无论是微软、Sun还是IBM、BEA都对Web Services看好，但它最终能否生存下来，还是要看用户是否愿从腰包里掏钱给它。今天的IT环境同.COM火爆年代相比，已不可同日而语。萎靡不振的全球经济，让Web Services的鼓吹者，不能够单靠一张嘴去打动用户的心。更加残酷的是，Web Services在近一段时间的发展下，已经不是可望不可及的东西，到了要用事实说话的时候了。

　　Web Services面临残酷的挑战，这里指的不是它的标准是否完善、也不是它的设想是否合理，而是Web Services能否让那些第一个吃“螃蟹”的用户，立即看到投资回报。还好现在已经有象Imperial Sugar、Nordstrom.com、Hewitt&Associates这样的公司，开始尝到Web Services给他们带来的甜头。

　　这些公司大多是在应用集成这个领域采用Web Services。Imperial Sugar公司，利用Web Services将五个重要的原材料供应商集成到一个订单管理系统之中。公司在2000年已经申请破产保护，因此每一笔在信息建设的投入，都要受到审查。公司最终选取了Web Services这种方式，在有限的资金条件下，建立了一条高效的供应链。利用Web Services模式，公司关键的原材料供应商们，可以围绕Imperial Sugar公司的生产流程，来访问他们与Imperial Sugar公司组成的供应链管理系统。通过SOAP通信协议，来查询和输入原材料数据。

　　“现在给一项新的项目进行投资，对于公司来说是十分困难的。”Imperial Sugar公司CIO Muller先生讲到“但当看到有关投资回报的调查之后，我们就做出了决定。”

　　此外诸如Bidders Edge或My Simon等的网上拍卖店，利用Web Services通过在网上搜索所有的相关拍卖行情，为便宜货搜索者提供方便、快捷的购物服务，并为用户提供最为廉价的货物信息。通过应用Web Services，这些网站将能自动扩展出更多的功能，例如评价并选择原料供应商，或选拔合格可用的产品技术支持专员负责处理用户的电子邮件咨询。Web Services还可被用于对顾客所需服务的自动识别，并发出网站的应用工具以用于寻找解决办法。对顾客来说，这将比以往要更为有效率。

　　从投资回报上看，Web Services已经得到了部分用户的认可。但是从TCO(总体拥有成本)的角度来看，用户仍然处于茫然的状态。Web Services毕竟是一个全新的事物，它的使用方式是依靠远程调用，形式上更接近早先的ASP。但今天ASP的前景已经非常暗淡，至少在中国是这样的，而由此人们便会担心Web Services到底是否能够真正的降低企业的TCO。

　　此外来自厂商的声音更搅得用户不知所措，围绕哪种开放平台可以让企业的TCO降到最小的争论，更是以微软和Sun为代表。针对开发Web Services应用，微软推出了Visual Studio .NET(简写VS.NET)，而Sun推出了J2EE。来自Merrill Lynch对100位美国和欧洲CIO的调查显示，他们已经分成两大派别，分别支持VS.NET和J2EE。

　　微软告诉人们在VS.NET平台下，用户可以利用VB、VC++、VC#等多种开发工具共同开发各样符合Web Services标准的应用，并且这些应用可以保持相互兼容，条件只有一个就是要统一在微软的平台之上。而Sun则宣布，利用SunONE平台开发的Web Services应用可以跨越所有的平台，你不会只拴在微软这一棵稻草上，但条件也只有一个，就是使用Java。

　　-编辑寄语

　　李学凌

　　本期，我们花了极大的精力，重新剖析Web Service，真可谓呕心沥血。说实话，在微软和SUN之间做比较的时候，我们也非常头痛。为了仔细比较MS.NET和SunONE之间的异同，我们请教了许多行业内的专家。在底层XML和SOAP等，两者是一样的；在顶层，Web Service两者又走到一起。决战之地在中间层，C#与JAVA，.NET构架对JDK等。我们在选题讨论会上，SUN公司的一位员工也谈到，SUN在移动设备领域和诸如摩托罗拉等公司的合作已经取得的实际进展；而我也在微软总部看到了原型的微软手机软件。这场战争会从服务器一直打到周边设备，成为名副其实的信息战争。

　　我个人认为，在过去两年当中出现的技术变革，能够影响今后10年的网络技术有两项，一项是端对端(P2P)的结构性革命，另一个就是Web Service。P2P的出现，击碎了网络物理稳定的思维模式，只要有相当概率的电脑在线，P2P就可以自主、自足组建成为牢固的网络，如果只是把P2P和盗版MP3链接起来，就太小觑了P2P对网络架构的颠覆。P2P出现后，网络中“上帝已经死了”。Web Service从某些层面上理解，包含了P2P的理念。1992年计算机图灵奖授予Butler Wright Lampson，表彰他在分布式计算方面的杰出贡献，Lapmpson本身就长期担任微软软件首席架构师。分布式存储和分布式计算一直以来都是计算机结构大师的梦想。Web Services从某个角度来说，正式要解决分布式计算的问题。“数据在服务器之间游走，计算力在网络之间分享”，正是Web Service要实现的梦想。可以这样说，Windows是操纵一台计算机的灵魂，MS.NET也好SunONE也罢，就是在争夺网络操作系统的控制权。

　　计算机发展的前20年，一直在打一场操作系统的战争；经过几年互联网基础发展之后，网络级操作系统的战争终于在两大利益集团之间爆发。IBM再也不会像当年那样，拱手把PC操作系统市场送给微软，百年不遇的机会面前，没有人会退缩。表面上看，这是微软和SUN公司之间的纠纷，其实质却是包括了IBM、ORICAL、SUN、HP和微软等等所有顶级计算机公司参与的计算机世界大战。

什么时候应该使用Web Service


跨越防火墙的通信
如果你的应用程序有成千上万的用户，而且他们都分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。那是因为客户端和服务器之间通常都会有防火墙或者代理服务器。在这种情况下，你想使用DCOM就不是那么简单了，而且，通常你也不愿意把你的客户端程序发布到如此庞大数量的每一个用户手中。于是，你最终选择了用浏览器作为客户端，写下一堆ASP页面，把应用程序的中间层暴露给最终用户。结果呢？运气好的话，只是开发难度大了一些，运气不好的话，就会得到一个根本无法维护的应用程序。
想象一下你应该怎么在你的应用程序里面加入一个新的页面：你必须先建立好用户界面(Web页面)，以及在这个页面后面，包含相应商业逻辑的中间层组件。这还不够，你还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把"结果页"送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程不就简单多了吗？还有，建立ASP页面的那一步可以省略掉吗？
当然。如果你的中间层组件是Web service的话，你完全可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web service，你可以直接使用Microsoft SOAP Toolkit或.NET这样的SOAP客户端，也可以使用你自己开发的SOAP客户端，然后把它和你的应用程序连接起来。这样做，不仅可以缩短开发周期，还可以减少代码的复杂度，并增强整个应用程序的可维护性。同时，你的应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"了。
以我的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web service这种结构，可以轻松的节省花在用户界面编程上的20%的开发时间。这样做还有另一个好处，就是你将得到一个由Web service组成的中间层，这一层是完全可以在应用程序集成或其他场合下被重用的。最后，通过Web service把你的应用程序的逻辑和数据暴露出来，还可以让其它平台上的客户重用你的应用程序。

应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发的力量。你的应用程序经常都需要从运行在古老的IBM主机上的程序中获取数据；或者再把数据发送到主机或UNIX应用程序中去。即使是在同一个平台上，不同的软件厂商生产的各种软件也常常需要集成起来。通过Web service，应用程序可以用标准的方法把功能和数据暴露出来，供其它的应用程序使用。
例如，你有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等信息。同时，你还有一个订单执行程序，用于实际货物发送的管理。这两个程序是来自不同软件厂商的。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web service，订单执行程序可以把"AddOrder"函数暴露出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。如下图。


通过Web service集成应用程序，点击小图放大

B2B的集成
用Web service集成应用程序，可以使你公司内部的商务处理更加自动化。但当交易跨越了你的供应商和客户，突破了公司的界线时又会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。
Web service是B2B集成成功的关键。通过Web service，你的公司可以把关键的商务应用暴露给指定的供应商和客户。例如，把你的电子下单系统和电子发票系统暴露出来，你的客户就可以以电子的方式向你发送购货订单，而你的供应商则可以以电子的方式把原料采购的发票发送给你。当然，这并不是一个新的概念：电子文档交换(EDI)早就是这样了。Web service和EDI之间的主要区别在于，Web service的实现要比EDI简单得多，而且Web service是运行在Internet上的，在世界任何地方都可轻易实现，这样其运行成本就相对较低。不过，Web service并不像EDI那样，是文档交换或B2B集成的一套完整的解决方案。Web service只是B2B集成的一个关键部分，还需要许多其它的部分才能完成这个集成。
用Web service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把你的商务逻辑暴露出来，成为Web service，你就可以让任何指定的合作伙伴轻松的调用你的商务逻辑，而不管他们的系统在什么平台上运行，使用的是什么开发语言。这样就大大减少了花在B2B集成的上的时间和成本。这样的低成本让许多原本无法承受EDI的投资成本的中小企业也能实现B2B集成。

软件重用
软件重用是一个很大的主题，它有很多的形式和程度。最基本的形式是源代码模块或者类一级的重用。另一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这样的可重用软件组件在市场上都占有很大的份额。但这类软件的重用都有一个很严重的限制：重用仅限于代码，而数据不能被重用。原因在于你可以很轻易的发布组件甚至源代码，但要发布数据就没那么容易了，除非那些数据都是不会经常变化的静态数据。
而Web service允许你在重用代码的同时，重用代码后面的数据。使用Web service，你不再像以前那样，要先从第三方购买、安装软件组件，再从你的应用程序中调用这些组件。你只需要直接调用远端的Web service就可以了。举个例子，你想在你的应用程序中确认用户输入的邮件地址，那么，你只需把这个地址直接发送给相应的Web service，这个Web service 就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址的确在相应的邮政编码区域。Web service 的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不现实的，因为那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是把好几个应用程序的功能集成起来。例如，你想要建立一个局域网上的门户站点应用，让用户既可以查询他们的联邦快递包裹，察看股市行情，又可以管理他们的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了上面的这些功能。一旦他们把这些功能都通过Web service 暴露出来，你就可以非常轻易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。如下图。

点击小图放大

用Web service来集成各种应用中的功能，为用户提供一个统一的界面
许多应用程序都会利用Web service，把当前基于组件的应用程序结构扩展为组件和Web service 的混合结构。你也可以在应用程序中使用第三方的Web service 提供的功能。你还可以把你自己的应用程序的功能通过Web service 提供给别人。所有这些情况下，你都可以重用代码和代码后面的数据。总之，Web service 将是软件重用的一种非常有力的形式。

什么时候不应该使用Web Service
一个对Web service的完整介绍还应该包括什么时候不该用Web service。经过前面的介绍，我们知道了Web service 在通过Web进行互操作或远程调用的时候是最有用的。不过，还有许多情况，Web service根本不能给你带来任何好处。

单机应用程序
目前，我们还有很多桌面应用程序是供商用和个人使用的。其中一些只需要与运行在本机上的其他程序通信。在这种情况下，我们最好就不要再用Web service ，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在一台服务器上的服务器软件也是这样：最好直接用COM或其他本地的API来进行应用程序间的调用。当然Web service 也能用在这些情况下，但那样不仅消耗太大，而且不会给你带来任何好处。

局域网上的同构应用程序
在许多应用中，你所有的程序都是用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。

总结
Web service是创建可互操作的分布式应用程序的新平台。Web service 的主要目标是跨平台的可互操作性。为了达到这一目标，Web service 是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。
Web service在应用程序跨平台和跨网络进行通信的时候是非常有用的。Web service适用于应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。
当然，Web service也不是万能的，你不能到处滥用Web service。在有些情况下，Web service 会降低应用程序的性能，而不会带来任何好处。例如，一台机器或一个局域网里面运行的同构应用程序就不应该用Web service 进行通信。

使用XML的五种场合


在很多研讨会和培训班上我遇到过许多人，他们还不明白为什么要使用XML也不知道如何在他们的应用中使用XML。一些来自诸如Gartner公司的报告建议说，商业公司不能再做局外人了，不能对XML置之不理。如果你还不清楚XML到底有什么好处的话，你并不是唯一的人。

我决定把与人们和媒体关于XML话题的交谈整理成文，列出XML在应用中的五个最令人喜爱的用法。尽管这些并不能包含XML的所有潜在应用，至少是些最重要的领域。

1、数据交换
用XML在应用程序和公司之间作数据交换已不是什么秘密了，毫无疑问应被列为第一位。那么为什么XML在这个领域里的地位这么重要呢？原因就是XML使用元素和属性来描述数据。在数据传送过程中，XML始终保留了诸如父/子关系这样的数据结构。几个应用程序可以共享和解析同一个XML文件，不必使用传统的字符串解析或拆解过程。

相反，普通文件不对每个数据段做描述(除了在头文件中)，也不保留数据关系结构。使用XML做数据交换可以使应用程序更具有弹性，因为可以用位置(与普通文件一样)或用元素名(从数据库)来存取XML数据。

2、Web服务
Web服务是最令人激动的革命之一，它让使用不同系统和不同编程语言的人们能够相互交流和分享数据。其基础在于Web服务器用XML在系统之间交换数据。交换数据通常用XML标记，能使协议取得规范一致，比如在简单对象处理协议(Simple Object Access Protocol, SOAP)平台上。

SOAP可以在用不同编程语言构造的对象之间传递消息。这意味着一个C#对象能够与一个Java对象进行通讯。这种通讯甚至可以发生在运行于不同操作系统上的对象之间。DCOM, CORBA或Java RMI只能在紧密耦合的对象之间传递消息，SOAP则可在松耦合对象之间传递消息。

3、内容管理
XML只用元素和属性来描述数据，而不提供数据的显示方法。这样，XML就提供了一个优秀的方法来标记独立于平台和语言的内容。

使用象XSLT这样的语言能够轻易地将XML文件转换成各种格式文件，比如HTML, WML, PDF, flat file, EDI, 等等。XML具有的能够运行于不同系统平台之间和转换成不同格式目标文件的能力使得它成为内容管理应用系统中的优秀选择。

4、Web集成
现在有越来越多的设备也支持XML了。使得Web开发商可以在个人电子助理和浏览器之间用XML来传递数据。

为什么将XML文本直接送进这样的设备去呢？这样作的目的是让用户更多地自己掌握数据显示方式，更能体验到实践的快乐。常规的客户/服务(C/S)方式为了获得数据排序或更换显示格式，必须向服务器发出申请；而XML则可以直接处理数据，不必经过向服务器申请查询-返回结果这样的双向“旅程”，同时在设备也不需要配制数据库。

甚至还可以对设备上的XML文件进行修改并将结果返回给服务器。想像一下，一台具有互联网功能并支持XML的电冰箱将会给市场带来多么大的冲击吧。你从此不必早起去取牛奶了！

5、配制
许多应用都将配制数据存储在各种文件里，比如.INI文件。虽然这样的文件格式已经使用多年并一直很好用，但是XML还是以更为优秀的方式为应用程序标记配制数据。使用.NET里的类，如XmlDocument和XmlTextReader，将配制数据标记为XML格式，能使其更具可读性，并能方便地集成到应用系统中去。使用XML配制文件的应用程序能够方便地处理所需数据，不用象其他应用那样要经过重新编译才能修改和维护应用系统。

如前所述，这里提到的五种使用XML的途径不包括全部场合。我希望这些可以有助于你思考如何

WebServices入门以及多种语言调用WebServices的例子


关键字: SOAP XML XSD WSDL
1． 什么是webservice
从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。
对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。
不管你的Web service是用什么工具，什么语言写出来的，只要你用SOAP协议通过HTTP来调用它，总体结构都应如下图所示。通常，你用你自己喜欢的语言(如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应答的方式把它送回到客户端。

2． 基本概念
SOAP
Web service建好以后，其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的远程过程调用( RPC)方法来调用Web service。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。客户端和服务端之间的方法调用请求和结果返回值都放在这些消息里。
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类型。
WSDL(Web Services Description Language)
用于描述服务端所提供服务的XML格式。WSDL文件里，描述了服务端提供的服务，提供的调用方法，以及调用时所要遵循的格式，比如调用参数和返回值的格式等等。WSDL 很像COM编程里的IDL(Interface Description Language)，是服务器与客户端之间的契约，双方必须按契约严格行事才能实现功能。
WSML(Web Services Meta Language)
用于描述WSDL里提供的方法与实现该方法的COM对象之间的映射关系。该文件是Microsoft的实现中特有的，不是SOAP标准的一部分。一般情况下，该文件只在服务端存在。





3．Webservice的技术特点
长项一： 跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问
题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。
举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。
如果中间层组件换成Web Service的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web Service，可以直接使用Microsoft SOAP Toolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web Service这种结构，可以节省花在用户界面编程上20%的开发时间。另外，这样一个由Web Service组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过Web Service把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。
长项二： 应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。
例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web Service，订单执行程序可以把“Add Order”函数“暴露