有些網(wǎng)友覺(jué)得j2ee技術(shù)論文難寫，可能是因?yàn)闆](méi)有思路，所以小編為大家?guī)?lái)了相關(guān)的例文，希望能幫到大家!

　　j2ee技術(shù)論文篇一

　　模型介紹

　　1、MVC

　　1.基本概念MVC 開(kāi)發(fā)模式是一種分而治之的思想， 它將數(shù)據(jù)的訪問(wèn)和數(shù)據(jù)的表現(xiàn)進(jìn)行了分離。通過(guò)這種模式， 可以開(kāi)發(fā)一個(gè)具有伸縮性、便于擴(kuò)展、便于整個(gè)流程維護(hù)的平臺(tái)。

　　MVC 主要由三個(gè)部分組成： 模塊( Model ) 、視圖(View) 和控制器( Controller) 。模塊， 即相關(guān)的數(shù)據(jù)， 它是對(duì)象的內(nèi)在屬性， 是整個(gè)模型的核心， 它表示的是解決方案空間的真正的邏輯。它采用面向?qū)ο蟮姆椒ǎ?將問(wèn)題領(lǐng)域中的對(duì)象抽象為應(yīng)用程序?qū)ο?。在這些抽象的對(duì)象中封裝了對(duì)象的屬性和這些對(duì)象所隱含的邏輯。

　　視圖是模型的外在表現(xiàn)， 一個(gè)模型可以對(duì)應(yīng)一個(gè)或者多個(gè)視圖。視圖具有與外界交互的功能， 主管應(yīng)用系統(tǒng)與外界的接口： 一方面它為外界提供輸入手段， 并觸發(fā)應(yīng)用邏輯運(yùn)行; 另一方面， 它又將邏輯運(yùn)行的結(jié)果以某種形式顯示給外界?？刂破魇悄Ｐ团c視圖的聯(lián)系紐帶， 控制器提取通過(guò)視圖傳輸進(jìn)來(lái)的外部信息， 并將其轉(zhuǎn)化成相應(yīng)事件， 對(duì)模型進(jìn)行更新; 同時(shí)， 模型的更新與修改也將通過(guò)控制器來(lái)通知視圖， 從而保持視圖與模型的一致性。

　　2.MVC設(shè)計(jì)模式的優(yōu)勢(shì)

　　MVC 設(shè)計(jì)模式具有設(shè)計(jì)清晰， 易于擴(kuò)展， 運(yùn)用可分布的特點(diǎn)， 因此在構(gòu)建Web 應(yīng)用中具有顯著的優(yōu)勢(shì)。

　　(1)MVC 模式結(jié)構(gòu)可適用于多用戶的、可擴(kuò)展的、可維護(hù)的、具有很高交互性的系統(tǒng)， 如電子商務(wù)平臺(tái)、CRM系統(tǒng)和ERP 系統(tǒng)等。

　　(2)MVC 可以很好的表達(dá)用戶與系統(tǒng)的交互模式，以及整個(gè)系統(tǒng)的程序架構(gòu)模式。

　　(3)MVC 模式可以很方便的用多個(gè)視圖來(lái)顯示多套數(shù)據(jù)， 從而可以使系統(tǒng)能方便的支持其它新的客戶端類型。除了運(yùn)行桌面型的瀏覽器外， 還可以運(yùn)行在PDA，WAP 瀏覽器上。

　　(4)對(duì)于開(kāi)發(fā)人員來(lái)講， 由于MVC 分離了模式中的數(shù)據(jù)的控制和數(shù)據(jù)表現(xiàn)， 從而可以分清開(kāi)發(fā)者的責(zé)任， 后臺(tái)開(kāi)發(fā)人員可以專注業(yè)務(wù)的處理， 前臺(tái)開(kāi)發(fā)人員專注于用戶交互的界面， 從而加快產(chǎn)品開(kāi)發(fā)以及推向市場(chǎng)的時(shí)間。 2 、J2EE 技術(shù)

　　SUN 公司的J2EE( Java2 企業(yè)版) 是一種利用Java 語(yǔ)言的標(biāo)準(zhǔn)體系結(jié)構(gòu)定義的， 它提供中間層集成框架用來(lái)滿足高可用性、高可靠性以及可擴(kuò)展性的應(yīng)用的需求。利用它， 各公司可以更為方便地在中間層加速分布式部署。開(kāi)發(fā)中利用這種體系結(jié)構(gòu)， 開(kāi)發(fā)者可以不必?fù)?dān)心運(yùn)行關(guān)鍵商務(wù)應(yīng)用所需的“ 管道工程”， 從而可以集中精力重視商業(yè)邏輯的設(shè)計(jì)和應(yīng)用的表示。

　　J2EE 技術(shù)主要有： EJB， Servlets， JSP， JNDI 等。J2EE平臺(tái)的應(yīng)用主要由構(gòu)件構(gòu)成， 應(yīng)用系統(tǒng)的開(kāi)發(fā)就是設(shè)計(jì)這些構(gòu)件并組裝成整個(gè)企業(yè)應(yīng)用。

