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