基於團隊模式開發中介模組

CloudSpace發表於2010-08-17
高 忠濤, 軟體工程師, IBM CDL
朱 李桃, 軟體工程師, IBM CDL

簡介: 在現代企業整合環境中,為了使應用程式整合變得更靈活、更簡單、可擴充套件性更強,越來越多的企業選擇了面向服務的體系結構(Service Oriented Architecture,SOA),而 WESB(WebSphere Enterprise Service Bus, WebSphere 企業服務匯流排)作為 SOA 中服務提供者和請求者之間的連線服務的中間層也被越來越多的企業所使用。WID(WebSphere Integration Developer)是使用 SCA(Service Component Architecture)模型來開發和整合應用的工具。對於企業來說,採用 WID6.2.0.1 以後版本所提供的基於團隊開發模式來進行中介模組開發,可以達到事半功倍的效果。本文重點闡述如何利用 WID 的此功能進行基於團隊模式的開發。

概念介紹

WESB

WebSphere Enterprise Service Bus (WebSphere 企業服務匯流排 ) 是從 WebSphere Application Server Network Deployment 的基礎上發展而來的。WESB 提供了基於標準的 Web Services 連線性、JMS 訊息傳遞和麵向服務的整合,是一種靈活的聯結器中間結構,全面支援面向服務架構的開發。

WID

WebSphere Integration Developer 是使用 SCA 模型來開發和整合應用的工具,它基於 Eclipse 技術,並面向 WebSphere Process Server 和 WebSphere ESB Server 執行時環境。

Mediation module 和 Mediation flow

Mediation module 是 WID 中可以建立的一種 WebSphere 業務整合工程,可以被部署到 WebSphere ESB 或者 WebSphere Process Server 上。Mediation module 通常包含一個或多個 Mediation flow 來提供處理服務請求者與服務提供者之間的資料傳遞。Mediation Flow 能夠對在服務端點之間進行交換的訊息執行路由,變換和日誌等操作,從而來實現企業的業務執行功能。

WID 基於團隊開發模式的新功能介紹

在企業的應用開發中,由於業務功能的繁瑣,一個 Mediation flow 往往會實現多個介面 (interface),且每個介面都包含了不同的方法 (operation),而這些方法可能會分配給不同的開發人員來實現。在 WID 的 6.2.0.1 版本以前,一個 Mediation flow 所有的 operation 實現,只能由一個開發人員來開發維護,或者由一位開發人員做完一部分以後,再移交給下一位開發人員,這樣導致了開發效率比較低下。從 WID 的 6.2.0.1 版本開始加入了一個新的功能—基於團隊的開發模式,該功能讓 WESB 開發人員們更有效,更快捷的實現 Mediation flow 的開發工作。

在以前版本的 WID 開發過程中,一個 Mediation flow 所有 operation 的實現都放在一個 .medflow 檔案裡,而新的基於團隊開發模式則把一個 Mediation flow 按照 operation 來分解成多個檔案來維護,每個 operation 對應一個 .mediation 檔案,如 圖 1 所示。專案負責人建立起模組後,就可以把這些 operation 的實現工作分配給不同的開發人員,開發人員可以同時進行開發工作,並且每個開發人員只需要負責維護自己的 operation 檔案就可以了,各個 operation 檔案之間互不影響,這樣做大大提高了開發效率。


圖 1. Multiple files 結構
Multiple files scheme

WID 基於團隊開發模式的簡單流程圖如 圖 2 所示,這個流程圖向我們展示了基於該模式進行專案開發各個階段的主要任務。


圖 2. 基於團隊開發模式的簡單流程圖
process flow

(參見圖 2 的放大圖。)

一個簡單的基於團隊開發的例項

這裡假定一個簡單的網路銷售的場景。該網路銷售管理系統具有產品下單和產品派送兩個功能,產品下單功能是指生成顧客購買產品的訂單,而產品派送功能主要是根據顧客的訂單進行產品分配。這兩個功能是可以獨立進行開發的。該例項的目標物件主要是對用 WID 開發 WESB 模組具有一定了解的開發人員。使用的 WID 版本是 7.0.0.0。

