1. 程式人生 > >Java EE/J2EE基本概念---技術背景

Java EE/J2EE基本概念---技術背景

Java EE/J2EE基本概念

J2EE可以說指Java在資料庫資訊系統上實現,資料庫資訊系統從早期的dBase、到Delphi/VBC/S結構,發展到B/SBrowser瀏覽器/Server伺服器)結構,而J2EE主要是指B/S結構的實現。

J2EE又是一種框架和標準,框架類似API、庫的概念,但是要超出它們。

J2EE是一個虛的大的概念,J2EE標準主要有三種子技術標準:WEB技術、EJB技術和JMS,談到J2EE應該說最終要落實到這三個子概念上。

這三種技術的每個技術在應用時都涉及兩個部分:容器部分和應用部分,Web容器也是指Jsp/Servlet容器,你如果要開發一個Web應用,無論是編譯或執行,都必須要有

Jsp/Servlet庫或API支援(除了JDK/J2SE以外)。

Web技術中除了Jsp/Servlet技術外,還需要JavaBeansJava Class實現一些功能或者包裝攜帶資料,所以Web技術最初簡稱為Jsp/Servlet+JavaBeans系統。

談到JavaBeans技術,就涉及到元件構件技術(component),這是Java的核心基礎部分,很多軟體設計概念(設計模式)都是通過JavaBeans實現的。

JavaBeans不屬於J2EE概念範疇中,如果一個JavaBeans物件被Web技術(也就是Jsp/Servlet)呼叫,那麼JavaBeans就執行在J2EEWeb容器中;如果它被

EJB呼叫,它就執行在EJB容器中。

EJB(企業JavaBeans)是普通JavaBeans的一種提升和規範,因為企業資訊系統開發中需要一個可伸縮的效能和事務、安全機制,這樣能保證企業系統平滑發展,而不是發展到一種規模重新更換一套軟體系統。

J2EE叢集原理: http://www.jdon.com/jive/article.jsp?forum=121&thread=22282

至此,JavaBeans元件發展到EJB後,並不是說以前的那種JavaBeans形式就消失了,這就自然形成了兩種JavaBeans技術:EJBPOJOPOJO完全不同於EJB概念,指的是普通JavaBeans,而且這個

JavaBeans不依附某種框架,或者乾脆可以說:這個JavaBeans是你為這個應用程式單獨開發建立的。

J2EE應用系統開發工具有很多:如JBuilderEclipse等,這些IDE首先是Java開發工具,也就是說,它們首要基本功能是可以開發出JavaBeansJava class,但是如果要開發出J2EE系統,就要落實到要麼是Web技術或EJB技術,那麼就有可能要一些專門模組功能,最重要的是,因為J2EE系統區分為容器和應用兩個部分,所以,在任何開發工具中開發J2EE都需要指定J2EE容器。

J2EE容器分為WEB容器和EJB容器,Tomcat/ResinWeb容器;JBossEJB容器+Web容器等,其中Web容器直接使用Tomcat實現的。所以你開發的Web應用程式可以在上面兩種容器執行,而你開發的Web+EJB應用則只可以在JBoss伺服器上執行,商業產品Websphere/Weblogic等和JBoss屬於同一種性質。

J2EE容器也稱為J2EE伺服器,大部分時它們概念是一致的。

如果你的J2EE應用系統的資料庫連線是通過JNDI獲得,也就是說是從容器中獲得,那麼你的J2EE應用系統基本與資料庫無關,如果你在你的J2EE應用系統耦合了資料庫JDBC驅動的配置,那麼你的J2EE應用系統就有資料庫概念色彩,作為一個成熟需要推廣的J2EE應用系統,不推薦和具體資料庫耦合,當然這其中如何保證J2EE應用系統執行效能又是體現你的設計水平了。

高質量的Java企業系統

衡量J2EE應用系統設計開發水平高低的標準就是:解耦性;你的應用系統各個功能是否能夠徹底脫離?是否不相互依賴,也只有這樣,才能體現可維護性、可拓展性的軟體設計目標。

為了達到這個目的,誕生各種框架概念,J2EE框架標準將一個系統劃分為WEBEJB主要部分,當然我們有時不是以這個具體技術區分,而是從設計上抽象為表現層、服務層和持久層,這三個層次從一個高度將J2EE分離開來,實現解耦目的。

因此,我們實際程式設計中,也要將自己的功能向這三個層次上靠,做到大方向清楚,涇渭分明,但是沒有技術上約束限制要做到這點是很不容易的,因此我們還是必須藉助J2EE具體技術來實現,這時,你可以使用EJB規範實現服務層和持久層,Web技術實現表現層;

EJB為什麼能將服務層從Jsp/Servlet手中分離出來,因為它對JavaBeans編碼有強制的約束,現在有一種對JavaBeans弱約束,使用Ioc模式實現的(當然EJB 3.0也採取這種方式),在Ioc模式誕生前,一般都是通過工廠模式來對JavaBeans約束,形成一個服務層,這也是是Jive這樣開源論壇設計原理之一。

由此,將服務層從表現層中分離出來目前有兩種可選架構選擇:管理普通JavaBeansPOJO)框架(SpringJdonFramework)以及管理EJBEJB框架,因為EJB不只是框架,還是標準,而標準可以擴充套件發展,所以,這兩種區別將來是可能模糊,被納入同一個標準了。

但是,通常標準制定是為某個目的服務的,總要犧牲一些換取另外一些,所以,這兩種架構會長時間並存。

