級別:?初級????王強,?軟件工程師
2003?年?3?月?01?日
商業流程執行語言BPEL4WS(Business?Process?Execution?Language?For?Web?Services)是專為整合Web?Services而制定的一項規范標準。它從本質上來說是IBM的WSFL和Microsoft的XLANG的結合物，目前已經成為業界標準。WSFL?支持圖形化的流程，而XLANG在結構化構造方面有獨到的方法，而BPEL4WS正是吸取了兩者的優點，同時摒棄了一些復雜繁瑣的部分，形成了一種較為自然的描述商業活動的抽象高級語言。
在本文的上一篇文章中(?商業流程開發新紀元——BPEL4WS語言介紹，第1部分：特點介紹及使用技巧提示)，已經向讀者介紹了BPEL4WS語言的主要特點，BPEL4WS主要元素使用技巧以及利用外部Web服務的一些技巧。在本文中將繼續向讀者介紹有關利用BPEL4WS語言進行系統開發時如何有針對性的利用現有成熟軟件過程RUP(Rational?Unified?Process)。?
引言
本文主要介紹的有2個方面的內容；?
1，分析利用BPEL4WS進行系統開發與普通的軟件開發過程相比有哪些應該特別加以注意的問題。?
2，針對BPEL4WS語言的特點，介紹如何有針對性的利用成熟軟件過程RUP進行系統開發。?
（注：對于BPEL4WS的基本語法介紹以及RUP的詳細內容由于篇幅原因并沒有包括在本文中，讀者可以參閱附錄中的相關資料介紹；在文中出現的"BPEL4WS系統"與"用BPEL4WS語言開發的商業系統"同義。）?
?
?回頁首?
?
利用BPEL4WS語言進行系統開發時所應注意的一些問題
BPEL4WS語言是一門專為創建商業處理流程而誕生的基于XML語言規范的高級抽象語言，它不僅在語言的Specification方面不同于傳統的計算機語言，而且當利用BPEL4WS語言進行系統開發(即創建具體的商業流程)時也與傳統的系統開發過程有一些不同之處。大家主要應該注意以下幾個方面：
〈一〉并行操作；?
BPEL4WS語言中的并行操作是由〈flow〉完成的。這種并行是通過同時調用Internet上位于不同地方（不同城市甚至是國家）的Web?Services進行各種商業處理來完成的。就如圖1所示，當處理流程開始后，進入〈flow〉結構，在〈flow〉中同時開始執行兩個并行的〈sequence〉操作，〈flow〉操作也只有等到這兩個〈sequence〉操作都完成后才可以結束。正是由于BPEL4WS具有這種并行特性，所以在建模的時候就要著重參照并發模型的建模方法。
?
圖1：并行操作〈flow〉示例
〈二〉弱數據處理能力；?
由于BPEL4WS語言在實際操作中不涉及到商業數據的存儲和處理，也就是說所有有關于數據庫的操作都隱式的由其調用的外部Web服務來完成，這些數據庫操作不論對于開發人員和用戶來說都是透明的。正因如此，在BPEL4WS中并沒有出現復雜的數據結構和數據類型，也沒有關于數據存儲和持久化的操作，涉及到顯式數據操作的地方就是〈container〉結構的使用了，而在〈container〉中的數據沒有那么復雜的數據類型，因此我們可以說BPEL4WS語言是弱數據處理能力的。正是由于它的弱數據處理能力，決定了針對BPEL4WS語言的建模方法不太適合采用面向數據流的分析設計方法和針對算法的建模，因此面向對象的分析設計方法以及面向對象的建模自然而然就成為了最好的選擇。
〈三〉分布式系統架構；
BPEL4WS的誕生，完全是由于分布式技術的飛速發展，SOAP,XML以及Web?Services的出現為BPEL4WS語言的出現奠定了堅實的基礎。在BPEL4WS中一個最重要的概念恐怕就是"伙伴"〈partner〉結構了，BPEL4WS中的主要操作都要指定相應的〈partner〉，〈portType〉和〈operation〉。〈partner〉實際上就指明調用了哪一個Web服務，〈portType〉指明了調用這個Web服務上的哪一個端口類型，〈operation〉指明了調用的具體操作（可類似看作調用一個函數）是〈portType〉中的哪一個。由于指定的"伙伴"?所位于的各個節點機可以為異構系統，且與這些"伙伴"之間進行的通信可以基于各種通信協議(只要符合SOAP協議)，所以決定了對于系統構件模型(component?model)和系統實施模型(deploy?model)的建模就變得相當的重要。只有在系統的分析和設計中清晰地體現出所有與系統相關的外部Web服務的有關信息，才能算是對系統的整體架構有一個完整的描述。
?
?回頁首?
?
針對BPEL4WS語言的特點，合理結合成熟軟件過程RUP進行系統開發
RUP(Rational?Unified?Process)即Rational統一過程，定義了一系列的過程元素，如角色，活動和產物，通過適當的組合，能夠幫助軟件開發組織有效地管理軟件過程。RUP的特點體現在它是以用況驅動(use?case?driven)的，以體系結構為中心(architecture-centric)，迭代和增量(iterative?process)的。在系統的整個開發生命周期內共有4個階段：初始(inception)、細化(elaboration)、構造(construction)和移交(transition)，隨著時間的推移，每個階段所注重的焦點也不斷發生變化，同時這四個階段也是不斷迭代完成的，每一次迭代都有增量的任務完成。
由于BPEL4WS語言自身所具有的特點，決定了在結合RUP使用的時候不能完全生硬的照搬RUP的整個過程，在一些方面要做一些適當的修改，這主要體現在以下幾點：
〈一〉項目階段重點的適度轉移?
從管理的觀點來說，Rational?Unified?Process?的軟件生命周期隨著時間分為四個依次進行的階段（初始、細化、構造和移交），每個階段的結束都有一個主要里程碑，這些里程碑實際上就是每一階段工作成果的輸出。針對普通的項目開發來說，每一階段的工作量大致可劃分為：
?先啟?精化?構建?產品化?
工作量?5?%?20?%?65?%?10%?
在這里要做出一些改變的地方是精化和構建階段。構建階段的主要工作結果輸出中有一項是實施模型，實施模型對在精化階段創建的模型進行了擴展，在實施模型中要確定所有要用到的構件，并且必須決定如何將設計模型中的類和包映射到實施模型中的構件和子系統中。對于普通的項目來說，系統中所要用到的構件要么由自己開發，要么使用第三方提供的構件。但對于BPEL4WS系統來說，由于并不存在本地構件的使用，系統中所用到的所有業務處理功能全部都是通過調用外部的WEB服務來實現的，雖然我們也可以把調用這些外部的WEB服務看成是調用散布在Internet上的控件，就好像調用CORBA,DCOM一樣，雖然結果是相同的，但由于這些外部的WEB服務都是由其他的商業團體提供的，再加上最重要的一點是同樣功能的WEB服務可能有很多，而且分別由不同的團體提供（這也體現了UDDI的好處），這些WEB服務雖然功能上是相同的，但在接口細節及其他一些方面（如性能等）有很大的差別，所以作出合理的選擇將是一件費時費力的工作，一旦沒有作出較好的選擇就有可能影響到實施階段的工作，還有可能導致返工。因此，應將構建階段中的實施模型中的一部分工作提前到精化階段中完成，尤其是系統外部"伙伴"的確定是至關重要的。但在精化階段由于用例（use?case）的分析還不夠深入，所以在精化階段不可能全部完成實施模型的創建工作，也就是說在利用BPEL4WS語言進行系統開發時，實施模型的構建活動應該在精化階段就開始，一直持續到構建階段結束，因此工作量方面也要作出適當的調整，大體上向精化階段增加5％－10％的工作量，具體根據情況而定，大致劃分如下。
?先啟?精化?構建?產品化?
工作量?5?%?25－30?%?55－60?%?10%?
〈二〉部分核心工作流程的調整?
在RUP中，項目開發可以包含幾個主要的核心工作流程，包括業務建模、需求、分析設計、實施、測試、部署、配置與變更管理、項目管理和環境。在這里要特別注意的除了實施（上面已經介紹過）以外，測試和配置與變更管理對于BPEL4WS系統來說是非常重要的。
測試：?
測試的目的在于核實對象之間的交互、核實軟件的所有構件是否正確集成、核實所有需求是否已經正確實施、確定缺陷并確保在部署軟件之前將缺陷解決。在很多組織中，軟件測試占軟件開發費用的?30%?到?50%。但大多數人仍然認為軟件在交付之前沒有進行充分的測試。這個矛盾主要來自兩個方面的原因，第一個，測試軟件十分困難。給定程序具有無數的不同行為方式。第二個，測試通常是在沒有明確的方法，不采用必須的自動化手段和工具支持的情況下進行的。由于軟件的復雜性，無法實現完全測試，但采用周密的方法和最新技術水平的工具可以明顯提高軟件測試的生產率和有效性。
由于BPEL4WS系統的特點決定了我們應該在整個軟件生命周期的早期就啟動執行良好的測試，這將明顯降低完成和維護軟件的開支，關鍵是它還可以大大降低與部署質量低劣的軟件相關的責任或風險。由于外部WEB服務具有一些不確定性（接口的可變性等），我們應該將初期測試的重點放在對于那些與外部WEB服務接口相關聯的模塊的測試上，要盡早建立合理的測試用例進行測試，而且一定要將測試用例和測試結果進行文檔化，這樣可以在最后進行整合測試時作為十分有價值的參考。
維護階段的測試顯得更加的重要，對于BPEL4WS系統來說，其系統維護成本通常要占到總成本的40%左右，而且維護成本會受到用戶數目的嚴重影響，這是因為用戶越多，所發現的錯誤也越多。在這里要專門提到的是有關于在發生在系統維護階段的程序缺陷修復活動，有時看上去很輕微的錯誤，比如調用WSDL中提供的<operation>時，從<container>中取出的數據的數據類型與<operation>中的<message>的數據類型不符，本來應該是長整數，結果錯用成整數，這類錯誤雖然很難發現，但一旦在維護階段的實際使用中暴露出來后，修復工作還是較簡單的（只限于這個子系統）。由于維護人員常常不是編寫代碼的開發人員，而是一些初級程序員或者新手，結果更大范圍的修復工作常常會被忽視，尤其是涉及到其他子系統時。所以在BPEL4WS系統的維護階段，測試變得更加的重要。每次發現錯誤修復后，必須重新運行先前的所有測試用例，這樣才可以確保系統不會以更隱蔽的方式被破壞。
配置與變更管理：?
在配置與變更管理中，最重要的是一個組織的配置與變更請求管理系統（CM?系統），因為在CM系統中存放了有關該組織的產品開發、部署和維護流程等的重要信息，并且保留了執行這些流程時產生的階段成果。CM?系統是整個開發流程中的核心部分，它必不可少。對于BPEL4WS系統，我們已經注意到與我們息息相關的外部WEB服務具有無法避免的易變性（這是由于商業系統本身就是一個易變的系統，各種商業活動的規范和流程都可能隨時改變，因此導致所提供服務的改變，正像《人月傳說》中說的那樣"不變只是愿望，變化才是永恒"），因此對于這些易變性的捕捉就變得十分的重要，這可能在開發階段體現的還不是很明顯，但在系統維護階段就變得顯而易見了，沒人能保證自己系統用到的外部WEB服務的接口不會變，也沒有人可以預測什么時候變，所以對于我們來說只能以不變應萬變，做好配置與變更管理，而且要把重點放在系統中所調用的外部WEB服務的接口規則上，一定要保持同時更新，保證所涉及的每一個子系統能同步得到最新的變更通知。
〈三〉新的人員角色的增加?
在RUP中，所有的人員按角色劃分可分為分析員、開發人員、測試人員、經理、其他角色。由于在BPEL4WS系統中外部WEB服務對我們來說是最重要的問題，我們的一切操作都要依靠它們，所以我們必須針對它們提供專門的人員角色來負一些重要的活動。
對于分析員角色，我們應該設置專職人員負責外部WEB服務的調查工作（如接口規則以及性能特點的調查），他還要在測試階段和測試人員合作一起負責相關測試用例的生成，這類人員的工作可以為系統的設計和測試提供充足的參考。我們可以把這類人員角色稱為"外部服務審核員"。
對于其他角色，如果人力資源準許的話，應該增加專職的文檔管理員來專門負責有關整個系統所涉及的所有外部WEB服務的相關文檔的收集和整理，我們可以把這類角色稱為"外部服務文檔管理員"，"外部服務文檔管理員"的工作應該和"外部服務審核員"的工作緊密聯系，并且這兩種人員角色的工作與測試、配置與變更管理這兩個系統核心流程緊密相關，如圖2所示（這并不是說與其他的核心流程就沒有關系了，這只是說與這兩個核心流程的關系更加緊密罷了，這也是由BPEL4WS系統的特點所決定的）。
以上兩種人員角色的工作十分的重要，他們的工作降低了復雜的外部Web服務可能對系統開發帶來的干擾性程度，因此我們在作系統開發時要盡量分配專職人員負責這些工作。
?
圖2：新增人員角色
?
?回頁首?
?
給開發者的建議
BPEL4WS系統比起普通的分布式系統，它體現了一種更高級的分布式系統抽象模型，它體現了最新的分布式概念，它所依靠的一系列的新技術無一不體現了分布式和面向對象技術的飛速發展,而其中的WebServices技術正是基于組件的系統開發模式在多層分布式系統中的最好體現。新技術的出現自然要求整體軟件開發過程也要隨之進步、發展。現在越來越多的國內軟件組織已經認識到了規范軟件過程的重要性，作為軟件從業人員，應該在提高自身技術水平的同時注意對自己在軟件過程規范性方面的培養，有條件的軟件組織最好對開發人員進行有關PSP（Personal?Software?Process）方面的培訓并結合一個成熟的軟件過程（如RUP）來規范組織的開發流程，爭取使整個開發組織達到CMM2（可重復層）的水平，然后在此基礎上逐漸過渡到TSP（Team?Soft?Process），當PSP/TSP在軟件組織中確實開展起來，并且所有的軟件人員都認識到了過程規范的重要性，那么無論是CMM3，CMM4甚至是CMM5，我想也就會變得不是那么可望而不可及了。但所有的過程都不是萬能的，必須要結合自己組織的特點以及要開發系統的特點做出適當的調整才可以達到事半功倍的作用，一味的死搬硬套有時不僅不能起到積極的作用，還有可能挫傷軟件人員的工作積極性，我們一定根據自己軟件組織的特點，在實踐中不斷摸索經驗和總結自身的特點，不斷的持之以恒的改進自己的過程，我相信只有這樣才能取得最令我們滿意的效果。
?
?回頁首?
?
結束語
在本文中向讀者介紹了有關利用BPEL4WS語言進行系統開發時如何有針對性的利用現有成熟軟件過程RUP(Rational?Unified?Process)。由于篇幅的限制，將有關如何合理利用UML(Unified?Modeling?Language)進行系統建模的介紹放在了下一篇文章中，并且在下一篇文章中還會舉一個實際的例子(貫穿分析，設計和實現)來闡明有關利用BPEL4WS進行系統開發和商業流程架構時應注意的細節問題，希望能對大家的具體工作起到一些幫助作用。
在本篇文章中，如有任何錯誤或者不夠完善的地方請您與我聯系，我的郵箱地址是：?qwang@mb1.ksp.fujixerox.co.jp，十分感謝您的反饋意見。?
另外，由于我目前正在從事BPEL4WS語言的集成開發環境的設計和開發，如果您對這方面有什么好的建議也可以直接來信和我聯系，謝謝。
?
?回頁首?
?
參考資料?
1．商業流程開發新紀元－BPEL4WS語言介紹，第1部分：特點介紹及使用技巧提示?http://www.ibm.com/developerworks/cn/webservices/ws-bpel/part1/index.shtml?
2．BPEL4WS語言規范：?
英文版：?http://www.ibm.comhttp://www.ibm.com/developerworks/library/ws-bpel/?
3．RUP(Rational?Unified?Process)?http://www.rational.com/products/rup/index.jsp?
4．CMM（Capability?Maturity?Model?）,PSP（Personal?Software?Process）,TSP（Team?Software?Process）?http://www.sei.cmu.edu/?
?