事務：在控制之中嗎？--附一些高深內容

2019-11-18 13:14:53

字體：大中小

來源：轉載

供稿：網友

　　BEA的WebLogic Platform 8.1的發布引起了行業分析家和IT從業者的極大熱情，他們熟悉到它的潛力使J2EE平臺的強大功能為更多的開發人員所使用。這使得J2EE架構師可以做它最擅長的工作--體系設計和技術問題的解決，同時答應"普通"開發人員使用由專家設計的體系結構，這些開發人員迄今為止還被限制于構建部門級的應用程序，因為他們缺少體系結構，從而缺乏可伸縮性來支持過去常使用的易用工具來生成的應用程序。
　　
　　WebLogic Platform的兩個要害特征可以把高級業務開發人員和高級J2EE架構師的職責分開--BEA WebLogic Workshop的運行時（runtime），它利用高級體系結構命令對資深業務人員施加影響；Workshop開發環境，它答應開發者通過一致的圖形抽象與環境相互作用，只有在需要表達業務規則而不是組裝應用程序時才轉變為代碼行。IDE同樣有幫助架構師的特性--它們可以產生骨架式的應用程序環境，植入標準組件等，并可以把這一環境以模板的形式向其他開發者發布，這使得業務程序員可以通過預先打包的方式和自動的方式快速啟動工程（重要的是，這是一個與開發標準及其他開發工程一致的快速啟動）。
　　運行時框架的要害部分是控件體系結構--控件提供了封裝業務邏輯的方法。業務開發者可以編寫業務規則，使用控件以組件的形式提供業務規則，或者封裝某些資源所需的復雜邏輯和基礎結構。J2EE架構師可以實現這一"硬核心管道化（plumbing）"并把它包裝在控件中，這樣應用程序開發者就可以很輕易地像使用他們自己的邏輯那樣地使用控件。這也解決了大型開發部門經常碰到的另一問題--J2EE編碼者編寫了許多非常優秀的基礎結構，但因為業務開發者不知道如何去使用它，所以它們只能被其他J2EE專家所使用。
　　從總體上來說，以J2EE開發者的角度來看，他們開始盡量避免做沉悶的、易錯的剪切和粘貼工作--讓我們做這些工作吧，它只不過是形成前端的另一個struts，或者只不過是另一個代碼摘錄來在JNDI查找JMS隊列并通過它發送消息，沒有人愿意干這種事。從非J2EE開發者的角度來說，用之前存在的組件組裝有用的應用程序（比如以一種新的方法組合現有子系統的另一套Web頁面）就變為可能，而這并不需要通過挑燈夜戰來學習J2EE知識。
　　
　　事務：您失去了計劃嗎？
　　對于事務我們究竟要做什么？什么都不需要，它只是背景。假如不討論它，我又怎么寫文章？它是什么？哦……
　　
　　事務、Workshop和控件
　　控件只是簡單的有注釋的java對象--這些注釋提供了答應控件用戶在高于通常的J2EE接口的抽象級工作的能力。當部署控件（實際上可能是多個控件的組合）時，注釋對生成運行時聯結（它是真正被部署的部分）起推動作用。與其他任何Java對象一樣，控件從調用者中繼續了事務上下文。因為控件沒有遠程接口的概念（至少當前的版本沒有），所以調用者通常是由包含在EJB中的WebLogic Workshop生成的輕重量級控件容器。假如您查看與這個（WebLogic Workshop治理的）EJB關聯的部署描述符，就會看到它有"容器"的事務策略--這樣控件的事務上下文可以由EJB容器使用JTA提供，就像該控件是您編寫的并從EJB代碼調用的簡單陳舊的Java對象。
　　Workshop中最接近遠程接口的事務是Web服務--它很輕易得到控件并把控件表現為Web服務（潛在的和對話Web服務），而不僅僅是一些鼠標的單擊，這樣剩下的問題就是……
　　
　　什么是Workshop Web Service的默認事務行為？
　　當對Web服務方法進行調用時，從消息到達調用的聯接已經通過大量J2EE（這完全取決于您在注釋里的聲明）機制完成，最后到達具有容器治理事務的EJB中。在執行方法期間， JTA事務將會運行。
　　假如方法成功，事務會進行提交。假如方法失敗（拋出Exception），事務將會回滾。就是這么簡單。
　　回憶這一點，即使WebLogic Workshop Web服務是可會話的（假如注釋是這么說）。會話狀態保存在數據庫的表中，這一持久狀態是如何與任何應用程序治理的持久狀態關聯的呢？它們包含在同一事務的上下文中。這樣假如您的方法失敗了，就似乎這段會話從來沒有發生過。精細自動的行為事務是受歡迎的。這對部署意味著，在默認情況下，對話狀態通過cgDataSource數據源保存。假如您的應用程序狀態保存在別的地方，您可能會得到錯誤提示：不能通過事務影響數據源，因為它已經影響了作為cgDataSource底層的cgPool。您可以通過兩種方法來修正該錯誤：要么更改cgPool來使用xa的數據庫訪問并得到兩階段的提交，要么讓會話狀態和應用程序狀態通過相同的連接池保留在同一數據庫實例中（Workshop的jws-config.PRoperties文件從WorkShop角度進行控制）來避免兩階段的提交需要。
　　假如一個Workshop Web服務調用另一個Web服務，在事務的上下文不會被傳播，這樣被調用的服務將根據我剛才概述的規則來運行它自己新的事務。假如您希望失敗的服務調用回滾到調用者的事務，請重新向該架構拋出異常。假如想不管Web服務調用的失敗來保存調用者（包括應用程序和會話)的狀態，則可以捕捉到異常但不重新拋出。
　　當然，現在應用的是事務的通常規則。假如您想保存一些數據（比如審計記錄）而不考慮事務最終的結果，則您需要用到TransactionManager對象，在調用之前掛起事務，并在稍后進行恢復。對非J2EE的高手來說這是很常見的，因為這會使該對象成為J2EE架構設計師應該實現并提供給應用程序開發人員作為預先構建的控件。
　　
　　要害是，它沒關系！
　　最后的幾百字對于許多應用程序開發者來說有些高深（至少是接近于高深）。而這就是要害。假如J2EE架構設計師理解了這些內容，并且當他們在做應用程序開發時把模板和開發方針一起使用時想到了這些內容，那么應用程序的開發人員就不需要擔心--框架代表他們做正確的事情，它們也會很快地開發出更多應用程序，與沒有指引正確方向的框架和模板相比，這些應用程序的行為更具有一致性。這意味著IT部門在下一次業務需求再次調整的緊急關頭可以面帶微笑并說沒問題，而不是嘀咕著更新自己的簡歷。

上一篇：Java.until.Map,Set,List的資料整理

下一篇：Java程序的性能優化StringBuffer與Vector