【樂】不可知

IT滴滴答答......

2012-07-18

Web Service & SOA & REST

  • 19769
  • 0
  • C#
  • 2012-07-19

Web Service & SOA & REST

Web Services

存在於Web上的服務(Service)

基於HTTP互相呼叫處理程序、使用開放式標準格式XML傳遞資訊的應用程式。

應用程式可以透過URL指定存取internet上任何一台電腦提供的服務，不管對方的電腦是甚麼作業平台或應用程式的類型，雙方只要遵循標準的協定就可以溝通、交換資料。

Web Service 為一可透過 URL來標示位置的軟體系統，此系統的公開介面是透過XML來定義與描述，並可被其它的軟體系統所查詢。

而這些系統間的溝通，是在網際網路的通訊協定上傳送以XML為格式的資訊。

很繞口吧！簡言之，Web Service是在網際網路上提供其它程式或系統呼叫使用的程式，而這些程式間用XML做為其溝通媒介。

#分散式應用程式的基石:可重覆使用的軟體元件，也可以使用其他現有的服務，無須花時間重新設計相同功能的軟體元件。

資料交換與資料傳遞在網際網路與企業之間是非常重要的，然而資料的計算與處理卻不容易在複雜的網路環境中實行。但是將服務包裝成 Web Service 之後，便能夠輕易地解決在網路架構中進行資料的處理與交換。
Web Service 為在 HTTP 通訊協定上所提供了標準化的介面，稱為網路資訊服務計算技術，目前主流以 XML、WSDL、SOAP、UDDI 為基礎。透過這些標準化的協定將能夠輕易地實現各種功能，並且將不同的系統透過 HTTP 互相溝通，達到資料交換與資料共享的優勢，也是發展為分散處理的途徑之ㄧ。

目前主流的 SOAP 技術雖然已經相當完善，但是卻面臨開發的門檻過高且功能的複雜性較高等等缺點。基於這樣的因素使用了更精簡的開發方式來實做 Web Service 會是更好的實行方法，並且在資料傳遞格式上提供更多元的種類，除了廣泛使用的 XML 之外也提供了更為精簡的 JSON 格式，為進行 Web 設計的使用者提供更快速的整合方式。對於系統架構與設計方式，採用 MVC 軟體架構進行設計，並且將物件導向與物件封裝提升到最完善的處裡模式。在資料的儲存中採用 ORM 技術來連接資料庫，此外也將 Web Service 設計為 REST 風格，如此更能輕易地進行分散處理，並且獲得更精簡與更快速的執行效率。

 

Web Service 是一種軟體元件，他透過Web 通訊協定及資料格式的開放式標準(EX: HTTP、XML、SOAP、UDDI、WSDL)來為其他應用程式提供服務。

根據這個定義我們可以發現幾個重點，

