Web Services的簡單介紹

來源:互聯網
上載者:User
services|web Web Services 是網格服務的基礎, 也是OGSA和IOGSI的奠基石(GT3). 理解WebService的架構是使用GT3,編寫網格服務的基礎。
  最近 有很多關於"Web Services"的議論並且許多公司也開始為他們的公司專屬應用程式作出反應。那麼,Web Services究竟是什嗎?簡單的說,他們是另一個分布計算技術(像CORBA, RMI, EJB等等),容許我們建立用戶端/服務端應用。
  舉個例子,讓我們假設我不得不為一個連鎖店開發一個程式。這家連鎖店分布在全國各地,但是我的產品主目錄(master catalog of product)只存放在我的中心辦公室的資料庫中,並且分店的軟體必須能夠訪問這個產品目錄.我可以通過一個被稱為ShopService的Web Service 來發布這些目錄。

  重要的是:在網站上發布的時候不能出錯。在網站上的資訊(像你正在讀到的一樣)是為人編寫的。而在Web Service上的資訊可以被軟體訪問,並不時直接被人訪問(儘管存在人用這個軟體的可能)。雖然Web Service 很大程度上依賴現有的Web技術(像我們正在看到的HTTP),但他們和Web瀏覽器與HTML沒有聯絡。我們再重複一遍: 網站是為人服務的,而Web Service 是為軟體服務的 :-)

  用戶端(在商店的PC)在那個時候將要串連(伺服器上的)WebService,並發送一個需要目錄的服務要求。伺服器將會通過一個服務響應返回目錄資訊。當然這是一個描述Web Service如何工作的非常潦草的例子。等一下,我們將會看到一個非常詳細的解釋。


  我們中的一些人可能會這麼想:"嘿,等一下!我可以通過RMI,CORBA,EJBs,等很多其他技術來實現啊!"。那麼。為什麼還要Web Service? 好的,Web Service 也有很多優於其他技術的地方:

Web Service由於使用標準的XML語言因而是平台無關、語言無關的,這就意味著我們的用戶端可以用C++編寫在windows下運行,而Web Service使用Java編寫而運行在linux下
大部分Web Service 使用HTTP傳輸訊息(像服務要求和響應)。如果你想建立一個Internet範圍的程式,這是一個主要的優點,因為大部分Internet's的代理和防火牆都不會破壞HTTP的傳輸(不像CORBA會在穿過防火牆時遇到麻煩)

當然了,Web Service也存在以下一些缺點:

壓力過大。很明顯所有在XML中的資料沒有定義好的二進位代碼效率高。在你贏得通用性的同時降低了效率。儘管那樣,這個壓力通常是可以被大部分應用程式所接受的,


用途狹窄。目前,由於他們只支援很基本的服務種類,所以Web Service 的用途不是很多。例如CORBA提供給編程者很多正在支援的服務(像持續服務,通知,生命週期管理,轉換等等)。事實上,在下一頁我們可以看到網格服務可以真正的補償了用途狹窄的缺點。
  然而,分布式的Web Service有一個很重要的特點。像CORBA和EJB技術是面向關係緊密的分布式系統的,它們的用戶端和服務端彼此非常依賴。但Web Services是面向鬆散關係的系統,用戶端可以直到真正調用web service才知道Web Service的知識,例如基於網格的應用。

一個典型的Web Service的調用
  這些都是如何工作的呢?讓我們看一下一個完整的Web Service調用的全部的調用步驟。現在還不要擔心那些縮寫詞(SOAP,WSDL,...),等一下我們將會詳細的解釋它們。







正如我們前面所說的,一個用戶端可以不知道Web Service是如何調用的.所以我們第一步是尋找滿足我們要求的Web Servicede 的位置,例如我們想要找一個可以告訴我們美國城市溫度的Web Service。我們可以通過與UDDI註冊點聯絡得到Web Service的位置。
UDDI註冊器將會返回告訴我們哪個伺服器可以提供給我們我們想要的服務(像美國城市的溫度)
我們現在知道Web Service的位置了,但我們還不知道如何使用它。我們確實知道它可以給我們美國城市的溫度,但是真是的服務是如何調用的呢?我們調用的方法可能被稱為Temperature getCityTemperature(int CityPostalCode),但是它也可以是
int getUSCityTemp(string cityName, bool isFarenheit).我們必須問Web Service 如何描述自己。(告訴我們如何使用它)
用被稱為WSDL的語言返回資訊。
我們終於知道Web Service的位置和如何調用它。調用方法是通過SOAP來實現的。那樣我們就發送SOAP請求要求一個城市的溫度。
Web Service 將會溫和的返回一個包含我們想要的溫度的SOAP響應,或者是當我們的請求資訊錯誤時返回一個錯誤資訊。

Web Service的定址
  我們剛剛看到了一個簡單Web Service的調用過程。在一點上UDDI註冊服務"告訴"了用戶端Web Service的位置。但是....如何準確的定址Web Service?這個答案非常的簡單:就像我們的網頁。我們使用樸素而簡單的URIs(Uniform Resource Identifiers)。如果你熟悉 URL (Uniform Resource Locator)這個名詞的話,那就不要擔心:URI和URL事實上是同一樣東西。

