Web Service

web廣泛用到的技術：

TCP/IP：通用網路協議，被各種設備使用

HTML（標準通用標記語言下的一個應用）：通用用戶界面，可以使用HTML標籤顯示數據

.NET: 不同應用程序間共享數據與數據交換

Java：寫一次可以在任何系統運行的通用編程語言，因為java具有跨平台特性

XML（標準通用標記語言下的一個子集）：通用數據表達語言，在web上傳送結構化數據的容易方法

他們的特點是其開放性，跨平台性，開放性正是Web services的基礎。

近幾年來，Internet的迅猛發展使其成為全球信息傳遞與共享的巨大的資源庫。越來越多的網路環境下的Web應用系統被建立起來，利用HTML、CGI等Web技術可以輕鬆地在Internet環境下實現電子商務、電子政務等多種應用。然而這些應用可能分佈在不同的地理位置，使用不同的數據組織形式和操作系統平台，加上應用不同所造成的數據不一致性，使得如何將這些高度分佈的數據集中起來並得以充分利用成為急需解決的問題。

隨著網路技術、網路運行理念的發展，人們提出一種新的利用網路進行應用集成的解決方案——Web Service。Web Service是一種新的Web應用程序分支，其可以執行從簡單的請求到複雜商務處理的任何功能。一旦部署以後，其他Web Service應用程序可以發現並調用它部署的服務。因此，Web Service是構造分散式、模塊化應用程序和面向服務應用集成的最新技術和發展趨勢。

內容更動態化

帶寬Bandwidth更便宜，易於獲得

存儲器Storage更便宜，更易獲得

普遍式計算變得更加重要：大量的設備，例如行動電話，頁面，電腦，pc，已經在Internet上變得普遍，平台變得更多元化，像XML（標準通用標記語言下的一個子集）這樣的跨平台技術變得更重要

趨勢

上述的這些趨勢意味著，更加智能的處理，操作和匯總內容變得十分重要。讓我們看看按照Web services角度所預示的四個趨勢：

內容更加動態：一個web service必須能合併從多個不同來源的內容，可以包括股票，天氣，新聞等，在傳統環境中的內容，如存貨水平，購物訂單或者目錄信息等，都從後端系統而來；

帶寬更加便宜：web services可以分發各種類型的內容（音頻，視頻流等）；

存儲更便宜:：web services必須能聰明地處理大量數據，意味著要使用資料庫，LDAP目錄，緩衝，和負載平衡軟體等技術保持可擴展能力；

普遍式計算更重要：web services不能要求客戶使用某一版本的windows的傳統瀏覽器，必須支持各種設備，平台，瀏覽器類型，各種內容類型；

兩種重要技術

要達到這樣的目標，Web services要使用兩種技術：

XML（標準通用標記語言下的一個子集）：XML是在web上傳送結構化數據的偉大方式，Web services要以一種可靠的自動的方式操作數據，HTML（標準通用標記語言下的一個應用）不會滿足要求，而XML可以使web services十分方便的處理數據，它的內容與表示的分離十分理想；

SOAP：SOAP使用XML消息調用遠程方法，這樣web services可以通過HTTP協議的post和get方法與遠程機器交互，而且，SOAP更加健壯和靈活易用；

其他像UDDI和WSDL技術與XML和SOAP技術緊密結合用於服務發現。

Web Service平台需要一套協議來實現分散式應用程序的創建。任何平台都有它的數據表示方法和類型系統。要實現互操作性，Web Service平台必須提供一套標準的類型系統，用於溝通不同平台、編程語言和組件模型中的不同類型系統。這些協議有：

XML和XSD

可擴展的標記語言（標準通用標記語言下的一個子集）是Web Service平台中表示數據的基本格式。除了易於建立和易於分析外，XML主要的優點在於它既與平台無關，又與廠商無關。XML是由萬維網協會(W3C)創建，W3C制定的XML SchemaXSD　定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。