　　1. JSP

　　JSP 技術(shù)與ASP 技術(shù)類似， 是一種在服務(wù)器端進(jìn)行解析， 動(dòng)態(tài)生成網(wǎng)頁(yè)傳遞給客戶端Web 技術(shù); 它是基于Java 技術(shù)， 將Java 代碼嵌入HTML 頁(yè)面中實(shí)現(xiàn)的。本質(zhì)上， JSP 是一種高層的Servlet。它與其它網(wǎng)頁(yè)編寫腳本有很大的相似性， 但是在執(zhí)行時(shí)有所不同。JSP 引擎將它和它所在的HTML 文件一起合成

　　Servlet 的代碼， 然后它的執(zhí)行就與Servlet 的一樣： 先編譯成. class 文件， 最后由支持Java 虛擬機(jī)的服務(wù)器來(lái)執(zhí)行， 最后輸出結(jié)果。在使用JSP 中如果結(jié)合使用JavaBean 技術(shù)， 那么對(duì)于處理就會(huì)更加方便靈活。

　　2 。Servlet

　　Servlets 是Java 210 中新增的一個(gè)全新功能， Servlets是一種采用Java 技術(shù)來(lái)實(shí)現(xiàn)CGI 功能的一種技術(shù)。Servlet 和CGI 一樣都是運(yùn)行在Web 服務(wù)器上， 用來(lái)生成Web 頁(yè)面。與傳統(tǒng)的CGI 或其它CGI 類似替代技術(shù)來(lái)說(shuō)， Java Servlets 效率更高， 使用更方便， 功能更強(qiáng)大， 更

　　小巧也更便宜。Java Servlet 提供了如下許多優(yōu)勢(shì)：

　　(1) Servlet 可以和其它資源( 文件、數(shù)據(jù)庫(kù)、Applet， Java應(yīng)用程序等) 交互， 以生成返回給客戶端的響應(yīng)內(nèi)容。如果需要， 還可以保存請(qǐng)求- 響應(yīng)過(guò)程中的信息。

　　(2) 采用Servlet， 服務(wù)器可以完全授權(quán)對(duì)本地資源的訪問(wèn)( 如數(shù)據(jù)庫(kù)) ， 并且Servlet 自身將會(huì)控制外部用戶的訪問(wèn)數(shù)量及訪問(wèn)性質(zhì)。

　　(3) Servlet 可以是其它服務(wù)的客戶端程序， 例如它們可以用于分布式的應(yīng)用系統(tǒng)中。

　　(4) 可以從本地硬盤， 或者通過(guò)網(wǎng)絡(luò)從遠(yuǎn)端硬盤激活Servlet。

　　(5) Servlet 可被鏈接(Chain) 。一個(gè)Servlet 可以調(diào)用另一個(gè)或一個(gè)系列Servelt， 即成為它的客戶端。

　　(6) 采用Servlet Tag 技術(shù)， 可以在HTML 頁(yè)面中動(dòng)態(tài)調(diào)用Servlet。

　　(7) Servlet API 與協(xié)議無(wú)關(guān)。它并不對(duì)傳遞它的協(xié)議有任何假設(shè)。

　　(8)像所有的Java 程序一樣， Servlet 擁有面向?qū)ο驤ava 語(yǔ)言的所有優(yōu)勢(shì)。

　　三、J2EE 平臺(tái)上MVC設(shè)計(jì)思想的實(shí)現(xiàn)

　　MVC系統(tǒng)模型構(gòu)建

　　J2EE 技術(shù)結(jié)合MVC 設(shè)計(jì)模式在構(gòu)建企業(yè)級(jí)Web 應(yīng)用的實(shí)現(xiàn)中， JSP 對(duì)應(yīng)于視圖， 因?yàn)檎麄€(gè)應(yīng)用系統(tǒng)主要通過(guò)JSP 來(lái)與外界進(jìn)行交互; Servlet 對(duì)應(yīng)于控制類， 作為JSP 與EJB 之間的中間樞紐; EJB 和JavaBean 對(duì)應(yīng)于模塊， 主要進(jìn)行數(shù)據(jù)業(yè)務(wù)的處理。

　　MVC 系統(tǒng)模型明確的將數(shù)據(jù)的顯示和數(shù)據(jù)業(yè)務(wù)的處理分開(kāi)， 從而使得邏輯結(jié)構(gòu)更為清晰。如果數(shù)據(jù)的顯示方式有所改變， 只需更改JSP 視圖頁(yè)面， 而并不要求相應(yīng)更改數(shù)據(jù)處理模塊; 反之， 如果業(yè)務(wù)要求發(fā)生變化， 也只需更改相應(yīng)的處理數(shù)據(jù)模塊。因而系統(tǒng)可以很容易加入新的業(yè)務(wù)， 可以靈活適應(yīng)各種需求的變化。

