版權(quán)聲明：任何獲得Matrix授權(quán)的網(wǎng)站，轉(zhuǎn)載時(shí)請(qǐng)務(wù)必以超鏈接形式標(biāo)明文章原始出處和作者信息及本聲明
作者:Palash Ghosh;
kelvincheng
原文地址:
http://www.onjava.com/pub/a/onjava/2005/03/23/components.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43899_Java_Component_Developmen.html
關(guān)鍵詞： Java Component Development
我先介紹幾個(gè)在構(gòu)建和設(shè)計(jì)解決方案來(lái)適應(yīng)商業(yè)活動(dòng)中的持續(xù)變化時(shí)需要注意的商業(yè)場(chǎng)景:
·公司需要將其文件倉(cāng)庫(kù)從文檔文件轉(zhuǎn)成網(wǎng)絡(luò)文件。
·公司需要更換其安全提供商。
·因?yàn)榻?jīng)濟(jì)情況的巨大的改變，保險(xiǎn)公司必須擴(kuò)展其保險(xiǎn)流程政策到更大范圍。
一樣?xùn)|西是很確定的，需求更改就像商業(yè)和技術(shù)一樣快速改變。但是對(duì)于所有改變，無(wú)論其大小，我們都需要拋棄原來(lái)整個(gè)系統(tǒng)重新開(kāi)始么？這是不必要的—架構(gòu)和設(shè)計(jì)解決方案時(shí)加入少許考慮，好的策略以及最優(yōu)方法可以適應(yīng)現(xiàn)有的體系結(jié)構(gòu)的變更而不需要太多爭(zhēng)辯。
在面向?qū)ο缶幊桃约胺植际綄?duì)象技術(shù)中，組件是類(lèi)和接口的集合，通過(guò)可重用的外部API來(lái)滿足需求（功能性的以及非功能性的）。組件應(yīng)該可以在分布式網(wǎng)絡(luò)環(huán)境運(yùn)行來(lái)形成網(wǎng)絡(luò)程序。基于組件的設(shè)計(jì)和開(kāi)發(fā)對(duì)于遵循面向?qū)ο蠓治雠c設(shè)計(jì)（OOAD）的方法學(xué)的專(zhuān)家并不是新的話題。
本文的目的是根據(jù)java的最優(yōu)方法和最初開(kāi)始一步一步地達(dá)到通用的概念模型來(lái)開(kāi)發(fā)java組件。本文面向的讀者需要具有Java，UML以及Java/J2EE設(shè)計(jì)模式的知識(shí)。這篇文章主要描述的范圍是：
·組件的基本性質(zhì)。
·如何利用Java設(shè)計(jì)最優(yōu)方法（設(shè)計(jì)模式）來(lái)實(shí)現(xiàn)這些Java組件設(shè)計(jì)的基本性質(zhì)，并且形成一個(gè)概念上的基本組件開(kāi)發(fā)框架, 這個(gè)框架將來(lái)可以方便地用于任何組件開(kāi)發(fā)中的。
組件的基本性質(zhì)
·為了讓其他組件可以與之相互作用，組件必須有服務(wù)接口（API）。
·組件必須有合適的生命周期機(jī)制（start, stop, initialize等等）
·組件必須可以配置。
·組件只有一個(gè)實(shí)例在企業(yè)程序中運(yùn)行。
·配置的改變應(yīng)該是動(dòng)態(tài)的（在運(yùn)行中）。
·組件必須有合適的第三方軟件融入的機(jī)制。
·組件必須有合適的處理錯(cuò)誤機(jī)制
如何實(shí)現(xiàn)基本的組件性質(zhì)
組件必須有服務(wù)接口（API）
無(wú)論我們是在一個(gè)類(lèi)還是幾個(gè)類(lèi)中寫(xiě)100行到1000行的代碼，最終勞動(dòng)成果（類(lèi)或者類(lèi)的結(jié)合）提供一些基本的高級(jí)的服務(wù)。返回去想想，我們甚至可以在實(shí)現(xiàn)他們之前定義那些我們想要達(dá)到的基本的高級(jí)的服務(wù)。
讓我們舉個(gè)來(lái)自保險(xiǎn)界的例子，保險(xiǎn)商在他每天做了以下的工作：
·檢查保險(xiǎn)申請(qǐng)。
·收集并評(píng)估背景信息。
·根據(jù)公司現(xiàn)有的規(guī)則計(jì)算保險(xiǎn)金
·從其他部門(mén)收集信息以及各種各樣的報(bào)告（醫(yī)學(xué)等等）。
·準(zhǔn)備相關(guān)的政策。
現(xiàn)在我們?nèi)绻雽?xiě)一個(gè)保險(xiǎn)商的商業(yè)組件，我們必須有如圖1的服務(wù)接口以及其實(shí)現(xiàn)：
Figure 1. Underwriter service interfac
當(dāng)其他組件請(qǐng)求保險(xiǎn)商組件的服務(wù)時(shí)，并不需要考慮組件內(nèi)部的操作。封裝其商業(yè)邏輯讓組件更易維護(hù)及擴(kuò)展。
服務(wù)組件將有一個(gè)主要的服務(wù)實(shí)現(xiàn)類(lèi)（服務(wù)接口的實(shí)現(xiàn)）以及這個(gè)類(lèi)使用助手類(lèi)，這個(gè)類(lèi)是組件的一部分，同時(shí)也可能使用其他的組件
在產(chǎn)品開(kāi)發(fā)中，我們也須有許多組件提供不同的服務(wù)。例如，在保險(xiǎn)業(yè)，我們有“索取流程組件”，“投保人服務(wù)組件”以及其他更多組件。所以我們必須有個(gè)機(jī)制來(lái)在企業(yè)解決方案中注冊(cè)這些服務(wù)組件，使其可以根據(jù)企業(yè)的特殊需要采用或者中止這些服務(wù)。
下面是XML結(jié)構(gòu)的例子，它可以自動(dòng)處理服務(wù)注冊(cè)的流程。
<Services>
<Service>
<Serviceid>S001</Serviceid>
<ServiceName>UnderwriterService</ServiceName>
<ServiceImplClass>
com.org.service.UnderWriterServiceImpl
</ServiceImplClass>
</Service>
<Service>
<ServiceId>S002</ServiceId>
<Servicename>PolicyHolderService</ServiceName>
<ServiceImplClass>
com.org.service.PolicyHolderServiceImpl
</ServiceImplClass>
</Service>
</Services>
組件應(yīng)該具有合適的生命周期機(jī)制
組件也需要一個(gè)在它的生命周期內(nèi)置的，可見(jiàn)的，獨(dú)立的機(jī)制，所以它可以根據(jù)需要被開(kāi)始和中止。ComponentControllerFactory（組件控制工廠）是singleton，因?yàn)槠渲恍枰粋€(gè)實(shí)例。這個(gè)工廠負(fù)責(zé)根據(jù)配置內(nèi)容為不同的提供商創(chuàng)建類(lèi)的實(shí)例。ComponentControllerFactory扮演雙重角色：首先其通過(guò)其init(),reload()等等方法來(lái)管理組件的生命周期（這就是為什么它是一個(gè)“工廠”），圖2顯示其方法
Figure 2. Component controller factory
組件的生命周期方法是:
·doStart(): 開(kāi)始組件
():幫助其從XML配置文件中取得配置對(duì)象，負(fù)責(zé)創(chuàng)建適當(dāng)?shù)念?lèi)的實(shí)例
·doStop():停止組件
·reload():如果當(dāng)組件已經(jīng)開(kāi)始但XML配置文件發(fā)生更改，這個(gè)方法將重新讀取XML配置文件并重啟逐漸。
·getInstance():返回ComponentControllerFactory類(lèi)的實(shí)例
一個(gè)組件應(yīng)該是可配置的
通常，每個(gè)組件有自己的可配置的不經(jīng)常改變的參數(shù)。例如，假設(shè)我們需要寫(xiě)一個(gè)緩存組件，它需要每小時(shí)從數(shù)據(jù)庫(kù)取得半靜態(tài)的數(shù)據(jù)來(lái)刷新本身狀態(tài)。更新的時(shí)間應(yīng)該在配置文件中設(shè)置，那樣我們可以不更改源代碼來(lái)更改參數(shù)的值。
下面是關(guān)于logger組件的XML配置文件的例子，專(zhuān)用于管理企業(yè)程序各個(gè)層次的logging。
<LoggingServiceProvider>
<Provider>
<ProviderName>Apache</ProviderName>
<AdapterImpl>com.org.integration.adapter.Log4jAdapter
</AdapterImpl>
<Enable>true</Enable>
</Provider>
<Provider>
<ProviderName>WebLogic</ProviderName>
<AdapterImpl>com.org.integration.adapter.WebLogicAdapter
</AdapterImpl>
<Enable>false</Enable>
</Provider>
</LoggingServiceProvider>
在企業(yè)應(yīng)用中組件只有一個(gè)實(shí)例在運(yùn)行
一個(gè)組件應(yīng)該有且只有一個(gè)實(shí)例在運(yùn)行，而Singleton設(shè)計(jì)模式是合適的選擇來(lái)保證在JVM中只有一個(gè)實(shí)例。但是當(dāng)這種模式在單一JVM情形下可行，但是在多JVM情形下就有問(wèn)題。但是由于配置信息在組件開(kāi)始時(shí)載入而不需要改變并處理所有靜態(tài)信息，用Singleton設(shè)計(jì)模式依然可行
我們假設(shè)組件可以在單JVM情況下可行，ComponentControllerFactory將會(huì)如圖3那樣：
Figure 3. Component controller factory in a single JVM
Singleton控制工廠提供的方法是
·getXXXService():方法返回在XML文件中定義的服務(wù)提供的實(shí)現(xiàn)類(lèi)
·getXXXAdapter():方法返回在XML文件中定義適配實(shí)現(xiàn)類(lèi)
配置文件的更改應(yīng)該是動(dòng)態(tài)的
如果組件是不可變的，每串代碼應(yīng)該有與singleton實(shí)例同樣的拷貝，但是如果它是不是不變得，我們需要改變時(shí)，配置文件需要?jiǎng)討B(tài)改變。
有兩種可能的情況但動(dòng)態(tài)配置文件更改：
·單一JVM情況
·多JVM情況
單一JVM情況
如果程序在單一JVM中運(yùn)行，事情就簡(jiǎn)單得多了。我們已經(jīng)知道，SingletonControllerFactory通常在JVM中有一個(gè)實(shí)例，所以任何時(shí)候配置文件發(fā)生任何改變，將需要根據(jù)一些通知機(jī)制輪流載入java串行的配置對(duì)象來(lái)重新載入工廠對(duì)象。這是基于Observer-Observable模式并做兩件事：
·通過(guò)XMLizer（單獨(dú)的組件）來(lái)讀取和處理XML配置文件并載入Java配置對(duì)象。
·監(jiān)視XML配置文件可能發(fā)生的更改。
圖4顯示ConfigManager的方法：
Figure 4. ConfigManager
ConfigManager類(lèi)當(dāng)被Observable通知時(shí)扮演Observer角色，其更新方法將會(huì)被調(diào)用。Update()方法將會(huì)調(diào)用SingletonControllerFactory的reload()方法，所以新創(chuàng)建的java對(duì)象將會(huì)從其配置信息中重新載入。
ConfigurationChangeNotifier扮演Observable的角色并在XML配置文件發(fā)生更改時(shí)啟動(dòng)通知ConfigManger線程，并將指出其內(nèi)容上的改變。圖5顯示其關(guān)系：
Figure 5. ConfigurationChangeNotifier
多JVM情況
在多JVM情況下，事情就不會(huì)變得這樣簡(jiǎn)單。我們必須有
·需要機(jī)制在運(yùn)行時(shí)來(lái)動(dòng)態(tài)載入更改的XML配置文件而不關(guān)閉整個(gè)企業(yè)程序。
·需要機(jī)制保證在群中只有一個(gè)實(shí)例在運(yùn)行。
結(jié)合RMI利用JNDI是一種選擇來(lái)保證在集群環(huán)境中的多個(gè)節(jié)點(diǎn)中的特定的一個(gè)節(jié)點(diǎn)自由一個(gè)實(shí)例在運(yùn)行。RMI服務(wù)需要編寫(xiě)，同時(shí)RMI stub要在RMI服務(wù)之外創(chuàng)建。創(chuàng)建的RMI stub需要被綁定在程序服務(wù)器的JNDI樹(shù)上。這個(gè)對(duì)象將保持在container中，container可以讓對(duì)象在集群中都可以用到。
為了處理這種情況，我們需要引入ConfigManager，它將會(huì)做一下任務(wù)：
·創(chuàng)建需要可以動(dòng)態(tài)改變的XML配置文件。
·創(chuàng)建來(lái)自XML文件的java串行文件。串行和非串行化將會(huì)在不同的組件中完成。
·創(chuàng)建RMI服務(wù)，注冊(cè)從RMI服務(wù)中創(chuàng)建的RMI stub,并通過(guò)RMI服務(wù)載入串行配置對(duì)象。
·將RMI stub與集群環(huán)境中的JNDI樹(shù)的任何節(jié)點(diǎn)綁定。
·創(chuàng)建通知系統(tǒng)，其將重新綁定RMI服務(wù)并當(dāng)XML文件似乎發(fā)生變化時(shí)重新載入對(duì)象。
圖6顯示RMI服務(wù)的接口以及其實(shí)現(xiàn)：
Figure 6. RMI service
在多JVM情況下，ConfigManager如圖7：
Figure 7. ConfigManager in a multiple-JVM scenario
ConfigManagerMultipleJVM 類(lèi)扮演Observer的角色。當(dāng)他被Observable通知時(shí)，其update方法將會(huì)被調(diào)用。通過(guò)update()方法，rebindRMIService()方法將會(huì)被調(diào)用，這樣新創(chuàng)建的對(duì)象（通過(guò)最新的配置信息）將會(huì)被重新載入。
SingletonControllFactory將會(huì)為RMI服務(wù)扮演wrapper角色，返回合適的已配置的對(duì)象。
這種方法的會(huì)產(chǎn)生問(wèn)題，因?yàn)橹挥幸粋€(gè)實(shí)例，所以只可以允許一個(gè)點(diǎn)的錯(cuò)誤。ConfigManager組件需要更強(qiáng)壯來(lái)處理錯(cuò)誤。
但是同樣有其他的方法，通過(guò)MDB和JMS在群眾的不同節(jié)點(diǎn)同步緩存的配置對(duì)象。在這種情況下，并不需要RMI服務(wù)。下面是實(shí)現(xiàn)這種方法的步驟：
·SingletonControllerFactory通過(guò)配置對(duì)象初始化并開(kāi)始組件。
·ConfigManager的Observer-Observable模型通過(guò)其通知機(jī)制來(lái)跟蹤XML配置文件的任何變更。當(dāng)發(fā)現(xiàn)更改時(shí)，他將公布消息到JMS topic。
·運(yùn)行在集群環(huán)境中的每個(gè)群中的MDB觸發(fā)其onMessage()方法，并載入更改的配置Java對(duì)象。
組件應(yīng)該有合適的第三方軟件整合機(jī)制
如果組件依賴(lài)第三方軟件整合來(lái)建立服務(wù)，第三方API不應(yīng)該直接在實(shí)現(xiàn)類(lèi)中使用。最佳的策略是開(kāi)發(fā)適配器并隔離第三方軟件調(diào)用和適配器的實(shí)現(xiàn)。
圖8顯示調(diào)用logger組件的適配器的例子，演示了如何讓其更方便的適應(yīng)第三方APIs。
Figure 8. Application logger interface
利用adapter模式的優(yōu)點(diǎn)是更容易的和第三方軟件APIs合并。此外，當(dāng)這些APIs改變時(shí),適配實(shí)現(xiàn)需要改變，而用此適配接口的服務(wù)將不需要改變。
通過(guò)XML配置文件從不同的適配器中選擇是便利的，就如上面這節(jié)介紹的那樣。
組件應(yīng)該有合適的錯(cuò)誤處理機(jī)制
每個(gè)組件應(yīng)該有自己的異常處理類(lèi)，它可以幫助捕捉適當(dāng)?shù)漠惓！＜僭O(shè)我們對(duì)于特定的即將使用的商業(yè)程序有單獨(dú)的組件來(lái)處理異常。這個(gè)特定組件異常類(lèi)（Underwriter exception）將會(huì)使需要的服務(wù)脫離異常處理組件。
Figure 9. Component exception handling
這個(gè)異常處理類(lèi)是特定用于Underwriter服務(wù)并擴(kuò)展基于企業(yè)程序的異常類(lèi)。其工作就是掩蓋在服務(wù)類(lèi)中產(chǎn)生的異常并重新釋放他。
結(jié)論
總的來(lái)說(shuō)，以下是整合的基本步驟：
·作為程序開(kāi)始過(guò)程的一部分，ConfigManager鍵通過(guò)XMLizer（用于XML-to-java對(duì)象轉(zhuǎn)換的單獨(dú)對(duì)象）來(lái)為不同的組件讀取XML配置文件，并通過(guò)程序服務(wù)器節(jié)點(diǎn)的JNDI tree來(lái)綁定Java配置對(duì)象。
·作為程序開(kāi)始過(guò)程的一部，配置對(duì)象將會(huì)被讀取，因此相關(guān)的provider/adapter/service需要被說(shuō)明。
·如果配置文件發(fā)生更改，ConfigManager將讀取更改后的XML文件并重新綁定配置對(duì)象。
·組件將會(huì)重新載入配置對(duì)象并根據(jù)其最新更改來(lái)重新初始化。
回到我們開(kāi)始的地方，當(dāng)你計(jì)劃開(kāi)發(fā)強(qiáng)壯的系統(tǒng)時(shí)組件框架將會(huì)有效地適應(yīng)商業(yè)和技術(shù)上的改變。概念框架的最佳部分是通過(guò)引入不同的即插即用的服務(wù)提供商的概念，完全將組件管理/生命周期進(jìn)程與商業(yè)邏輯和不同的第三方APIs隔離。即使發(fā)生改變，除了更改/替代服務(wù)提供商，你也不需要擔(dān)心代碼的其他部分。這樣可以使程序更易維護(hù)，更易適應(yīng)，和更強(qiáng)壯。
作者:
Palash Ghosh是有6年架構(gòu)，設(shè)計(jì)和開(kāi)發(fā)Java/J2EE解決方案專(zhuān)家經(jīng)驗(yàn)的軟件架構(gòu)師。