Kalin的部落格

當撰寫用戶端來存取 bean 的時候, 這個客戶可能是在本地(Local), 或是遠端(Remote). 一個本地的客戶表示它和這個 bean 執行在相同的 heap. 換句話說, 這個 bean 跟用戶端都存在相同的 heap 裡. 不過這是對entity bean 或是在某些非常特殊的情況下才會用 local 用戶端.
 
Java 參照(reference)所保有的位元值, 一但離開了正在運行的 JVM 後就不具有任何意義了. 換句話說, 如果你是一個物件並且手上握有另一個物件的 reference, 那麼這個物件必須跟你坐落在相同的 heap.
 
Java RMI (Remote Method Invocation) 藉由給予用戶端一個 proxy 物件: stub, 來扮演客戶與遠端物件之媒介代理, 來解決上述的問題. stub 處理了所有跟遠端物件間地低階網路通訊細節, 包括 sockets 和 streams.
 
藉由 RMI, 用戶端物件就好像是執行一個遠端的方法呼叫一樣, 但是實際上發生的事情是在呼叫跟用戶端運行在相同 heap 裡的 stub 的 method.

RMI 的目標是要促使網路的透通性(transparency), 基於這個目標, 在 server 端接收 socket 連線的腳色就是 skeleton, 它跟用戶端的 stub 是互相配對的(早期是, 但是現再不一定).
 

---

# 透過 remote object 的 method 傳遞一個 local 的 object:
 
所有的遠端方法都必須宣告 java.rmi.RemoteException, 所以除了 RemoteException 以外, remote method 的呼叫跟 local method 的呼叫其實沒什麼兩樣.
 
1. 用戶端只是呼叫 local 的stub(坐落在相同的heap), 然後 stub 必須打包所有的引數(透過一種 marshalling 的程序), 同時經由 socket 連線到 server, 再將它們送到 output stream.
 
2. 而 skeleton 得處理 stub 傳來的 streams, 卸包參數, 並決定該做的事情, 接著呼叫 remote object(現在變成 local object)的 method.
 
3. skeleton 打包回傳值並將之傳給stub, 並將回傳值以正常, 普通的格式交付給 client.
 
為了要在網路上可以傳遞參數與回傳值, 它們必須是 Shippable, 而 shippable 必須是:
* primitive type.
* Serializable object.
* primitive type 或 Serializable object 的 Array 或是 collection.
* remote object.
 
Q: Java 傳遞物件的方式是, 傳遞一份 object reference 的 copy, 而不是 object 的 copy. 所以在 remote object 的 method 的呼叫上, 這不是不具意義的嗎? 因為 reference 的是另一個 heap 上的東西.
 
A: 是沒錯, 正常的來說, Java 的 argument 是以 by value 的方式而非 by reference 的方式傳遞. 也就是傳遞 object reference 的 copy, 也就是傳遞 object reference 的 copy 的 value. 但是, 如果遠端方法必須有一個 object type 的 argument, 則該 argument 是以這個 object 本身的完整副本被傳遞出去. 所以對於遠端的呼叫, Java 是以 object 的 copy 傳遞物件, 而非 obejct reference 的 copy. 但是前提是這個 object 是一個可以續列化的物件. 所以它必須 implements java.io.Serializable 這個 interface.
 
 
/********************************************
  * Client 的 code
  *******************************************/
 try
 {
  Dog fido = new Dog();
  //這時傳遞的是真正 Dog object 的 copy
  remoteStub.trainPet(fido);
 }
 catch (RemoteException rex)
 {
  rex.printStackTrace();
 }
 /********************************************
  * Server 的 code
  *******************************************/
 void trainPet(Dog arg){}
 
 
1. Client 對  stub 呼叫 trainPet(fido), 傳遞 Dog object reference 的 copy. //實際上只有一個 Dog object.
 
2. stub 製造一個 Serializable object copy, 並透過網路將這個 copy 給 server 的 skeleton.
 
3. skeleton deserialize 傳來的 argument, 在 remote 的 heap 裡製造一個新的 Dog object. //這時的 Dog 跟在 client 的 Dog object 是一樣的.
 
4. skeleton 呼叫 remote object 的 method, 傳遞一個新的 Dog object reference 的 copy. 
 
 

---

# 透過 remote object method 傳遞一個 remote object:
 
Java 實際傳送的是 remote object 的 stub, 換句話說, 在 runtime 時, remote object 還是待在原地, 只是透過網路傳送它的 stub. 一個 remote object reference 指的是 remote reference 的 stub. 如果 client 擁有一個 remote object reference, 它便擁有該 stub 的 local reference, 同時, 該 stub 可以跟 remote  object 溝通.
 