第一:   Web 通訊協定(HTTP。

第二:  資料格式的標準(XML、SOAP、JSON)

Web Services的價值。:
作為提供服務的元件，它可用來建構分散式架構系統，實現分散式架構動態整合、平衡負擔、單元升級等優點。
以Web的開放標準為基礎，在已經廣被使用的Web網路架構上來運作，採用開放式標準讓Web Services具有良好互通性，在不同平台上用不同程式語言建置的系統也可以輕易整合，克服目前分散式系統各自使用不同機制造成整合困難的情形。

v1v3

v2

 

直接看國外也有很多提供免費Web Servcie 的網站  http://www.webservicex.net ，上去逛逛就會對Web Service 比較有畫面

v8

Web Services 特色：

 

  • 寬鬆的分散式架構
  • 平台中立，與實作無關(開發工具、程式語言)
  • 無狀態(Stateless)
  • 提供同步與非同步的程序呼叫
  • 容易穿越防火牆(使用HTTP協定 Port:80)

 

 

Web Services的重要標準：

(Web Services運作還需要更多基礎，以下這些都是以XML為基本語法建立的重要標準。)

 


WSDL (Web Service Description Language)：

描述一個Web Services的運作方式，以及指示用戶端與它可能的互動方式。

WSDL 是一份以 XML 撰寫的文件，附檔名就是 .WSDL，其主要的用途是「描述 Web Services」，也就是讓用戶端知道如何使用 Web Services。WSDL 的文件內容也有一個共同的標準，以便與各種用戶端應用程式相互整合，此標準是由 IBM 與 Microsoft 共同研擬。

v7


SOAP (Simple Object Access Protocol)：

        1.在網路上交換結構化和型別資訊的一種簡易通訊協定。

        2.一個基於XML的可擴展消息信封格式，需同時綁定一個傳輸用協議。這個協議通常是HTTP或HTTPS，但也可能是SMTP或XMPP。

        3.架構在XML之上，是一種架構簡單的輕量級資料傳輸協定，用於分散式網路環境下做資料訊息交換，只要訊息收送雙方都支援此協定，就可以彼此交談，這也正是Web Service想要突破平台、語言疆界的最佳利器。

SOAP 是架構在 HTTP 之上的物件存取協定，也就是說透過 HTTP 來傳遞訊息，而訊息的內容則是以 XML 格式來描述。當用戶端程式需要呼叫一個遠端物件的方法時，可以把這項要求封裝成 SOAP 呼叫傳遞給遠端的 Web Services，當 Web Services 收到了用戶端的請求便去執行其指定的方法，並且在執行完畢之後傳回結果。因此也可以說 SOAP 就是 internet 上面的 RPC。

相較於傳統的 RPC，SOAP 不但是個被業界所支援的公開標準，還具有容易穿透防火牆的優點，使遠端程序呼叫得以順利跨越不同的網域。SOAP 之可以順利穿透防火牆，是由於其搭載的純文字訊息是透過 HTTP 協定來傳輸，而大部分的企業網路的防火牆都會開放 HTTP 使用的 80 埠的緣故。

SOAP的出現是為了簡化網頁伺服器（Web Server）在從XML數據庫中提取資料時，無需花時間去格式化頁面，並能夠讓不同應用程式之間透過HTTP通訊協定，以XML格式互相交換彼此的資料，使其與程式語言、平台和硬體無關。

簡單的例子來說明 SOAP 使用過程，一個 SOAP 訊息可以發送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價資訊的資料庫，訊息的參數中標明這是一個查詢訊息，此站點將返回一個 XML 格式的資訊，其中包含了查詢結果（價格，位置，特點，或者其他資訊）。

以貨幣匯率為例

SOAP1.1

v9

SOAP1.2

v10

GET & POS

v11

Web Service Discovery：

WSDL 是在你已經確定要使用某個 Web Service 並且知道其網址的情形下才有用，萬一你不知道哪裡有你需要的 Web Services 怎麼辦？例如，你的應用程式現在要加入一項功能，可以讓使用者輸入特定關鍵字找尋相關的 MP3 檔案的下載網址，這時候你要去哪裡找這類 Web Services？

Disco 的用途就在這裡，就像電話簿和搜尋引擎網站一樣，提供資訊分類以及尋找的服務，讓你可以方便快速地找到你需要的 Web Services。

其運作原理是，當開發人員將一個 Web Service 設計完成之後，可以將它登錄到一個集中的地方，其他人就可以向這個集中地查詢找到需要的服務。這個登錄－查詢的機制只要就是依靠 UDDI（Universal Description, Discovery and Integration）來達成。

 

UDDI (Universal Description Discovery and Integration)：

提供註冊與搜尋Web Service資訊的一個標準。

UDDI 是一種目錄服務，企業可以使用它對 Web services 進行註冊和搜索。

什麼是 UDDI？

UDDI 是一個獨立於平台的框架，用於通過使用 Internet 來描述服務，發現企業，並對企業服務進行集成。

  • UDDI 指的是通用描述、發現與集成服務
  • UDDI 是一種用於存儲有關 web services 的信息的目錄。
  • UDDI 是一種由 WSDL 描述的 web services 界面的目錄。
  • UDDI 經由 SOAP 進行通信
  • UDDI 被構建入了微軟的 .NET 平台

UDDI官網

 

Web Service 方式：

 

RPC (Remote Procedure Call) 遠端程序呼叫：

WEB服務提供一個分布式函數或方法介面供用戶呼叫，這是一種比較傳統的方式。通常，在WSDL中對RPC介面進行定義（類似於早期的XML-RPC）。

儘管最初的WEB服務廣泛採用RPC方式部署，但針對其過於緊密之耦合性的批評聲也隨之不斷。這是因為RPC式WEB服務實質上是利用一個簡單的映射，以把用戶請求直接轉化成為一個特定語言編寫的函數或方法。如今，多數服務提供商認定此種方式在未來將難有作為，在他們的推動下，WS-I基本協議集（WS-I Basic Profile）已不再支持遠端程序呼叫。

 

SOA (Service-oriented architecture) 服務導向架構：

現在，業界比較關注的是遵從面向服務架構（Service-oriented architecture，SOA）概念來構築WEB服務。在面向服務架構中，通訊由消息驅動，而不再是某個動作（方法呼叫）。這種WEB服務也被稱作面向消息的服務。

SOA式WEB服務得到了大部分主要軟體供應商以及業界專家的支持和肯定。作為與RPC方式的最大差別，SOA方式更加關注如何去連接服務而不是去特定某個實現的細節。WSDL定義了聯絡服務的必要內容。

SOA 是一種架構模型，由網站服務技術等標準化元件組成，目的是為企業、學校或提供網路服 務單位建構一個具彈性、可重複使用的整合性介面。服務導向架構的好處為系統可重用性高、彈性大，功能可以輕易地堆疊成更上層的功能。藉此大幅降低系統之間 的耦合性與打散相互的依賴關係。SOA 可以透過 Web Service 的實做來達成目的，使用開放且標準的通訊協定能夠快速的整合不同的系統，亦能藉由服務之間的調用來組成新的服務，大幅降低程式開發的時間。

SOA服務導向架構是一種新興的系統架構模型，主要概念是針對學校或企業需求組合而成的一組軟體元件。組合的元素通常包括：軟體元件、服務及流程三個部份。當學校或企業面對外部要求時，流程負責定義外部要求的處理步驟；服務包括特定步驟的所有程式元件，而軟體元件則負責執行工作的程式。SOA 已成為現今軟體發展的重要技術，透過 SOA 讓異質系統整合變得容易，程式再使用度也提高。不必自行開發或擁有所有程式元件，發展者可以視其需要組合網路上最好的服務。不受限於特定廠商的產品功能或是平台，達到真正的開放性(Openness)。從分散式元件架構到 SOA概念上，SOA 如同物件導向、軟體元件等軟體技術一般，運用小的零組件組合成應用系統。但 SOA 強調的是如何將彼此關係鬆散的應用系統功能元件在網路上發行、組合及使用。

SOA 具有下列技術特性：

  1. 分散式架構 (distributed)－SOA 的組成元件是由許多分散在網路上的系統組合而來，可能是區域網路，也可能是來自廣域網路。例如網站服務技術 (web services) 就是運作 HTTP來相互連結的 SOA。如此的作法，也使得網站服務技術很快的就成為所有支援網際網路的系統平台均能使用的技術。

  2. 關係鬆散的界面 (loosely coupled)－傳統的系統主要是將應用系統功能需求切割成相互關聯的小零組件：模組、物件或元件，發展者要花費極大的心力了解零組件是如何設計及使用，以確保不會違反零組件連接關係限制。如此一來，若要以不同零組件替換原始設計，就成為一件困難的事。SOA 的作法是以界面標準來組合系統，只要符合界面要求，零組件可以任意替換，大幅提高系統變更的彈性度。

  3. 依據開放的標準 (Open standard)－使用開放標準是 SOA 的核心特色，過去的軟體元件平台如 CORBA、DCOM、RMI、J2EE 採用專屬協定作為元件連結的規範，使得不同平台的元件無法相通。SOA 則著重於標準與互動性，將可避免不同平台 (.NET web services 與 Java web services) 開發程式間相互整合的困擾。

  4. 以流程角度出發 (process centric)－在建構系統時，首先了解特定工作的流程要求，並將其切割成服務界面(包括輸入與輸出資料格式)，如此其他的發展者就可以依據服務界面開發 (或選擇) 合適的元件來完成工作

 

REST (Representational State Transfer) 表徵狀態轉移：

REST 從資源的角度來觀察整個網路，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表徵。獲得這些表徵致使這些應用程序轉變了其狀態。隨著不斷獲取資源的表徵，客戶端應用不斷地在轉變著其狀態，所謂表徵狀態轉移（Representational State Transfer）。

REST是設計風格而不是標準。REST通常基於使用HTTP，URI，和XML以及HTML這些現有的廣泛流行的協議和標準。

v5

  • 資源是由URI來指定。
  • 對資源的操作包括獲取、修改、創建和刪除資源，這些操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法。
  • 通過操作資源的表現形式來操作資源。
  • 資源的表現形式則是XML或者HTML，取決於讀者是機器還是人，是消費web服務的客戶軟體還是web瀏覽器。當然也可以是任何其他的格式。
REST的要求
  • 客戶端和伺服器結構
  • 連接協議具有無狀態性
  • 能夠利用Cache機制增進性能
  • 層次化的系統
  • 隨需代碼 - Javascript （可選）
關於狀態

應該注意區別應用的狀態和連接協議的狀態。REST對於連接的無狀態性實際上要求每次經過無狀態的連接協議傳送的信息必須包含應用中所有的狀態信息。.

REST這個字眼常常看到，儘管他是Dr. Roy Fielding在2000年時候就提出的，但是我想真正開始紅起來，是因為Amazon和Yahoo都開始拋棄Web Service改提供REST形式的服務

REST就本身而言不是一種技術，而是一種架構網要。is not really a technology in itself, but more an architectural pattern. REST非常簡單，以普通XML或JSON作為通信機制，結合可以表現底層系統狀態的URL形式和 HTTP方法如 GET, PUT, POST和 DELETE.

每一個HTTP方法映射到一個action，如用GET方法獲取資料，用PUT方法創建資料，用POST更新資料等等。在這個意義上 REST非常適合 CRUD (Create、Read、Update、Delete)

 

如果想從語言上來看REST，就從Ruby on Rails ，ROR對RESTful貢獻極大

HTTP Method:

HTTP/1.1協議中共定義了八種方法（有時也叫「動作」）來表明Request-URI指定的資源的不同操作方式：

OPTIONS
返回伺服器針對特定資源所支持的HTTP請求方法。也可以利用向Web伺服器發送'*'的請求來測試伺服器的功能性。
HEAD
向伺服器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
GET
向特定的資源發出請求。注意：GET方法不應當被用於產生「副作用」的操作中，例如在Web Application中。其中一個原因是GET可能會被網路蜘蛛等隨意訪問。參見安全方法
POST
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT
向指定資源位置上傳其最新內容。
DELETE
請求伺服器刪除Request-URI所標識的資源。
TRACE
回顯伺服器收到的請求，主要用於測試或診斷。
CONNECT
HTTP/1.1協議中預留給能夠將連接改為管道方式的代理伺服器。

方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，伺服器應當返回狀態碼405（Method Not Allowed）；當伺服器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。

HTTP伺服器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支持的實現都應當符合下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP伺服器還能夠擴展自定義的方法。

 

微軟相關技術:

ADO.NET Data Service –> RESTful WCF

情境說明：

Q1: 應用程式如何透過Internet逐行遠端程序呼叫，而且不用知道對方作業環境與應用程式型態?

A1:需要一個標準的資訊格式以便可以順利地在各平台之間傳遞。所以透過SOAP傳遞訊息的格式。

 

Q2:用戶端如何知道怎樣使用某個Web Service? 或者說，如何得知該服務的介面(提供哪些方法呼叫)?

A2:需要一個描述Web Services的文件，用戶端可以透過解讀這個文件來了解如何使用它。所以利用WSDL來描述服務內容。

 

時代演進:

XML -> XML-RPC –> Web Service 三劍客(WSDL、SOAP、UDDI)  -> REST (又稱 REST-like) –> RESTful (4種HTTP Method)

資料格式:

XML –> JSON  

XML: 結構完整，速度慢，應用:資料交換。

JSON: 結構不完整，速度快，應用:手機最多。

歷史包袱：

EDI(Electronic Data Interchange) 電子資料交換:

XML-RPC :是一個遠程過程調用（遠端程序呼叫）（remote procedure call，RPC)的分布式計算協議，通過XML將調用函數封裝，並使用HTTP協議作為傳送機制[1]。

RPC (Remote Procedure Call）遠程過程調用 : 一個計算機通信協議。該協議允許運行於一台計算機的程序調用另一台計算機的子程序，而程式設計師無需額外地為這個交互作用編程。如果涉及的軟體採用物件導向編程，那麼遠程過程調用亦可稱作遠程調用或遠程方法調用。

 

相關連結:

資策會WebService介紹

服務導向架構 簡介-台灣科技大學

 

說真的，只是把大量的資料整理一下，我也不知道是從哪裡抄來的，如有侵權請告知。