實戰Web服務

來源:互聯網
上載者:User
web|web服務  
架構Web Service: 實戰Web服務  
  


   
內容:

案例需求描述
應用的系統架構
Catalog Service
Order Service
Feedback Service
互動,互動些什麼?
為什麼選擇基於Web服務的解決方案?
什麼是需要公開的?
參考資料
作者簡介


相關內容:

基於Web服務的應用、解決方案和開發平台
什麼是Web服務?
為什麼需要Web服務?
動態電子商務模式




柴曉路 (fennivel@uddi-china.org)
Chief System Architect
2001年8月14日

本文是架構Web服務的系列文章的第四篇,繼探討了Web服務的商業需求,技術定義和技術規範以及現有現有的Web服務實踐之後,通過使用一個具體的案例開始對Web服務實戰的篇章。在本文中給出了一個實際的具有實用性並且能夠延伸出去的電腦產品交易市場的案例,通過簡要的系統分析、模組劃分,對鬆散系統間待交換的資料進行了界分,同時為定義基於Web服務的API的資料結構奠定了系統和分析的基礎。
在先前的文章系列裡面,我已經對Web服務的商業需求、Web服務的技術實現以及Web服務當前的應用以及開發工具做了全面的介紹,那麼在接下來的文章中,我將結合一個執行個體來詳細地描述如何真正地規劃、設計和建立一個Web服務的具體應用。

本文所引用的資源主要包括兩類,一類是Web服務的技術資源網站,包含了大量Web服務的技術資訊,另一類是Web服務“stack"系列技術規範,他們是一個整體的技術體系,包括UDDI、SOAP、WSDL、XML等。本文的最後給出了這些資源的連結,有興趣的讀者可以通過這些資源連結找到所需的內容。

案例需求描述

在這裡我們假設應用背景是一個電腦產品銷售市場,其中的角色及其對應的行為描述如下:

電腦產品交易市場,該市場是聯絡電腦產品生產商/零售商與消費者之間的營銷平台。其職責和功能包括:收集並發布來自各個電腦產品生產商/零售商的產品目錄;接受消費者的購買請求並可靠地遞送給生產商/零售商系統完成購買事務;採集來自消費者的消費反饋,給出商品購買的導引建議,並傳送給生產商/零售商。
生產商/零售商,這是直接銷售電腦產品的商家,他能夠通過自己的Web發布產品目錄,同時也能將目錄傳送給電腦產品交易市場。他能夠接受訂單(來自自己的Web網站或者來自電腦產品交易市場)並轉入內部管理系統,至於資金流和物流則由離線系統完成。
消費者,電腦產品的購買者(可能是個人,也可能是企業),他能夠訪問電腦產品目錄,能夠利用線上的定購服務進行購買。
通過對以上角色及其行為的分析,我們認為在最終的實現系統中應該有這樣幾種概要層次上的對象:

產品目錄,產品目錄由生產商/零售商產生,由電腦產品交易市場匯總歸類,由消費者瀏覽使用。
訂單,訂單由消費者產生,由電腦產品交易市場傳遞,由生產商/零售商接受。
反饋資訊,由消費者產生,由電腦產品交易市場匯總歸類,由消費者和生產商/零售商使用。
使用者,使用者分兩類,一類是消費者使用者,一類是生產商/零售商使用者,分別用於處理兩類事務。
應用的系統架構

綜合上面的分析,我們可以將整個系統按如下架構劃分:

Figure 1.   系統劃分概要


大家可能會發現,Marketplace System和Retailer System這兩個系統沒什麼大區別嘛? 的確是這樣,我們在設計的時候應當無時無刻不能忘記"重用"這個概念,重用的組件越多,開發的代價就越少,維護的代價也越低,可擴充性也就越好,當然重用不能導致功能的異化,這也是我們需要注意的。

下面我花一點篇幅稍微解析一下架構中的三個主要服務:Catalog Service、Order Service和Feedback Service。

Catalog Service

對於這個服務而言,Retailer System中的Catalog Service應當是Marketplace System功能的子集。Retailer System中,Catalog Service應當具備如下功能:

類別(Category)管理,包括增加一個Category、刪除一個Category、修改一個Category等;

產品(Product)管理,包括增加一個Product、刪除一個Product、修改一個Product、移動一個Product(從一個Category下移動到另一個Category下)等;