/********************************************
  * Client 的 code
  *******************************************/
 try
 {
  //我不確定是不是用 remoteStub.getCustomer() 這樣寫, 只是將感覺寫出來, 以後要 check
  remoteStub.getCustomer();
 }
 catch (RemoteException rex)
 {
  rex.printStackTrace();
 }
 /********************************************
  * Server 的 code
  *******************************************/
 public class Customer
 {
 };
 public class A
 {
  Customer c = new Customer();
  public getCustomer()
  {
   return Customer();
  }
 };
 
1. client 透過 stub A invoke remote object A 的 getCustomer().
 
2. remote object A 回傳一個 Customer object reference 的 copy, 接著 skeleton 將它置換成(同時 serialize) remote object Customer 的 stub, 然後將 Customer  stub 回傳給 client.
 
3. Customer stub 在 client 被 deserialize, 同時 client 得到指向這個新的 Customer stub 的 local reference copy.
 
 

---

 
Q: client 怎麼知道有哪些方法可以呼叫?? stub 怎麼知道 remote object 提供哪些方法?
 
Before Answer: 如果 stub 要假裝是 remote object, 它就必須提供跟 remote object 相同的方法.
 
A: 一個 interface. 這是所有分散環境下, 所有方法必須讓 client 看的見的管道. 這個 interface 稱為商業邏輯介面, 因為它有 client 想要呼叫的商業邏輯方法. 在技術上一個 remote object 的商業邏輯界面必須是一個遠端介面. so.. 它必須遵循:
1. 繼承java.rmi.Remote
2. 每個 method 必須宣告 java.rmi.RemoteException
3. 引數和回傳值必須是可以傳遞的.
 
import java.rmi.*;
public interface DiceRoller extends Remote
{
 public int rollDice() throws RemoteException;
}
 

---

 
# 在 EJB, remote object 是 EJBObject 而非 bean!
EJBObject 永遠是 bean 的 guard. 所以 EJBObject 實作 remote business logic interface, 並接收 remote invocation. 一旦呼叫達到 EJBObject, server 便介入其中提供所有的服務, such as 安全控管(client 有被授權可以呼叫這個方法嗎?), 交易(這個呼叫是現在交易的一部份, 還是要啟動一個另一個交易?), 存續(在執行這個方法前, 這個 bean 還需要從 db 載入任何資訊嗎?)
 
所以說, stub 跟 EJBObject 皆 implements remote business logic object, 但是裡面卻沒內容. 而 bean 雖然沒有去 implements remote business logic object, 但是它卻有真正 business logic 的功能.

何謂EJB:
 
Eenterprise JavaBean 很簡單. ㄟ~ 至少比自己寫一個具延展性(scalable), 交易性(transctional), 安全性(secure), 又能支援多人多工(concurrent) 能力的企業級伺服器相比的話. ps: 但是它"不保證"負載平衡(load-balance), 容錯(fail-over), 和叢集(clustering).
 
使用EJB, 可以研發出像積木一樣的EJB Component, 這可以讓你或其他人組合出新的或是重組到不同應用程式的元件. 你可以利用宣告的方式來設定和客制化bean (透過XML為基礎的佈署描述檔 Deployment Descriptor; DD) 來改變執行時期bean的特性. 換句話說, 就是在部署時期透過改變XML文件來改變一個bean使用底層服務的方式. EJB 不單只是寫一次到處跑(write once run anywhere), 而是寫一次到處裝(write once deploy anywhere)
 
EJB 讓人專注在商業邏輯上, 而將所有底層的服務交給EJB伺服器的供應商(Server Vendor)來解決. EJB Server提供了一堆services, such as 交易管理(Transaction management), 安全控管(Security), 多人多工(Concurrency), 網路通訊(Networking), 資源管理(Resource management), 存續管理(Persistence), 訊息服務(Messaging), 佈署時期的客制化(Deploy-time customization).
 
 
Q: EJB和J2EE有什麼不同?
A: J2EE和EJB都是對伺服器的規範, 實際上EJB是J2EE的子集合, 換句話說, 一個J2EE伺服器裡面包含一個EJB Container. 所以每個 J2EE Server 必須包含一個 EJB Container 和一個 Web Container(to run JSP & Servlet).
 
Q: 可以在Java類別裡撰寫商業邏輯程式碼, 然後在 bean 裡去呼叫這些商業邏輯方法, 這樣我就可以再利用這些商業邏輯嗎?
A: 可以, 如果你的 bean 呼叫一個不是 bean 的 Java 類別上的方法, 那個方法還是在 Container 的控制範圍之下, 所以只要關係到了 Container, 那些非 bean 的方法也會變成 bean 的一部分功能.
 
