Posted on 2009-06-06 09:03
thui 閱讀(2859)
評(píng)論(3) 編輯 收藏 所屬分類:
java技術(shù)
JBoss 的部署架構(gòu)可以分為三個(gè)部分：熱部署機(jī)制、部署的通用流程、部署的過程。
熱部署機(jī)制，使得我們?cè)诓恍枰貑Boss的情況下，可以增加、修改和刪除部署單元。JBoss會(huì)在運(yùn)行時(shí)“察覺”到這些變化，并做出相應(yīng)的處理。
部署的通用流程，是一個(gè)對(duì)不同類型的部署單元都適用的部署過程。JBoss支持多種部署單元，包括jar格式的EJB組件、war格式的Web組件、ear格式的企業(yè)應(yīng)用組件、sar格式的服務(wù)組件、har格式的hibernate應(yīng)用等等。不同類型組件的部署過程是不同，但從宏觀的角度看，它們還有一個(gè)通用的流程。
部署的過程，就是每種類型組件自己獨(dú)特的部署操作。每種類型的組件都由一個(gè)特定的子部署器來完成部署過程。子部署器都是org.jboss.deployment.SubDeployer的子類。
部署單元可以是一個(gè)壓縮包，也可能一個(gè)目錄。JBoss使用DeploymentInfo對(duì)象來封裝部署單元的相關(guān)信息，在部署的過程，對(duì)DeploymentInfo對(duì)象進(jìn)行操作。
在這篇文章中，我將介紹熱部署機(jī)制和部署的通用流程。由于可部署組件的類型太多，我就不一一介紹每種組件部署的過程。
首先，我先介紹部署的通用流程。
每種組件的部署都有三個(gè)階段，依次是init、create和start。這三個(gè)階段構(gòu)成了部署的通用流程。整個(gè)流程由org.jboss.deployment.MainDeployer負(fù)責(zé)管理。MainDeployer作為一個(gè)MBean，在JBoss啟動(dòng)時(shí)被創(chuàng)建。部署一個(gè)組件，從調(diào)用MainDeploy的deploy方法開始。Deploy首先會(huì)調(diào)用MainDeploy的init方法，進(jìn)入init階段。如果這一階段執(zhí)行成功，則接著調(diào)用MainDeploy的create方法，進(jìn)入create階段。如果這一階段也執(zhí)行成功，則調(diào)用MainDeploy的start方法，進(jìn)入start階段。如果這一階段也執(zhí)行成功，那么整個(gè)部署就成功了?，F(xiàn)在讓我們看看MainDeploy在每個(gè)階段都做了什么事情。
Init階段：
首先，MainDeployer需要判斷部署單元是否要被解壓縮和拷貝到臨時(shí)目錄。一般來說，部署單元是被方法${JBOSS_HOME}/server/default/deploy目錄下。如果部署單元是一個(gè)目錄，那么就直接部署。如果部署單元是一個(gè)壓縮包，就需要將它解壓到${JBOSS_HOME}/server/default/tmp/deploy。解壓縮是可以理解的，為什么需要拷貝到臨時(shí)目錄呢？如果直接解壓縮到deploy目錄，那么JBoss就會(huì)將解壓后的目錄視為一個(gè)新的部署單元。這樣，一個(gè)部署單元被部署兩次，這是不可以的。
然后，MainDeployer將為部署單元查找能夠部署它的SubDeployer。例如，MainDeployer會(huì)為EJB組件找到EJBDeployer。所有的SubDeployer同MainDeployer一樣，都是在JBoss啟動(dòng)時(shí)創(chuàng)建的。而且，每個(gè)SubDeployer都被注冊(cè)到MainDeployer中，這樣MainDeloyer就能找到它們。那么，MainDeployer是如何查找的呢？每種SubDeployer都會(huì)實(shí)現(xiàn)一個(gè)accepts方法，這個(gè)方法接收DeploymentInfo對(duì)象作為參數(shù)，并判斷自己能不能部署它。如果能，返回true，否則返回false。MainDeployer就依次調(diào)用每個(gè)SubDeployer的accepts方法，MainDeplpyer將第一個(gè)返回true的SubDeployer，作為部署單元的SubDeployer。
接著，MainDeployer將部署單元添加到部署等待隊(duì)列中。這個(gè)隊(duì)列的作用是，如果某個(gè)部署單元因?yàn)橐蕾?/span>關(guān)系不滿足，而不能被部署，則將它暫存起來。但依賴關(guān)系滿足時(shí)，MainDeployer就可以從等待隊(duì)列中將它取出，并重新部署。
再接著，MainDeployer將調(diào)用部署單元的SubDeployer的init方法，進(jìn)行特定于組件類型的初始化工作。
接著，MainDeployer為部署單元?jiǎng)?chuàng)建一個(gè)統(tǒng)一類加載器UCL，這個(gè)與JBoss的類加載器架構(gòu)有關(guān)。
再接著，MainDeployer讀取MANIFEST.MF文件，如果有引用的jar，將它們作為子部署單元，添加到部署單元中。
最后，調(diào)用MainDeployer.init方法（這是一個(gè)遞歸的過程），初始化所有的子部署單元。
Create階段：
首先，調(diào)用MainDeployer.create方法，創(chuàng)建所有的子部署單元。然后，調(diào)用部署單元的SubDepoyer的create方法（這是一個(gè)遞歸的過程），進(jìn)行特定于組件類型的創(chuàng)建工作。
Start階段：
首先，調(diào)用MainDeployer.start方法，啟動(dòng)所有的子部署單元。然后，調(diào)用部署單元的SubDeployer的start方法（這是一個(gè)遞歸的過程），進(jìn)行特定于組件類型的啟動(dòng)工作。最后，檢查部署單元關(guān)聯(lián)的所有MBean是不是都已經(jīng)啟動(dòng)。如果沒有的話，整個(gè)部署就失敗了。
下面，我再介紹一下熱部署機(jī)制。熱部署機(jī)制的實(shí)現(xiàn)是很比較復(fù)雜的，有很多技術(shù)問題需要解決。但是它的結(jié)構(gòu)是很簡(jiǎn)單的。所有需要熱部署的部署單元都方法deploy目錄下，有一個(gè)專門監(jiān)視該目錄的線程，它定期掃描目錄下的部署單元。如果有新的部署單元被添加進(jìn)來，或者某個(gè)部署單元被刪除掉，該線程就會(huì)通知MainDeloyer部署或銷毀該部署單元。如果某個(gè)部署單元被修改，該線程就會(huì)通知MainDeployer充新部署該部署單元。該線程是通過文件的修改時(shí)間，來判斷某個(gè)部署單元是否被修改。org.jboss.deployment.scanner.URLDeploymentScanner負(fù)責(zé)熱部署的執(zhí)行。它作為一個(gè)MBean，在JBoss啟動(dòng)時(shí)被創(chuàng)建。JBoss啟動(dòng)時(shí)，會(huì)調(diào)用它的createService方法。該方法又會(huì)其父類AbstractDeploymentScanner的createService方法。其父親的createService方法會(huì)創(chuàng)建一個(gè)ScannerThread線程，這個(gè)線程每隔一段時(shí)間就會(huì)調(diào)用URLDeploymentScanner的scan方法。scan方法的工作就是檢查deploy目錄下的變化，并調(diào)用MainDeployer的相應(yīng)方法來進(jìn)行重新部署、銷毀等操作。