　　MVC 設(shè)計(jì)模式應(yīng)用于Web 應(yīng)用程序， 其整個(gè)流程如下： 當(dāng)Web 客戶端的HTML 或JSP 網(wǎng)頁(yè)向服務(wù)器提交時(shí)，服務(wù)器端的控制器Servlet 統(tǒng)一處理這些提交請(qǐng)求。這個(gè)控制器Servlet 根據(jù)提交的業(yè)務(wù)不同， 將請(qǐng)求傳遞給相應(yīng)的業(yè)務(wù)Bean 操作處理， 然后將業(yè)務(wù)Bean 的處理結(jié)果再傳遞給視圖JSP。視圖JSP 在服務(wù)器上處理之后以HTML 的方式回顯給客戶端。這里的業(yè)務(wù)Bean 是一系統(tǒng)處理業(yè)務(wù)邏輯的Java Bean， 每個(gè)Java Bean 處理一種業(yè)務(wù)。會(huì)話Bean 和實(shí)體Bean 都是具體的與數(shù)據(jù)庫(kù)的操作， 在整個(gè)數(shù)據(jù)模塊中供各種業(yè)務(wù)的Bean 進(jìn)行調(diào)用。

　　四、使用分層模型改進(jìn)MVC 設(shè)計(jì)架構(gòu)

　　1、MVC 模式的缺點(diǎn)

　　雖然MVC模式很好地實(shí)現(xiàn)了職能分工，但它本身也有一定的問(wèn)題，主要包括：

　　(1)視圖和控制器之間的緊密連接視圖和控制器是分離的但又是緊密相關(guān)的組件，它妨礙了它們的單個(gè)重用。一個(gè)視圖離開(kāi)其控制器使用好像是不可能的，而反之亦然，例外情況是共享忽略所有的輸入的控制器的只讀視圖。

　　(2)視圖和控制器與模型的緊密耦合視圖和控制器組件都是直接調(diào)用模型。它表明模型接口的改變很可能使視圖和控制器的代碼無(wú)效。如果系統(tǒng)使用多個(gè)視圖和控制器，這個(gè)問(wèn)題就被放大了。

　　控制器接收來(lái)自瀏覽器的請(qǐng)求，然后調(diào)用業(yè)務(wù)邏輯，由業(yè)務(wù)邏輯來(lái)和底層的Model 打交道。在這個(gè)過(guò)程中用數(shù)據(jù)傳遞對(duì)象(DTO)來(lái)進(jìn)行參數(shù)的傳遞。在Struts 中，有一個(gè)ActionForm的類，它與視圖的表單對(duì)應(yīng)，這樣表單的數(shù)據(jù)就能從View 傳到Controller，在到Business Logic 最后到Model，這樣做的一個(gè)缺點(diǎn)就是：一點(diǎn)業(yè)務(wù)邏輯發(fā)生了變化，相關(guān)的類就要修改。

　　但是與后續(xù)相關(guān)的Action、Business Logic、Model 都要發(fā)生變化，這是我們所不想看到的。在設(shè)計(jì)軟件系統(tǒng)的架構(gòu)，我們希望：

　　(1) 僅限于對(duì)解決方案的某一部分進(jìn)行更改以便盡量降低對(duì)其它部分的影響，從而減少調(diào)試和糾錯(cuò)的工作量，使應(yīng)用程序易于維護(hù)，并增強(qiáng)應(yīng)用程序的總體靈活性;

　　(2) 組件應(yīng)該可被多個(gè)應(yīng)用程序重用;

　　(3) 獨(dú)立的團(tuán)隊(duì)?wèi)?yīng)該能夠在處理解決方案的各個(gè)部分時(shí)盡量減少對(duì)其它團(tuán)隊(duì)的依賴，并且應(yīng)該能夠針對(duì)定義明確的接口展開(kāi)開(kāi)發(fā)工作;

　　(4) 各個(gè)組件應(yīng)保持內(nèi)聚性;

　　(5) 無(wú)關(guān)的組件應(yīng)保持松散耦合。針對(duì)這樣的問(wèn)題我們的解決方案，就是用耦合性低的層來(lái)改進(jìn)MVC 模式。

　　2、分層模型對(duì)MVC 的改進(jìn)

　　2.1 分層模型的概念

　　從廣義上來(lái)說(shuō)，MVC 也是一種分層模型，我們?cè)O(shè)計(jì)分層模型是為了改進(jìn)MVC 而并非完全摒棄它。所謂分層模型就是將系統(tǒng)的組件分隔到不同的層中;每一層中的組件應(yīng)保持內(nèi)聚性，并且應(yīng)大致在同一抽象級(jí)別;每一層都應(yīng)與它下面的各層保持松散耦合;每一層都按照一定的規(guī)則將上一層傳來(lái)的數(shù)據(jù)進(jìn)行解包，進(jìn)行一定的處理后再按一定的規(guī)則將數(shù)據(jù)進(jìn)行打包后傳遞給下一層。