例如UDDI註冊服務期可能會返回如下 URI:

http://webservices.mysite.com/weather/us/WeatherService

   這個很容易被認為是一個網頁的地址。然而Web Service 是通過軟體來記住這個地址的(不再是讓人直接記住)。如果你寫一個Web Service的URI進你的Web瀏覽器,你可能會的到一個錯誤資訊或者是難以理解的代碼(一些Web Service 會顯示給你一個漂亮的介面,但是這個介面和通常的不一樣)。當你擁有一個Web Service 的URI時,你通常需要將這個URI交給一個程式。事實上,我們寫的大部分的用戶端程式都會把網格服務URI作為一個命令參數來接收。

Web Services 的架構
  現在我們已經看到了在Web Service調用過程中的不同活動者,讓我們來更清楚地瞭解Web Service的架構吧!


Service Discovery: 這部分容許我們尋找滿足需要的Web Service。這部分通常由UDDI(Universal Description, Discovery, and Integration)來處理。GT3目前不支援UDDI.


Service Description: Web Service最有趣特點之一就是他們能夠自我描述。這意味著一旦你定位了Web Service,你能要求他"描述自己"並告訴你如何操作和使用它。這是通過Web Services Description Language (WSDL)來處理的


Service Invocation: 調用一個Web Service(和一般的任何類似CORBA對象或者Enterprise Java Beand的分布式服務)的過程中包含在用戶端與服務端之間傳輸的資訊。SOAP (Simple Object Access Protocol)規範了我們如何格式化送往伺服器的請求資訊和如何格式化伺服器本身的響應資訊。在理論上,我們還可以使用其它調用語言(例如XML_RPC或者 even some ad hoc XML language).然而,SOAP是Web Service更樂意的選擇。


Transport: 最後,這些所有的資訊可以在服務端和用戶端之間傳輸。架構這部分選擇的協議是HTTP(HyperText Transfer Protocol),與訪問Internet上的普通網頁的協議相同!在理論上我們仍然能使用其他協議,但HTTP協議是目前使用最廣泛的了。
Web Service 應用看起來是什嗎?
  OK,你現在對什麼是Web Service已經有了一個概念了,你可能可望立刻開始編寫Wev Service.在你這麼做之前,你可能像直到基於Web Service的應用程式的結構式什麼樣的。如果你曾經編寫過CORBA或者RMI,這個結構會看起

  首先,你應該知道儘管存在很多協議和在周圍浮現的眾多語言,Web Service 編程者通常不用寫一行SOAP或者WSDL的代碼。一旦我們到了我們的用戶端需要調用一個Web Service那一刻時,我們授權給軟體中一塊叫本地stub(a client stub)的任務。好訊息是有很多可以利用的工具為我們自動產生基於WSDL的Web Service描述的本地stub(a client stub)。

  這樣你不需要逐字地解釋"典型的調用"對話過程。一個Web Service用戶端通常不會在一個調用過程中經過所有步驟。一個更正確的事件流程如下:

我們通過UDDI定位一個滿足我們需要的Web Service。
我們獲得關於這個Web Service的WSDL描述。
我們產生stub,然後在我們的應用程式中包含它們。
這個應用程式會在每次調用Web Service 時使用stub。
  服務端的編程比較容易。我們不用必須寫一個複雜的需要動態解釋SOAP請求和產生SOAP響應的服務程式,我們能簡單的實現我們Web Service的所有功能,然後產生一個伺服器stub(the term skeleton is also used),這個stub負責解釋請求然後將這些請求轉交給伺服器的實現部分。當伺服器實現部分包含一個結果時,它將會把這個結果交給伺服器stub,這樣就產生了合適的SOAP響應。這個伺服器stub還能通過WSDL描述產生,或者從其他語言(像IDL)定義的介面。此外的是伺服器實現和伺服器stub都通過軟體中被稱為Web Service容器的代碼來管理,這個容器會確保提交給Web ServviceHTTP請求直接交給伺服器stub。

下圖描述了調用一個Web Service的步驟。



我們來假設我們的用戶端已經定位了Web Service,從WSDL描述產生了用戶端stub,並且服務端程式也產生了服務端stub。

無論用戶端什麼時候需要調用Web Service,它都需要調用用戶端stub。這個用戶端stub會將這個本地調用轉換為合適的SOAP請求。這步經常被稱為編組過程(marshalling process).
SOAP請求使用HTTP協議通過網路發送出去。Web Service容器接收到SOAP的請求後將它交給伺服器stub。伺服器stub把SOAP請求轉換伺服器實現程式能夠理解的形式。這步經常被稱為解散。
伺服器實現部分收到從伺服器stub轉來的請求後,執行所請求的工作。例如我們調用了 int add(int a, int b) 方法,伺服器實現執行加法功能。
執行請求的結果由伺服器stub處理轉換為SOAP響應。
SOAP響應使用HTTP協議通過網路發送。用戶端stub收到SOAP響應並將它轉換為用戶端應用可以理解的形式。
最終用戶端應用接受到調用Web Service的結果並使用這個結果。


相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。