译者注：这是一篇来自MSDN介绍 Web服务基本思想的文章，希望通过此文给大家在理解Web服务思想时带来一些帮助。这是本人第一次翻译并且第一次在CSDN上发表文章，其中存在谬误和翻译不当是在所难免的，真心希望大家能提出宝贵意见和建议！谢谢！
_ 编者按：本文为开发人员提供基本的 Web服务思想的入门介绍，如果你想了解Web服务和 _ _ .NET的商业前景请参阅： http://www.microsoft.com/net/business 。 _
如今，任何用于构筑分布式应用的方法都不及 Web 模型被更为快速和广泛地采用。 Web 模型的极大成功归功于他的核心特征：比起 传统的 RPC, DCOM 和 CORBA 等分布式编程模型， Web 模型具有更为松散的关联性。 Web 客户端和服务器的交互非常简单，他们通过传送 MIME （译者注：多用途的网际邮件扩充协议）类型的数据包来交换信息，并且可以通过修改协议头来改变信息的语义。信息传送的目的地址用 URL 来间接地指定，这种间接指定可作协调负载平衡、协议跟踪和其他作用。
由于交互的简单性， Web 编程模型使系统开发可采用渐增的方式，不象紧密关联的 RPC 和分布式对象系统，应用程序的各个部分必须被同时开发。你可以根据需要向基于 Web 的系统增加客户端和服务器端应用，可以非常容易得建立与新增的应用的连接，并且，你可以用分散的方式来做这些，除了向域名服务器注册以外，不需要任何的集中协调和控制。但是系统却具有深度的互操作性、大规模应用能力和易管理性。这些就是 Web 模型引人注目的地方。
Web 服务背后的基本思想就是使应用程序也具有 Web 分布式编程模型的松散连接性，而这些应用并不一定是象 Web 模型一样基于浏览器的。 Web 服务提供一个建立分布式应用的平台，使得运行在不同的操作系统和不同的设备上的软件、用不同的程序语言和不同厂商的软件开发工具开发的软件、所有可能的已开发和部署的软件能够利用这一平台实现分布式计算的目的。
** Web ** ** 服务如何工作？ **
** ** Web 服务建立于传统 Web 编程模型的松散耦合特性之上，并将这种特性运用于其他的应用程序。 Web 服务和传统的 Web 运用有三个主要区别： Web 服务采用 SOAP 消息而不是传统 Web 的 MIME 消息； Web 服务的传输协议并不仅仅采用 HTTP ； Web 服务提供了信息产生和使用时的元数据描述。下边我们详细讨论这三种区别：
首先， Web 服务采用 SOAP 消息进行通信。 SOAP 使用 XML 从一个程序向另一个程序传递数据， SOAP 定义了协议转换和扩展的框架模型，可以反馈出错信息和实现在 HTTP 上传递信息。 SOAP 的消息体包含应用程序需要发送的任何 XML 。按如下格式所示：
1<env:envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
2<env:body>
3<ns:order xmlns:ns="urn:fabrikam-com:orders">
4<item>Wallabee</item>
5<item>Wombat</item>
6<item>Wren</item>
7</ns:order>
8</env:body>
9</env:envelope>
从MIME消息到SOAP消息的转变反映了传统的基于浏览器的Web客户端与Web服务客户端的关键不同之处。浏览器仅仅是呈现接收到的HTML页面（或者其他MIME类型的数据，如：图片），而让用户去识别页面的含义。但是，Web服务的客户端则需要解释接收到的数据，并根据含义执行一定的操作——也许并不具有用户界面接口。XML提供了描述和操作数据的统一方法，并且XML处理工具无处不在，它理所当然的称成了Web服务的信息格式。（用DIME这种封装能将MIME消息转化成为SOAP信息，用这种方式转换数据为XML格式的效率低以至不可接受）。
当SOAP规定将XML作为信息的载体的时候，并没有规定XML象什么样，这要等到Web服务的设计者去决定XML要传递那些数据。在一些情况下，消息可能包含方法调用的参数。这样做的优点是提供了一个非常熟悉的类似于传统RPC的编程模型，缺点是导致客户端和服务器端紧密关联，至少，消息接受者在接受正在发送的数据时是这样的。而且，大多数以方法调用为中心的系统要求消息中包含的参数的个数、顺序、类型都必须正确。另一些情况下，消息描述中可能不包含方法调用，这时客户端和服务器端允许松散关联， 数据的格式和内容的产生和使用更加灵活。这种编程模型更像传统的 Web 模型，它并不规定被处理的消息包含的数据如何组织发送。
Web 服务和传统 Web 编程第二个主要的不同是 Web 服务并不指定传输协议。 SOAP 规范定义了在 HTTP 协议上如何发送 SOAP 消息——这是如今大多数 Web 服务采用的，其他的传输协议也可以用于 SOAP 消息的发送，你可以使用 SMTP、TCP、实时消息协议如Jabber，或者任何其他的你喜欢的传输协议。但是，预计大多数SOAP消息将使用HTTP协议。支持使用其他协议也非常重要，HTTP协议不支持长运行请求，也不支持向客户端广播事件。最好的解决办法就是使用其它协议，这些标准在不久后将会出台。
由于Web服务可以采用不同的传输协议进行通信，任何高层服务如：安全，都需要被定义以满足消息中立，传输方式无关。为了支持这种高层服务，SOAP消息格式中包含了一个元素可扩展的消息头，消息头包含了消息数据元，那些扩展元素与消息体内的领域数据没有直接联系。采用消息头扩展其基本的request/response行为，已被用于HTTP协议。在SOAP之上定义协议扩展可以确保其语义被很好的理解，而不用关心所采用的传输协议。
另外，为了达到传输协议无关性，SOAP不要求消息以简单的‘跳跃’方式从客户端发送消息到服务器端。SOAP规范引入了中间件的概念，即一个消息要通过一定的路径才到达最终目的地。利用中间件，你可以虚拟物理网络拓扑结构实现Web服务消息传递，而无论什么路径，不管邦定何种协议更合适。SOAP消息中间件还没有被现在的Web服务工具广泛支持，但不久将会实现。一旦这种功能成为主流，你将能够开发更为广泛适用于不同网络结构的Web服务，并且不需要改变客户端和服务器端代码。
Web 服务和传统 Web 编程第三个主要不同是 Web 服务是自描述的，它提供了信息产生和使用时的元数据描述。这种信息交换模式表达了 Web 服务具有的行为，使用的物理传输协议，和逻辑访问地址。 Web 服务使 用 XML Schema来定义其消息格式。用于描述更广范围内的消息结构方面，XML Schema能够达到足够的灵活，包括描述能获得可扩展性控制的开放目录模型——这种模型被认为在数据发送和接受期间能够实现松散关联服务。Web服务具有的行为使用Web Service Description Language (WSDL)来描述，它按信息交换的操作分组成为不同的接口，并描述了这些操作如何通过邦定特殊的传输协议来访问，可以根据这些描述来编写软件实现与Web服务的通信，软件代码可直接编写也可以使用代码生成工具来产生。
** 勇敢的进入新世界 **
Web服务运动将会创建一个新的具有多种用途的构建松散关联分布式系统的平台，如果你想进入Web服务世界，不要忘记以下四件点：
● 一切都是围绕松散关联，这是 Web成功之所在，也是Web服务引人注目的原因。
● 一切都是基于 XML，对XML的理解越深对Web服务的理解就会越深刻。
● 对象可用于实现 Web服务，但它并不是Web服务编程模型的核心。
● 这一平台还在不断发展，现在你可用这个范围广大的平台建立自己的 Web服务，修改传输协议以及其他有意义的工作还在继续，他们会提供更高水平的服务。