1. 建立一個 library,命名為 SaleLibrary。在 SaleLibrary 中建立 6 個 Business Object,分別命名為 Customer、Item、BookRequest、BookResponse、DispatchRequest 和 DispatchResponse,如 圖 3 所示。


圖 3. 業務相關 Business Object
Business Object

(參見圖 3 的放大圖。)

2. 在 SaleLibrary 裡建立兩個介面,命名為 SaleInterface 和 ServiceInterface,其中包含的 operation 如 圖 4圖 5 所示。


圖 4. SaleInterface 介面
SaleInterface

圖 5. ServiceInterface 介面
ServiceInterface

3. SaleLibrary 完成以後,我們接著建立一個 Mediation Module,命名為 SaleModule,選擇新增 SaleLibrary 作為 required library。

4. 在 SaleModule 裡建立一個 Mediation Flow,命名為 SaleMediation,新增 SaleInterface 作為 source interface,以及 ServiceInterface 作為 target reference。接著選擇“Save the mediation flow as multiple files”選項,如 圖 6 所示,然後點選“Finish”。


圖 6. “Save the mediation flow as multiple files”選項
Save the mediation flow as multiple files

我們可以從 Mediation Flows 編輯檢視的屬性中看到 SaleMediation flow 已經儲存為“多個單獨檔案”的形式,如 圖 7 所示。同樣也可以通過這個屬性設定轉變成預設的方式,即把該 flow 儲存為一個檔案。


圖 7. SaleMediation 屬性設定
Properties of SaleMediation

(參見圖 7 的放大圖。)

5. SaleMediation 建完以後,我們開啟 Mediation Flows 編輯檢視,分別為 bookOperation 和 dispatchOperation 新增目標服務。bookOperation 選擇 bookService 作為目標呼叫服務 , 而 dispatchOperation 選擇 dispatchService 作為目標呼叫服務。這樣,SaleMediation flow 的基本框架已經建立完成。

6. 在 Business Integration 檢視中選擇 SaleMediation,點選右鍵選擇“show files”,開啟 Physical Resources 檢視能看到該 mediation 對應的檔案,如 圖 8 所示。我們可以看到每個 operation 都各自生成一個 .medflow 檔案,SaleMediation_SaleInterface_bookOperation.medflow 和 SaleMediation_SaleInterface_dispatchOperation.medflow。


圖 8. SaleMediation 檔案資源
SaleMediation files resources

其中值得注意的一點是,當建立完一個 mediation 後,需要編輯其中一個 operation(可以沒有任何實現,只是新增目標服務)並儲存,才會為每個 operation 生成一個 .medflow 檔案。

7. 至此,模組負責人的建立工作基本完成,可以把該模組作為 Repository 提交到 CVS 伺服器上了。然後把兩個 operation 的實現任務分給開發人員 A 和開發人員 B。開發人員 A 負責實現 bookOperation 的產品下單流程,開發人員 B 負責實現 dispatchOperation 的產品派送流程。開發人員 A 和開發人員 B 此時就可以從 CVS 伺服器上下載模組資源到本地,同時進行開發工作了。

8. 開發人員 A 需要實現 bookOperation,即產品下單的功能,request flow 和 response flow 的實現分別如 圖 9圖 10 所示。


圖 9. BookOperation Request flow
Request flow

(參見圖 9 的放大圖。)

圖 9 的 request flow 中,客戶端傳入 customer_ID(使用者 ID)、item_ID(產品 ID)和 quantity(購買數量),呼叫“itemQuantityCheck”這個 Custom Mediation primitive。“itemQuantityCheck”根據傳入的 item_ID 檢查其對應的產品庫存量,如果庫存量檢查 OK 則呼叫 bookService 服務,生成一條有效的訂單記錄,即把該訂單記錄的狀態設成 true;如果庫存量檢查 FAIL 不足則並把該訂單記錄狀態設成 false,直接返回客戶端。


圖 10. BookOperation Response flow
Response flow

圖 10 的 response flow 中,直接把呼叫 bookService 服務的結果返回了客戶端。