資料交換,包括單個類別下所有產品的匯入匯出(Import/Export),單個產品資料的匯入匯出,整個類別樹狀目錄的匯入匯出等;

資料備份,整個目錄下所有產品資料的備份/恢複等。

而Marketplace System中,需要增加一個功能:在資料交換和資料備份模組應當提供對指定資料擁有者的相關資料的操作,比如匯出某個類別下IBM的所有產品等等。

Order Service

對於這個服務而言,Retailer System中的Order Service和Marketplace System中的Order Service可以說基本沒有什麼本質上的差別。他們都將具備如下功能:

接受訂單
向其他接受訂單的服務發送訂單
兩者的區別,僅僅在於Retailer System中的Order Service接受的訂單來自使用者介面,而需要向Marketplace System中的Order Service傳送。Marketplace System中的Order Service接受的訂單來自Retailer System中的Order Service,而需要向自己內部的公司專屬應用程式傳送訂單。

Feedback Service

對於Feedback Service而言,在兩個系統中的地位與Catalog Service是類似的。

反饋資訊(Feedback)管理,包括增加一條反饋資訊、刪除一條反饋資訊、修改一條反饋資訊等,反饋資訊可以掛在Category下,也可以掛在Product下(有針對一類產品的評測報告,也有針對一個產品的使用評價等);
資料交換,包括與單個類別關聯或與單個產品關聯的反饋資訊的匯入匯出(Import/Export),以及與單個使用者(Retailer使用者,資料擁有者)相關的所有反饋資訊的匯入匯出等;
Feedback可以看作是與整個產品目錄樹的各個結點相關聯的評論文章。不僅在Marketplace系統中由消費者發布並歸消費者查詢,同時也將在相關的Retailer系統儲存並可供Retailer使用。

互動,互動些什麼?

我們將以上功能描述加以總結,去除內部實現的部分,我們可以發現在Internet上需要傳輸的資料的邏輯視圖如下:

Figure 1.   資料實體關聯圖


其中黃色的三個實體完全可以看成是一個樹狀的資訊目錄,其中有三個層次的結點:Category,Product和Feedback,Category的子結點可以是Category、Product和Feedback,而Product的子節點只能是Feedback,整個分類樹的根結點是Category。

而對於每個Product而言,都有一個資料擁有者,這個資料擁有者應當是Marketplace中的一個Retailer帳號。

另一類實體是訂單,對於一張訂單而言,將可以包含多個Product的定購記錄,以及定購對象:某個Retailer。

在系統之間互動資料是互動的第一層次:資料交換,然而對於Web服務而言,光光有資料交換是不夠的,應當提供更高層次:服務整合的支援。

因此,互動的內容不光包括互相互動的資料,同時應當包含對資料的操作(比如資料請求,資料添加,資料更新等等)。這些往往會對應與服務端的一個處理模組。

無論是對資料的操作,還是資料本身,為了在系統與系統之間進行互動,尤其是異構平台之間,我們需要將所有的操作(服務調用)和操作的資料(服務調用的參數和傳回值)進行正常化的描述,形成規範文檔後發布以供所有需要參與互操作的系統共同遵守。

為什麼選擇基於Web服務的解決方案?

我在前面已經就為什麼電子商務需要Web服務作了初步的論述。電子商務需要擺脫獨立解決方案的實現模式,需要捨棄複雜系統串連的實現方法。一個有效電子商務應用絕對不應該是僅僅基於程式員以及那些複雜的代碼的。對於電子商務而言,傳統的由程式員主導的由裡向外的開發模式應當被由使用者主導的由外向裡的開發模式取代。冗長的串列的開發迴圈應當被即時的,快速的應用裝配所取代。同時這樣的應用應當天生就具備高可定製性。如果探究其商業本質,這是來自經過時間考驗的商業技術概念:"即時製造"以及"規模可伸縮"等概念,我們需要做的就是將傳統的商業概念延伸到電子商務中去。

通過使用Web服務,企業能夠以前所不可能的方式通過抽象和混合將自身的電子商務組件化。當一個企業的核心競爭力被組件化之後,那麼這些核心競爭力就能夠很方便地在不同的企業之間共用,同時架構跨企業的電子商務應用,形成商務Web。

