本文共 6240 字，大约阅读时间需要 20 分钟。
本文转载于：
大家或多或少都听过 WebService（Web服务），有一段时间很多计算机期刊.书籍和网站都大肆的提及和宣传 WebService 技术，其中不乏很多吹嘘和做广告的成分。但是不得不承认的是 WebService 真的是一门新兴和有前途的技术，那么 WebService 到底是什么？何时应该用？
当前的应用程序开发逐步的呈现了两种迥然不同的倾向：一种是基于浏览器的瘦客户端应用程序，一种是基于浏览器的富客户端应用程序（RIA），当然后一种技术相对来说更加的时髦一些（如现在很流行的Html5技术），这里主要讲前者。
基于浏览器的瘦客户端应用程序并不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。传统的 Windows 富客户应用程序使用 DCOM 来与服务器进行通信和调用远程对象。配置好 DCOM 使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多 IT 工程师的噩梦。事实上，许多 IT 工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个 DCOM。关于客户端与服务器的通信问题，一个完美的解决方法是使用 HTTP 协议来通信。这是因为任何运行 Web 浏览器的机器都在使用 HTTP 协议。同时，当前许多防火墙也配置为只允许 HTTP 连接。许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用 COM 或 .NET 语言写的，并且都运行在 Windows 平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件( VSAM )的形式存放，并由 COBOL 语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用 C++，Java，Visual Basic 和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的 API，如 IBM 的高级程序到程序交流( APPC )等来完成的。在以前，没有一个应用程序通信标准，是独立于平台.组建模型和编程语言的。只有通过 Web Service，客户端和服务器才能够自由的用 HTTP 进行通信，不论两个程序的平台和编程语言是什么。
一言以蔽之：WebService 是一种跨编程语言和跨操作系统平台的远程调用技术。
所谓跨编程语言和跨操作平台，就是说服务端程序采用java编写，客户端程序则可以采用其他编程语言编写，反之亦然！跨操作系统平台则是指服务端程序和客户端程序可以在不同的操作系统上运行。
所谓远程调用，就是一台计算机 a 上的一个程序可以调用到另外一台计算机 b 上的一个对象的方法，譬如，银联提供给商场的 pos 刷卡系统，商场的 POS 机转账调用的转账方法的代码其实是跑在银行服务器上。再比如，amazon，天气预报系统，淘宝网，校内网，百度等把自己的系统服务以 webservice 服务的形式暴露出来，让第三方网站和程序可以调用这些服务功能，这样扩展了自己系统的市场占有率，往大的概念上吹，就是所谓的 SOA 应用。
其实可以从多个角度来理解 WebService，从表面上看，WebService 就是一个应用程序向外界暴露出一个能通过 Web 进行调用的 API，也就是说能用编程的方法通过 Web 来调用这个应用程序。我们把调用这个 WebService 的应用程序叫做客户端，而把提供这个 WebService 的应用程序叫做服务端。从深层次看，WebService 是建立可互操作的分布式应用程序的新平台，是一个平台，是一套标准。它定义了应用程序如何在 Web 上实现互操作性，你可以用任何你喜欢的语言，在任何你喜欢的平台上写 Web service ，只要我们可以通过 Web service 标准对这些服务进行查询和访问。
WebService 平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，WebService 平台必须提供一套标准的类型系统，用于沟通不同平台.编程语言和组件模型中的不同类型系统。Web service 平台必须提供一种标准来描述 Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个 Web service 进行远程调用,这种方法实际是一种远程过程调用协议( RPC )。为了达到互操作性，这种 RPC 协议还必须与平台和编程语言无关。
XML + XSD，SOAP 和 WSDL 就是构成 WebService 平台的三大技术。
WebService 采用 HTTP 协议传输数据，采用 XML 格式封装数据（即在 XML 中，说明要调用远程服务对象的哪个方法，传递的参数是什么，以及服务对象的返回结果是什么）。XML 是 WebService 平台中表示数据的格式。除了易于建立和易于分析外，XML 主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
XML 解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，64 位？这些细节对实现互操作性很重要。XML Schema ( XSD ) 就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。WebService 平台就是用 XSD 来作为其数据类型系统的。当你用某种语言 (如 VB.NET 或 C# ) 来构造一个 Web service 时，为了符合 WebService 标准，所有你使用的数据类型都必须被转换为 XSD 类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。
WebService 通过 HTTP 协议发送请求和接收结果时，发送的请求内容和结果内容都采用 XML 格式封装，并增加了一些特定的 HTTP 消息头，以说明 HTTP 消息的内容格式，这些特定的 HTTP 消息头和 XML 内容格式就是 SOAP 协议。SOAP 提供了标准的 RPC 方法来调用 Web Service。
SOAP 协议 = HTTP 协议 + XML 数据格式
SOAP 协议定义了 SOAP 消息的格式，SOAP 协议是基于 HTTP 协议的，SOAP 也是基于 XML 和 XSD 的，XML 是 SOAP 的数据编码方式。打个比喻：HTTP 就是普通公路，XML 就是中间的绿色隔离带和两边的防护栏，SOAP 就是普通公路经过加隔离带和防护栏改造过的高速公路。
好比我们去商店买东西，首先要知道商店里有什么东西可买，然后再来购买，商家的做法就是张贴广告海报。 WebService 也一样，WebService 客户端要调用一个 WebService 服务，首先要有知道这个服务的地址在哪，以及这个服务里有什么方法可以调用，所以，WebService 服务器端首先要通过一个 WSDL 文件来说明自己家里有啥服务可以对外调用，服务是什么（服务中有哪些方法，方法接受的参数是什么，返回值是什么），服务的网络地址用哪个 url 地址表示，服务通过什么方式来调用。
WSDL ( Web Services Description Language ) 就是这样一个基于XML 的语言，用于描述 Web Service 及其函数.参数和返回值。它是WebService 客户端和服务器端都能理解的标准格式。因为是基于 XML 的，所以 WSDL 既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的 Web service 生成 WSDL 文档，又能导入 WSDL 文档，生成调用相应 WebService 的代理类代码。
WSDL 文件保存在 Web 服务器上，通过一个 url 地址就可以访问到它。客户端要调用一个 WebService 服务之前，要知道该服务的 WSDL 文件的地址。WebService 服务提供商可以通过两种方式来暴露它的 WSDL 文件地址：1. 注册到 UDDI 服务器，以便被人查找；2. 直接告诉给客户端调用者。
WebService 开发可以分为服务器端开发和客户端开发两个方面：
服务端开发：把公司内部系统的业务方法发布成 WebService 服务，供远程合作单位和个人调用。(借助一些 WebService 框 架可以很轻松地把自己的业务对象发布成 WebService 服务，Java 方面的典型 WebService 框架包括：axis，xfire，cxf 等，java ee 服务器通常也支持发布 WebService 服务，例如 JBoss。)
客户端开发：调用别人发布的 WebService 服务，大多数人从事的开发都属于这个方面，例如，调用天气预报 WebService 服务。（使用厂商的 WSDL2Java 之类的工具生成静态调用的代理类代码；使用厂商提供的客户端编程 API 类；使用 SUN 公司早期标准的 jax-rpc 开发包；使用 SUN 公司最新标准的 jax-ws 开发包。当然 SUN 已被 ORACLE 收购)WebService 的工作调用原理：对客户端而言，我们给这各类 WebService 客户端 API 传递 WSDL 文件的 url 地址，这些 API 就会创建出底层的代理类，我调用这些代理，就可以访问到 webservice 服务。代理类把客户端的方法调用变成 SOAP 格式的请求数据再通过 HTTP 协议发出去，并把接收到的 SOAP 数据变成返回值返回。对服务端而言，各类 WebService 框架的本质就是一个大的 Servlet，当远程调用客户端，给它通过 http 协议，发送 SOAP 格式的请求数据时，它分析这个数据，就知道要调用哪个 java 类的哪个方法，于是去查找或创建这个对象，并调用其方法，再把方法返回的结果包装成 SOAP 格式的数据，通过 http 响应消息送回给客户端。
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用 DCOM 就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆 ASP 页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。如果中间层组件换成 WebService 的话，就可以从用户界面直接调用中间层组件。从大多数人的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用 WebService 这种结构，可以节省花在用户界面编程上 20% 的开发时间。
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的.在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在 IBM 主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过 WebService，可以很容易的集成不同结构的应用程序。
用 WebService 集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户.突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做 B2B 集成。WebService 是 B2B 集成成功的关键。通过 WebService，公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念，EDI (电子文档交换)早就是这样了。但是，WebService 的实现要比 EDI 简单得多，而且 WebService 运行在 Internet 上，在世界任何地方都可轻易实现，其运行成本就相对较低。不过，WebService 并不像 EDI 那样，是文档交换或 B2B 集成的完整解决方案。WebService 只是 B2B 集成的一个关键部分，还需要许多其它的部分才能实现集成。
用 WebService 来实现 B2B 集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来，成为 WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在 B2B 集成上的时间和成本，让许多原本无法承受 EDI 的中小企业也能实现 B2B 集成。
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，一种形式是二进制形式的组件重用。采用 WebService 应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用，达到业务级重用。
目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用 WebService，只要用本地的 API 就可以了。COM 非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用 COM 或其它本地的 API 来进行应用程序间的调用。当然 WebService 也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。
在许多应用中，所有的程序都是用 VB 或 VC 开发的，都在 Windows 平台下使用 COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个 Win32 或 WinForm 的客户程序要连接局域网上另一个服务器的程序。在这些程序里，使用 DCOM 会比 SOAP/HTTP 有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个 .NET 程序，应该使用 .NETremoting。有趣的是，在 .NETremoting 中，也可以指定使用 SOAP/HTTP 来进行 WebService 调用。不过最好还是直接通过 TCP 进行 RPC 调用，那样会有效得多。