關于Java組件開發:一個概念框架(組圖)

2019-11-18 12:20:32

字體：大中小

來源：轉載

供稿：網友

　　我先介紹幾個在構建和設計解決方案來適應商業活動中的持續變化時需要注重的商業場景:
　　
　　·公司需要將其文件倉庫從文檔文件轉成網絡文件。
　　
　　·公司需要更換其安全提供商。
　　
　　·因為經濟情況的巨大的改變，保險公司必須擴展其保險流程政策到更大范圍。
　　
　　一樣東西是很確定的，需求更改就像商業和技術一樣快速改變。但是對于所有改變，無論其大小，我們都需要拋棄原來整個系統重新開始么？這是不必要的—架構和設計解決方案時加入少許考慮，好的策略以及最優方法可以適應現有的體系結構的變更而不需要太多爭辯。
　　
　　在面向對象編程以及分布式對象技術中，組件是類和接口的集合，通過可重用的外部API來滿足需求（功能性的以及非功能性的）。組件應該可以在分布式網絡環境運行來形成網絡程序。基于組件的設計和開發對于遵循面向對象分析與設計（OOAD）的方法學的專家并不是新的話題。
　　
　　本文的目的是根據java的最優方法和最初開始一步一步地達到通用的概念模型來開發java組件。本文面向的讀者需要具有Java，UML以及Java/J2EE設計模式的知識。這篇文章主要描述的范圍是：
　　
　　·組件的基本性質。
　　
　　·如何利用Java設計最優方法（設計模式）來實現這些Java組件設計的基本性質，并且形成一個概念上的基本組件開發框架, 這個框架將來可以方便地用于任何組件開發中的。
　　
　　組件的基本性質
　　
　　·為了讓其他組件可以與之相互作用，組件必須有服務接口（API）。
　　
　　·組件必須有合適的生命周期機制（start, stop, initialize等等）
　　
　　·組件必須可以配置。
　　
　　·組件只有一個實例在企業程序中運行。
　　
　　·配置的改變應該是動態的（在運行中）。
　　
　　·組件必須有合適的第三方軟件融入的機制。
　　
　　·組件必須有合適的處理錯誤機制
　　
　　如何實現基本的組件性質
　　
　　組件必須有服務接口（API）
　　
　　無論我們是在一個類還是幾個類中寫100行到1000行的代碼，最終勞動成果（類或者類的結合）提供一些基本的高級的服務。返回去想想，我們甚至可以在實現他們之前定義那些我們想要達到的基本的高級的服務。
　　
　　讓我們舉個來自保險界的例子，保險商在他天天做了以下的工作：
　　
　　·檢查保險申請。
　　
　　·收集并評估背景信息。
　　
　　·根據公司現有的規則計算保險金
　　
　　·從其他部門收集信息以及各種各樣的報告（醫學等等）。
　　
　　·預備相關的政策。
　　
　　現在我們假如想寫一個保險商的商業組件，我們必須有如圖1的服務接口以及其實現：
　　　關于Java組件開發:一個概念框架(組圖)（圖一）

　　Figure 1. Underwriter service interfac
　　
　　當其他組件請求保險商組件的服務時，并不需要考慮組件內部的操作。封裝其商業邏輯讓組件更易維護及擴展。
　　
　　服務組件將有一個主要的服務實現類（服務接口的實現）以及這個類使用助手類，這個類是組件的一部分，同時也可能使用其他的組件
　　
　　在產品開發中，我們也須有許多組件提供不同的服務。例如，在保險業，我們有“索取流程組件”，“投保人服務組件”以及其他更多組件。所以我們必須有個機制來在企業解決方案中注冊這些服務組件，使其可以根據企業的非凡需要采用或者中止這些服務。
　　
　　下面是xml結構的例子，它可以自動處理服務注冊的流程。
　　<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>
　　
　　組件應該具有合適的生命周期機制
　　
　　組件也需要一個在它的生命周期內置的，可見的，獨立的機制，所以它可以根據需要被開始和中止。ComponentControllerFactory（組件控制工廠）是singleton，因為其只需要一個實例。這個工廠負責根據配置內容為不同的提供商創建類的實例。ComponentControllerFactory扮演雙重角色：首先其通過其init(),reload()等等方法來治理組件的生命周期（這就是為什么它是一個“工廠”），圖2顯示其方法
　　　關于Java組件開發:一個概念框架(組圖)（圖二）

