ASP.NET WebService(一)_Web Service專案_分散式應用介紹雜記

最近才剛開始接觸  Web Service這項技術

在講Web服務之前
我們先來了解  何謂  服務????

一般你去餐廳點餐
我們可以畫出一個簡單的小關聯架構圖

你是一個去餐廳吃飯的客人
當然可能不只你一個人去
所以當中要和廚房工作廚師告知客人要點捨麼餐的就是
服務生職責
送餐的也是服務生
這就是一個比較直觀直白的所謂  服務  的概念
他是雙向的溝通模式
服務生是客人和廚房之間溝通媒介
主要會先接收客人訂單
再傳給廚房讓廚房得知要如何做餐

所謂的  Web Services 主要是一種服務(電腦提供的一種功能)

透過Web通訊協定(像HTTP、SOAP等)和藉由XML等開放式標準

標示一些位址資訊內容以提供給其他應用程式異質服務、資料交互。

此類型系統或專案之公開介面是透過XML來定義、描述

並可被其它的軟體系統所查詢的到

系統之間溝通主要靠的就是於網際網路協定中傳送 XML格式之資訊!!!!!

你可以說它是剛才餐廳的服務生
如果你是在台灣
那共同語言標準就都是用中文溝通喔!!!

英文定義:
Web Service is a series of services available over the web.
To enable communication between two applications.


(1)Server (Service Provider)
A Web Service provider develops / implements the application (web service)

and makes it available over the internet.


(2)Client (Service Consumer)
send request to Service Provider

Local端服務

在早期應用程式開發僅能存取單機的資源於單機運行

Ex: 檔案系統   、  簡單的文書處理、玩遊戲(彈珠射擊、接龍、連連看)

這就是俗稱的Local端服務

Web服務

隨著資訊科技日益更新網路盛行讓系統可以分工合作

漸漸延伸出所謂的   檔案伺服器 (File Server) 、 列印伺服器  

和  大型DataBase服務(SQL Server)、訊息系統服務(Exchange)

讓程式設計師在進行開發時可注重於自己所要的商業邏輯。

如今更進一步技術革命讓資訊技術員能夠在建置系統時

可把全世界資源都善加利用。

當中就是讓 不同分散的的應用程式可以在網際網路上 藉由 SOAP 來互相呼叫彼此。

SOAP   不是  香皂 嗎~~~~  香皂還有這麼強大用途喔!?

當然不是啦 ~~  是一種協定喔!!!! 

所謂的  SOAP  是指  Simple Object Access Protocol 於後頭我們接著介紹

檢而言之....

Web Service  主要是一種可透過Web來提供的服務
可讓應用程式之間透過web來進行溝通傳輸
提供一個標準協定/格式來進行溝通


為何要使用 Web Service呢??
有可能我們在本機所寫的程式是只能獨立運作在特定平台的
也就是所謂的 platform independent communication議題
例如一般在生產製造產業中場內一堆機台所運作的電腦
並不一定用的作業系統都是統一的

當中可能有  Linux 、 Unix 、 Windows
等等諸多平台  在細分又可能還可能有 CentOS、RedHat......
RedHat 可能還會有  ver3  ver5    ver7 ....

所以我要如何在諸多不同平台
和對不同類型轉類的應用程式

可以彼此溝通呢????交換資料、資訊???
Web Service 主要就是可以解決此問題的一個媒介

然而從企業需求面、技術面此兩層面來做更深一層探討

從企業需求角度來看
古早時期企業之間資料交換主要透過 EDI(Electronic Data Interchange)  來實踐
也就是所謂的  「電子資料交換」
不過EDI的相關系統價格都十分昂貴
不僅用特定協定及資料格式 且 維護成本也高
更不易擴充
漸漸網路興盛，高開放性架構、協定和資料格式愈來愈受到關注
Ex: TCP/IP、HTML、XML
甚至促成 一堆
企業對客戶(B2C)
企業對企業(B2B)
之電子商務熱潮
於 B2B 模式方面則 逐漸衍生成 電子交易市集(eMarketplace)商務模式

此模式由第三方提供一個交易場所（網站）
讓各商家在此地進行交易，資料輸入仍以人工作業為主
以目前各行業競爭之激烈，速度可說是勝負的關鍵

如果能夠將人工輸入資料的方式改成電腦之間自動交換資料
就可以大幅縮短企業間溝通及資料交換的時間
進而提昇企業的競爭力與反應速度(Ex:產能、測試效率)。

因此著重在應用程式與應用程式之間的互動!!!!!


技術面

以技術的角度來看為什麼需要 Web Services
我們可以從現有分散式架構有何不足做探討



目前大多數的分散式應用系統都是以遠端程序呼叫(Remote Procedure Call，RPC)的方式
存取另一台電腦上的服務

Ex：
Microsoft 的 Distributed Component Object Model(DCOM)
Sun 的 Remote Method Invocation(RMI)
OMG 的 Common Object Request Broker Architecture(CORBA) 等

這些以 RPC 為基礎的分散式架構提供了開發人員熟悉的程式撰寫方式(函數呼叫)
以及位置透明化(location transparency)的優點


但有以下幾個缺點：

緊密耦合
用戶端與伺服器程式之間要規定詳細的呼叫方式，
而且用戶端得事先知道如何存取這些服務的相關細節（例如函式有哪些參數及其型態），
伺服器這邊稍有改變可能就會令用戶端無法執行。


