創建靈活易擴展的J2EE企業應用程序框架

2019-11-18 12:28:31

字體：大中小

來源：轉載

供稿：網友

　　隨著J2EE的飛速發展，已經有越來越多的企業應用程序以J2EE技術為其構建的基石，J2EE本身并不是產品，它只是制定了一套創建企業應用程序的規范，不同廠商根據J2EE規范，創建了符合J2EE規范的產品，這給予了我們更多的選擇創建企業應用的平臺。
　　
　　一個典型的J2EE的應用，至少應該包括以下三部分：表現層，業務邏輯層和數據持久層，為了更加輕易地創建企業應用程序，許許多多的Framework涌現出來，表現層我們可以選擇Struts, JSF, Tapestry, WebWork, Velocity等，數據持久層我們可以選擇原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等，業務邏輯層我們可以用普通的java Beans,也可以用EJB(session Bean)。
　　
　　每種技術都有它的優點與缺點，各自有各自的適用范疇，例如EJB可以很好地進行分布式處理和Object Cache等，但EJB的運行需要EJB容器，開發調試起來很不方便，非凡在需求不確定性很大、模型不穩定的情況下，實在是一種重量級別的開發；而JAVA BEAN則是一種很輕量級的方式，開發調試輕易，但又很難實現分布式處理。
　　
　　在各種技術紛爭的今天，暫時還沒有一種技術處于絕對的霸主地位，在這種條件下，我們不能把“賭注“押在任何一種技術上，如何使我們的應用程序有很高的靈活性和易擴展性是我們要仔細研究的課題。
　　
　　在實際的項目中，關于應用程序開發時所用技術的問題，大致存在兩種情況，一種是構架師或技術經理沒有嚴格限定用什么技術來實現具體的業務邏輯或者只有簡單的開發規范，程序員在開發時，只是依據自己的技術背景，選擇自己熟悉的實現方式，這種情況一般屬于橫向開發，在小的項目中，每個人只做自己負責的一個模塊，從表現層，業務邏輯層，一直到數據層，都由同一個人來負責，這種方式給了技術人員更多的自我發揮能力的空間，但不便于后期維護，非凡是人員流動頻繁的情況下，問題更是嚴重。
　　
　　第二種情況是構架師或技術經理在項目初期從開發成本，項目需求等等各個方面做出評估，經過幾番取舍，確定項目各個層面使用什么樣的技術實現方式，按不同層面進行分工，不同的工作人員負責不同層面的技術實現，這種方式比第一種方式要好得多，適合校大項目的開發，但也存在很多問題。
　　
　　在目前各種實現技術紛爭的情況下，沒有一種技術是萬能的，在做取舍時，難免和某一技術或實現方式依靠性過強，同時限定了技術人員個人技術特長的很好發揮，當由于某些原因要更改實現方式時，經常是牽一發而動全身，造成資源的極大浪費和開發成本的提高。
　　
　　所以，在構建企業應用時，應該有個好的技術框架，這個框架應該考慮到各種主流的實現技術，我們既可以根據實際情況進行取舍，同時在從一種實現方式變更為另一種實現方式時，又可以進行平滑過度，讓多種技術實現并存，發揮技術人員的最大優勢，降低項目成本，提高開發效率。
　　
　　基于SOA的構架
　　
　　圖一
　　創建靈活易擴展的J2EE企業應用程序框架

