关于网络游戏开发的软件架构的总体考虑：即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前端进行直接通讯。

惟一的问题在于，它并不完美。它抽象出了几乎全部的东西，惟独同样东西没有抽象出来：

并发模型！

作到这一点并不容易。由于只要去掉了任务与线程对应的假设，一切便都变成了问题。一切都须要进行从新的设计。即：须要打破整个系统的架构。并发模型即任务执行模型的变动是一场瘟疫。它要求对一切进行从新设计。

可是它甚至未曾尝试。

如把整个系统的并发模型改成批处理。它基于必定的模型进行工做。用户也许对基础建设的确获得了真正的平台独立性，但却被绑定在其它未被规范涉及到的地方。

也就是说，它看起来是完美的。可是它并无提供全部的东西。

。。。。。。

也许这就是它历来未曾流行的缘由：它看上去很美。而且它在大多数应用环境下也的确很美。可是它不适合“我”的应用。