企業(yè)應用架構選型
本文將首先考察企業(yè)應用的一般概念和需求；然后討論兩種目前最流行的企業(yè)級Java應用架構，分析它們滿(mǎn)足企業(yè)應用的需求的方式，最后清算一下兩種選型的代價(jià)和使用范圍。
企業(yè)應用的概念和需求
籠統地說(shuō)，一個(gè)“企業(yè)級應用系統”肯定是一個(gè)“服務(wù)于商業(yè)目的，處理企業(yè)業(yè)務(wù)信息，數據的軟件系統”。大概可以總結出以下五方面特征:
1．有復雜的業(yè)務(wù)邏輯
2．有大量持久化數據
3．與多種外部系統相關(guān)聯(lián)
4．有較高的性能要求
5．在運行時(shí)需要隨時(shí)監控，管理；應該能夠實(shí)時(shí)記錄，觀(guān)察系統運行情況，修改系統配置。
當然，開(kāi)發(fā)人員要設計，實(shí)現的并不是整個(gè)系統的所有部分。開(kāi)發(fā)人員只負責實(shí)現與業(yè)務(wù)相關(guān)的核心應用內容，其余的底層結構部分則是在架構選定之后，由相關(guān)的系統軟件提供(可能是AppServer或者是專(zhuān)門(mén)的框架產(chǎn)品)。開(kāi)發(fā)人員關(guān)心的是最終完成的“業(yè)務(wù)構件”，這些“構件”填入“架構”，形成了整個(gè)企業(yè)系統。
我們之所以把系統中這些有待開(kāi)發(fā)的關(guān)鍵部分稱(chēng)為“構件”，而不是“組件”或“對象”，是因為后面這兩種稱(chēng)呼，恰恰與兩種具體的架構選型有關(guān)。眾所周知，如果我們開(kāi)發(fā)的是一個(gè)EJB架構的企業(yè)應用系統，那么我們的實(shí)際工作是在編寫(xiě)EJB組件；另一方面，如果我們使用Spring框架開(kāi)發(fā)應用，那么我們寫(xiě)出的則主要是些POJO。
但無(wú)論采用哪種架構，由于前面提到的企業(yè)應用的基本特征，我們編寫(xiě)的“構件”都需要從架構系統軟件獲得一些關(guān)鍵支持或稱(chēng)為“基礎服務(wù)”。
1． 事務(wù)處理：確保關(guān)聯(lián)操作正常，完整的執行。
2． 持久性：實(shí)現數據的存儲，關(guān)系性數據與業(yè)務(wù)對象之間的映射。
3． 安全性：保證資源只被授權的客戶(hù)端訪(fǎng)問(wèn)。
4． 構件的生命周期管理和資源管理：負責構件的創(chuàng )建，銷(xiāo)毀，構件之間關(guān)系的維護，構件的裝池(pooling)和重用，并負責構件要用到的Socket，線(xiàn)程，數據庫連接等資源的分配，釋放和裝池。
5． 并發(fā)訪(fǎng)問(wèn)管理：處理多個(gè)客戶(hù)端對特定業(yè)務(wù)構件的并發(fā)訪(fǎng)問(wèn)。
6． 尋址服務(wù)：當業(yè)務(wù)構件需要調用其他對象/組件時(shí)，架構系統軟件應該提供相應的尋址機制，對調用者隱藏被調用者的實(shí)現細節。
以上列出的基礎服務(wù)，對于絕大多數企業(yè)應用都是不可或缺的。另外，考慮到企業(yè)級應用擴展，集成，升級的可能性，還有一些需求也應該屬于這里：
7． 遠程機制：如有業(yè)務(wù)構件和web構件不在同一物理層中，則往往有必要通過(guò)某種遠程機制（RMI或web service）暴露業(yè)務(wù)接口。
8． 集群機制：當企業(yè)應用的規模擴展，負載增加時(shí)，肯定會(huì )考慮添加備份服務(wù)器以提高處理效率。
9． 管理機制：可以是一個(gè)console界面或其他類(lèi)型的管理接口，供系統管理員實(shí)時(shí)掌握運行狀態(tài)，更改系統配置。
10. 日志機制：記錄系統運行信息和異常信息。
在理想情況下，業(yè)務(wù)構件應該能夠“透明的”享受以上大多數的基礎服務(wù)。一個(gè)常見(jiàn)的例子是日志機制，系統所采取的日志記錄格式，記錄媒質(zhì)，都應該獨立于核心的業(yè)務(wù)邏輯，業(yè)務(wù)邏輯只是隱式地使用了日志服務(wù)。
EJB架構
EJB架構是一種基于組件模型的系統架構，EJB容器提供了對事務(wù)處理，持久性，安全性，組件生命周期管理和資源管理，并發(fā)訪(fǎng)問(wèn)管理，尋址服務(wù)，遠程機制以及集群機制的內置支持。換句話(huà)說(shuō)，這是一座一上來(lái)就標榜“全功能”的豪華公寓。
事務(wù)處理：EJB容器負責實(shí)現底層事務(wù)服務(wù)，并通過(guò)JTA提供訪(fǎng)問(wèn)。
持久性：通常由Entity Bean實(shí)現。有BMP(通常DAO模式封裝)和CMP兩種。
安全性：EJB容器提供了聲明式安全性機制，可以通過(guò)配置實(shí)現基于role的訪(fǎng)問(wèn)限制。
組件的生命周期和資源管理：AppServer負責這些核心機制(pooling/callback)。
尋址服務(wù)：JNDI。
遠程機制：RMI/IIOP(EJB2.0技術(shù)規范)。SOAP(web service形式EJB2.1技術(shù)規范)。
集群機制：EJB架構同時(shí)支持縱向擴展和橫向擴展。
通過(guò)以上介紹我們發(fā)現，EJB架構提供了企業(yè)級應用的所有基礎服務(wù)(EJB開(kāi)發(fā)范式誕生的初衷)，但其中一些服務(wù)的實(shí)現存在缺陷，在應對特定業(yè)務(wù)場(chǎng)景的時(shí)候往往捉襟見(jiàn)肘；另一方面，所有這些服務(wù)都必須一籃子提供，即使只使用到了其中的少數幾個(gè)服務(wù)，我們也必須付出運行所有服務(wù)的代價(jià)。
另外，EJB采取的組件模型具有很強的“侵略性”，為了享用上述服務(wù)，業(yè)務(wù)構件必須具有EJB的接口聲明。
輕量級容器架構
很長(cháng)一段時(shí)間以來(lái)，EJB架構一直被認為是完整的J2EE方案中不可或缺的核心成分。但隨著(zhù)AOP，Ioc等技術(shù)的逐漸發(fā)展成熟，一些開(kāi)發(fā)者干脆放棄了EJB容器，轉而采取了一種全新的J2EE方案。
在EJB容器之外提供各種企業(yè)級基礎服務(wù)——輕量級容器架構不僅做到了這一點(diǎn)，而且讓開(kāi)發(fā)者感到了可貴的自由。針對EJB架構的兩大弊病a.一攬子提供所有服務(wù) b.組件接口的強侵略性，輕量級容器架構做出了徹底的變革：a.實(shí)現透明的“照單點(diǎn)菜”服務(wù)提供，使用者可以按需配置當前運行的服務(wù)；b.放棄組件開(kāi)發(fā)范式，采用POJO，基本上消除了EJB架構強加給業(yè)務(wù)構件的侵略性接口。
以下考察輕量級容器框架怎樣通過(guò)AOP，Ioc技術(shù)實(shí)現各項企業(yè)級服務(wù)的。
事務(wù)處理：
底層服務(wù)由專(zhuān)門(mén)的事務(wù)處理框架完成，業(yè)務(wù)對象可以采用編程方式實(shí)現事務(wù)(如事務(wù)模版)；但更好的方案是通過(guò)聲明實(shí)現(xml配置或者在源代碼中給出meta data注釋)。Spring框架在底層通過(guò)interception，為POJO業(yè)務(wù)對象添加事務(wù)功能。
持久性
Spring框架通過(guò)DAO模式實(shí)現對象持久性，并針對各種常見(jiàn)數據訪(fǎng)問(wèn)機制(如JDBC，JDO，Hibernate，iBatis，SQL Map)設計了專(zhuān)門(mén)的處理模版。
安全性
可以通過(guò)AOP攔截，實(shí)現基于聲明的安全機制，這通常比EJB安全機制更符合復雜的業(yè)務(wù)需求。
對象的生命周期管理和資源管理
生命周期管理由容器實(shí)現。對象無(wú)需具有特定接口，回調方法在配置聲明，以供容器到時(shí)自動(dòng)完成回調。資源尋址由容器完成，資源管理由容器調用底層服務(wù)實(shí)現。
并發(fā)訪(fǎng)問(wèn)管理
容器負責自動(dòng)處理并發(fā)請求；開(kāi)發(fā)者可以把業(yè)務(wù)對象視為單線(xiàn)程模型。
尋址服務(wù)
借助IoC架構，尋址服務(wù)由容器透明地實(shí)現，無(wú)需進(jìn)行顯示代碼，只需在配置文件中聲明對象之間的依賴(lài)關(guān)系即可。
遠程機制
Spring內置了對RMI, web services(JAX-RPC)的支持，另外還支持兩種輕量級的遠程機制：Hessian(一種二進(jìn)制協(xié)議)/Burlap(一種XML協(xié)議)。
集群機制
通常采用橫向集群方案，也就是添加整個(gè)應用系統的備份。
評價(jià)：與EJB容器相比，輕量級容器在事務(wù)處理，持久性，尋址以及構件生命周期管理/
資源管理機制方面具有較大優(yōu)勢。在安全性，并發(fā)訪(fǎng)問(wèn)，遠程機制方面與EJB容器相差無(wú)幾，也許在集群機制（本文沒(méi)有詳述消息處理機制，因為缺乏MDB的代替方案）方面與EJB容器有明顯差距。
選擇與代價(jià)
我們首先從系統開(kāi)發(fā)的角度，通過(guò)三個(gè)方面考慮兩種架構的差異。
1． 組件編程 vs. 對象編程
首先，組件的粒度大于對象，一個(gè)組件可以由多個(gè)對象構成。其次，組件不能脫離相關(guān)框架獨立存在，組件的生命周期完全由框架管理，并且在接口和實(shí)現中都顯示地依賴(lài)于框架中基礎設施，而在理想情況下，對象則可以單獨使用。最后，組件往往要求接口和實(shí)現之間的分離，用戶(hù)在使用組件時(shí)，只要知道接口定義即可；而一個(gè)對象則不一定具有這樣嚴格定義的接口特征。
EJB開(kāi)發(fā)體現了組件編程范式的典型特征，EJB不能須臾離開(kāi)容器存在。用EJB實(shí)現的業(yè)務(wù)組件無(wú)法擺脫對專(zhuān)門(mén)的接口和異常的依賴(lài)——這正暴露了EJB的“侵略性”。
基于輕量級容器的開(kāi)發(fā)則是傳統Component編程和POJO編程的一種混合體。由于它廣范采用了IoC地注入，回調機制，所以業(yè)務(wù)對象代碼中幾乎不存在對容器和相關(guān)服務(wù)的依賴(lài)；業(yè)務(wù)對象不需要容器特有的接口聲明，所以這些對象完全可以獨立于容器使用，測試。另一方面，業(yè)務(wù)對象一旦進(jìn)入容器，也仍然區別于傳統，單純的Java對象，它在整個(gè)生命周期中受到容器的全程管理，事實(shí)上，用戶(hù)對它的調用也會(huì )經(jīng)過(guò)容器多次攔截/代理。最后，即使是在輕量級容器架構中，通常也會(huì )鼓勵接口與實(shí)現之間的分離。
總上所敘，輕量級容器架構的自由隱含著(zhù)巨大的收益。另外從面向對象原則，測試調試，開(kāi)發(fā)效率等等角度來(lái)說(shuō)，對于大多數企業(yè)應用系統，輕量級架構都優(yōu)于EJB架構。
2． 正交性
EJB架構和輕量級容器架構，從“正交性”視角出發(fā)，它們的部分初衷都是區分，隔離與業(yè)務(wù)邏輯“正交”的各項系統功能，并改由容器提供相關(guān)服務(wù)，而不是手動(dòng)編碼實(shí)現。
如前文所述，EJB架構已經(jīng)抽象出了各種關(guān)鍵的企業(yè)服務(wù)，并且提供了聲明性的配置策略；而且在EJB容器本身的底層實(shí)現中，我們也已經(jīng)能看到對interception的大量應用。
但只有在明確地引入了AOP技術(shù)的輕量級架構中，我們才能看到更為徹底的功能正交劃分；interception能讓開(kāi)發(fā)者能夠以更靈活，更符合業(yè)務(wù)需求的形式定制基礎服務(wù)。
但應當注意的是，AOP也并非解決正交問(wèn)題的萬(wàn)應藥：“基礎服務(wù)”的很多細節，不可避免的要與“業(yè)務(wù)邏輯”混雜在一起——事實(shí)上，在很多時(shí)候它們就是“業(yè)務(wù)邏輯”的一部分。在一些特別繁復的應用場(chǎng)景中，與其為正交而正交，勉強隔離各項功能，不如考慮怎樣讓它們體面地共存。
因此，從正交性角度考慮，對于業(yè)務(wù)需求極為簡(jiǎn)單或極為復雜的場(chǎng)景，采用EJB架構也許還有優(yōu)勢，對于較復雜的場(chǎng)景，輕量級架構則可能更為適用。
3．“設計”vs.“補丁”
輕量級容器架構易于配置，易于即插即用地添加新功能，與EJB架構相比，這顯然隱含著(zhù)一種更靈活，更能隨機應變的開(kāi)發(fā)范式。
通過(guò)AOP增強業(yè)務(wù)對象，加入原先的設計中不包含的功能，這固然能夠一時(shí)應付全新的需求，但是采用了這種范式，開(kāi)發(fā)者確實(shí)傾向于“懶得”從一開(kāi)頭就把事情想清楚，傾向于懷疑理性預測未來(lái)的能力。如果啊AOP的興起只是助長(cháng)了這種編碼風(fēng)格，那么我們面臨的就不僅是兩種容器架構的分歧，而且還是“設計”與“補丁”這樣兩種精神取向的區別。
從這個(gè)角度考慮，也許應該首先預估系統業(yè)務(wù)需求變更地可能性，當需求相對固定時(shí)，EJB架構不乏可取之處；如果需求變化頻繁，那么也許應該考慮輕量級架構——但即使如此也應牢記，AOP的本意并不是“打補丁”。
