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

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

并发模型！

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

但是它甚至不曾尝试。

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

也就是说，它看起来是完美的。但是它并没有提供所有的东西。

。。。。。。

也许这就是它从来不曾流行的原因：它看上去很美。并且它在大多数应用环境下也的确很美。但是它不适合“我”的应用。