　　Figure 2. Component controller factory
　　
　　組件的生命周期方法是:
　　
　　·doStart(): 開始組件
　　
　　():幫助其從XML配置文件中取得配置對象，負責創建適當的類的實例
　　
　　·doStop():停止組件
　　
　　·reload():假如當組件已經開始但XML配置文件發生更改，這個方法將重新讀取XML配置文件并重啟逐漸。
　　
　　·getInstance():返回ComponentControllerFactory類的實例
　　
　　一個組件應該是可配置的
　　
　　通常，每個組件有自己的可配置的不經常改變的參數。例如，假設我們需要寫一個緩存組件，它需要每小時從數據庫取得半靜態的數據來刷新本身狀態。更新的時間應該在配置文件中設置，那樣我們可以不更改源代碼來更改參數的值。
　　
　　下面是關于logger組件的XML配置文件的例子，專用于治理企業程序各個層次的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>
　　
　　在企業應用中組件只有一個實例在運行
　　
　　一個組件應該有且只有一個實例在運行，而Singleton設計模式是合適的選擇來保證在JVM中只有一個實例。但是當這種模式在單一JVM情形下可行，但是在多JVM情形下就有問題。但是由于配置信息在組件開始時載入而不需要改變并處理所有靜態信息，用Singleton設計模式依然可行
　　
　　我們假設組件可以在單JVM情況下可行，ComponentControllerFactory將會如圖3那樣：
　　　關于Java組件開發:一個概念框架(組圖)（圖三）

　　Figure 3. Component controller factory in a single JVM
　　
　　Singleton控制工廠提供的方法是
　　
　　·getXXXService():方法返回在XML文件中定義的服務提供的實現類
　　
　　·getXXXAdapter():方法返回在XML文件中定義適配實現類
　　
　　配置文件的更改應該是動態的
　　
　　假如組件是不可變的，每串代碼應該有與singleton實例同樣的拷貝，但是假如它是不是不變得，我們需要改變時，配置文件需要動態改變。
　　
　　有兩種可能的情況但動態配置文件更改：
　　
　　·單一JVM情況
　　
　　·多JVM情況
　　
　　單一JVM情況
　　
　　假如程序在單一JVM中運行，事情就簡單得多了。我們已經知道，SingletonControllerFactory通常在JVM中有一個實例，所以任何時候配置文件發生任何改變，將需要根據一些通知機制輪流載入java串行的配置對象來重新載入工廠對象。這是基于Observer-Observable模式并做兩件事：
　　
　　·通過XMLizer（單獨的組件）來讀取和處理XML配置文件并載入Java配置對象。
　　
　　·監視XML配置文件可能發生的更改。
　　
　　圖4顯示ConfigManager的方法：
　　　關于Java組件開發:一個概念框架(組圖)（圖四）

　　Figure 4. ConfigManager
　　
　　ConfigManager類當被Observable通知時扮演Observer角色，其更新方法將會被調用。Update()方法將會調用SingletonControllerFactory的reload()方法，所以新創建的java對象將會從其配置信息中重新載入。
　　
　　ConfigurationChangeNotifier扮演Observable的角色并在XML配置文件發生更改時啟動通知ConfigManger線程，并將指出其內容上的改變。圖5顯示其關系：
　　　關于Java組件開發:一個概念框架(組圖)（圖五）

　　Figure 5. ConfigurationChangeNotifier
　　
　　多JVM情況
　　
　　在多JVM情況下，事情就不會變得這樣簡單。我們必須有
　　
　　·需要機制在運行時來動態載入更改的XML配置文件而不關閉整個企業程序。
　　
　　·需要機制保證在群中只有一個實例在運行。
　　
　　結合RMI利用JNDI是一種選擇來保證在集群環境中的多個節點中的特定的一個節點自由一個實例在運行。RMI服務需要編寫，同時RMI stub要在RMI服務之外創建。創建的RMI stub需要被綁定在程序服務器的JNDI樹上。這個對象將保持在container中，container可以讓對象在集群中都可以用到。
　　
　　為了處理這種情況，我們需要引入ConfigManager，它將會做一下任務：
　　
　　·創建需要可以

上一篇：實例解析:設計一個完全可擴展的應用

下一篇：Linux下的多線程編程