采用EJB開發(fā)的三個優(yōu)勢
EJB是sun的服務(wù)器端組件模型，***的用處是部署分布式應(yīng)用程序當然,還有許多方式可以實現(xiàn)分布式應(yīng)用，類似微軟的.net技術(shù)。憑借java跨平臺的優(yōu)勢，用EJB技術(shù)部署的分布式系統(tǒng)可以不限于特定的平臺。下面主要介紹采用EJB開發(fā)的三個優(yōu)勢。
JAVA語言已經(jīng)慢慢的在成為主流的開發(fā)語言之一，或者說現(xiàn)在已經(jīng)成為了主流的開發(fā)語言。在JAVA語言平臺上，也出現(xiàn)了多種開發(fā)模型。對于剛?cè)腴T的JAVA程序員來說，也許面對這么多的開發(fā)模型，會眼花繚亂，不知道該如何選擇。筆者剛開始接觸JAVA語言的時候沒有多少的開發(fā)模型可以選擇。而前幾年筆者也遇到了這個問題。
可選的開發(fā)模型比較多，筆者必須選擇一個開發(fā)模型作為未來自己的主攻方向。因為人的精力是有限的，特別是我們做程序開發(fā)的。我們要把有限的精力花在刀口上。筆者在這里向大家推薦EJB開發(fā)模型。
這個EJB本質(zhì)上就是一個被管理的組件，存在于J2EE容器中，由J2EE容器進行創(chuàng)建、控制和銷毀。J2EE容器復雜控制當前存在的EJB數(shù)目和EJB所使用的資源。在重負載的情況下，即使是客戶端正在使用的EJB，也將被返回到實例池，如此的話，這個EJB實例還可以供其他客戶端使用，從而提高EJB實例的利用率。
雖然J2EE官方也是推薦使用EJB，但是這并不是一個強制性的措施。程序開發(fā)人員除了利用EJB之外，還可以利用JSP或者單機版的JAVA應(yīng)用程序等等。但是如果應(yīng)用程序需要不斷的升級、性能要求比較高等等，那么筆者就向大家推薦使用EJB，主要有如下三個方面的原因。
一、可以隱藏管道代碼。
現(xiàn)在音樂噴泉在各地迅速的被采用，成為高科技景觀的一個代表之作。程序員在開發(fā)這個應(yīng)用程序的時候，程序人員需要用到這些管道，但是并不需要知道這些水管的具體走向。這不是程序開發(fā)人員所需要關(guān)注的內(nèi)容。程序開發(fā)人員之需要直接使用這些現(xiàn)成的管道即可。我們把這些管道就叫做“管道代碼”。其實程序開發(fā)人員有時候就好像一個工業(yè)設(shè)計師。工業(yè)設(shè)計師在設(shè)計洗澡用的花撒水籠頭的時候，其根本不用關(guān)心自來水管道。
為什么呢?因為自來水管道都是采用同一的標準，水壓的話也是國家有一個強制性的標準。為此在需要使用管道的時候，設(shè)計者之需要直接引用這些標準化的參數(shù)即可。在早期的一些開發(fā)模型中，如最原始的 CORBA開發(fā)模型，程序開發(fā)人員不得不便寫大量的代碼來完成同Corba環(huán)境的交互、連接、注冊過程。其實這些代碼就是通常所說的管道代碼。而如果采用 EJB模型的話則可以***限度的減少這些管道代碼的編寫工作。
如程序開發(fā)人員通過聲明屬性就可以無需要編寫代碼來控制這些功能即可指定組件的事務(wù)性為;不用通過編寫管道代碼來定義EJB組件之間的關(guān)系以及所需要用到的資源，因為可部署的J2EE應(yīng)用程序在部署描述信息中定義了多個EJB組件之間的關(guān)系同時定義了EJB組件所需要用到的資源;如每個Bean 都遵循一個定義的聲明周期和一套規(guī)則，為此程序開發(fā)人員不需要知道“管道”的設(shè)計，而只需要知道管道接口的參數(shù)即可，如此的話系統(tǒng)代碼與應(yīng)用程序代碼之間就是兩個互相獨立的內(nèi)容。
顯然，通過J2EE提供的EJB組件，可以讓程序開發(fā)人員將精力集中在業(yè)務(wù)代碼的編寫上，而盡量減少編寫管道代碼。這不僅可以提高應(yīng)用程序的開發(fā)效率，而且把管道代碼與應(yīng)用程序代碼獨立開來，也利于后續(xù)的調(diào)試與維護。這就是筆者推薦使用EJB模型來開發(fā)JAVA應(yīng)用程序的***個原因。
二、EJB預定義了一些復雜的處理機制。
在應(yīng)用程序開發(fā)的過程中，或多或少有一些共性的內(nèi)容。如需要進行應(yīng)用程序的生命周期管理，需要進行命名和注冊，需要進行事務(wù)管理等等。如果每次在開發(fā)應(yīng)用程序的時候，都需要從零開始來開發(fā)這些功能，那么工作量就會很大，而且代碼的重復利用性也會比較差。為了解決這些問題，EJB提供了一些預定義的服務(wù)，把一些應(yīng)用程序開發(fā)中要用到的服務(wù)集成到J2EE開發(fā)環(huán)境中。需要用到這些服務(wù)的時候，程序開發(fā)人員之需要聲明一下或者通過少量的代碼就可以調(diào)用這些服務(wù)，實現(xiàn)一些復雜的控制管理機制。
如在應(yīng)用程序開發(fā)中，為了保持數(shù)據(jù)的一致性事務(wù)管理機制是必須要實現(xiàn)的一個機制。如果在應(yīng)用程序?qū)用鏇]有實現(xiàn)事務(wù)管理機制的話，則當同一個業(yè)務(wù)涉及到多條記錄的時候，很容易破壞數(shù)據(jù)的一致性。而如果從零開始來編寫事務(wù)處理機制代碼的話，那么工作量會很大。在EJB的容器服務(wù)中就預先提供了事務(wù)管理的解決方式，程序開發(fā)人員可以憑借這個預定義地解決方案輕松的創(chuàng)建事務(wù)、處理與控制事務(wù)等等。
如在應(yīng)用程序開發(fā)中命名與注冊也是很麻煩的一件工作。而EJB也提供另一個命名與注冊的容器，EJB容器和服務(wù)器為 EJB提供了對命名服務(wù)的訪問。遠程和本地客戶端使用這些服務(wù)來尋找EJB;EJB組件本身也使用這些服務(wù)來查詢自身所需要的資源。也就好說，程序開發(fā)人員在應(yīng)用程序開發(fā)中不用通過代碼來實現(xiàn)命名與注冊服務(wù)，而直接調(diào)用EJB組件中的命名與注冊容器即可。這個容器會自動生成相關(guān)的代碼來完成所需要實現(xiàn)的功能。
另外，EJB組件還提供了生命周期管理容器、安全性和訪問控制容器、持久性容器等等，通過這些容器可以讓程序開發(fā)人員少寫大量的代碼，不僅可以提高程序的開發(fā)效率，而且同意了這些基礎(chǔ)性內(nèi)容解決方案。這也有利于后來的人員了解源代碼，有利于應(yīng)用管理軟件的后續(xù)升級。
三、用戶接口與底層業(yè)務(wù)功隔離。
在企業(yè)管理中共性與個性是并存的，這也體現(xiàn)在了企業(yè)的管理軟件上。如同一家企業(yè)，如果管理者的文化背景不同，其或許多同一個業(yè)務(wù)具有不同的管理方式。這個用我們程序開發(fā)人員專業(yè)的術(shù)語來講就是用戶接口不同。但是其背后的管理模型是相同的，也就是說其業(yè)務(wù)功能是相同的。
如利用JAVA語言開發(fā)的一個訂單管理系統(tǒng)，其訂單的處理機制是相同的，都在數(shù)據(jù)庫中建立相關(guān)的紀錄并在保存記錄之前進行數(shù)據(jù)有效性的審核。但是不同的訂單類型其處理方式可能稍有不同。如對于預付訂單，必須要先收到客戶的款項才能夠下訂單給生產(chǎn)部門安排生產(chǎn)或者倉庫部門準備出貨;如對于倉庫訂單，則在流程處理上不需要經(jīng)過生產(chǎn)而直接轉(zhuǎn)到倉庫出貨等等。
也就說是，10種不同類型的訂單，其80%的功能是相同的，而又20%的內(nèi)容由于管理方式或者其他的原因而有所不同。在這種情況下難道要寫十個不同的代碼來實現(xiàn)這十種不同的需求嗎?
在EJB開發(fā)模型中不用這么復雜，因為EJB允許獨立于表達層開發(fā)和部署業(yè)務(wù)功能。如上面這個訂單管理需求，程序開發(fā)人員可以利用EJB模型來實現(xiàn)底層的功能(80%的共性內(nèi)容)，然后再無需重新設(shè)計或者開發(fā)整個應(yīng)用程序或者銷售訂單管理模塊的情況下，可以利用不同的用戶接口來實現(xiàn)用戶的不同需求。
這就好像父母與子女的關(guān)系。現(xiàn)把父母的特性定義好，然后再根據(jù)不同的需要生養(yǎng)不同的子女即可(用戶接口)。由于子女繼承了父母的全部特性。那么只需要把用戶需要實現(xiàn)的一些個性特點嫁接到子女身上即可。
所以這種業(yè)務(wù)需求與業(yè)務(wù)功能相分離，各自獨立的特征，是EJB開發(fā)模型的***優(yōu)勢。程序開發(fā)人員可以利用EJB實現(xiàn)分布式應(yīng)用程序，將用戶接口與底層業(yè)務(wù)功能隔離開來。
【編輯推薦】