　　分層模型交互的過(guò)程如下：

　　從最低級(jí)別的抽象開(kāi)始— — 稱為第1 層，這是系統(tǒng)的基礎(chǔ)。通過(guò)將第J 層放置在第J-1 層的上面逐步向上完成抽象階梯，直到到達(dá)功能的最高級(jí)別稱為第N 層。

　　通常使用下列技術(shù)擴(kuò)充基本的分層模式：

　　(1)層超類型。如果一層中的組件具有相同的一組行為，就可以將這些行為提取到一個(gè)公共類或組件中，并使層中的所有組件都繼承該公共類或組件。這不僅簡(jiǎn)化了維護(hù)并提高了可重用性，還允許通過(guò)對(duì)超類型(而不是特定組件)的運(yùn)行時(shí)引用來(lái)調(diào)用公共行為，從而減少了層之間的依賴性。

　　(2)抽象接口。抽象接口是為較高級(jí)別中的組件所調(diào)用的某一層中的每個(gè)組件定義的。較高層通過(guò)抽象接口(而不是直接調(diào)用組件) 來(lái)訪問(wèn)較低級(jí)別組件。這使得可以在不影響較高級(jí)別組件的情況下更改較低級(jí)別組件的實(shí)現(xiàn)。

　　(3)層外觀。對(duì)于大型系統(tǒng)，常見(jiàn)的方法是使用Facade 模式來(lái)為層或子系統(tǒng)提供單個(gè)統(tǒng)一接口，而不是為每個(gè)公開(kāi)的組件分別開(kāi)發(fā)一個(gè)抽象接口。這使得層之間具有最低的耦合，因?yàn)檩^高級(jí)別組件僅直接引用外觀。所以認(rèn)真設(shè)計(jì)外觀是非常重要的，在后期改變外觀是非常困難的，因?yàn)橛性S多組件都將依賴于它。

　　2.2 改進(jìn)的MVC 模式

　　根據(jù)分層模型的思想和擴(kuò)充技術(shù)，我們改進(jìn)原有的MVC模式，對(duì)View 層進(jìn)行泛化，對(duì)Controller 用Service 來(lái)替代，而Model 我們則對(duì)它進(jìn)行再分層，分為BO、DO 和DA。

　　我們對(duì)View 曾進(jìn)行了泛化，MVC 主要針對(duì)的是Web 應(yīng)用程序，而現(xiàn)實(shí)中的View 泛指用戶的界面，他是與用戶交互的接口，所以我們這里把View 命名成UI，可以是手機(jī)的WAP 頁(yè)面，普通的網(wǎng)頁(yè)，F(xiàn)orm程序，甚至是Athlon 的顯示模型。當(dāng)然，不同類型的View 采取的編碼方式是不同的，對(duì)此，雖然我們可以通過(guò)配置文件等進(jìn)行一系列的改進(jìn)，但無(wú)法從根本上提高我們的開(kāi)發(fā)效率。

　　MVC的Controller我們用Service這一層來(lái)提供，由Service來(lái)導(dǎo)引系統(tǒng)的流程。Service 位于UI 的下一層，起到了承上啟下的作用。一方面，Service 層接收UI 傳入的數(shù)據(jù)，根據(jù)UI 傳

　　入的參數(shù)或者配置文件的設(shè)置，進(jìn)行處理后將處理結(jié)果或者查詢結(jié)果返回給UI 層，顯示給用戶。為了簡(jiǎn)化UI 和Service，Service 和Model 之間的調(diào)用關(guān)系，我們使用抽象的類來(lái)調(diào)用Service，也通過(guò)抽象的類來(lái)返回結(jié)果給對(duì)應(yīng)需要的層。這樣，當(dāng)我增加一個(gè)業(yè)務(wù)層的時(shí)候，每一層只需要管理好內(nèi)部的層即可，不需要考慮其它層的內(nèi)容改變。

　　我們對(duì)Model 進(jìn)一步的細(xì)分，分成Business Object Layer、Data Object Layer、Data Access Layer。這3 層分別處理業(yè)務(wù)對(duì)象，數(shù)據(jù)庫(kù)對(duì)象，數(shù)據(jù)庫(kù)存儲(chǔ)。而各個(gè)層次之間也是通過(guò)抽象類來(lái)實(shí)現(xiàn)。抽象類的好處是提供一種抽象的接口，模糊了各個(gè)層次之間調(diào)用的明細(xì)。各個(gè)層次內(nèi)部再自行打包和解包，然后完成各自的業(yè)務(wù)。這樣，每一層次的耦合度就降低了，而且當(dāng)一個(gè)層次的內(nèi)容發(fā)生修改時(shí)，其它的層次不需要做相應(yīng)的變化。

