原文： http://wenku.baidu.com/view/f87b55f19e31433239689314.html
WebServices簡介
先給出一個概念 SOA ，即Service Oriented Architecture ，中文一般了解為面向服務的架構，
既然說是一種架構的話，是以一般認為 SOA 是包含了運作環境，程式設計模型，
架構風格和相關方法論等在内的一整套新的分布式軟體系統構造方法和環境，
涵蓋服務的整個生命周期。而在 SOA 的架構風格中，服務是最核心的抽象手段。
SOA 中的服務是建構在一些列基于開放标準的基礎之上的，
Web 服務定義了如何在異構系統之間實作通信的标準化方法，
進而就使得 Web 服務可以跨越運作平台和實作語言，
同時也使得 Web 服務成為了實作 SOA 中服務的主要技術。
至于SOA 的話，太高深的技術，這裡不予讨論（嘿嘿），本篇博文隻介紹 WebServices 這項技術。
引子
有沒有一種辦法可以實作跨應用程式進行通信和跨平台進行通信呢？
換句話說，就是有什麼辦法可以實作我的應用程式 A 可以和應用程式 B 進行通信呢？
或者說是，我用 Java 寫的應用程式和用 . Net 開發的應用程式之間進行通信呢？
很多時候，上面提到的這些，我們是必須要使用的，比如，一個跨應用程式吧，
拿騰訊 QQ 來說吧，我估計每一個人都用過騰訊 QQ 上面的天氣預報工具吧 ！ ！ ！
上面的這個天氣預報功能是如何實作的呢？
有一種辦法，那就是騰訊公司放個衛星上天，并且在公司中成立一個氣象部門，天天關注于天氣，
然後每時每刻更新騰訊 QQ 上的這個天氣預報資訊，
确實，這種辦法确實行得通，不過，要真這樣做的話，估計馬化騰也該被踢出去了（哪有這麼蠢啊？），
那麼上面這個是如何實作的呢？别急，且聽我慢慢道來~~~
然後，我們再來看看跨平台這個東東又是什麼呢？
這裡主要是拿 . Net 平台和Java 平台來說明例子，
假若，有兩個公司，每個公司呢都有自己的一個項目，一個公司呢使用 . Net 開發，一個呢，使用 Java 開發，
恩，本來呢，這兩個是互相獨立的，進水不犯河水，但是有一天，突然，這兩個公司給合并了，
合并後的老總發現，如果把兩個項目結合起來将會大大的賺一筆，為此，如何做？
因為要把兩個項目結合在一起，那麼這兩個項目之間總應該通通信吧 ！！！
可這兩個項目又是基于不同的平台，怎麼通信呢？麻煩了吧 ！！！
而後再看一種情況，就是比如一個公司使用的伺服器是 Windows Server 2008，
那麼它如何和 IT 供應商的UNIX 或者是 Linux 伺服器進行連接配接呢？也很複雜吧 ！！！
WebServices特點介紹
WebServices 提供一個建立分布式應用的平台，使得運作在不同作業系統和不同裝置上的軟體，或者是用不同的程式語言和不同廠商的軟體開發工具開發的軟體，所有可能的已開發和部署的軟體，能夠利用這一平台實作分布式計算的目的。WebServices的思想是：使得應用程式也具有 Web 分布式程式設計模型的松散耦合性。
WebServices的特點：
（1），WebServices 是自包含的。即在用戶端不需要附加任何軟體，隻要客戶機支援 HTTP 和XML 就 OK 了。
（2），WebServices 是自我描述的。在用戶端和服務端都不需要知道除了請求和響應消息的格式和内容外的任何事。
（3），WebServices 是跨平台和跨語言的。用戶端和服務端均可以在不同的平台和語言環境中實作，同時，不必為了支援 WebServices 而更改現有的代碼。
（4），WebServices 是基于開放和标準的。XML 和 HTTP 是WebServices 的主要技術基礎，而 XML 和HTTP 早就成了業内标準了。
（5），WebServices 是動态的。
（6），WebServices 是可以組合的。也就是通過一個 WebService 通路另外一個 WebService 來達到組合的目的。通過組合 WebServices 便可以将簡單的 WebServices 聚合成為實作更多複雜功能的複雜的服務。
（7），WebServices 是松散耦合的。它完全解耦了用戶端和服務端。
（8），WebServices 提供程式設計通路的能力。換句話說，就是可以通過編寫程式來通路Web 服務。
（9），WebServices 是基于經過考驗的成熟技術上建構的。比如 XML 和 HTTP。
（10），WebServices 提供打包現有應用程式的能力。
（11），WebServices 通過網絡進行釋出，查找和使用。
上面這些特點呢，現在不清楚的話，也不用緊，等下還會有詳細的說明的 ！！！
WebServices到底是什麼？
如果簡單的說的話，WebServices就是一組函數庫，不過這和我們平時概念中的函數庫卻又有所不同，我們平時所使用的函數庫要麼是自己寫的（在自己的應用程式當中寫一組函數庫），
要麼是調用底層的 API（作業系統 API 如Win32 API），上面的這兩種情況有一個共同點，
那就是函數庫是位于用戶端本地的，比如，您調用 Win32 API的話，就是調用本地作業系統上的函數庫，而這裡提到 Web 服務也是一組函數庫這個概念和上面提到的函數庫這個概念的差別就在此處，因為 Web服務看做一組函數庫的話，那麼這組函數庫不是位于本地的，而是位于遠端機器上（當然也可以是本地機器中）。
何為 Web 服務？
也就是網絡服務，那就是把網絡上不知道那個地方的一些函數看做是一組服務，然後我再通過網絡就可以使用這些服務。
關于什麼是 Web 服務，上面的說法那是山寨版的，稍微正經一點的說法是：
Web 服務是一種部署在 Web 上的對象或者是應用程式元件。
Why WebServices？
為什麼需要使用 WebServices呢？這必須根據 WebServices 的特點以及其優勢進行分析了。
首先，上面呢，也說了，Web服務的話，就是一組網絡上的應用程式元件，
這樣的話，您便可以通過在您的應用程式中使用 Web 服務來将您的應用程式提升到服務層面上來。
既然可以看做是一組服務了的話，那麼當然就是可以提供給别個（别的應用程式）使用咯。
比如，我可以通過 Web 服務來公開一些接口給别個使用，至于這些要不要收費呢？那就看我心情了，前面舉了騰訊 QQ 上查詢天氣的例子，這個例子呢，就可以在這裡來做一個解釋了，
在中國，應該隻有一個衛星來進行天氣預報的吧？騰訊也不可能為了天氣預報而專門放個衛星上天吧？
可是騰訊 QQ 又确實是可以查詢天氣的，這裡，便可以通過 Web 服務來解決。
首先，中國氣象局應該是有一個衛星的，氣象局根據衛星所傳回的結果實時釋出全國各地的天氣狀況，并且将這些天氣資訊以 Web 服務的形式公開，然後呢，騰訊 QQ 便可以通過這個 Web 服務來通路到天氣狀況了，再将這些天氣狀況回報到 QQ 上就 OK 了。
然後，上面提到了 Web服務是應用程式元件，既然是元件，那麼就可以對這個元件重複的進行使用了，
同時可以通過 Web 服務來實作将這個應用程式元件作為一個服務來進行使用，
更為強大的是，可以将多個 WebServices組合成為更為強大的 WebServices ，
并且是通過網際網路哦！！！
這也是一大優點啊，
然後呢，最基本的 WebServices是基于 XML 和 HTTP 的
（當然這是最基本的 WebServices ，比如 WebServices 還可以通過 HTTPS 或者是 SMTP 來實作通信），
這又有什麼好處呢？很明顯，XML 和HTTP 這些都已經是标準了，
不論你是 Java 平台呢，還是 . Net 平台開發出來的（或者是是使用 Web 服務），既然我是使用 XML 和 HTTP 的話，我才懶得鳥你什麼 Java 還是 . Net 呢，我也不管你是 Linux 還是 Windows ，這一切都和我 Web 服務無關，
我關注的隻是通過 HTTP 協定來傳輸 XML 就 OK 了，
至于這些 XML 是如何被服務提供者開發出來的或者這些 XML 是如何被服務請求者使用的，這些都和我無關，這裡便可以看出 Web 服務的另一個優勢了，那就是跨語言跨平台（實作協同工作），是以可以通過 Web 服務來實作不同應用程式和不同平台之間的通信。
Web 服務允許獨立于實作服務基于的硬體或者是軟體平台和編寫服務所用的程式設計語言使用服務，
根據上面這兩點呢，
便可以解決掉最開始提出的使用 Java 開發的應用程式如何和使用 . Net 開發的應用程式之間進行通信這一問題，
同時，也可以解決 Linux 或者是UNIX 和 Windows Server 2008 之間進行連接配接這一問題了。
最後就是通過使用不同的 Web 服務，也不管 Web 服務是那種程式設計語言實作的，
我們都可以從不同的平台和作業系統進行通路，進而大大提高了不同應用程式共享資料和應用的能力。
并且 Web服務提供了建構 SOA 所必須得技術基礎。
從上面可以看出通過 WebServices解決了我們曾經想都不敢想的問題，這麼強大的東西為什麼不加以好好利用呢？
WebServices體系結構
在Web 服務的體系結構中，涉及到三個角色，
一個是 Web 服務提供者，一個是 Web 服務中介者，還有一個就是 Web 服務請求者，
同時還涉及到三類動作，即釋出，查找，綁定，
Web 服務提供者：
可以釋出 Web 服務，并且對使用自身服務的請求進行響應，
Web 服務的擁有者，它會等待其他的服務或者是應用程式通路自己。
Web 服務請求者：
也就是 Web 服務功能的使用者，它通過服務注冊中心也就是 Web 服務中介者查找到所需要的服務，
再利用 SOAP 消息向 Web 服務提供者發送請求以獲得服務。
Web 服務中介者：
也稱為服務代理，用來注冊已經釋出的 Web服務提供者，并對其進行分類，同時提供搜尋服務，
簡單來說的話，Web 服務中介者的作用就是把一個 Web 服務請求者和合适的 Web 服務提供者聯系在一起，
充當一個管理者的角色，一般是通過 UDDI來實作。
釋出：
通過釋出操作，可以使 Web服務提供者向 Web 服務中介者注冊自己的功能以及通路的接口。
發現（查找）：
使得 Web 服務請求者可以通過 Web 服務中介者來查找到特點的種類的 Web 服務。
綁定：
這裡就是實作讓服務請求者能夠使用服務提供者提供的服務了。
WebServices三種基本元素之 SOAP
SOAP 即 Simple Object AccessProtocol 也就是簡單對象通路協定。
SOAP 呢，其指導理念是“唯一一個沒有發明任何新技術的技術”，
是一種用于通路 Web 服務的協定。
因為 SOAP 基于XML 和 HTTP ，其通過XML 來實作消息描述，然後再通過 HTTP 實作消息傳輸。
SOAP 是用于在應用程式之間進行通信的一種通信協定。
因為是基于 XML 和HTTP 的，是以其獨立于語言，獨立于平台，并且因為 XML 的擴充性很好，
是以基于 XML 的 SOAP 自然擴充性也不差。
通過 SOAP 可以非常友善的解決網際網路中消息互聯互通的需求，
其和其他的 Web 服務協定建構起 SOA 應用的技術基礎。
SOAP 協定的一個重要特點是它獨立于底層傳輸機制，Web 服務應用程式可以根據需要選擇自己的資料傳輸協定，
可以在發送消息時來确定相應傳輸機制。
由于 HTTP 協定本身的一些特點和局限性，
使得當 SOAP 使用HTTP 綁定的 Web 服務并不能滿足某些企業應用的需求。
比如，HTTP 不是一個可靠傳輸協定，是以有可能在傳輸過程中出現問題，
然後 HTTP 協定基于Request/Response 模型，也就是說用戶端需要在等待響應消息接收完成後才能繼續執行，
而此時如果響應時間過長呢？
基于上面的這些需求，便需要選擇合适的傳輸協定了。
關于這方面的内容的話，有點深奧了，有興趣的可以去看看 IBM 的一些關于這方面内容的介紹。
還有一點需要提及一下，那就是 SOAP 是可以繞過防火牆的，将來将會作為 W3C 的标準進行發展。
WebServices三種基本元素之 WSDL
WSDL 即Web Services Description Language也就是 Web 服務描述語言。
是基于 XML的用于描述 Web 服務以及如何通路 Web 服務的語言。
服務提供者通過服務描述将所有用于通路 Web服務的規範傳送給服務請求者，
要實作 Web服務體系結構的松散耦合，服務描述是一個關鍵，
不管是請求者還是服務提供者，通過服務描述便可以不必了解對方的底層平台，程式設計語言等，
服務描述與底層的 SOAP 基礎結構相結合，
足以封裝服務請求者的應用程式和服務提供者的 Web服務之間的這個細節。
WSDL 描述了 Web服務的三個基本屬性：
（1）服務所提供的操作
（2）如何通路服務
（3）服務位于何處（通過 URL 來确定就 OK 了）
WebServices三種基本元素之 UDDI
UDDI 即 Universal Description，Discovery and Integration，也就是通用的描述，發現以及整合。
WSDL 呢，用來描述了通路特定的 Web 服務的一些相關的資訊，可以在網際網路上，
或者是在企業的不同部門之間，如何來發現我們所需要的 Web 服務呢？
而 Web 服務提供商又如何将自己開發的 Web 服務公布到網際網路上，
這就需要使用到 UDDI 了，UDDI的話，是一個跨産業，跨平台的開放性架構，
可以幫助 Web 服務提供商在網際網路上釋出 Web 服務的資訊。
UDDI 呢是一種目錄服務，企業可以通過 UDDI 來注冊和搜尋 Web 服務。
簡單來時候話，UDDI 就是一個目錄，隻不過在這個目錄中存放的是一些關于 Web 服務的資訊而已。
并且 UDDI 通過SOAP 進行通訊，建構于 . Net 之上。
開發 Web服務的方式
（1）開發階段：
實作一個 Web 服務，使這個 Web 服務能響應和接收 SOAP 消息，
（這個呢，其實可以通過 Visual Studio 來幫助實作），
定義好邏輯子產品（這個 Web 服務總要幹點事情吧），
然後再撰寫 WSDL 檔案（這個呢，開發工具會自動生成的，不需要人工撰寫了）
（2）部署階段：
指定 Web 服務的傳輸協定，将 Web 服務注冊到相應服務描述部署檔案（這些也是可以由工具來自動完成的）
（3）釋出階段：
将 Web 服務的接口和調用的位址公開給用戶端調用，
常用的釋出方式為基于 Web 提供的WSDL 的連結，當然 UDDI 也是一個選擇。
總結一下 WebServices的優點
其實呢，前面介紹的都是關于 WebServices 的優點，在這裡就隻是淺要的總結一下了。
首先，WebServices 是基于 Internet 和異構平台的應用，
這樣便可以友善的實作通過網絡來通信，同時可以實作在不同的平台之間共享資料。
然後就是，WebServices 是基于 XML 和HTTP 的，
也就是基于标準和開放的，基于 XML 的話，擴充性自然好，自然跨語言。
基于 HTTP 的話，自然跨平台了。
最後，再回憶一下 WebServices 是一種應用程式元件吧，這樣便可以将 WebServices 重複使用了。
談談 WebServices 的缺點
首先就是由于 XML 檔案的難以解析，是以在使用 Web 服務的時候，會消耗較多的 CPU 和記憶體資源，
而後，SOAP 是基于XML 的，是以在網絡傳輸中傳輸的是 XML 檔案，
但是由 XML 檔案相比于二進制檔案來說，要大很多，自然就會消耗更多的網絡資源了。
而後，由于通過 WSDL 解耦了Web 服務提供者和請求者，且 SOAP 消息時從發送者向接收者單向傳送的，
這在一定程度上造成了 WebServices 是一種無狀态服務，
盡管現在在 . Net 中可以通過 Session 來實作在用戶端和服務端共享一些資料，
但是單單依靠 Session 來實作用戶端和服務端的狀态互動也太牽強了吧
WebServices 在資料綁定上也存在一些缺陷，
因為所有的資料在傳輸中都是使用的 XML 來實作的，
是以，需要在二進制資料和 XML 之間進行一個轉換（通過序列化和反序列化來實作），
而在轉換過程中有可能出現語義丢失的情況。
最後就是 WebServices 的技術要求相對比較高，
因為涉及到底層的 HTTP 協定以及SOAP ，WSDL 和UDDL 這三大平台元素，
是以學習的曲線也是比較長的，
當然，在 . Net 中可以通過 Visual Studio 非常快速和簡單的開發和通路一個 Web 服務，
但這隻限于在簡單的使用上，而對于本質的東西，是比較難的。
後續
正如題目所言，是 WebServices 簡介，既然是簡介的話，那麼自然就是以簡為目标了，
說明一下的是，上面的這篇博文呢，源自前幾天做的一個關于 WebServices 的演講，
演講的 PPT 還存有，有興趣要的可以留個郵箱的。
. Net中 WebServices 的實戰
下面呢，就來具體看看在 . Net中如何開發一個WebServices 以及如何使用這個 WebServices
開發環境：
Windows 7 下IIS 7.5
Visual Studio TeamSystem 2008
Sql Server 2008
首先來看看如何開發一個 WebServices
先建立一個 ASP.NET 應用程式項目，然後再在項目中添加一個 WebServices 服務，
然後就是在這個 WebServiceTest中編寫業務邏輯了，
本次執行個體的業務邏輯呢就是從資料庫“圖書館管理系統”中取出所有的讀者的資訊。
WebServiceTest.asmx中的代碼如下
usingSystem.Web.Services;
usingSystem.Data;
usingSystem.Data.SqlClient;
usingSystem.Web.Configuration;
namespace WebServiceDemo
{
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
public classWebServiceTest :System.Web.Services.WebService
{
[WebMethod]
public DataSet GetAllReader()
{
DataSet ds = newDataSet();
string connStr =
WebConfigurationManager.ConnectionStrings["DBConnString"].ConnectionString;
string sqlStr = "SELECT[ReaderID],[ReaderIDType],[ReaderName]," +
"[ReaderSex],[ReaderBirth]" +
"FROM [圖書館管理系統].[dbo].[Reader]";
using (SqlConnection sqlCon = new SqlConnection(connStr))
{
using (SqlCommand sqlCom =sqlCon.CreateCommand())
{
sqlCom.CommandType = CommandType.Text;
sqlCom.CommandText = sqlStr;
using (SqlDataAdapter sqlDa = newSqlDataAdapter(sqlCom))
{
sqlDa.Fill(ds);
}
}
}
return ds;
}
}
}
然後我再在這一個項目 WebServiceDemo中添加一個頁面 Test . aspx
來實作通路自身應用程式中的 WebServices
（Test. aspx和 WebServiceTest . asmx 位于同一應用程式中）。
這個 Test . aspx 呢非常簡單，僅僅在上面放了一個 GridView ，然後稍微寫點 Code-Behind 就 OK 了，
其代碼如下：
using System;
namespace WebServiceDemo
{
public partial class Test : System.Web.UI.Page
{
protected void Page_Load(objectsender, EventArgs e)
{
if(!IsPostBack)
{
WebServiceTesttest= new WebServiceTest();
GridView1.DataSource = test.GetAllReader();
GridView1.DataBind();
}
}
}
}
再來浏覽一下 Test . aspx頁面
可以看出已經達到了預定的效果，也就是從資料庫中通過 WebServices取出了資料。
而從上面的代碼可以看出，僅僅是将 WebServices看做是一個類了，
将其作為一個類來進行使用（實質上也就是一個類而已）。
下面我們還需要看一種情況，
那就是，實作在另外的一個應用程式中通路上面建立的 WebServices。
其實這種情況呢，就是和通路網絡上的 WebServices 一樣了，
比如騰訊 QQ 就是使用這種方式來實作的，
為了模拟這種實作，我首先将上面建立的這個 ASP.NET 應用程式 部署到 IIS 上面，
且指定了一個端口為 81
然後我再建立一個項目 TestWebServices
并且在這個項目裡面也添加一個頁面 Test . aspx
在Test . aspx 上也隻放一個 GridView 控件。
然後就要給這個項目添加 Web服務的引用了（右鍵TestWebService 點選“添加 Web 引用”）
如果您要通路的是網際網路上的 Web服務，比如查詢天氣，
那麼就需要在上面的 URL中寫入 Web 服務所在的位址，然後“前往”就 OK 了，
由于本次的示範，我隻是把我的 Web服務放在了本地的 IIS 上面，
是以在此處呢選擇“本地計算機上的 Web服務”，
從上面的截圖中就可以看出，在 81号端口上面我有一個 Web 服務，
就是前面的 Demo中建立的 Web 服務 WebServiceTest
然後我選擇這個 Web 服務，單擊它即可，
上面的這幅截圖中便可以看出我在 Web 服務WebServiceTest 中公開的接口了，
由于我隻在其中寫了一個接口 GetAllReader ，是以在這裡便隻顯示了一個了。
在這一步中，您便可以添加這個 Web 引用了，不過要注意的是，
如果在這一步添加 Web 引用的話，那麼這個 Web 服務中所有被公開的方法都會被添加到您的項目中，
比如，如果我在上面的 Web 服務中還有一個 GetAllName 的方法的話，
那麼在這一步添加 Web 引用的話，就會将 GetAllReader 和 GetAllName 全部添加到您的項目當中，
但是有時候，這樣會太浪費了，因為我可能根本就不需要使用 GetAllName 而隻需要 GetAllReader，
此時，可以單擊上面的 GetAllReader 進入下一步，
在這一步中添加 Web 引用的話，那麼就隻會在項目中添加 GetAllReader 這個方法的引用了，
我們在這裡使用這種方法來添加 GetAllReader 的引用。
單擊“添加引用”，此時可以看到在項目中生成一些檔案，
（這裡呢，其實就是代理模式來實作了）
既然在項目中引用了這個 Web服務了，
那麼下一步就是在 Test . aspx中使用這個 Web 服務了。
看看 Test . aspx的 Code-Behind 吧
using System;
namespace TestWebService
{
public partial class Test : System.Web.UI.Page
{
protected void Page_Load(objectsender, EventArgs e)
{
if(!IsPostBack)
{
//WebServiceTest.GetAllReader 這一段是我引用後的服務名
WebServiceTest.GetAllReader.WebServiceTesttest =
new WebServiceTest.GetAllReader.WebServiceTest();
GridView1.DataSource = test.GetAllReader();
GridView1.DataBind();
}
}
}
}
下面就來看一看效果了
從上面的效果便可以看出，我們已經成功在另外的應用程式中通路了 Web 服務，
也可以得出 Web 服務實作了在不同應用程式之間資料的共享。
如果，讀者對通過網絡 URL 來通路WebServices 有疑問的話，
可以參考一下筆者的另外一篇稍微帶有 WebServices 性質的博文，
在其中實作了一個通路網際網路上提供的天氣查詢 Web 服務。
http://www.cnblogs.com/QinBaoBei/archive/2010/03/30/1700898.html
上面呢，通過幾個 Demo 對WebServices 在 .Net 中的實戰進行了一個簡單的應用了。
在這裡一切似乎都和前面所提到的 SOAP ，WSDL，UDDI 均扯不上關系，
其實不然，隻不過這些全部都由别個（工具）給你完成了，而你隻是簡單的開發一下邏輯就 OK 了，
不過呢，簡單歸簡單，了解前面的一些原理還是很有必要的。
這裡還點一下，就是上面呢，我通過 WebServices 來查詢資料庫并且傳回一個 DataSet，
不過，大家有沒有想過，如果這個 DataSet 中的資料量有很大呢，比如 100萬條，甚至更多，
這樣的話，在網絡傳輸中那不慢的要死啊，其實有一種比較好的解決辦法，那就是壓縮，
關于壓縮呢，又有好幾種方法，比如 GZIP 可以将其壓縮到原來的一半以上，
這幾種方法各有所長，一個晚上又過咯，很晚啦，以後有時間的話，可能會寫一篇這方面的博文吧 ！！！
關于WebServices 的簡介就到這裡了 ！！！