Web Service平台是用XSD來作為數據類型系統的。當你用某種語言如VB. NET或C#　來構造一個Web Service時，為了符合Web Service標準，所有你使用的數據類型都必須被轉換為XSD類型。如想讓它使用在不同平台和不同軟體的不同組織間傳遞，還需要用某種東西將它包裝起來。這種東西就是一種協議，如 SOAP。

SOAP

SOAP即簡單對象訪問協議(Simple Object Access Protocol)，它是用於交換XML（標準通用標記語言下的一個子集）編碼信息的輕量級協議。它有三個主要方面：XML-envelope為描述信息內容和如何處理內容定義了框架，將程序對象編碼成為XML對象的規則，執行遠程過程調用(RPC)的約定。SOAP可以運行在任何其他傳輸協議上。例如，你可以使用 SMTP，即網際網路電子郵件協議來傳遞SOAP消息，這可是很有誘惑力的。在傳輸層之間的頭是不同的，但XML有效負載保持相同。

Web Service 希望實現不同的系統之間能夠用“軟體-軟體對話”的方式相互調用，打破了軟體應用、網站和各種設備之間的格格不入的狀態，實現“基於Web無縫集成”的目標。

Web Service描述語言WSDL　就是用機器能閱讀的方式提供的一個正式描述文檔而基於XML（標準通用標記語言下的一個子集）的語言，用於描述Web Service及其函數、參數和返回值。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的。

UDDI

UDDI 的目的是為電子商務建立標準；UDDI是一套基於Web的、分散式的、為Web Service提供的、信息註冊中心的實現標準規範，同時也包含一組使企業能將自身提供的Web Service註冊，以使別的企業能夠發現的訪問協議的實現標準。

調用RPC與消息傳遞

Web Service本身其實是在實現應用程序間的通信。我們有兩種應用程序通信的方法：RPC遠程過程調用　和消息傳遞。使用RPC的時候，客戶端的概念是調用伺服器上的遠程過程，通常方式為實例化一個遠程對象並調用其方法和屬性。RPC系統試圖達到一種位置上的透明性：伺服器暴露出遠程對象的介面，而客戶端就好像在本地使用的這些對象的介面一樣，這樣就隱藏了底層的信息，客戶端也就根本不需要知道對象是在哪台機器上。

操作系統離不開豐富的應用軟體的支持。同樣，Web Service這項技術只有通過日益廣泛的應用才能體現出其價值，比較流行的實現方法是使用.NET 和 Java兩種技術，並且兩種實現方法可以互相操作；如今我們已經可以看到使用微軟、Oracle、SUN、Borland等不同廠商的Web Service構建工具建立的Web Service應用。

微軟.NET

微軟的.NET技術應該算是時下最為流行的Web Service 開發技術。首先因為其公司在以前相應的產品就佔有相當大的市場份額，以至使新推出的.NET得以有比較穩定的用戶群；其次也是更重要的是 .NET平台不僅延續了微軟一貫的編程風格，而且還增加了許多支持Web 服務的關鍵性技術，使得.NET在操作的簡單性和執行的穩定性，高效性上達到了一個非常好的結合。

微軟的Visual Studio. NET便是一個便於 Web 服務的開發工具。微軟的目標是，將其新編程語言——C#作為Web Service的首選語言。雖然C#看起來與Java類似，但是還有一些Java中沒有的獨特的功能。.NET技術中用於Web Service 開發的主要工具是ASP. NET。從技術上說，ASP. net 提供了一些超出ASP以前版本的優點(例如：代碼和HTML（標準通用標記語言下的一個應用）的分離，與腳本語言相比較，對“真正”的編程語言如 C# 的支持)。

IBM的WebSphere

IBM公司是業界第一家能夠提供全面支持Web服務的電子商務基礎設施中間件的公司。通過多年來與W3C(The World Wide Web Consortium)的共同努力，包括DB2、Lotus、Tivoli 和WebSphere在內的所有IBM軟體都實現了對SOAP、WSDL、UDDI、Linux、XML（標準通用標記語言下的一個子集）、J2EE等開放技術和標準的全面支持。

