JavaEE應用程式

標籤：abi   spell   叢集   邏輯   ack   聲明   應用   article   互動   

一直想寫一些關於JavaEE的東西，從剛開始看《Ejb in Action》的時候就想寫，總是感覺自己知道的太少了、太不值得一提了、太欠缺了（我太謙虛了）……哈哈哈。到後來工作中一直在使用JavaEE的相關技術。開源的那些流行架構（SSH以及以Spring為核心的Spring家族的東西）丟的也差點兒相同了。工作的時候JavaEE企業級的東西把自己搞的也跟傻子似的。回過頭來看看總結一下避免自己真的成了傻子。

先從“組件”（component）說起，不知道從什麼時候開始人們希望軟體開發就像孩子搭積木似的能夠是組裝的。隨之而來的一個概念就是“組件”，用專業一些的話說就是“組件是一個自包括的、能夠重用的軟體單元，能夠把它整合到應用程式中”。更加直白一些說就是一塊積木是能夠獨立完畢一項任務的，並且這個塊積木是能夠被多個地方使用的（想想螺絲、螺母大一些的話想想發動機、變速器相信能協助讀者理解“組件”這個概念）。在Java中組件的最簡單形式是JavaBean。我們通常叫bean。

講到這剛開始學習的人聽到這個詞會罵街。豬八戒，豬悟能、豬剛鬣、木母、淨壇使者、天蓬元帥一堆名字到頭來不就是一頭豬麼！

什麼bean，Javabean到頭來不就是Java中的類麼。

罵街歸罵街，不同的名稱在不同的地方是有意義的。

天蓬元帥指這頭豬在天庭當官時候的稱呼，豬八戒是這頭豬跟了唐僧之後的稱呼，豬剛鬣是豬在高老莊時期的稱呼……好像說遠了。總之要說的是不同的名稱所包括的意義以及要反應的東西是有差別的千萬不要一葉障目。如今JavaBean的這個名字你理解了吧？

在企業範圍內，組件更專註於實現商務服務。同一時候依據組件可啟動並執行業務操作定義組件的協定。Java EE的標準組件模型是EJB模型，它定義了封裝、部署以及與自包括商務服務進行互動的方式。

EJB的類型決定了須要與之互動的協定。會話bean（Session bean）使用標準的Java介面來定義能夠調用的業務方法集合。而訊息驅動bean（message-driven bean）的行為取決於bean旨在接受的訊息類型和格式。

上面的這段話是非常官方的。總結成接地氣的話就是在JavaEE領域不同類型的組件有著其自身的規範，這些組件能夠依照其自身的規範來完畢商務服務。

啊。好抽象……

在我們平時開發其中時候使用組件模型是可選的，一般來說能夠用會話bean的Container Service也可用servet。

結果導致如今大多數Web應用程式全然避開了EJB，直接從Servet到資料庫。

這也導致了以Spring為核心的Spring家族以及類Spring家族的開源架構的蓬勃發展。

在使用組件的時候我們須要以層的形式組織應用程式，其中商務服務處於組件模型中。且表示服務層位於它之上（你可能在想MVC了。就筆者如今的理解EJB與MVC的關係不是包括也不是並列的關係。他們是……以後再說）。

眼下之所以非常多Web應用程式不選擇EJB是因為曆史上EJB的複雜性。相對於EJB2來說EJB3吸收了非常多開源架構的思想，眼下能夠說已經非常easy了。隨著複雜性這個問題得到解決人們開始漸漸的收穫定義明白的商務服務集合所帶給應用程式的優點。（拗口吧，意思就是EJB已經不像之前那麼不複雜了，牛X了，開始好用了，謔哈哈哈）。

l  鬆散耦合（oose couping）。以組件的思想組織商務邏輯，更easy寫出松耦合的代碼。

l 依賴性管理（dependencymanagement）。不管是註解還是設定檔。容器和人（主要是人）都能一目瞭然。

l 生命週期管理（ifecyce management）。組件由容器定義和管理能夠統一處理資源的擷取和釋放。

l 聲明性Container Service（decarativecontainer service）。組件的業務方法是由應用server所截獲。所以並發性、交易管理、安全性以及遠端這些服務不須要分散開發人員過多的精力。

l 可移植性（portabiity）。一個應用程式在Tomcat下能跑那麼Gassfish也能用。在Webogic下沒問題那麼Jboss下也不會有太大的問題，講到這IIS不吭聲了。

l 可擴充性和可靠性（scaabiity and reiabiity）。

應用server旨在確保組件能夠有效地實現可擴充性管理。依據組件的類型和server配置，使用組件實現的業務操作能夠重試失敗了的方法調用，或者甚至把容錯移轉到叢集上的還有一台server（考慮RMI）。

JavaEE應用程式