只能同步執行(synchronous calls)
用戶端呼叫伺服器的某個程序時，必須等該程序執行完畢之後才能繼續其他動作，
期間使用者能做的只有等待。儘管可以使用多執行緒的技巧來解決，
但卻增加了程式的複雜度，程式也比較難撰寫。
當應用程式需要以非同步的方式執行工作時，
便衍生出另一種所謂的訊息導向的架構

例如：Microsoft 的 MSMQ，IBM 的 MQSeries 等。
有別於 RPC 的程序呼叫方式，這種架構使用非同步訊息傳遞的機制，
訊息送出後用戶端便可以繼續執行其他工作，訊息保證會送達目的地，
至於何時送達則不確定，這是它最大的特色，而其缺點為：

先收到的訊息先處理（佇列）
無法提供特定工作流程（workflow）的執行順序
程式設計師必須處理訊息封包的包裝、解讀與驗證，是一項不輕的負擔。
各家廠商提供的解決方案彼此不相容。
不管是 RPC 還是訊息導向的架構，它們都有一個共同的缺點，
就是會跟特定的作業環境或軟體綁在一起，
而且各種產品使用不同的傳輸協定或資料格式，使得彼此不能相互溝通。
另外，DCOM、RMI、CORBA 等二進位協定通常會被防火牆擋在外面，
使外界無法直接存取企業內部的資訊服務，若要讓它們能夠穿過防火牆，
網管人員就必須在牆上打洞，如此勢必引發網路安全的問題，
這也是現有的分散式架構中一個比較讓人頭痛的地方。





為了解決這些問題，Web Services 便應運而生。它具有以下特點：

1. 寬鬆的（loosely-coupled）分散式架構
2. 平台中立，與實作（開發工具、程式語言）無關
3. 無狀態（stateless）
4. 提供同步與非同步的程序呼叫
5. 容易穿越防火牆

但並不是說 Web Services 就可以完全取代傳統的分散式技術，
只能說各有其適用的時機吧，在評估要使用哪一種技術來開發應用程式時，
除了瞭解技術本身的優缺點，也要確實瞭解應用程式的需求及環境的限制，
才不會發生以尖端科技製造無用軟體的情形。

Web Service 相關概念

web service 是單一建構實體可透過網路(Ex:區網)

去描述、探索、定位、呼叫的服務

是一種平台中立的 web 服務
應用程式可以透過 URL 指定存取 internet 上任何一台電腦提供的服務
不管對方的電腦是什麼作業平台  or  應用程式的類型
雙方只要遵循標準的協定就可以溝通
也是 分散式應用程式的基石

基於其跨平台且對平台中立的特性
軟體程式設計師 (工程師們)
可以將所撰寫設計好的 Web Services 公布於 Internet上
讓其他應用程式使用喔!!!!

藉此也可讓其他的開發資訊人員
可以重複使用這些現有的服務來建構分散式應用程式
就可免去重新設計相同功能的軟體功能元件

在 Web Service 體系又分為三個主要角色及在三者之間會發生的主要操作

三個主要角色:

(1)服務的 提供者(發送 Response回來給Client請求者)

(2)服務的 請求(消費)者(發送 Request給Server端也就是 服務提供者)

(3)服務的 中介者
(彼此之間使用的溝通媒介及共同語言標準
 Ex: Medium:HTTP,Internet / Format:XML/Json)

在三者之間會發生的主要操作:

1.發布(Publish)

2.查找(Find)

3.綁定(Bind)

運作流程如下：

Step1.服務提供者開發 Web Services。
Step2.服務提供者將 Web Services 佈署至伺服器環境，
           並且向服務中介者登錄其相關資訊至 UDDI 註冊資料庫中。
Step3.服務的請求者到 UDDI 註冊資料庫中搜尋所需的服務。
Step4.服務的請求者在取得 Web Services 的相關資訊後就可以使用該服務。

Web Service細項又分為

1.XML 
==> 傳遞內容格式

2.SOAP (Simple Object Access Protocol ) 
==> 跨平台傳遞訊息協定(以XML為基礎的編碼技術) 溝通內容會包裝於SOAP之中

3.WSDL (Web Service Description Language)
==> 描述服務內容(清楚知道某個Web Services 有哪些參數,各自又是捨麼型態 、方法)

4.UDDI (Universal Description, Discovery and Integration)
==>可以想成眾多服務的電話簿列表

當 Web Services 在網際網路愈來愈多時
我們就需要透過類似購物清單之類的概念存取一個註冊列表

因此前端程式會透過UDDI去找尋合適的服務(SOAP Discovery)

小工程師: 為何它沒有介面呢???

老工程師: 那是因為它是給程式和程式之間彼此溝通的阿 所以才不需要人機介面設計喔

老工程師: 古時  要自己雕刻出服務然後可經由SOAP存取

或讓應用程式可透過SOAP調用網際網路服務並不容易

因為我們要耗費非常大又複雜的功夫處理通訊協定

老工程師: 現在利用.NET  建立新  Web Service 整合開發環境會自動去處理這些繁瑣細節

會方便許多喔~~

=====================================================================

參考Link:

http://sun.cis.scu.edu.tw/~nms9115/articles/delphi/WebServices/WebServices1.htm