對於企業級JavaBeans形成的商務層構件，也就是我們所熟知的Java 2 Enterprise Edition平台，相對於軟件的進化為服務，在結構方面並沒有停滯不前，在EJBs3.0版本同早期的版本比較中，我們已經可以看到一個具有了完全不同的開發模型，這就使得在使用Web services的過程更加簡單。
如果你是EJB的早期采用者，那麼你對這個技術自從最初以來的復雜性應該比較了解。復雜性讓很多人已開始就放棄了使用EJB的想法，更不要說根據這個Java規范來實現Web services的可能性了。就這樣，很多項目都使用了單獨的API，如JAX-RPC或者類似Apache Axis的框架來在Java環境中部署Web services。盡管這種方式提供了一種新對較低的入口門檻，但是它缺少內在的中間件服務——例如事務處理和安全服務——很多的都是使用EJB架構的主要原因，使得開發者不得不去在一個不是最好的情況下來處理Java Web services，以使得能夠以高級的中間件性能來運作或者帶來一個十分復雜的開發生命周期。
最先的，應該指出的是EJB不是一個本質上的EJB，而是為大家更為廣泛的指導的Session EJB的擴展。那也就是說，一個Web services使能的EJB開始是以一個改進過的會話EJB運行的。在EJB版本2.1中，規范設計者看到了需要提供一個通過SOAP消息訪問機制，但是在哪個時候不是構建一個現有EJB的分支的實現——會話，實體和消息——這個決定是使用擴展了的會話bean來適應Web services。
前面所說到的在EJB2.1種的問題是以一個傳統的接口方式來解決的——是以一種Web 服務終端的形式來服務的——和一個額外的部署描述符來定義具體的服務行為。盡管如此，在這個過程中的大部分的苦差事並不是僅僅由於底層EJB的會話bean的實際上的創建，而也同你想把它轉變成一個Web services EJB的念頭有關。
簡短的來說，我們只是列舉在一些特別的過程中的缺點，後面我們會轉移到一段實際的EJB3.0代碼來看看是如何改變的。在EJB2.1中部署一個Web service最為顯著的問題如下：
Web service需要從一個會話EJB采用它的行為，而這個會話EJB本身是和一個遺產層次——例如在EJB3.0之前的版本——是緊密聯系在一起的，同時也具有一系列的為EJB環境所需要的伴隨接口。
你需要定義一個傳統的Java接口，這個傳統接口將會用於提供服務端點，服務端點就是類似於在一個會話EJB中已經包含的遠程接口。
還需要另外一個配置文件——部署描述符——進一步的來指明EJB的服務行為。
對這些Web services EJB的問題的減輕分為兩種主要的形式：注釋和簡單的舊Java對象(POJO's)。注釋是可以被放置在Java源代碼文件中的元數據，為的是能夠提供進一步的配置屬性或者處理指令來執行Java環境。在另外一個方面，POJO's被拆分成java類，這些java類沒有遺傳依賴關系。
通過注釋，所有在部署描述符中已經定義了的數據可以被替代的放置在一個當讀的文件當中，也就是那個包含了商務邏輯的源文件。這不是說外在的部署描述符在Web services EJB 3.0中廢除了。相反的，他們仍然是非常有效的，盡管他們現在將會提供一種後退機制，來形成一種更加自然並且簡單的過程，以配置商務邏輯的內嵌信息。
另一方面，商務邏輯的設計和編碼階段是可以達到的，正如Web services可以通過使用POJO's來獲得極大的簡化。在EJB2.1種，創建一個能提供Web services的EJB的過程強迫你去處理會話EJB強加的遺傳條件。因此對於這些情況，如果你以一個簡單和容易理解的Web service操作集合開始，創建一個簡單的Java對象只是EJB的過程中的開始，因為你需要作許多其他的工作來達到Web services設計的EJB的最後。
把POJO's作為EJB來處理的能力實際上是前面所提到的注釋的概念的結果，同時也是已經在核心Java5 平台和Java 5 Enterprise Edition中都進行了約束的范式轉移。但是現在，讓我們看看我們手邊的工作，列表1.1展示的是在EJB3.0 中，一個Web servicec看起來是怎麼樣的。
列表 1.1 Web Service EJB 3.0
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;
@Stateless
@WebService(serviceName="Weather", portName="WeatherPort")
public class WeatherBean {
@WebMethod
public double hiTemp(String city) {
// Perform lookup to DB or some other data source
return temp;
}
@WebMethod
public double lowTemp(String city) {
// Perform lookup to DB or some other data source
return temp;
}
@WebMethod
public double avgTemp(String city) {
// Perform lookup to DB or some other data source
return temp;
}
// This method will not be exposed through the web service
public double fahrenheitToCelsius(double fahrenheit) {
// Perform conversion
return celsius;
}
// This method will not be exposed through the web service
public double celsiusToFahrenheit(double celsius) {
// Perform conversion
return fahrenheit;
}
}
以前的Web service EJB最令人驚歎的地方應該就是它的簡潔，但是不要讓它的簡短愚弄了你。在EJB2.1中所提供的相同的功能也在這個單獨的文件的各個部分出現了。你會注意到這個源文件中的很多地方都用到的@符號。這些標記表示的是Java注釋，這些java注釋在後來將會被底層的EJB應用服務器用來產生預定的結果。請注意到，沒有這些注釋，我們的這個類只是一個POJO，因為它沒有利用任何特定的API或者構造。它只是平淡而簡單的商務邏輯。
最頂端的注釋——@Stateless 和 @WebService——表示的是這個類將會被用作揖個具有Web services功能的會話bean，而在@WebService旁邊的屬性，表示的是特定的Web services數據，這些數據在EJB2.1中是被放置在一個部署描述符中的。剩下的@WebMethod注釋是用來指定哪些方法將會作為Web service接口被提供出來，換句話說，Web service接口就是那些使用一個用來描述EJB Web service的 WSDL契約的操作。
這個例子解釋了在EJB3.0中最基本的前提。其他的可供選擇的方法可以包括同在EJB2.1中相同的方式來使用一個分隔端點接口，但是通過注釋來鏈接它，並且，當然的，通過注釋指定它的高級中間件屬性——例如事務處理和安全證書——這些可能是你選擇使用EJB Web services的最主要的原因。
通過這個，我們可以總結一下我們對在為生產Web services的EJB模型裡面發生的一些改變的看法，對於那些使用需要添加EJB提供的能力的Web serivcies ，這是必將帶來受到歡迎的轉移的過程，並且其他的一些選擇的可能仍然在試圖獲取最簡單的可能的機制來集成Web serivces到他們的Java項目中去。