IBM公司的WebSphere也是比較好的基礎架構軟體開發平台。WebSphere軟體平台及開發工具包括WebSphere Studio Application DeveloperWSAD 基於J2EE、XML 和Web服務等開放標準，並具備 IBM 在可靠性、擴展性和安全性上的主要優勢。WebSphere 是 IBM 在 Web Services策略中的核心平台，它支持所有開發、發布、部署 Web Services應用所必需的開放標準和技術，包括 UDDI，SOAP，J2EE，WSDL，和對 XML 技術集成的增強，這使得它在全球有很多用戶。

Borland的JBuilder

Borland公司在 JBuilder7中，用戶可以用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3進行更快捷地開發Web Service和無線應用。這樣將使開發者能夠在同一個開發環境中輕鬆地創建和集成Web Service。新推出的JBuidler8更是針對Web Service開發更提供了方便和高效的方法。

總之，在Web Service開發上，.NET 和Java都是很好的選擇，儘管兩者都有一些需要完善的地方，但是它們還是最好的開發手段和技術。具體選擇哪種開發工具，也是仁者見仁，智者見智的問題。從根本上說，這兩種方法沒有孰優孰劣的問題，只是根據使用者對這兩種方法的掌握程度和對具體語言的偏愛程度來決定。

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

返回的數據就應該是這樣：

這個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

可擴展的標記語言（標準通用標記語言下的一個子集）是Web service平台中表示數據的基本格式。除了易於建立和易於分析外，XML主要的優點在於它既是平台無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟體廠商是不會選擇一個由競爭對手所發明的技術的。

XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底代表什麼？16位，32位，還是64位？這些細節對實現互操作性都是很重要的。W3C制定的XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。Web service平台就是用XSD來作為其數據類型系統的。當你用某種語言(如VB. NET或C#)來構造一個Web service時，為了符合Web service標準，所有你使用的數據類型都必須被轉換為XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你很可能會根據你的需要修改一下轉換過程。

SOAP

Web service建好以後，你或者其他人就會去調用它。簡單對象訪問協議(SOAP)提供了標準的RPC方法來調用Web service。實際上，SOAP在這裡有點用詞不當：它意味著下面的Web service是以對象的方式表示的，但事實並不一定如此：你完全可以把你的Web service寫成一系列的C函數，並仍然使用SOAP進行調用。SOAP規範定義了SOAP消息的格式，以及怎樣通過HTTP協議來使用SOAP。SOAP也是基於XML（標準通用標記語言下的一個子集）和XSD的，XML是SOAP的數據編碼方式。

WSDL

你會怎樣向別人介紹你的Web service有什麼功能，以及每個函數調用時的參數呢？你可能會自己寫一套文檔，你甚至可能會口頭上告訴需要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web service的時候，他們的工具(如Visual Studio)無法給他們提供任何幫助，因為這些工具根本就不了解你的Web service。

解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web service描述語言(WSDL)就是這樣一個基於XML（標準通用標記語言下的一個子集）的語言，用於描述Web service及其函數、參數和返回值。WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼。

UDDI

Universal Description, Discovery and Integration

為加速Web Service的推廣、加強Web Service的互操作能力而推出的一個計劃，基於標準的服務描述和發現的規範(specification)。

以資源共享的方式由多個運作者一起以Web Service的形式運作UDDI商業註冊中心。

UDDI計劃的核心組件是UDDI商業註冊，它使用XML文檔來描述企業及其提供的Web Service。

UDDI商業註冊提供三種信息：

White Page包含地址、聯繫方法、已知的企業標識。

Yellow Page包含基於標準分類法的行業類別。

Green Page包含關於該企業所提供的Web Service的技術信息，其形式可能是指向文件或URL的指針，而這些文件或URL是為服務發現機制服務的。

Web Service開發實例

利用WebService實現數據添加

利用WebService實現數據刪除

利用WebService給手機發簡訊

適合使用Web Service的情況

跨越防火牆；

應用程序集成；

B2B集成；

軟體重用

不適合使用Web服務的情況

單機應用程序；

區域網上的同構應用程序