Q: 一般 javabean 和 enterprise javabean 有何不同?
A: 一般 javabean 是指一些根據命名原則所撰寫且可以被開發工具使用的可在利用元件. 且絕大部分都被利用在開發時期, 主要是為了讓一個 bean 的 event 更簡單快速的聯接上別的 bean 的方法, 或是改變instance variable value. 就像其他一般的 class 一樣, 可以在 JVM 裡面執行. 可利用在 Swing, Jini, Servlets...等, 但是一個 enterprise javabean 必須在一個 EJB Container 的控制下執行, 且在執行時期才會被交出來. 在一個 EJB 裡面絕大部分的方法都是 Container 自己去呼叫的. 而這些方法到了 Server 外就變得沒有意義了.
 
 
EJB Server 裡面的三大部分: 
 
1. EJB Object: 會干涉所有對 bean 的呼叫, 所以用戶端永遠不能跟 bean 直接交談. The EJB object is the bodyguard for the bean... it intercepts the calls coming from the client and passes the request to the Container. 這使得 server 或 container 有機會介入並加入一些底層的服務(container services).
 
2. Container services: The Container services are the things you’re paying for... the reason you’re using EJB in the first place - transactions, security, persistence, etc.
 
3. EJB: The bean has the real business logic. It has the actual functionality (method code) to do whatever it is this remote service is supposed to do (track your shopping cart, do a big calculate, update a customer’s address, etc.
 
 
 
三種 bean:
 
1. Entity: 使用一個 entity bean 來代表在永續儲存體(persistence store) 裡面的一個東西, 通常會來代表資料庫裡的某個東西, 而一個 entity bean 的一個實體(instance) 代表 table 裡的一筆資料. 一個典型的 entity 範例就是 Customer, 其中一個實體可能代表 Bo Olean(ID# 343) 而另一個 instance 可能代表 Trixia Lin (ID# 870).
 
2. Message-driven: 當你需要一個 JMS 用戶時就可以使用 message-driven bean. 換句話說, 它可以監聽來自 JMS 信息服務的信息. 就如同規範一樣, 用戶端永遠不可能直接呼叫 message-driven bean, 但是 message-driven bean 沒有 EJBObject, Client 必須發送一個信息給信息服務, server 會直接從信息服務取得用戶端的請求.
 
3. Session: entity bean 通常代表一個東西, 而 session bean 代表一個處理程序(process). 除了上述所有的事情以外, 都使用 session bean. 幾乎所有型態的後端服務都可以, 也通常應該要由一個 session bean 起始. 這是因為通常會使用到一種叫做 Session Facade 的 Design Pattern.
 
兩種 Session bean:
 
3-1. stateful 的 session bean: 可以在方法呼叫的過程中記住交談狀態(conversational state, 就像購物車).
 
3-2. stateless bean 一旦等到被呼叫的方法完成了以後就會直接把這個 client 給忘掉. 不過這不代表用戶端不會持續的呼叫這個 bean 來記住與前一次的方法呼叫有關的狀態. 一個stateless bean 還是可以有 instance variable, 它只是無法用來維持屬於某個特定用戶的值.
 
雖然 stateless session bean 比 stateful session bean 要來的延展性(scalable)(因為這跟 Contaniner 如何管理 stateless session bean ),  但是當你需要交談狀態時, 你應該考慮 stateful session bean, 還有就是當使用替代方法來保存時所造成的效能影響比 stateful session bean 還大的時候.
ps: 這裡指的保存狀態像是讓用戶端來保存狀態, 或用 servlet 來保存狀態, 甚至使用資料庫來保存這個用戶端災呼叫每個方法與方法之間的狀態. 
 
* Entity bean 可能代表的是在酒吧裡賣的各種飲料及每個客戶, 但是沒有調酒師, 飲料對客戶有什麼意義? 你需要有個人把實體的東西(飲料與客戶) 透過某種意義連結在一起, 那就是 session bean 要做的事情!
 
 
 
建立一個 EJB 要做的五件事情:
 
1. 撰寫具有商業邏輯的 bean class.
 
package headfirst;
import javax.ejb.*;
public class AdviceBean implements SessionBean
{
 private String [] adviceStrings = {"test", "test1", "test2", "test3"};
 public void ejbActivate() //必須實作來自 SessionBean 的 method
 {
  System.out.println("ejb activate");
 }
 public void ejbPassivate() //必須實作來自 SessionBean 的 method
 {
  System.out.println("ejb passivate");
 }
 public void ejbRemove() //必須實作來自 SessionBean 的 method
 {
  System.out.println("ejb remove");
 }
 public void setSessionContext(SessionContext ctx) //必須實作來自 SessionBean 的 method
 {
  System.out.println("session context");
 }
 
 public String getTheMessage() //來自 component 的真正的商業邏輯, 也是 Client 想呼叫的東西
 {
  System.out.println("in get advice()");
  int random = (int)(Math.random()*adviceStrings.length);
  return adviceStrings[random];
 }
 public void ejbCreate() //不來自 SessionBean, 但是是一個 EJB 規則, 必須要有這個 method
 {
  System.out.println("in jeb create()");
 }
}
 
2. 為這個 bean 寫兩個 interface (Home & Component).
 
HOME 介面: Client 使用 home interface 來要求一個對 component interface 的參照. 這個 home 是 client 為了要取得一個對 bean reference 的起始點(或至少 client 會認為這是一個 bean ). 我們可以先把 home 想像為某個製造和散佈 bean 的 reference 給 client 的工廠.
 
package headfirst;
import javax.ejb.*;
import java.rmi.RemoteException;
public interface AdviceHome extends EJBHome
{
 //create() 必須回傳一個 component interface 型態
 public Advice create() throws CreateException, RemoteException;
}
 
COMPONENT: 所有商業邏輯宣告的地方. 換句話說, 就是把所有 client 想呼叫的 method 都放在這裡.
 
package headfirst;
import javax.ejb.*;
import java.rmi.RemoteException;
public interface Advice extends EJBObject
{
 //實際的商業邏輯 必須對應到 bean class 裡面的 method
 public String getTheMessage() throws RemoteException;
}
 
Q: 為何 bean class 必須要有和 component interface 相同的 method 卻不去實作 component 呢?
 
A: 規範裡不建議這樣做, 因為:
 
1) component extends EJBObject, 而 EJBObject 不是一個標誌介面, 它是具有一些方法的, 這意味著任何一個實作 component 的 bean 也必須實作 EJBObject 的所有方法. 而且, EJBObject extends java.rmi.remote interface, 所以如果 bean 真的 implements component, 那也代表 bean 將成為一個 remote class, 這永遠都不該發生! 因此除了 server 本身以外, 永遠不應該用任何東西, 任何方式去存取 bean.
 
2) 雖然對 client 來說, 好像是直接呼叫 bean class 的 method, 但是真正來說, 是呼叫 component 的 method, 換言之, client 真正呼叫的是 EJBObject, 這是 server 在 deploy 時實作出來的. client 永遠, 永遠, 永遠不會直接跟 bean 互動.
 
