話說天下大事
分久必合
合久必分
(三國演義)
軟件行業是不是也一樣呢?
現在的軟件行業有著各種各樣的技術平台
體系架構
但由於不同平台關注的方面不一樣
各有各自的特色
平台之間很難溝通
從而形成一個個的信息孤島．那如何把這些信息孤島聯系在一起呢
?業界提出了很多的方案
一個很著名的方案就是 Serviced
Oriented (面向服務)
那面向服務是什麼呢?這是對它的定義:
SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents
A service is a unit of work done by a service provider to achieve desired end results for a service consumer
Both provider and consumer are roles played by software agents on behalf of their owners
(
)
面向服務是一系列服務的集合
各個服務之間可以互相通信(包括簡單的數據傳遞和多個服務共同參與一個活動)
它通過為各個系統提供一些外部接口
從而達到集成各個系統的目的．業界也有些相對應的體系架構
例如: DCOM
CORBA
J
EE
但都無法徹底實現跨系統的集成
個人覺得原因如下:
接口定義語言無法被不同系統所接收．無論是DCOM
COBRA 還是J
EE都有各自的接口定義語言(都是二進制的)
它們都無法被其他系統所接受
而接口一旦被設定就很難改變
而用戶的需求是在不斷變化的
使用的是二進制的網絡協議來進行數據通信
很難跨過防火牆
而且各自使用的協議沒有被廣泛的接收
這點對Internet的運用尤為關鍵
這時一種新的體系架構出現了
它就是XML Web Services
微軟對它的定義是 :
XML Web services 是提供特定功能元素（如應用程序邏輯）的可編程實體
任何數量的
可能是完全不同的系統都可以用常見的 Internet 標准（如 XML 和 HTTP）訪問它
它的核心特征是存在於服務的實現與使用之間的高度抽象化
Web Services正在迅速的被各個平台所接受
相對於其他架構
它的優勢在與:
接口定義語言
它使用WSDL作為接口定義語言
這是一種基於XML格式的Document
而文本是可以被各種系統和平台所認識的
使用HTTP
SOAP
SMTP等其他被廣泛接受的協議進行數據通信
而HTTP是Internet的基礎協議之一
那如何深入的理解Web Services呢?個人覺得應從以下幾個方面入手:
一 目的 它是實現SOA的一種方式
是為了連接不同的系統和計算設備
實現系統和數據的互操作性
簡單的說是要能夠訪問不同的系統和計算設備中的數據
而不用關心這些數據在各自系統和設備中是如何存放的
也可以說成不用關心數據是如何封裝的(類似OO裡的黑盒)
二 定義 XML Web Service顧名思義就是使用XML來提供Web服務．其實嚴格的說Web可以不要
就是XML Service
因為並不是所有的Web Service都需要WebServer的．服務就是把我有的功能提供給使用者
也就是向使用者提供一個接口
這就是Web Service．因此Web Service絕對不是一種新的分布式對象
而DCOM
CORBA
J
EE 本質上都是分布式的對象
三 組成 一些能處理XML的組件．
首先XML Web Service(或者Web Service)要能夠處理XML
至於處理XML的組件是如何設計的
不同語言
平台有不同的方式
可以是OO(面向對象)的
也可以是其他方式
在
Net裡是通過
Net Framework 提供的一些類實現的
XML 文檔
前面我們說過Web Service優勢之一在與接口定義語言(IDL)是基於XML的文檔
由於Web Service 是SOA(面向服務)的一種
而SOA的目標是在系統之間建立一種松散的耦合
因此服務和消費服務方就不能以Object作為數據溝通的紐帶或者說锲約(Contract)
就必須使用XML文檔來做為锲約
那為了使服務提供方和消費方都能夠理解Contract的含意
Web Service使用WSDL來描述XML文檔
即描述對外的接口．同時使用XML Schema來描述文檔裡的數據
XML文檔的載體
有了ＸＭＬ文檔就需要一個承載它的協議．Web Service使用SOAP作為載．SOAP:簡單對象訪問協議
嚴格來說這個名稱是錯的
因為它不是用來訪問對象的．MS給它的定義是
SOAP 是一種基於 XML 的
用於在 Web 上交換結構化和類型信息的簡單的輕量協議
．它以信封的方式來承載XML文檔．信封分為兩部分: 信封頭(head) 和信封體(body)．頭一般用來保存一些輔助的信息
例如安全(簽名和加密數據)和路由信息
信封體用來保存锲約即服務的接口描述和具體的數據
服務的地址
用來告訴服務消費方從哪裡可以訪問服務
服務位於何地
對此
Microsoft提供了UDDI(通用說明
發現和集成)
Net 實現Web Service的方式是通過ASP
NET．它封裝了很多的細節
使開發人員開發WebService很方便
但造成的結果是使認識本質比較困難
(MS的一貫作風)．
l 通過Web方法的形式來調用Web Service．
前面說了Web Service之間交換的實際上是XML文檔
考慮到很多程序員
不習慣直接操作XML(喜歡操作對象及其方法)
在
Net裡將接收到的
XML文檔轉換成對象或作為方法的參數的值
同時又會將得到的值或對
象反序列化成XML文檔發送回服務消費者
服務消費者就可以以傳統的
調用對象的方法的形式來向服務提供者發送請求從而獲得希望的數
據．從消費者提出服務申請到得到相應的結果的流程如下(
)
:
由這個流程圖(
)可以看到
客戶端要調用Web Service首先要發送消息
而服務端是通過消息知道有消費者要調用它．因此從某種意義上說
Web
Service是一種基於消息的體系架構
只不過消息是基於XML的文檔
l 代理類的產生
代理類的作用是用來方便和Web服務進行通信的
在
Net 裡可以以自動和手
動的方式產生
兩者都是根據服務的WSDL文件產生的
正如前面所說為了方便
程序員的習慣用法
Net會將XML文檔反序列化成對象
在代理類裡也是同樣的
這樣就會給我們一種錯覺
好像在客戶端重新生成了服務端的對象
例如: 一個
Web方法 Test向客戶返回一個ObjectA
public class ObjectA
{
public string FieldA
public string FieldB
}
那麼在代理類同樣會生成一個ObjectA
它的結構和服務端的ObjectA是一模一
樣的
但實際上這只是
Net為了方便我們使用Web Service而人為生成的(這也是
很多人認為WebService是用來進行遠程對象訪問的原因之一)
對Web服務客戶
端而言
接收到永遠只有XML文檔
文檔裡的數據是以XML Schema描述的
至於
怎麼使用是各個Web客戶端各自的特點
對
Net而言它會將一些復雜的自定義
的XML Schema類型轉換成Object
其他的一些客戶端就不會轉換成Object
例如
Soap Tookit
它會轉換成一個XML 節點(Node)對象
下面就結合一個實際的項目來說明如何實施Web Service
一 項目概況 某公司有個現有產品ProductA
(PA)
它需要獲得一些數據來進行業務處理．這些數據按地區和時間是會變化的
同時數據是由相應的政府機構定的
不同地區的政府機構的數據是不同的
每變動一次都需要以公函的形式通知產品用戶
或者由公司自己整理然後告訴用戶去更新．這樣就造成不同地區有不同版本
用戶升級困難
同時政府機構之間的數據很難溝通和對比
二 解決方案 利用Web Service的功能
將所有政府機構的數據都公開(當然要權限的 J)．產品(PA)作為WebService的客戶端可以實時訪問不同的數據
這樣產品和數據之間
數據和數據之間
用戶和數據之間都無縫的聯系在一起了
三 具體實施 有了服務就有服務的兩個參與者
服務的提供者和服務的消費者
對於產品(PA)它是服務的消費者．因此它只是個Web Service Client
可以是任
何類型的程序．現有的PA是個VB版的程序
可以通過代理類來訪問不同
的 Service
對於數據(A
B
C……
)
它們即是服務提供者同時也是服務消費者．由於用戶
需要能夠能直接查詢一些數據
因此對於用戶
我們給每個數據做了一個網站以
方便用戶查詢(使用 建立)
前面我們說了服務是將已有的功能和數據通過接口公開而不需要關心功能和
數據在各自的系統中是如何實現的
因此對功能和數據本身依然可以采用既有
的技術
實現功能和數據部分還是采用三層架構
將Web Service作為一個獨立的
層(Facade層)
框架圖如下:
Net提供了Asmx文件作為具體實現的文件
在具體實施的過程中有幾個問題要注意:
l SOAP的格式
Soap是服務锲約的載體
它本身也有一定的格式．對於SOAP中的信封
有兩種格式 Document
From:http://tw.wingwit.com/Article/os/fwq/201311/10201.html
