MILY: 宋體; FONT-SIZE: 9pt; mso-bidi-font-size: 10.0pt">譯者注：這是一篇來自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。按如下格式所示：

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Body>
      <ns:Order xmlns:ns="urn:fabrikam-com:orders">
         <item>Wallabee</item>
         <item>Wombat</item>
         <item>Wren</item>
      </ns:Order>
   </env:Body>
</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服務，修改傳輸協議以及其他有意義的工作還在繼續，他們會提供更高水平的服務。