模板
教程
環境
性能
功能
管理
架構WebService:實戰Web服務
| 架構Web Service:實戰Web服務 |  |
|
| |
| ||||
| ||||
|
柴曉路 (fennivel@uddi-china.org) （本文最初由 IBM developerWorks 中國網站發表，其網址是 本文是架構Web服務的系列文章的第四篇，繼探討了Web服務的商業需求，技術定義和技術規范以及現有現有的Web服務實踐之后，通過使用一個具體的案例開始對Web服務實戰的篇章。在本文中給出了一個實際的具有實用性并且能夠延伸出去的計算機產品交易市場的案例，通過簡要的系統分析、模塊劃分，對松散系統間待交換的數據進行了界分，同時為定義基于Web服務的API的數據結構奠定了系統和分析的基礎。 在先前的文章系列里面，我已經對Web服務的商業需求、Web服務的技術實現以及Web服務當前的應用以及開發工具做了全面的介紹，那么在接下來的文章中，我將結合一個實例來詳細地描述如何真正地規劃、設計和創建一個Web服務的具體應用。 本文所引用的資源主要包括兩類，一類是Web服務的技術資源網站，包含了大量Web服務的技術信息，另一類是Web服務“stack"系列技術規范，他們是一個整體的技術體系，包括UDDI、SOAP、WSDL、XML等。本文的最后給出了這些資源的鏈接，有興趣的讀者可以通過這些資源鏈接找到所需的內容。 案例需求描述 在這里我們假設應用背景是一個計算機產品銷售市場，其中的角色及其對應的行為描述如下：
通過對以上角色及其行為的分析，我們認為在最終的實現系統中應該有這樣幾種概要層次上的對象：
應用的系統架構 綜合上面的分析，我們可以將整個系統按如下架構劃分： Figure 1. 系統劃分概要 大家可能會發現，Marketplace System和Retailer System這兩個系統沒什么大區別嘛? 的確是這樣，我們在設計的時候應當無時無刻不能忘記"重用"這個概念，重用的組件越多，開發的代價就越少，維護的代價也越低，可擴展性也就越好，當然重用不能導致功能的異化，這也是我們需要注意的。 下面我花一點篇幅稍微解析一下框架中的三個主要服務：Catalog Service、Order Service和Feedback Service。 Catalog Service 對于這個服務而言，Retailer System中的Catalog Service應當是Marketplace System功能的子集。Retailer System中，Catalog Service應當具備如下功能：
而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可以看作是與整個產品目錄樹的各個結點相關聯的評論文章。不僅在Marketplace系統中由消費者發布并歸消費者查詢，同時也將在相關的Retailer系統保存并可供Retailer使用。 交互，交互些什么? 我們將以上功能描述加以總結，去除內部實現的部分，我們可以發現在Internet上需要傳輸的數據的邏輯視圖如下： Figure 1. 數據實體關系圖 其中黃色的三個實體完全可以看成是一個樹狀的信息目錄，其中有三個層次的結點：Category，Product和Feedback，Category的子結點可以是Category、Product和Feedback，而Product的子節點只能是Feedback，整個目錄樹的根結點是Category。 而對于每個Product而言，都有一個數據擁有者，這個數據擁有者應當是Marketplace中的一個Retailer帳號。 另一類實體是訂單，對于一張訂單而言，將可以包含多個Product的定購記錄，以及定購對象：某個Retailer。 在系統之間交互數據是交互的第一層次：數據交換，然而對于Web服務而言，光光有數據交換是不夠的，應當提供更高層次：服務集成的支持。 因此，交互的內容不光包括互相交互的數據，同時應當包含對數據的操作(比如數據請求，數據添加，數據更新等等)。這些往往會對應與服務端的一個處理模塊。 無論是對數據的操作，還是數據本身，為了在系統與系統之間進行交互，尤其是異構平臺之間，我們需要將所有的操作(服務調用)和操作的數據(服務調用的參數和返回值)進行規范化的描述，形成規范文檔后發布以供所有需要參與互操作的系統共同遵守。 為什么選擇基于Web服務的解決方案? 我在前面已經就為什么電子商務需要Web服務作了初步的論述。電子商務需要擺脫獨立解決方案的實現模式，需要舍棄復雜系統連接的實現方法。一個有效的電子商務應用絕對不應該是僅僅基于程序員以及那些復雜的代碼的。對于電子商務而言，傳統的由程序員主導的由里向外的開發模式應當被由用戶主導的由外向里的開發模式取代。冗長的串行的開發循環應當被即時的，快速的應用裝配所取代。同時這樣的應用應當天生就具備高可定制性。如果探究其商業本質，這是來自經過時間考驗的商業技術概念："即時制造"以及"規?？缮炜s"等概念，我們需要做的就是將傳統的商業概念延伸到電子商務中去。 通過使用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系統之間還能實現低代價的對等互聯?？梢哉f，依據規范的基于Web服務的服務集成是真正的按照Internet的開放互聯理念的Internet時代的服務集成的方式。 什么是需要公開的? 我們已經談到我們需要公開的是調用規范，那么調用規范該如何定義呢，如果大家在本專欄先前的關于UDDI的文章中跟隨我稍微研究了一下UDDI規范的話，那么基本可以了解對于Web服務而言(UDDI Registry就是一種標準的Web服務)，規范定義可以分為兩部分:
在后面的文章中，我將就本文關注的這個Demo Case，一步一步地講述如何定義Programmer's API和Data Structure。 參考資料
作者簡介  柴曉路: 上海得易電子商務技術有限公司(DealEasy)首席系統架構師、XML技術顧問。UDDI-China.org藍色火焰工作室(Blue Blaze Studio)成員。UDDI Advisor Group成員，WSUI Working Group成員。2000年獲復旦大學計算機科學碩士學位，曾在國際計算機科學學術會議(ICSC)、亞太區XML技術研討會(XML Asia/Pacific'99)、中國XML技術研討會(北京)、計算機科學期刊等各類國際、國內重要會議與期刊上發表論文多篇。專長于基于XML的系統集成和數據交換的技術研究，同時對數據庫、面向對象技術及CSCW等技術比較擅長。 | ||||||||||||||||||||||||||||
- 評論列表（網友評論僅供網友表達個人看法，并不表明本站同意其觀點或證實其描述）
-