　　這樣的改進(jìn)一方面改變了原先MVC 的Controller 功能過(guò)于依賴View，降低了模塊間的耦合，另一方面也使得層次更加清晰化，各個(gè)層次的責(zé)任更加明確，為更好的軟件復(fù)用提供有利條件。

　　五、總結(jié)

　　利用分層模型的思想改進(jìn)的MVC 設(shè)計(jì)模式一方面體現(xiàn)了分離思想，是開(kāi)發(fā)人員利用自身的特長(zhǎng)各司其職，另一方面也降低了原來(lái)MVC 設(shè)計(jì)模式的耦合度。這樣的改進(jìn)從某一個(gè)角度來(lái)說(shuō)，增加了軟件的可維護(hù)性、可重用性、可伸縮性、可靠性和安全性，但其本身也會(huì)提高開(kāi)發(fā)的成本，而且多層的分部在增加靈活性的同時(shí)也加大了系統(tǒng)開(kāi)發(fā)時(shí)調(diào)試的不方便。而且，很難設(shè)計(jì)一個(gè)很好的接口，使得多層之間的交換便捷。

　　j2ee技術(shù)論文篇二

　　基于J2EE平臺(tái)的系統(tǒng)集成研究 摘要：J2EE作為一種應(yīng)用開(kāi)發(fā)平臺(tái)，由于其具有平臺(tái)無(wú)關(guān)性、可移植性、多用戶性、安全性等優(yōu)點(diǎn)，正被越來(lái)越多的企業(yè)和系統(tǒng)集成商所采用。文章應(yīng)用分層構(gòu)建思想對(duì)基于J2EE平臺(tái)的系統(tǒng)集成的架構(gòu)進(jìn)行了分析和闡述，并對(duì)Siebel這一CRM集成領(lǐng)域的先驅(qū)進(jìn)行了介紹和分析。

　　關(guān)鍵詞：系統(tǒng)集成;J2EE平臺(tái);Siebe;CRM

　　一、前言

　　系統(tǒng)集成，是以用戶的應(yīng)用需要和投入資金的規(guī)模為出發(fā)點(diǎn)，綜合應(yīng)用各種計(jì)算機(jī)相關(guān)技術(shù)，適當(dāng)選擇各種軟硬件設(shè)備，經(jīng)過(guò)相關(guān)人員的集成設(shè)計(jì)、安裝調(diào)試、應(yīng)用開(kāi)發(fā)等大量技術(shù)性工作和相應(yīng)的管理性及商務(wù)性工作，使集成后的系統(tǒng)能夠滿足用戶對(duì)實(shí)際工作要求，具有良好的性能和適當(dāng)?shù)膬r(jià)格的計(jì)算機(jī)網(wǎng)絡(luò)系統(tǒng)的全過(guò)程。

　　系統(tǒng)集成要求將各個(gè)分離的設(shè)備(如個(gè)人電腦)、功能和信息等集成到相互關(guān)聯(lián)的、統(tǒng)一和協(xié)調(diào)的系統(tǒng)之中，使資源達(dá)到充分共享，實(shí)現(xiàn)集中、便利、高效的管理。系統(tǒng)集成實(shí)現(xiàn)的關(guān)鍵在于解決系統(tǒng)之間的互連和互操作性問(wèn)題，它是一個(gè)多廠商、多協(xié)議和面向各種應(yīng)用的體系結(jié)構(gòu)。這需要解決各類設(shè)備、子系統(tǒng)間的接口、協(xié)議、系統(tǒng)平臺(tái)、應(yīng)用軟件等與子系統(tǒng)等相關(guān)的一切面向集成的問(wèn)題。

　　二、基于J2EE平臺(tái)的系統(tǒng)集成的架構(gòu)

　　J2EE旨在為支持Java語(yǔ)言服務(wù)器端部署而提供與平臺(tái)無(wú)關(guān)的、可移植的、多用戶的、安全和標(biāo)準(zhǔn)的企業(yè)級(jí)平臺(tái)。

　　Java具有平臺(tái)無(wú)關(guān)性，可以運(yùn)行在Windows、Linux、Unix等不同的操作系統(tǒng)上，Java的跨平臺(tái)是通過(guò)Java虛擬機(jī)(JVM)來(lái)實(shí)現(xiàn)的，Java源代碼被編譯成一種結(jié)構(gòu)中立的中間文件格式，只要有Java運(yùn)行系統(tǒng)的機(jī)器都能執(zhí)行這種中間代，Java源程序被編譯成一種與機(jī)器無(wú)關(guān)的字節(jié)碼格式，在Java虛擬機(jī)上運(yùn)行。