在我們的這個電腦產品銷售網路應用中,我們可以預見到不同的銷售商採用的系統很可能是多種多樣的,有基於Windows/IIS的Web應用,有基於Java Platform的Web應用,也有基於Windows平台的案頭應用,也有可能是基於UNIX的ERP應用部分,要相容那麼多種類的應用,用一般的整合技術很難滿足所有場合的需要。即使滿足了,當有其他想加入這個體系的新的Retailer出現的時候,彼此的整合代價也是無法預知的。而通過公布預先定義好的可擴充的服務訪問規範,使得這些需要整合入體系的Retailer系統都可以以一種方便地標準的方式進入。

大家可能會說Retailer系統不也是我們來開發的嗎?是的,一部分,甚至可能是很大一部分Retailer系統可能用的都是與Marketplace系統同構的平台,而且只不過是服務模組少了幾塊而已。然而,我們是處在Internet的開放互聯的時代,對於Marketplace來說,越多的Retailer的進入就代表著更多的商機,Marketplace的運營者一定會想盡辦法招攬,整合更多的Retailer系統,那麼與其每出現一個異構的Retailer系統就要運用人力物力與其進行單點整合的項目開發,不如制定一種規範,使得這些新加入的Retailer能夠依照這些規範自主地加入系統。Marketplace同樣具備海納百川的能力,同時又不用指數倍地投入開發代價。

同時如果該規範成為一種公用接受的規範的話,其他的相容該標準的Marketplace同樣也可以出現,而遵循該規範的Retailer系統則可以廣泛地以極低的代價接入到所有相容該規範的Marketplace中去,獲得更多的銷售機會和渠道。甚至按照規範來實現,Retailer系統之間還能實現低代價的對等互聯。可以說,依據規範的基於Web服務的服務整合是真正的按照Internet的開放互聯理念的Internet時代的服務整合的方式。

什麼是需要公開的?

我們已經談到我們需要公開的是調用規範,那麼調用規範該如何定義呢,如果大家在本專欄先前的關於UDDI的文章中跟隨我稍微研究了一下UDDI規範的話,那麼基本可以瞭解對於Web服務而言(UDDI Registry就是一種標準的Web服務),規範定義可以分為兩部分:

Programmer's API:這是類似傳統含義的API定義,不過承載的介質是SOAP Message,也就是說Programmer's API是一組SOAP API,不同的API用於完成不同的服務調用,在這部分中需要定義不同的SOAP API的行為和實現的調用/響應的功能描述;
Data Structure:這部分定義了在SOAP訊息中傳輸的參數/資料和響應資料的XML模式,這部分為每個API補充的訊息格式,同時為最終的API處理提供了資料層解析/封裝的規範。
在後面的文章中,我將就本文關注的這個Demo Case,一步一步地講述如何定義Programmer's API和Data Structure。

參考資料

Web Service 技術/評論網站
UDDI-China.ORG, 以UDDI為主的Web服務技術網站。
WebServices.ORG, Web服務的綜合類技術網站。
IBM developerWorks/Web Service Zone, IBM的Web服務技術資源中心
MSDN Online Web Services Developer Resources, Microsoft的Web服務的開發人員資源網站
ITPapers/Web Service, ITPapers的Web服務評論文章
解決B2B電子商務應用互動和整合的InterOP Stack系列技術標準規範
UDDI執行白皮書, UDDI-China.org, UDDI.org
UDDI技術白皮書, UDDI-China.org, UDDI.org
UDDI程式員API規範, UDDI-China.org, UDDI.org
UDDI資料結構參考, UDDI-China.org, UDDI.org
Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000
SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000
Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000
作者簡介

柴曉路: 上海得易電子商務技術有限公司(DealEasy)首席系統架構師、XML技術顧問。UDDI-China.org藍色火焰工作室(Blue Blaze Studio)成員。UDDI Advisor Group成員,WSUI Working Group成員。2000年獲複旦大學電腦科學碩士學位,曾在國際電腦科學學術會議(ICSC)、亞太地區區XML技術研討會(XML Asia/Pacific'99)、中國XML技術研討會(北京)、電腦科學期刊等各類國際、國內重要會議與期刊上發表論文多篇。專長於基於XML的系統整合和資料交換的技術研究,同時對資料庫、物件導向技術及CSCW等技術比較擅長。



相關文章

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。