典型的Web Service結構

典型的Web Service結構 

不管你的Web service是用什么工具，什么語言寫出來的，只要你用SOAP協議通過HTTP來調用它，總體結構都應如下圖所示。 

通常，你用你自己喜歡的語言(如VB 6或者VB.NET)來構建你的Web service，然后用SOAP Toolkit或者.NET的內建支持來把它暴露給Web客戶。于是，任何語言，任何平臺上的客戶都可以閱讀其WSDL文檔，以調用這個Web service?？蛻舾鶕SDL描述文檔，會生成一個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調用一個遠程對象，你的代碼看起來就與調用本地對象一樣。而消息傳遞則不同，它強調傳遞的東西是什么，但不管消息傳遞過去后干什么?？蛻舨恍枰婪掌魇窃趺磳崿F的，以及消息是怎么被處理的。
我們已經說過，你可以建立一個消息服務器，根據收到的消息來調用對象。這是通過消息傳遞方式有效的實現了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 

原文轉自：http://www.kjueaiud.com