9. 與此同時,開發人員 B 在實現 dispatchOperation,即產品派送功能,request flow 和 response flow 的實現分別如 圖 11圖 12 所示。


圖 11. DispatchOperation Request flow
Request flow

(參見圖 11 的放大圖。)

圖 11 的 request flow 中,客戶端傳入 customer_ID(使用者 ID)、item(產品資訊)和 status(訂單狀態),呼叫“checkStatus”這個 Message Filter Mediation primitive。“checkStatus” 根據傳入的 status 判斷是否進行派送工作,

  • 如果狀態是 true,呼叫“checkCustomer”這個 Service Invoke Mediation primitive 檢查客戶相關資訊,如果檢查通過則呼叫“customerLog”這個 Message Logger Mediation primitive 記錄該訂單的相關資訊,最後呼叫“dispatchService”服務進行產品派送工作;否則輸出錯誤資訊。
  • 如果狀態是 false,那麼把結果的 dispatch_ID(派送 ID)設成 null,然後返回給客戶端。


圖 12. DispatchOperation Response flow
Response flow

(參見圖 12 的放大圖。)

圖 12 的 response flow 中,呼叫“dispatchStatusLog”這個 Message Logger Mediation primitive 記錄派送服務完成的相關資訊,最後把該結果返回給客戶端。

10. 由於 Operation 的開發工作是同時進行的,假設開發人員 A 比開發人員 B 提前完成了自己的開發工作,於是先向 CVS 伺服器上提交了自己的實現檔案。首先,開發人員 A 同步本地的模組,在 Business Integration 檢視中右鍵點選該模組選擇“Team”中的“Synchronize with Repository”選項,開啟同步檢視,如 圖 13 所示。


圖 13. 資源同步 (A)
Synchronize with Repository(from A)

圖 13 中我們可以看到開發人員 A 實現的 bookOperation 對應的 SaleMediation_SaleInterface_bookOperation.medflow 檔案有改動,而另一個 dispatchOperation 對應的 .medflow 檔案並沒有變化。開發人員 A 發現沒有資源衝突,於是提交了自己的實現檔案。

11. 此時,開發人員 B 的開發工作也完成了,於是也開始同步本地的模組,如 圖 14 所示。


圖 14. 資源同步 (B)
Synchronize with Repository(from B)

圖 14 中我們可以看出開發人員 A 已經把 bookOperation 的相關實現提交了,而且開發人員 B 實現的 dispatchOperation 對應的 SaleMediation_SaleInterface_dispatchOperation.medflow 檔案也沒有衝突,所以對這些檔案進行更新和提交操作就可以了。不過,我們也看到了 SaleMediation.mfcex 檔案有衝突發生,那是因為兩個 operation 中都新增了便籤(Note, 如 圖 11 中的黃色框區域),這就需要手工進行合併操作了。完成以上操作後,開發人員 B 也完成了把 dispatchOperation 的實現資源提交到 CVS 伺服器的工作。

以下幾點是在同步資源的時候可能會發生檔案衝突的情況:

  • 新增,刪除,或者編輯 source interfaces,source operations,target interfaces 或者 target operations 會引起 .mfc 檔案變化。
  • source operation 被刪除時,其對應的 .medflow 檔案也會被刪除。
  • Promoted properties 會引起共通的 .medflow 檔案變化。
  • 新增,刪除,或者編輯便籤會引起共用的 .mfcex 檔案變化。

所以,為了避免衝突太多,建議每天先同步更新本地資源再進行開發。

12. 至此,Mediation 的 operation 並行開發工作已基本完成,專案負責人可以從 CVS Server 下載資源進行模組的整合實現了,如 圖 15 所示。這樣,這個簡單的網路銷售管理模組就開發完成了。


圖 15. SaleModule
SaleModule

結束語

我們通過這個例項向讀者簡單介紹了利用 WID 基於團隊的開發模式新功能進行團隊並行開發的過程。這個新功能使開發人員更加快捷的開發 Mediation flow,提高了開發效率。

原文連結:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1007_gaozt_intermediary/1007_gaozt_intermediary.html

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14789789/viewspace-671155/,如需轉載,請註明出處,否則將追究法律責任。

相關文章