1. 程式人生 > >Web Service的概念及其實現

Web Service的概念及其實現

你可能早就聽說過Web service了,你也可能已經對Web service有一些概念了。一時間,好像所有的計算機期刊、書籍和網站都開始提及Web service。然而,當前大多數對Web service的介紹都沒能清楚的說明Web service到底是什麼。他們只是鼓吹Web service是多麼多麼的好,簡直就像是在做廣告。在本文中會講清楚兩件事:Web service到底是什麼;在什麼情況下你應該使用Web service。

分散式應用程式和瀏覽器
研究一下當前的應用程式開發,你會發現一個絕對的傾向:人們開始偏愛基於瀏覽器的瘦客戶應用程式。這當然不是因為瘦客戶能夠提供更好的使用者介面,而是因為它能夠避免花在桌面應用程式釋出上的高成本。釋出桌面應用程式成本很高,一半是因為應用程式安裝和配置的問題,另一半是因為客戶和伺服器之間通訊的問題。 
傳統的Windows富客戶應用程式使用DCOM來與伺服器進行通訊和呼叫遠端物件。配置好DCOM使其在一個大型的網路中正常工作將是一個極富挑戰性的工作,同時也是許多IT工程師的噩夢。事實上,許多IT工程師寧願忍受瀏覽器所帶來的功能限制,也不願在區域網上去執行一個DCOM。在我看來,結果就是一個釋出容易,但開發難度大而且使用者介面極其受限的應用程式。極端的說,就是你花了更多的資金和時間,卻開發出從使用者看來功能更弱的應用程式。不信?問問你的會計師對新的基於瀏覽器的會計軟體有什麼想法:絕大多數商用程式使用者希望使用更加友好的Windows使用者介面。
關於客戶端與伺服器的通訊問題,一個完美的解決方法是使用HTTP協議來通訊。這是因為任何執行Web瀏覽器的機器都在使用HTTP協議。同時,當前許多防火牆也配置為只允許HTTP連線。 
許多商用程式還面臨另一個問題,那就是與其他程式的互操作性。如果所有的應用程式都是使用COM或.NET語言寫的,並且都執行在Windows平臺上,那就天下太平了。然而,事實上大多數商業資料仍然在大型主機上以非關係檔案(VSAM)的形式存放,並由COBOL語言編寫的大型機程式訪問。而且,目前還有很多商用程式繼續在使用C++、Java、Visual Basic和其他各種各樣的語言編寫。現在,除了最簡單的程式之外,所有的應用程式都需要與執行在其他異構平臺上的應用程式整合並進行資料交換。這樣的任務通常都是由特殊的方法,如檔案傳輸和分析,訊息佇列,還有僅適用於某些情況的的API,如IBM的"高階程式到程式交流(APPC)"等來完成的。在以前,沒有一個應用程式通訊標準,是獨立於平臺、組建模型和程式語言的。只有通過Web Service,客戶端和伺服器才能夠自由的用HTTP進行通訊,不論兩個程式的平臺和程式語言是什麼。

什麼是Web Service
對這個問題,我們至少有兩種答案。從表面上看,Web service 就是一個應用程式,它向外界暴露出一個能夠通過Web進行呼叫的API。這就是說,你能夠用程式設計的方法通過Web來呼叫這個應用程式。我們把呼叫這個Web service 的應用程式叫做客戶。例如,你想建立一個Web service ,它的作用是返回當前的天氣情況。那麼你可已建立一個ASP頁面,它接受郵政編碼作為查詢字串,然後返回一個由逗號隔開的字串,包含了當前的氣溫和天氣。要呼叫這個ASP頁面,客戶端需要傳送下面的這個HTTP GET請求:
http://host.company.com/weather.asp?zipcode=20171

返回的資料就應該是這樣:
21,晴

