關於網絡遊戲開發的軟件架構的總體考慮：即EJB在遊戲開發中的可行性研究

1，EJB是什麼：

    它是企業級軟件開發環境中的一個標準：應用開發者與服務提供者經過這個統一的界面進行交互。它的存在，大大提升了企業級應用的可移植性------這裏指的是相對於平臺的可移植性。好比，若是我把應用建在SPRING FRAMEWORK上，那麼當SPRING再也不流行的時候，或者當我發現有更好的框架或平臺的時候呢？。。。

一旦我把平臺建在EJB標準上。這就意味着在具體支撐平臺與應用之間增長了一道額外的中間層。這道中間層，爲系統的擴充或實現的更新，修改，更換提供了無限的可能。它（即EJB）在整個軟件系統中的價值，與interface在java中的價值，是同樣多的。只不過這兩種價值分別處於不一樣的層次。對interface來講，它的價值在於爲不一樣的語言級部件提供了一個抽象交互的手段；而對於EJB來講，它的價值在於爲不一樣的系統級部件或者說模塊件部件、庫級部件提供了一個抽象交互的手段。

EJB提供了一切。EJB提供了事務管理，分佈式管理，持久層管理，安全性，可伸縮性，以及與異構應用通訊的能力，緩存等。

甚至，由於它也是一個JAVA規範，因此在提供上述的同時它也提供了一個併發模型：

任務==線程！

 

 

 

2，EJB的工做模式：

WEB SERVER，SERVLET CONTAINER， EJB CONTAINER，分別是不同的東西。有些APPLICATION SERVER將三者放在一塊兒，如WEBSPHERE，但其實內部仍然是經過相互通訊的手段連成一個總體的。這個通訊的手段有可能（能夠）是本地調用即方法調用，也有多是外部調用即協議調用（如IIOP。至於其是否支持其它協議，目前尚且未知）。而這種協議調用，也有可能發生在系統（OS）內，也有可能發生在系統（OS）外。

 3，EJB甚至能夠經過FLASH REMOTING與FLASH前端進行直接通訊。

惟一的問題在於，它並不完美。它抽象出了幾乎全部的東西，惟獨同樣東西沒有抽象出來：

併發模型！

作到這一點並不容易。由於只要去掉了任務與線程對應的假設，一切便都變成了問題。一切都須要進行從新的設計。即：須要打破整個系統的架構。併發模型即任務執行模型的變動是一場瘟疫。它要求對一切進行從新設計。

可是它甚至未曾嘗試。

如把整個系統的併發模型改成批處理。它基於必定的模型進行工做。用戶也許對基礎建設的確獲得了真正的平臺獨立性，但卻被綁定在其它未被規範涉及到的地方。

也就是說，它看起來是完美的。可是它並無提供全部的東西。

。。。。。。

也許這就是它歷來未曾流行的緣由：它看上去很美。而且它在大多數應用環境下也的確很美。可是它不適合「我」的應用。