對於企業級 JavaBeans 構成的業務層組件——即我們熟知的 Java 2 Enterprise Edition 平台，隨著軟件向服務化演進，其結構並未停滯。在 EJB 3.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 起始於一個改良的會話 Bean。在 EJB 2.1 中，規範設計者看到了通過 SOAP 訊息訪問的需求，但當時並未構建現有 EJB 分支（會話、實體、訊息）的實現，而是決定使用擴展的會話 Bean 來適配 Web Services。
EJB 2.1 中的問題以傳統介面方式解決——以 Web 服務端點形式服務——並額外增加部署描述符定義具體服務行為。儘管如此，大部分繁重工作不僅源於底層 EJB 會話 Bean 的實際創建，也與將其轉變為 Web Services EJB 的想法有關。
簡言之，EJB 2.1 部署 Web Service 的顯著問題包括：
解決這些問題的兩大形式：註解與簡單舊式 Java 物件（POJO）。註解可放置在 Java 原始碼中的元資料，提供進一步配置屬性或處理指令；POJO 則是無遺傳依賴的 Java 類。
透過註解，部署描述符中定義的所有數據可替代性地放置在包含業務邏輯的源文件中。外部部署描述符在 Web Services EJB 3.0 中並未廢棄，仍有效，但現在提供回退機制，形成更自然、簡單的配置業務邏輯內嵌資訊的過程。
另一方面，業務邏輯的設計與編碼階段可通過 POJO 讓 Web Services 獲得極大簡化。在 EJB 2.1 中，創建能提供 Web Services 的 EJB 過程強迫您處理會話 EJB 強加的遺傳條件。因此，若從簡單易懂的 Web Service 操作集合開始，創建簡單 Java 物件只是 EJB 過程的開始，因為仍需大量工作才能達到 Web Services 設計的 EJB 終點。
現在，讓我們看看實際的 EJB 3.0 代碼。列表 1.1 展示 EJB 3.0 中一個 Web Service 的樣貌。
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 最令人驚嘆的地方是其簡潔，但別被其短小欺騙。EJB 2.1 提供的相同功能也在這單一文件的各部分出現。您會注意到源文件多處使用的 @ 符號，這些標記表示 Java 註解，稍後將被底層 EJB 應用伺服器用來產生預定結果。請注意，沒有這些註解，我們的類只是一個 POJO，因為它未利用任何特定 API 或構造，只是平淨簡單的業務邏輯。
頂層註解 @Stateless 和 @WebService 表示該類將作為一個具備 Web Services 功能的會話 Bean，@WebService 旁的屬性指定特定 Web Services 數據，這些在 EJB 2.1 中放於部署描述符。剩下的 @WebMethod 註解指定哪些方法將作為 Web Service 介面提供，換句話說，Web Service 介面就是那些使用 WSDL 契約描述 EJB Web Service 的操作。
此例闡述了 EJB 3.0 最基本的前提。其他可選方法包括同 EJB 2.1 相同方式使用分離端點介面，但通過註解鏈接，並透過註解指定高級中間件屬性——如事務處理與安全憑證——這些或許是您選擇使用 EJB Web Services 的主要原因。
總結來看，為生產 Web Services 的 EJB 模型發生的變化，對於那些需要 EJB 提供能力的 Web Services，必將帶來受歡迎的轉變；而其他一些選擇可能仍在嘗試獲取最簡單機制將 Web Services 整合到 Java 專案中。
