這個主題討論 Session Bean Facade 的一般概念及介紹工作台所提供之實作的好處。工作台會實作與 WebSphere EJB 調解者互動且作用於靜態產生的服務資料物件 (SDO) 之 Session Bean Facade。
Session Facade 的 Rational Application Developer 實作包括建立一個 Session Bean 來封裝一或多個 CMP Entity Bean 的資料和邏輯內容。 這個 Session Bean 會與隨著 Session Bean 而建立的對應 SDO 互動,且會針對一或多個 CMP Entity Bean 所指定之資料的表示法而自訂。 建立 Session Bean Facade精靈用來在 CMP Entity Bean 中產生註釋,之後,便能利用註釋來產生 Session Bean Facade。 當使用這個精靈時,您可以利用圖形方式來選取 CMP Entity Bean 及其全部或部分 CMP 屬性和 CMR 欄位,以併入新的 SDO 中。 結果是一個 Session Bean 實例,它會參照對應的 SDO 圖形且會利用 EJB-QL 與 EJBMediator 進行任何持續性查詢的互動。
請參閱 Session Facade 和 SDO 的註釋,以取得用來定義 Session Bean Facade 和 SDO 的 @ws.sdo 和 @ws.sbf 標示組的參照資訊。
資料物件最初是設計成一種將用戶端應用程式的實際資料緩衝在商業層的方法。 例如資料存取物件,它們是抽象化和封裝不同來源之資料的標準方法。
服務資料物件 (SDO) 是從 CMP Entity Bean 衍生出其內容之資料物件的類型。它們能夠將一或多個 CMP Entity Bean 的部分個別儲存器管理關係 (CMR) 內容封裝在單一物件中,以便在用戶端應用程式和商業層之間進行較粗略的交易。資料變更由管理一或多個 SDO 的資料圖來監視,中間層的資料調解者服務則會管理與用戶端之間的資料轉送。
傳統上,Session Facade 是用來緩和用戶端層和商業層應用程式和物件的緊密結合而產生的複雜度和效能問題。 傳統的分散式企業應用程式會搭配 Session Bean 和 Entity Bean 來使用 Enterprise Bean,Session Bean 用來進行處理,Entity Bean 用來呈現資料,Enterprise Bean 用來將商業資料和邏輯呈現於用戶端層。
當應用程式較大時,所產生的一項結果便是用戶端層和商業層的互動會成長,商業邏輯的複雜度會逐漸和用戶端應用程式糾纏在一起。 因此,用戶端必須適當瞭解和回應整體的商業邏輯和資料。
在用戶端和伺服器之間維護資料完整性很容易成為一項龐大的工作,這需要與用戶端進行越來越多的網路呼叫來將用戶端和伺服器同步化,用戶端程式本身的複雜度也會膨脹。
引進 Session Facade 就是一種將資料和用戶端的操作分開,以消除許多這些情況的方法。 這是藉由建立 CMP Entity Bean 的 Session Facade 來接收商業層所提供的抽象資料及這項資料所需要之商業方法來完成的。現在,資料交換可由調解者來處理,通常就是 EJB 機制本身的 CMP 機能。 現在,用戶端只使用方法和資料表示法,不必負責資料的完整性及整體商業邏輯的符合。
不過,傳統 Session Facade 實作有些限制。 給定的 Session Facade 只能使用單一 Entity Bean 實例,即使進階應用程式會包含多個 CMP 定義的資料也是如此。 這會造成用戶端和商業層之間許多相對精細的網路呼叫,可能使網路效能退化。