熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java高級技術 >> 正文

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

2013-11-23 19:54:43  來源: Java高級技術 

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

  當其他組件請求保險商組件的服務時並不需要考慮組件內部的操作封裝其商業邏輯讓組件更易維護及擴展
  
  服務組件將有一個主要的服務實現類(服務接口的實現)以及這個類使用助手類這個類是組件的一部分同時也可能使用其他的組件
  
  在產品開發中我們也須有許多組件提供不同的服務例如在保險業我們有索取流程組件投保人服務組件以及其他更多組件所以我們必須有個機制來在企業解決方案中注冊這些服務組件使其可以根據企業的特殊需要采用或者中止這些服務
  
  下面是XML結構的例子它可以自動處理服務注冊的流程
  <Services>
  <Service>
  <Serviceid>S</Serviceid>
  <ServiceName>UnderwriterService</ServiceName>
  <ServiceImplClass>
  serviceUnderWriterServiceImpl
  </ServiceImplClass>
  </Service>
  <Service>
  <ServiceId>S</ServiceId>
  <Servicename>PolicyHolderService</ServiceName>
  <ServiceImplClass>
  servicePolicyHolderServiceImpl
  </ServiceImplClass>
  </Service></Services>
  
  組件應該具有合適的生命周期機制
  
  組件也需要一個在它的生命周期內置的可見的獨立的機制所以它可以根據需要被開始和中止ComponentControllerFactory(組件控制工廠)是singleton因為其只需要一個實例這個工廠負責根據配置內容為不同的提供商創建類的實例ComponentControllerFactory扮演雙重角色首先其通過其init()reload()等等方法來管理組件的生命周期(這就是為什麼它是一個工廠顯示其方法
  
 educitycn/img_///gif >
  Figure Component controller factory
  

  組件的生命周期方法是:
  
  ·doStart(): 開始組件
  
  ():幫助其從XML配置文件中取得配置對象負責創建適當的類的實例
  
  ·doStop():停止組件
  
  ·reload():如果當組件已經開始但XML配置文件發生更改這個方法將重新讀取XML配置文件並重啟逐漸
  
  ·getInstance():返回ComponentControllerFactory類的實例
  
  一個組件應該是可配置的
  
  通常每個組件有自己的可配置的不經常改變的參數例如假設我們需要寫一個緩存組件它需要每小時從數據庫取得半靜態的數據來刷新本身狀態更新的時間應該在配置文件中設置那樣我們可以不更改源代碼來更改參數的值
  
  下面是關於logger組件的XML配置文件的例子專用於管理企業程序各個層次的logging
  
  <LoggingServiceProvider>
  <Provider>
  <ProviderName>Apache</ProviderName>
  <AdapterImpl>integrationadapterLogjAdapter
  </AdapterImpl>
  <Enable>true</Enable>
  </Provider>
  <Provider>
  <ProviderName>WebLogic</ProviderName>
  <AdapterImpl>integrationadapterWebLogicAdapter
  </AdapterImpl>
  <Enable>false</Enable>
  </Provider></LoggingServiceProvider>
  
  在企業應用中組件只有一個實例在運行
  
  一個組件應該有且只有一個實例在運行而Singleton設計模式是合適的選擇來保證在JVM中只有一個實例但是當這種模式在單一JVM情形下可行但是在多JVM情形下就有問題但是由於配置信息在組件開始時載入而不需要改變並處理所有靜態信息用Singleton設計模式依然可行
  
  我們假設組件可以在單JVM情況下可行ComponentControllerFactory將會如圖那樣
  
 educitycn/img_///gif >
  Figure Component controller factory in a single JVM
  

  Singleton控制工廠提供的方法是
  
  ·getXXXService():方法返回在XML文件中定義的服務提供的實現類
  
  ·getXXXAdapter():方法返回在XML文件中定義適配實現類
  
  配置文件的更改應該是動態的
  
  如果組件是不可變的每串代碼應該有與singleton實例同樣的拷貝但是如果它是不是不變得我們需要改變時配置文件需要動態改變
  
  有兩種可能的情況但動態配置文件更改
  
  ·單一JVM情況
  
  ·多JVM情況
  
  單一JVM情況
  
  如果程序在單一JVM中運行事情就簡單得多了我們已經知道SingletonControllerFactory通常在JVM中有一個實例所以任何時候配置文件發生任何改變將需要根據一些通知機制輪流載入java串行的配置對象來重新載入工廠對象這是基於ObserverObservable模式並做兩件事
  
  ·通過XMLizer(單獨的組件)來讀取和處理XML配置文件並載入Java配置對象
  
  ·監視XML配置文件可能發生的更改
  
  圖顯示ConfigManager的方法
  
 educitycn/img_///gif >
  Figure ConfigManager
  

  ConfigManager類當被Observable通知時扮演Observer角色其更新方法將會被調用Update()方法將會調用SingletonControllerFactory的reload()方法所以新創建的java對象將會從其配置信息中重新載入
  
  ConfigurationChangeNotifier扮演Observable的角色並在XML配置文件發生更改時啟動通知ConfigManger線程並將指出其內容上的改變顯示其關系
  
 educitycn/img_///gif >
  Figure ConfigurationChangeNotifier
  

  多JVM情況
  
  在多JVM情況下事情就不會變得這樣簡單我們必須有
  
  ·需要機制在運行時來動態載入更改的XML配置文件而不關閉整個企業程序
  
  ·需要機制保證在群中只有一個實例在運行
  
  結合RMI利用JNDI是一種選擇來保證在集群環境中的多個節點中的特定的一個節點自由一個實例在運行RMI服務需要編寫同時RMI stub要在RMI服務之外創建創建的RMI stub需要被綁定在程序服務器的JNDI樹上這個對象將保持在container中container可以讓對象在集群中都可以用到
  
  為了處理這種情況我們需要引入ConfigManager它將會做一下任務
  
  ·創建需要可以
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27655.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.