您好,登錄后才能下訂單哦!
小編給大家分享一下Java如何使用EJB容器,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
Java EJB的體系結構:
EJB的上層的分布式應用程序是基于對象組件模型的,低層的事務服務用了API技術。EJB技術簡化了用 JAVA語言編寫的企業應用系統的開發,配置,和執行。EJB的體系結構的規范由Sun Microsystems公司制定。 Inprise的EJB容器是基于1.1版的規范。
EJB技術定義了一組可重用的組件:Enterprise Beans。你可以利用這些組件,象搭積木一樣的建立你的分布式應用程序。當你把代碼寫好之后,這些組件就被組合到特定的文件中去。每個文件有一個或多個 Enterprise Beans,在加上一些配置參數。最后,這些Enterprise Beans被配置到一個裝了EJB容器的平臺上。客戶能夠通過這些Beans的home接口,定位到某個beans,并產生這個beans的一個實例。這樣,客戶就能夠調用Beans的應用方法和遠程接口。
EJB服務器作為容器和低層平臺的橋梁管理著EJB容器和函數。它向EJB容器提供了訪問系統服務的能力。 例如:數據庫的管理和事務的管理,或者對于其它的Enterprise的應用服務器。
所有的EJB 實例都運行在EJB容器中。容器提供了系統級的服務,控制了EJB的生命周期。因為容器掌握了絕大多數系統級的issues(呵呵,不知道怎么翻譯)。Enterprise Beans 的開發者不需要應用邏輯考慮進來。通常來說,EJB容器掌握了以下的系統級issues.
1、Security–配置描述器(The Deployment descriptor)定義了客戶能夠訪問的不同的應用函數。容器 通過只允許授權的客戶訪問這些函數來達到這個效果。
2、Remote Connectivity–容器為遠程鏈接管理著低層的通信issues,而且對Enterprise Beas的開發者和客戶都隱藏了通信issues.Enterprise Beans的開發者在編寫應用方法的時候,就象是在條用本地的平臺一樣的。客戶也不清楚他們調用的方法可能是在遠程被處理的。
3、Life Cycle managment–客戶簡單的創建一個Enterprise beans的實例,并通常取消一個實例。而容器管理著Enterprise Beans的實例,使Enterprise Beans實現最大的效能和內存利用率。容器能夠這樣來激活和去活Enterprise Beans,保持眾多客戶共享的實例池。等等。
4、Trasction management—配置描述器定義了Enterprise beans 的事務處理的需求。容器管理著那些管理分布式事務處理的復雜的issues。這些事務可能要在不同的平臺之間更新數據庫。容器使這些事務之間互相獨立,互不干擾。保證所有的更新數據庫都是成功發生的,否者,就回滾到事務處理之前的狀態。
Enterprise Beans 組件:
Enterprise Beans 是基于分布式事務處理的企業級應用程序的組件。所有的Enterprise beans都有如下 的特點:
Enterprise beans包含了處理企業數據的應用邏輯。
Enterprise beans provider定義了Enterprise beans的客戶界面(Enterprise beans 的遠程界面)。這樣的界面不受容器和服務器的影響。于是,當一個 Enterprise beans被集合到一個應用程序中去時,不用更改代碼和重新編譯。
Enterprise beans能夠被 定制
各種系統級的服務,例如安全和事務處理的特性,都不是屬于Enterprise beans class的。而是由 配置和組裝應用程序的工具來實現。
有兩種類型的Enterprise beans: Session beans 和 entity beans.
Session beans:
Session beans 是一種作為單個的client執行的對象。作為對遠程的任務請求的相應,容器產生一個 Session beans 的實例。一個Session beans有一個client.從某種程度上來說,一個Session bean 對于服務器來說就代表了它的那個client.Session beans 也能用于事務,它能夠更新共享的數據,但它不直接描繪這 些共享的數據。
Session beans 的生命周期是相對較短的。典型的是,只有當client保持會話的時候,Session beans 才是活著的。一旦client退出了,Session beans 就不再與client相聯系了。Session beans被看成是瞬時的,因為如果容器崩潰了,那么client必須重新建立一個新的Session對象來繼續會話。
一個Session bean典型的聲明了與client的互操作或者會話。也就是說,Session bean了在客戶會話期間,通過方法的調用,掌握Client的信息。一個具有狀態的Session bean稱為有狀態的Session bean.當client 終止與Session beans互操作的時候.會話終止了,而且,bean 也不再擁有狀態值。
一個Session bean也可能是一個無狀態的 session bean.無狀態的Session beans并不掌握它的客戶的信息或者狀態。Client能夠調用beans的方法來完成一些操作。但是,beans只是在方法調用的時候才知道 client的參數變量。當方法調用完成以后,beans并不繼續保持這些參數變量。這樣,所有的無狀態的 session beans的實例都是相同的,除非它正在方法調用期間。這樣,無狀態的Session beans就能夠支持多個client.容器能夠聲明一個無狀態的Session beans.能夠將任何Session beans指定給任何client.
Entity Beans:
Entity Beans對數據庫中的數據提供了一種對象的視圖。例如:一個Entity bean能夠模擬數據庫表中一行相關的數據。多個client能夠共享訪問同一個Entity bean.多個client也能夠同時的訪問同一個Entity bean.Entity beans通過事務的上下文來訪問或更新下層的數據。這樣,數據的完整性就能夠被保證。
Entity Beans能存活相對教長的時間,并且狀態是持續的。只要數據庫中的數據存在,Entity beans就一直存活。而不是按照應用程序或者服務進程來說的。即使EJB容器崩潰了,Entity beans也是存活的。Entity Beans生命周期能夠被容器或者 Beans自己管理。如果由容器控制著保證 Entity beans持續的issus。如果由 Beans自己管理,就必須寫Entity beans的代碼,包括訪問數據庫的調用。
Entity Beans是由主鍵(primary key 一種唯一的對象標識符)標識的。通常,主鍵與標識數據庫中的一 塊數據,例如一個表中的一行,的主鍵是相同的。主鍵是client能夠定位特定的數據塊。
EJB roles:
EJB體系結構通過把編程的過程分為6個不同的角色而使開發復雜的的應用系統變的簡單。6個不同的角色 ,每個都有特定的任務。6個角色包括下層的服務,應用程序的開發,配置和操作說明(issues)
EJB體系結構能夠簡化應用程序開發人員的工作。在EJB體系結構中,容器和代理服務承擔了很多在其他環 境中又程序設計人員承擔的工作。這樣的代理提供了很多原來需要程序設計人員編寫代碼的系統級的服務。
Infrastructure roles;(下層構造角色)
EJB Server Providor服務提供者是典型的提供分布式低層服務的代理。EJB服務提供者提供了一個分布式 應用程序開發者需要的平臺和設施。也提供了分布式程序的運行時環境。
EJB Container Providor 容器提供者是分布式系統,事務處理,安全方面的專家容器提供者提供了一個 EJB的配置工具,和這些配置實例的運行時支持。
一個容器對一個或多個EJB來說,是一個運行時系統。它將Enterprise Beans和EJB服務,包括事務服務,安全服務,分布式網絡管理等膠合在一起。容器是既是一個定制的代碼和對特定的 Enterprise beans產生詳細代碼的工具。容器也提供了一個配置Enterprise beans的工具和管理監視應用程序的方法。
Application roles:(應用角色)
Enterprise beans Provider:Beans提供者在應用領域方面是專家。例如:Beans提供者可能是金融或電信方面的專家。Beans提供者提供了業務 tasks,Enterprise beans的業務方法,定義了beans的romote和home接口,還定義了beans的配置描述器。因為容器管理著系統級的任務,所以,Beans 提供者便不需要關心分布處理,事務處理,安全性能等從應用方面看來沒什么關系的方面。
Application Assembler程序組裝器:
這是一個將定制的Enterprise beans和其它的組件,例如,GUI client,applet,Servelet等組裝成一個完整的應用程序的行家。在Enterprise的配置器下,組裝器在組裝成一個應用程序的時候,只關心beans的接口,包括romote接口和home接口。而不關心這些接口是怎么實現的。組裝的結果就是一個一個的應用程序,或者由多個 Enterprise beans組合成的一個比較復雜的Enterprise beans.
Deployment and Operate roles配置和操作角色
配置器為特定的Enterprise beans配置特殊的操作環境。配置器為了適應應用程序,將多個Enerprise beans 組合起來,通過修改Enterprise beans 的屬性來達到配置相應的操作環境。例如,配置器通過設置配置描述符的相應的屬性來設置事務和安全方針。配置器的另一個任務是將應用程序與現有的 Enterprise管理軟件結合起來。
System Administrator系統管理者;
是與配置應用有關的。管理者配置個管理Enterprise計算和網絡服務的低層,包括EJB服務和容器。管理員監視著應用服務器的運行狀況,當應用服務器不正常運行是就采取相應的措施。典型的說,管理員使用Enterprise管理工具來與應用程序打交道,通過由容器提供的hooks來配置。
傳統的應用程序開發者現在是Enterprise beans的提供者。也可能是應用程序的裝配者。這樣能使他們將主要精力放在應用問題或者應用邏輯上面。當安裝Enterprise beans時,配置器定義了一系列的配置方針。機制的復雜性和執行配置的方針就交給了專門的代理。雖然分布式的應用程序還是比較復雜,可是,應用程序設計者的工作卻變的簡單了,因為所有復雜的工作都交給了EJB服務器和容器提供者了。
通過大量的設計之前的定義和命名約定,EJB達到了前面提到的目的。這樣的編程體系結構限制了一定的自由,但是,允許EJB服務器和容器提供者假定應用程序的設計,并以一種行之有效的方式來支持他們。
EJB的設計模式和命名約定:
有三種途徑來建立一個基于對象的,多層的,分布式的系統:無狀態服務的途徑,基于會話的途徑和持續對象的途徑。
無狀態的服務是通過對象的操作提供一種功能的函數,但是,不保持會話的狀態。當一個客戶使用無狀態的對象時,客戶不能夠提供上一次操作的信息。
基于會話的設計產生了一個中間層的對象,稱為一個會話(Session)。這個會話可以看成是這個客戶的代理。典型的,會話的生命是由客戶和所在的服務程序決定的。客戶如果完成了會話就可以將對象移走。如果服務終止了,會話對象就會超時。會話對象就會變的無效了。
持續對象設計模式綁定了存在數據庫中的一塊數據。提供了操作這塊數據的一些個操作。持續對象是由多個客戶共享的。起生命期是由存儲數據的庫所決定的。
EJB規范中將這些分別稱做:stateless Session, stateful Session, Entiry Beans.Session Beans模式就是基于會話的設計模式。Entiry Beans模式就是持續對象設計模式。每種模式都定義了一些接口和命名約定。
Enterprise JavaBeans infrastruct (EJB的基礎結構)
容器和服務提供者實現了EJB的基礎構造。這些基礎構造處理了EJB的分布式方面,事務管理,安全性方面。EJB規范定義了基礎構造和J ava API的為了適應各種情況的要求。而沒有去指定用什么技術,平臺,協議來實現他們。
Enterprise beans, container, server說明了EJB基礎結構的要求,EJB基礎結構必須提供客戶和Enterprise beans通信的通道。雖然這不是EJB規范所定義的。但保證通道的安全也是很重要的。特別是當客戶通過internet訪問遠程的Enterprise beans時。EJB基礎結構也必須能夠加強Enterprise beans 的訪問控制。
Enterprise beans所有的數據的持續性必須被保證。EJB的低層結構必須提供在企業級的計算環境中與現存系統的結合能力。Beans的所有通信都是分布式事務的一部分,需要由EJB低層結構來管理對于一個成功的配置,EJB低層必須提供分布式應用管理工具的鉤子(hooks)
Container
容器可能是EJB里面最重要的概念。因為它向程序開發人員提供了最大程度的方便。基于對象的中間層軟件平臺如CORBA或者遠過程調用RMI是程序開發者從網絡傳輸中解放出來,通過提供對象定位機制,數據重組機制等等。容器的概念則走的更遠一點。通過簡化分布式應用程序的那些復雜的方面,如:安全性,事務協調性,數據持久性。
一旦Enterprise Beans準備好了可以配置了。就被打包成一個標準的JAVA文件,ejb-jar文件。一個ejb-jar文件可以包括一個或多個的 Enterprise Beans。對每一個Enterprise beans,都由它的接口,類,和配置描述器。
Enterprise Beans Provider提供如下東西給ejb-jar 文件:
Enterprise Beans 的remote 接口,接口說明了Client端能調用的函數。
Enterprise Beans 的home 接口,home接口使客戶生成和定位一個Enterprise Beans的實例。
Enterprise 類本身,實現了Enterprise beans 的語義。
Deploy Descripot配置描述器,deployer通過利用配置描述器來提供沒有在代碼中申明的信息。例如方針和屬性。EJB的1.0規范把配置描述器定義為javax.ejb.deployment. SessionDescriptor類或者javax.ejb.deployment.EntityDescriptor的一個實例,但是在1.1版本中不贊成這樣做。而是用XML來定義配置描述器。
配置一個Enterprise Beans 意味著將一個Enterprise Bean安裝到容器中去。安裝過程包括了如下幾個方面:
保證不同的Enterprise beans能夠工作在一起。用名字服務來注冊一個Enterprise Bean。通過EJB服務的通信系統提供訪問EJB的入口。
執行事務管理和安全方針。在一個EJB容器中可以又任意多個Enterprise beans.除了安裝和執行以外,容器也提供了配置Enterprise beans的工具。為什么用Inprise的EJB 容器?Inprise EJB容器提供的完全的服務完全支持EJB1。1規范。一個有效的運行和管理EJBs的容器。提供命名服務,事務服務,植入Java RDBMS的內部。編程,配置簡單充分的例子來演示怎樣使用EJBs和EJB容器。對于Enterprise beans的開發者來說,EJB 容器是一個高級Enterprise類產品。因為它有如下優點:完整的,靈活的運行時環境:EJB容器完全實現了EJB1。1的規范,包括了它的所有功能。
每一個由工具產生的Enterprise bean都同時是Enterprise bean 對象和CORBA對象。
EJB容器能夠進行單獨配置,100%的純JAVA服務,或者作為完全的分布式的配置。這樣的靈活性意味著你能夠根據你的要求調整你的應用程序。
與其它的EJB服務不一樣,Inprise 的EJB容器服務并沒有限制一定要分開。而是任意個數的Enterprise beans可以放在任意個數的容器中,這些容器也可以放在任意個數機器上。并且支持分布式的事務協議,允許Enterprise beans的分別裁定。允許部分的配置你的應用,而將你的性能配置成最優化。
Inprise 的EJB是建立在Vbroker和RMI—IIOP之上的。
EJB容器是建立在Inprise的Vbbroker之上的。VisBroker是已經被證明的在各種條件下都是ORB的領導角色。無論在各大公司的聯合測試下,或者在實際的應用環境中。VisiBroker提供了一個很好的的運行時的任務的完成。
為了更好的性能,Vbroker使用了大量的運行時優化,高級的多路鏈接,鏈接池和管理,線程池和管理。
客戶和Enterprise beans,Enterprise benas之間,Enterprise beans 和其它的CORBA對象之間的通信都是通過用VisiBroker的IIOP方式進行的。VisiBroker完全適應CORBA2。3規范,RMI— IIOP通過值傳遞的方式來實現。這意味著,復雜的JAVA數據類型能夠用新的IDL值類型寫到IIOP里面去。就象在CORBA2。3規范中一樣。數據和服務之間相互協調怎樣傳送復雜的數據類型是很重要的。否則,協同能力就會受到危及。EJB容器能夠與其他的所有支持RMI-over-IIOP的進行協同工作。
安全特性是可由VisiBroker所有的。保證信用是從客戶傳象服務。
事務上下文也是由visibroker所有的。保證當CORBA客戶開始一個事務時,并且訪問EJB容器的服務時。事務上下文被傳向服務,當服務需要調用環境中的各項資源時,就要使用事務上下文。
事務的兩段提交是由Inprise的ITS管理的。如果JDBC支持兩階段提交協議,EJB就支持兩階段提交協議。當時,如果JDBC不支持兩階段提交,兩階段提交就不能被完成。
Enterprise的EJB容器是一個CORBA對象:
Inprise 的java2iiop編譯器和EJB容器一樣,都是與CORBA兼容的。EJB容器能夠理解RMI調用,但是,它用IDL來存放接口定義。雖然 Java2iiop編譯器從java接口產生了stub 和skeleton.也能夠從java接口中產生IDL。然后在其他語言里面用。對于一個CORBA客戶端,EJB容器是一個CORBA服務,EJB容器工具就是與控制EJB的功能相同的CORBA工具。
EJB容器是建立在JNDI和CosNaming,JTS/OTS基礎山的。他們都是完全支持CORBA的。
容器對不同的Enterprise beans 的支持:
EJB容器的主要的特征就是它提供對各種各樣的Enterprise beans的管理和支持。包括:
有狀態或無狀態的Session Enterprise beans.
Entiry beans包括container-manager和beans-manager的持續性。
EJB容器可以包括一個或多個的jar文件。每一個jar文件又能夠包括多個的Enterprise beans。每個Enterprise bean都包括一個配置描述器。一個EJBhome接口,一個EJBremote接口,還有Enterprise bean的實現代碼。
使Inprise 的EJB容器不同的是:它支持許多當前的客戶,包括如下兩個方面:
VisiBroler提供了連接管理,允許一個服務同時支持比TCP連接數多的客戶連接。用最近最少使用算法來關閉連接。
對于客戶來說,容器本身是無狀態的。意味著容器并沒有為每一個新的Enterprise bean會話分配內存。這樣,容器就能夠支持任意多的無狀態的Session Enterprise beans.
配置的支持:
Inprise 容器提供了產生代碼的編譯器。也提供了一個驗證的工具來在配置之前檢查你的Enterprise beans.支持EJB1。1的JNDI命名基于XML的配置描述器。
事務管理者:
事務管理者提供了事務管理的手段。包括分布式的兩段提交的支持。遵從最新的SUN公司JTS規范。也支持最新的OMG的OTS規范。在開發時盡量少用JTS而在配置時使用健壯的ITS。
JDBC鏈接池和事務綜合:
所有JDBC訪問數據庫都是通過DataSource對象的實現來完成的。DataSource對象與數據庫的池鏈接還有JTS管理的全局的事務處理和用JDBC管理的數據庫事務處理。
命名服務:
命名服務提供了分布式的命名管理。服務遵從JAVA的命名和目錄規范(JNDS)。也遵從OMG的cosNaming規范。與事務服務類似,在配置的時候,你可以用JNS,也可以用更健壯的INS。JNDI提供的容器能夠運行在其他的JNDI實現之上。這樣就能夠使用其他的命名服務,例如:LDAP。
安全性的支持:
在CORBA之上的Inprise 的安全服務是附加的。
JAVA數據庫:
Java數據庫提供了一個全關系型的高性能的數據庫來存儲Enterprise beans的狀態。
JAVA數據庫既可以運行在同一個進程的容器中,或者,為了提高性能,也可以運行在一個單獨的進程中。實際上,JAVA 數據庫是即插即用的。意味著終端用戶能夠用一個另外的實現就取代了所有的JAVA版本。例如,能夠實現一個用別的數據庫來存儲會話狀態和Entiry Data的后臺存儲。
容器管理的Entity beans的持久性:
Inprise 提供了一個CMP(Container-Managed Persistence)引擎來提供透明的對象關系映射和在純JDBC上的持續框架。更進一步,第三方的工具可以通過開放的API插進來。
EJB與其他組件的結合:
在配置環境的真實世界里,EJB的四個模式能夠與以下的組件工作在一起:
client鏈接到Enterprise beans對象。Clients可以由java Enterprise bean接口的EJB對象,或者IDL接口的CORBA對象。在Inprise 的EJB容器服務中,每一個Enterprise bean都同時是EJB對象也是CORBA對象。CORBA客戶能夠用所有支持CORBA的語言來實現,包括C++,Java,Delphi.
從Enterprise bean的數據庫訪問。典型的,Enterprise beans對象是Entity beans對象,或者是beans-managed,或者是container-managed.
后端服務:CORBA服務,用C++,Java ,Delphi實現,運行在任何兼容CORBA的ORB中。EJB服務,包括所有其他的inprise的服務,或者其他支持IIOP的代理商的服務。其它原來的服務,包括ERP系統,main-frame程序。等等。
以上是“Java如何使用EJB容器”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。