　　J2EE標(biāo)準(zhǔn)制定了一個(gè)開(kāi)發(fā)者編寫企業(yè)應(yīng)用時(shí)必須遵守的標(biāo)準(zhǔn)，也制定了各種應(yīng)用系統(tǒng)服務(wù)商必須提供的基于標(biāo)準(zhǔn)的服務(wù)，這樣企業(yè)應(yīng)用程序就可以在不同平臺(tái)間統(tǒng)一地使用這些服務(wù)。就像J2EE是一個(gè)工業(yè)支持開(kāi)放標(biāo)準(zhǔn)一樣，應(yīng)用開(kāi)發(fā)者要確信由應(yīng)用服務(wù)器以統(tǒng)一方式在不同平臺(tái)和不同供應(yīng)商之間提供下層支持服務(wù)，這就允許應(yīng)用開(kāi)發(fā)商集中于業(yè)務(wù)邏輯的開(kāi)發(fā)而不用在他們的應(yīng)用代碼里執(zhí)行這類系統(tǒng)級(jí)服務(wù)。

　　另外，一旦建立一個(gè)基于Java的組件，就可以在多個(gè)軟件系統(tǒng)上重復(fù)使用，也可以移植到不同系統(tǒng)上。重用已經(jīng)建立的組件，企業(yè)不需要擁有編寫整個(gè)應(yīng)用系統(tǒng)所需要的所有技術(shù)裝備，可以從不同的專門研究某一領(lǐng)域的供應(yīng)商處購(gòu)買組件，把這些組件充分利用到自己的應(yīng)用系統(tǒng)中，這不僅使應(yīng)用系統(tǒng)開(kāi)發(fā)速度快速增長(zhǎng)，而且減少了處理各種技術(shù)集的花費(fèi)。 正是由于諸如以上的眾多優(yōu)點(diǎn)，J2EE平臺(tái)堪稱集成信息系統(tǒng)的“強(qiáng)力粘合劑”，它依靠WEB層和業(yè)務(wù)層的組件處理事務(wù)及安全和擴(kuò)展性，降低了訪問(wèn)不同系統(tǒng)的難度。J2EE平臺(tái)的架構(gòu)由客戶層、WEB層、業(yè)務(wù)層、集成層、數(shù)據(jù)庫(kù)層構(gòu)成

　　客戶層是系統(tǒng)的用戶界面，呈現(xiàn)出適當(dāng)?shù)囊晥D，以收集查詢，顯示最終結(jié)果，它可以是瘦客戶端，胖客戶端這些非瀏覽器的客戶端，也可以是基于瀏覽器的客戶端?？蛻魧訉⑿畔⒑蛿?shù)據(jù)呈現(xiàn)給最終用戶，應(yīng)用程序用戶與客戶端應(yīng)用程序交互，客戶端應(yīng)用程序與企業(yè)應(yīng)用程序的其他組件相連。用戶接口/代理提供了客戶與信息進(jìn)行交互的工具和相關(guān)的支持服務(wù)，它使客戶與系統(tǒng)的交互變得簡(jiǎn)單、快捷。J2EE支持的Java客戶端包括Applet、Java應(yīng)用客戶端、J2ME移動(dòng)客戶端或MIDlet，瀏覽器是一個(gè)瘦客戶端，在J2EE系統(tǒng)的客戶端中應(yīng)用最廣?？蛻舳祟愋投喾N多樣，容器必須提供組件支持，為客戶端組件提供運(yùn)行時(shí)環(huán)境，JVM提供了Java運(yùn)行時(shí)環(huán)境，個(gè)人桌面系統(tǒng)、工程工作站、Applet和應(yīng)用客戶端等組件都支持JVM，而MIDlet要求對(duì)JVM進(jìn)行稍加修改。

　　由于業(yè)務(wù)需求瞬息萬(wàn)變，WEB層成了一個(gè)動(dòng)態(tài)層，WEB層主要有兩種職責(zé)：接收客戶層組件的要求，處理請(qǐng)求，然后將請(qǐng)求路由到業(yè)務(wù)層的適當(dāng)組件;接受業(yè)務(wù)層傳來(lái)的結(jié)果，計(jì)算一個(gè)適當(dāng)?shù)囊晥D，然后將視圖路由到對(duì)應(yīng)客戶端。客戶層使用瀏覽器應(yīng)用程序與WEB層組件交互，J2EEWEB層的重要組件有Servlet，ServletFilter和JSP，這些組件部署在高端服務(wù)器上，Web服務(wù)層和容器提供了事務(wù)、命名、目錄和JDBC等服務(wù)。其中，MVC模式分開(kāi)了表示邏輯，業(yè)務(wù)邏輯和數(shù)據(jù)。

　　業(yè)務(wù)層負(fù)責(zé)執(zhí)行必需的業(yè)務(wù)邏輯，它根據(jù)客戶請(qǐng)求計(jì)算業(yè)務(wù)邏輯，但最好將這些組件隱藏起來(lái)，不將業(yè)務(wù)邏輯直接呈現(xiàn)給客戶端。J2EE業(yè)務(wù)層包括業(yè)務(wù)邏輯，數(shù)據(jù)訪問(wèn)邏輯和相關(guān)服務(wù)。EJB是運(yùn)行在業(yè)務(wù)層的業(yè)務(wù)組件，EJB具有分布特點(diǎn)，面向事務(wù)，其中會(huì)話Bean負(fù)責(zé)創(chuàng)建和維護(hù)客戶與服務(wù)器組件的對(duì)話，實(shí)體Bean以適當(dāng)方式實(shí)現(xiàn)數(shù)據(jù)的持久層，消息