3) 透過 component interface 的 implements EJBObject(由 server 製作出來的 EJBObject ), 也就是 remote object, 它會干預所有對這個 bean 的 business logic method 的呼叫. 
 
4) 所以我們透過 server 來檢查 component interface 與 bean class 的 method 是互相吻合的.
 
 
重點來了!!
1. component interface  has to implements EJBObject.
2. this bean has to implement SessionBean, and can't implements component.
3. verify the same methods of bean & component via a deployment tool.
 
3. 建立一個 XML 的 Deployment Descriptor; DD, 來告訴 server:  是哪一種 bean, 和如何管理它. 必須將它命名為 ejb-jar.xml. DD 必須放在一個稱為 META-INF 的目錄下.
 
4. 將這個 bean, 兩個 interface, 和 Deployment Descriptor 放進一個 ejb-jar檔(一個 ejb-jar 檔案裡面可能會有一個以上的 EJB, 但是只會有一個 DD). 
 
ps: 以上4個步驟都是 Bean Provider (bean 開發人員) 需要做的.
 
5. 利用 server vendor 所提供的工具把這個 bean deploy 到 server 上. 其實這步驟包含了兩各步驟:
5-1. 組成應用程式(Application Assembly): 整合不同的 bean 跟一個 DD 放在一個全新的 ejb-jar 檔. 在整合的階段, 也需要加入一些 Bean Provider 不知道的事情到 DD 裡面.
5-2. 佈署(Deployment): deployment 的兩個關鍵部份就是:
5-2-1) 命名 bean, 所以 client 會知道如何找到 bean.
5-2-2) 讓 bean 進入到 container 的控管範圍.
 
 
 
EJB 參與人員的腳色與責任:
 
Bean Provider:
應交付事項: ejb-ja 檔案.
責任: 撰寫 bean 的原始碼.
特性: 知道 business logic.
 
Application Assembler:





 
 
 
Client 必須要做的 5 件事:
 
1. 取得一個對 JNDI InitialContext 的 reference.
 
2. 使用 InitialContext 去 lookup 那個 bean 的 home interface. 換句話說, 就是使用在 deploy 時所給的 JNDI 名字去 lookup.
 
3. Narrow 和 Cast 我們透過 lookup 傳回來的東西, 而這個東西實作了 home interface.
 
4. 呼叫在這個 home interface 上的 create(), 去取得一個對 component interface 的 reference.
 
5. 呼叫 component interface 上的 business logic method.
 
 
 
 
 
 
Reference : Head First EJBtm scbcd 專業認證指南