前面談了服務層框架,使用服務層框架可以將JavaBeansJsp/Servlet中分離出來,而使用表現層框架則可以將Jsp中剩餘的JavaBeans完全分離,這部分JavaBeans主要負責顯示相關,一般是通過標籤庫(taglib)實現,不同框架有不同自己的標籤庫,Struts是應用比較廣泛的一種表現層框架。

這樣,表現層和服務層的分離是通過兩種框架達到目的,剩餘的就是持久層框架了,通過持久層的框架將資料庫儲存從服務層中分離出來是其目的,持久層框架有兩種方向:直接自己編寫JDBCSQL語句(如iBatis);使用O/R Mapping技術實現的HibernateJDO技術;當然還有EJB中的實體Bean技術。

持久層框架目前呈現百花齊放,各有優缺點的現狀,所以正如表現層框架一樣,目前沒有一個框架被指定為標準框架,當然,表現層框架現在又出來了一個JSF,它代表的頁面元件概念是一個新的發展方向,但是複雜的實現讓人有些忘而卻步。

最後,你的J2EE應用系統如果採取上面提到的表現層、服務層和持久層的框架實現,基本可以在無需深刻掌握設計模式的情況下開發出一個高質量的應用系統了。

還要注意的是: 開發出一個高質量的J2EE系統還需要正確的業務需求理解,那麼域建模提供了一種比較切實可行的正確理解業務需求的方法,相關詳細知識可從UML角度結合理解。

當然,如果你想設計自己的行業框架,那麼第一步從設計模式開始吧,因為設計模式提供你一個實現JavaBeans或類之間解耦參考實現方法,當你學會了系統基本單元JavaBeans或類之間解耦時,那麼系統模組之間的解耦你就可能掌握,進而你就可以實現行業框架的提煉了,這又是另外一個發展方向了。

以上理念可以總結為一句話:

J2EE開發三件寶: Domain Model(域建模)、patterns(模式)和framework(框架)。

元件框架比較

EJB2/EJB3

Spring Framework

靈活性
(
鬆耦合)

EJB3EJB2更具靈活性,EJB3支援應用系統POJO

支援應用系統POJO,框架基礎功能不能替換

支援應用系統POJO,框架本身可分離配置,定製性更強

功能完整性

全面,支援非同步JMS 分散式事務

較為全面。有自己的表現層和持久層模板,可支援非同步

基本完整,表現層藉助Struts實現。有自己簡單的持久層模板

單臺效能

一般,批量查詢等大資料量業務處理須小心,存在本地不透明缺陷。

一般,框架本身元件無效能提升極致,應用程式可配置cache/Pool

好,框架本身元件使用快取提升效能,應用程式可配置cache/Pool,批量查詢專門優化,適合實時性併發性要求較高應用

可伸縮性

可支援多臺伺服器分散式計算。

不支援,可依靠EJB實現

不支援,可依靠EJB實現

開發效率

學習曲線長,導致熟練掌握難。藉助商業開發工具可加快熟練者的開發速度。

較為複雜,可挑選只適合自己的功能實現。當元件很多時,需要照顧這些元件之間呼叫關係。

簡單快速,表現層編碼很少。當元件個數很多時,無需照顧它們之間的呼叫關係

系統規模

EJB2適合大型系統;EJB3適合中大型系統

適合中小型系統

適合小中型系統,和EJB無縫結合,可藉助EJB支援中大型系統

重量級別

重量,正在減肥

輕量偏重,有可能繼續增肥

最輕量,恪守簡單快速原則

Ioc框架

程式碼案例

假設有呼叫者B和被呼叫者A程式碼如下:

呼叫者B

 package test;

 public class B{   

          AInfterface a;

public B(AInfterface a){ 

this.a = a

     }

          public void invoke(){

                a.myMethod();

          }

 }

被呼叫者A類:

package test;

 public class A  implements AInfterface {

          public void myMethod(){

               System.out.println("hello");

          }

 }

生成B類例項程式碼如下:

B b = new B(new A());

建立B的例項要逐個照顧到B類中涉及到所有其他類(如A類)的例項化,給程式設計者帶來程式碼編寫的瑣碎工作,無法提高效率。

使用Jdon框架的Ioc模式後,B類生成例項程式碼如下:

B b =  (B)  WebAppUtil.getService(“b”);

b. invoke();

無需首先照顧其他類如A類的例項生成。B的例項生成再也與其他類如A類沒有任何關係了,實現鬆耦合。如果B類中涉及不只是A類,還有CDEF等類,那麼生成B類例項時,我們就無需關心這些類的建立了。

實現上述呼叫效果,需另外進行一下jdonframework.xml配置如下:

<app>

   <services>

                    <pojoService name="b"  class="test.B"/>

                     <pojoService name="a"  class="test.A"/>

       </services>

   ……

</app>

革命性優點

兩個革命性優點:

1. 顛覆物件使用之前必須建立的基本定律,正象無需關心物件銷燬一樣,您可以無需關心物件建立。

Java程式設計中類建立成例項的過程簡化:(Class -> Instance

使用JdonIoc框架前:程式設計者需要自己逐個解決這個Class相關涉及的其他Class的例項化。

使用JdonIoc框架後:

無需程式設計者自己實現這種級聯式、瑣碎的例項化過程。

2. 鬆耦合;更換各種子類方便。面向物件程式設計之父Grady Booch 說:物件最偉大之處在於其可被替代。而Jdon框架偉大之處是幫助你替代這些物件,甚至包括Jdon框架本身。

上例中,如果Ainterface有另外一個實現子類AA類,只要將jdonframework.xml中:

<pojoService name="a"  class="test.A"/>

更換為:

<pojoService name="a"  class="test.AA"/>