　　驅(qū)動(dòng)的Bean可將J2EE應(yīng)用程序與基于JMS的中間件集成到一起。業(yè)務(wù)組件部署在業(yè)務(wù)服務(wù)器上，業(yè)務(wù)服務(wù)器為業(yè)務(wù)組件提供各種“校準(zhǔn)”服務(wù)，如事務(wù)、命名和目錄等。

　　EIS層將前端業(yè)務(wù)邏輯層的組件與后端數(shù)據(jù)庫(kù)層連接起來(lái)，這一層的組件應(yīng)盡量確保數(shù)據(jù)庫(kù)不同資源與業(yè)務(wù)邏輯層組件的無(wú)縫集成。很多信息系統(tǒng)有規(guī)模大、技術(shù)難度大的特點(diǎn)，若巧妙集成這些信息系統(tǒng)，將能保護(hù)現(xiàn)有投資，并有效“重用”信息，流程和工作流。EIS層的集成不是單純的數(shù)據(jù)集成，還涉及信息集成，對(duì)JDBC、JMS、J2EE連接器架構(gòu)、JNI和JNDI等技術(shù)能起到幫助作用，其中J2EE連接器架構(gòu)對(duì)企業(yè)最重要，能給J2EE平臺(tái)帶來(lái)“可插入”行為，廠商的資源適配器允許將信息系統(tǒng)插入J2EE平臺(tái)，以實(shí)現(xiàn)近乎零障礙的集成。

　　三、Siebel-基于J2EE平臺(tái)的CRM集成解決方案

　　Siebel是CRM理念與技術(shù)應(yīng)用的最初實(shí)踐者，為后來(lái)不斷涌現(xiàn)的CRM軟件廠商提供了業(yè)界的標(biāo)準(zhǔn)，可以毫不夸張的認(rèn)為其是CRM的先驅(qū)與開(kāi)創(chuàng)者。到目前為止，Siebel的CRM系統(tǒng)在CRM3個(gè)關(guān)鍵領(lǐng)域，即銷售、營(yíng)銷及服務(wù)3者之間的數(shù)據(jù)/流程整合度最高，各種應(yīng)用界面最為統(tǒng)一。Siebel產(chǎn)品功能齊全，企業(yè)更能根據(jù)自己的需要選擇相應(yīng)模塊，有利于系統(tǒng)的集成，并為今后系統(tǒng)的功能擴(kuò)展提供充足的前提條件。SiebelCRM應(yīng)用引擎的多層體系如圖2所示：

　　用戶界面提供個(gè)性化用戶界面，管理用戶交互行為，從目標(biāo)定義庫(kù)(SRF)讀取有關(guān)用戶界面定義子集并解釋執(zhí)行。目標(biāo)管理器(ObjectManager)為Siebel所有企業(yè)管理邏輯目標(biāo)(BusinessObjects)提供完整一致的目標(biāo)行為，從SRF讀取與企業(yè)管理邏輯有關(guān)的目標(biāo)定義子集并解釋執(zhí)行。數(shù)據(jù)管理器管理一個(gè)獨(dú)立于RDBMS邏輯數(shù)據(jù)映像(DataView)，從而使目標(biāo)管理器功能獨(dú)立，企業(yè)管理邏輯定義無(wú)需因不同的RDBMS而有所改變，并激發(fā)實(shí)時(shí)SQL語(yǔ)句，讀取并解釋SRF中有關(guān)數(shù)據(jù)關(guān)系鏈(DatabaseSchema)的定義，與數(shù)據(jù)交換層(DataExchange)通訊以訪問(wèn)存于RDBMS的物理數(shù)據(jù)。數(shù)據(jù)交換層直接處理與RDBMS相關(guān)的交互信息，作為數(shù)據(jù)管理器和RDBMS的中介橋梁。

　　客戶端接口提供了用戶界面的簡(jiǎn)單整合，利用COM、CORBA、ACTIVEX、XML等技術(shù)可以在客戶端進(jìn)行客戶化整合。服務(wù)端的接口為企業(yè)邏輯定義目標(biāo)提供了實(shí)時(shí)連接，利用COM、CORBA、XML、MQSeries可在服務(wù)器端進(jìn)行整合。數(shù)據(jù)管理器的接口提供了數(shù)據(jù)庫(kù)與數(shù)據(jù)庫(kù)之間的數(shù)據(jù)遷移工具，利用數(shù)據(jù)庫(kù)工具在不同的RDBMS之間進(jìn)行大容量數(shù)據(jù)交換。