這個ASP頁面就應該可以算作是Web service 了。因為它基於HTTP GET請求,暴露出了一個可以通過Web呼叫的API。當然,Web service 還有更多的東西。
下面是對Web service 更精確的解釋: Web services是建立可互操作的分散式應用程式的新平臺。作為一個Windows程式設計師,你可能已經用COM或DCOM建立過基於元件的分散式應用程式。COM是一個非常好的元件技術,但是我們也很容易舉出COM並不能滿足要求的情況。
Web service平臺是一套標準,它定義了應用程式如何在Web上實現互操作性。你可以用任何你喜歡的語言,在任何你喜歡的平臺上寫Web service ,只要我們可以通過Web service標準對這些服務進行查詢和訪問。

新平臺
Web service平臺需要一套協議來實現分散式應用程式的建立。任何平臺都有它的資料表示方法和型別系統。要實現互操作性,Web service平臺必須提供一套標準的型別系統,用於溝通不同平臺、程式語言和元件模型中的不同型別系統。在傳統的分散式系統中,基於介面(interface)的平臺提供了一些方法來描述介面、方法和引數(譯註:如COM和COBAR中的IDL語言)。同樣的,Web service平臺也必須提供一種標準來描述Web service,讓客戶可以得到足夠的資訊來呼叫這個Web service。最後,我們還必須有一種方法來對這個Web service進行遠端呼叫。這種方法實際是一種遠端過程呼叫協議(RPC)。為了達到互操作性,這種RPC協議還必須與平臺和程式語言無關。下面幾個小節就簡要介紹了組成Web service平臺的這三個技術。

XML和XSD
可擴充套件的標記語言(XML)是Web service平臺中表示資料的基本格式。除了易於建立和易於分析外,XML主要的優點在於它既是平臺無關的,又是廠商無關的。無關性是比技術優越性更重要的:軟體廠商是不會選擇一個由競爭對手所發明的技術的。
XML解決了資料表示的問題,但它沒有定義一套標準的資料型別,更沒有說怎麼去擴充套件這套資料型別。例如,整形數到底代表什麼?16位,32位,還是64位?這些細節對實現互操作性都是很重要的。W3C制定的XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的資料型別,並給出了一種語言來擴充套件這套資料型別。Web service平臺就是用XSD來作為其資料型別系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時,為了符合Web service標準,所有你使用的資料型別都必須被轉換為XSD型別。你用的工具可能已經自動幫你完成了這個轉換,但你很可能會根據你的需要修改一下轉換過程。在第二章中,我們將深入XSD,學習怎樣轉換自定義的資料型別(例如類)到XSD的型別。

SOAP
Web service建好以後,你或者其他人就會去呼叫它。簡單物件訪問協議(SOAP)提供了標準的RPC方法來呼叫Web service。實際上,SOAP在這裡有點用詞不當:它意味著下面的Web service是以物件的方式表示的,但事實並不一定如此:你完全可以把你的Web service寫成一系列的C函式,並仍然使用SOAP進行呼叫。SOAP規範定義了SOAP訊息的格式,以及怎樣通過HTTP協議來使用SOAP。SOAP也是基於XML和XSD的,XML是SOAP的資料編碼方式。第三章我們會討論SOAP,並結識SOAP訊息的各種元素。

WSDL
你會怎樣向別人介紹你的Web service有什麼功能,以及每個函式呼叫時的引數呢?你可能會自己寫一套文件,你甚至可能會口頭上告訴需要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題:當程式設計師坐到電腦前,想要使用你的Web service的時候,他們的工具(如Visual Studio)無法給他們提供任何幫助,因為這些工具根本就不瞭解你的Web service。解決方法是:用機器能閱讀的方式提供一個正式的描述文件。Web service描述語言(WSDL)就是這樣一個基於XML的語言,用於描述Web service及其函式、引數和返回值。因為是基於XML的,所以WSDL既是機器可閱讀的,又是人可閱讀的,這將是一個很大的好處。一些最新的開發工具既能根據你的Web service生成WSDL文件,又能匯入WSDL文件,生成呼叫相應Web service的程式碼。