　　SOA(Service Oriented Architecture)，對這一術語我們并不生疏，因為Web service是基于SOA的一種技術，服務的提供者將提供的服務注冊到UDDI，其使用者從UDDI上獲得服務的描述（WSDL），然后根據服務接口使用服務。
　　
　　Web Service用xml進行消息的傳遞,通過SOAP綁定在現有的輕量級協議，如HTTP之上，可以透過防火墻，不依靠服務端和客戶端具體地實現技術，進行分布式遠程調用，它是現有的應用向Internet的延伸。
　　
　　Web service在EAI,B2B,應用到應用的集成等方面體現了巨大的優勢，有很多文獻介紹Web service，由于這不是本文重點，在此不再贅述。
　　
　　SOA的優勢在于降低了服務的提供者與使用者之間的耦合性，服務的提供者將自己提供的服務注冊在中介那里，服務使用者先通過中介查找自己所需服務，使用者獲得的是服務接口，但并不知道服務的具體實現，它根據調用接口調用服務，這樣即使服務的實現方式發生了變化，只要供使用者調用接口沒有改變，服務使用者就不會受到任何影響，這種思想正是我們應該學習和借鑒的地方。
　　
　　那么既然Web service是基于SOA的，我們的企業應用是不是就可以完全構架在Web service上呢？我們并不建議這么做，Web service對于企業內部的應用并不太適合，在一個應用內部使用Web service，系統大量的資源花費在進行XML消息的解析和進行遠程調用上，造成系統運轉緩慢。
　　
　　當然，從某種意義上講，EJB也是SOA的一種實現，服務的提供者把服務注冊在JNDI上，使用者通過JNDI找到自己想要的服務，通過遠程接口使用服務，但EJB的運行需要EJB容器，開發調試起來不方便，非凡對于需求經常變化的系統，進行EJB調試的時間會更久。
　　
　　我們所需要的是一個輕量級的構架，能兼顧各種主流的技術，但又不依靠具體的某個實現方式，當實現方式從一種技術變更為另一種技術時，對于服務的使用者來說幾乎沒有影響，從而實現客戶端和服務器端的松耦合，這樣，我們的表現層，業務邏輯層和數據持久層都可以依據實際需求情況與偏好隨意選擇各種實現方式。
　　
　　MiniSOA構架介紹
　　
　　MiniSOA設計思想
　　
　　MiniSOA是以SOA思想為指導的一個極其輕量級的構架，其主旨是降低服務使用者和提供者之間的耦合度，使現在流行的多種技術能夠很好的并存，并充分發揮各自的優勢，技術人員能夠發揮自己的特長，用自己熟悉的技術來實現業務邏輯，同時應用程序某些層面能夠方便的在不同的實現技術之間進行切換，而不會對其他層面造成影響。
　　
　　MiniSOA沒有創建一個新的編程模式，沒有Web service,EJB那么工業化的龐大，它只是通過XML配置把應用組件裝配在一起，通過必要的緩存，提高組件的運行效率，自動治理組件運行時的事務、環境參數等信息，使其能更有效的運行，同時，提供多小組的團隊開發的支持，并方便進行單元測試，使開發人員集中精力開發業務邏輯，提高勞動生產率。
　　
　　MiniSOA概述
　　
　　為了降低表現層，業務層和數據持久層等各個層面之間的耦合性，各個層面使用其他層面提供的服務時，不是直接去使用服務對象，而是通過服務中介，查找定位服務接口，通過接口來訪問服務，服務提供者可以通過各種方式來實現服務接口，然后把提供的服務注冊到服務中介，服務中介是服務使用者和服務提供者之間進行通訊的橋梁，可以在服務中介上做一些其他方面的控制，如事務，安全等。
　　
　　表現層作為業務層的使用者，在使用業務層提供的服務時，通過Business Service Manager這個中介來查找和使用服務接口；業務層是表現層的服務提供者，它把通過各種方式實現的服務對象注冊到Business Service Manager,供表現層對象使用，同時業務層也是數據持久層服務的使用者，它通過Data access Object Manager這個中介來使用數據持久層提供的服務；同樣數據持久層把對數據庫，文件等資源的存取進行封裝，把以各種方式提供的服務對象以接口的形式注冊到Data Access Object Manager,供業務層對象使用。
　　
　　MiniSOA包括業務層和數據持久層兩部分組件，業務層的核心組件是ServiceManager, 它是表現層和業務層進行交互的橋梁；數據持久層的核心組件是DaoManager,它是業務層和數據持久層進行交互的橋梁。
　　
　　根據數據模型和業務需求，定義提供的服務接口后，開發人員用自己熟悉的技術開發接口的實現組件，經過單元測試后，把服務接口、實現組件和相應的事務，環境參數等信息配置到dao-conf.xml,service-conf.xml文件，服務使用者就可以通過ServiceManager,DaoManager來查找所需的服務接口，調用服務方法。
　　
　　MiniSOA 業務層核心組件簡介：
　　
　　ServiceFacotry：作為表現層調用業務層的Facade,它讀取service-factory-conf.xml配置文件，創建用于各個模塊的ServiceManager，便于多個開發小組的分工合作。 Service-factory-conf.xml 實例：
　　
　　module1
　　module1-service-conf.xml
　　module2
　　module2-service-conf.xml
　　
　　通過service-factory-conf.xml配置文件，每個模塊可以使用和本模塊相關的service配置，適合多個開發小組共同開發，有效避免了資源沖突。
　　
　　ServiceManager, ServiceManagerBuilder：ServiceManagerBuilder用于讀取serivice-conf.xml配置信息，創建每個service對象使用的環境對象ServiceContext，返回用于服務使用者查找具體服務的ServiceManager接口。
　　
　　Service-conf.xml實例：
　　
　　cglib-enabled="true"
　　dao-config="dao-hibernate-conf.xml"
　　/>
　　demo.Order
　　demo.OrderImpl
　　smtphost
　　<value>mail.mycom.com
　　mailfrom
　　<value>from@mycom.com
　　sendMail
　　false
　　*
　　true
　　...
　　
　　供使用者使用的每個service分別配置在標簽中，cglib-enable屬性用于配置本模塊的services是否要用cglib來增強PRoxy功能，dao-config屬性指定service使用的dao配置信息，runas屬性設置service的實現方式：(java-bean,remote-ejb,local-ejb),singleton屬性用于配置service是否是單一實例的，假如singleton為true,則此service在第一次創建和使用后，被ServiceManager緩存起來,其他Client再請求此service時，則使用被緩存的對象，而不會再被創建，singleton為true的service是無狀態的，不能保持每個Client的狀態信息，相反，singleton為false的service是有狀態的，每個Client都使用自己的service對象，它們之間互不影響。
　　
　　ServiceContext：是ServiceManager和service實

上一篇：使用消息驅動Beans(1)

下一篇：優化entity Bean的七條準則