　　Siebel的企業(yè)數(shù)據(jù)整合管理(EIM)是專門為系統(tǒng)實(shí)施所提供的數(shù)據(jù)整合管理工具，它用來(lái)處理Siebel數(shù)據(jù)庫(kù)和企業(yè)其他數(shù)據(jù)庫(kù)之間的數(shù)據(jù)交換。EIM利用系統(tǒng)中介數(shù)據(jù)庫(kù)表(InterfaceTables)暫時(shí)存儲(chǔ)輸入輸出數(shù)據(jù)，開(kāi)發(fā)人員只需直接讀寫中介數(shù)據(jù)庫(kù)表的內(nèi)容，中介表與Siebel數(shù)據(jù)庫(kù)之間的數(shù)據(jù)交換與轉(zhuǎn)換由Siebel服務(wù)器的EIM批作業(yè)自動(dòng)完成。使用EIM可以對(duì)數(shù)據(jù)進(jìn)行批量輸入、輸出、數(shù)據(jù)整合和刪除。在需要數(shù)據(jù)輸出到別的應(yīng)用系統(tǒng)場(chǎng)合，可以用EIM從Siebel數(shù)據(jù)庫(kù)輸出數(shù)據(jù)供其他系統(tǒng)使用。必要時(shí)可以根據(jù)對(duì)定義對(duì)數(shù)據(jù)庫(kù)的紀(jì)錄進(jìn)行整合處理，消除重復(fù)紀(jì)錄?？梢愿鶕?jù)定義進(jìn)行數(shù)據(jù)刪除工作，EIM將根據(jù)要求將各相關(guān)的紀(jì)錄刪除。

　　Siebel服務(wù)器采取邏輯體系：

　　Gateway服務(wù)器也稱名字服務(wù)器，作為各企業(yè)服務(wù)器的單一入口，動(dòng)態(tài)分配注冊(cè)Siebel服務(wù)器和各應(yīng)用組件(ServerComponent)的可應(yīng)用狀態(tài)，存儲(chǔ)服務(wù)組件定義以及分配連接信息;如安裝第三方負(fù)載平衡軟件，則可以根據(jù)服務(wù)器負(fù)載情況動(dòng)態(tài)分配入口請(qǐng)求。Siebel服務(wù)器運(yùn)行一個(gè)或多個(gè)Siebel服務(wù)程序，從名字服務(wù)器讀取服務(wù)器的配置信息，利用數(shù)據(jù)接口訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器。企業(yè)服務(wù)器(EnterpriseServer)邏輯管理一個(gè)或多個(gè)Siebel服務(wù)器，

　　讀取單個(gè)RDBMS。數(shù)據(jù)庫(kù)服務(wù)器存儲(chǔ)Siebel數(shù)據(jù)關(guān)系鏈，支持各種流行的數(shù)據(jù)庫(kù)標(biāo)準(zhǔn)接口。Siebel文件系統(tǒng)存儲(chǔ)所有經(jīng)壓縮的文檔數(shù)據(jù)及其他非標(biāo)準(zhǔn)數(shù)據(jù)，以供Siebel應(yīng)用軟件讀取和存儲(chǔ)。

　　四、總結(jié)

　　通過(guò)集成將企業(yè)多種應(yīng)用連接在一起形成企業(yè)集成系統(tǒng)是企業(yè)信息化建設(shè)的高級(jí)階段，構(gòu)建企業(yè)集成系統(tǒng)可以提高企業(yè)信息化應(yīng)用的水平，為提升企業(yè)的市場(chǎng)競(jìng)爭(zhēng)力提供信息技術(shù)手段上的支持。采用集成平臺(tái)技術(shù)實(shí)施企業(yè)集成系統(tǒng)是目前相對(duì)先進(jìn)和有效的方法，J2EE由于其平臺(tái)無(wú)關(guān)性成為開(kāi)發(fā)集成平臺(tái)的首選，Siebel是基于J2EE平臺(tái)的系統(tǒng)集成解決方案，可通過(guò)數(shù)據(jù)交換、企業(yè)數(shù)據(jù)整合管理(EIM)、流程整合等實(shí)現(xiàn)系統(tǒng)間的集成，現(xiàn)廣泛應(yīng)用于CRM領(lǐng)域。

　　參考文獻(xiàn)：

　　1、熊嚴(yán),路書(shū)顏,郝永平.網(wǎng)絡(luò)制造環(huán)境下基于J2EE平臺(tái)的信息集成技術(shù)[J].機(jī)械設(shè)計(jì)與制造,2004(11).

　　2、劉澤軒,江春花.基于J2EE架構(gòu)的科研管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與設(shè)計(jì),2007(11).

　　3、范玉順,李建強(qiáng).企業(yè)集成與集成平臺(tái)技術(shù)[M].機(jī)械工業(yè)出版社,2004(8).