BEA对SolarMetric的收购引发了来自非技术媒体和分析人士社区的诸多疑问，所以我在此将介绍一些幕后背景。
J2EE的短暂历史
回到客户-服务器时代，那时应用程序与数据库是完全联系在一起的。数据库供应商为查询数据库的应用程序的提供构建工具。1990年末出现了Internet，随之而来的还有Web服务器和Web浏览器。起初Web站点只不过是带有文本、图片和超链接等允许人们阅读贴出的内容并随心所欲导航的HTML文件。终于人们觉得，使用包含业务逻辑和数据库连接的基于浏览器的应用程序会更好。这就是通常所说的Web应用程序。相关例子包括电子交易、互联网银行以及其他的业务应用程序。
那时构建这些应用程序出奇地复杂，而且成本非常高，使它们正常且安全地运转也同样让人头疼。最后人们研制出了一种新型产品来解决这个问题，即应用服务器。应用服务器提供每个应用程序所需的底层平台或应用基础架构，比如集群、安全性、管理等等。
1997年有几十家软件公司提供此类产品，包括Gemstone、Persistence、Bluestone、Netscape、Forte、Kiva、NetDynamics、ATG和WebLogic。虽然革新很活跃，但是每种产品都有自己专有的编程模型，这使得它们难以学习，而且具有高风险。如果企业采用了其中的一种产品，而供应商不再对它进行改进，那么企业花在技能培训和应用程序代码上的巨大投资就会付诸流水。只要这种不确定性的疑云还笼罩在这种新型架构上，它就无法有大的发展。
终于，一组旨在解决这个问题的新开放标准出现了，它被称为Java2企业版(Java2 Enterprise Edition，J2EE)，由Java Community Process (JCP)管理。开发人员社区意识到，Java编程语言更适合于服务器端计算机，而不是台式机。因为这种语言天生就支持多种新的Internet标准和协议，所以它就成为构建Web应用程序的自然选择，但是该语言本身并不完备，还需要定义一个通用的编程模型。
J2EE定义了一些应用程序编程接口(Application Programming Interface，API)和协议，开发人员可以利用它们来编写服务器端Web应用程序。J2EE由许多子规范组成，比如EJB、JSP、JDBC、Servlet、JMS、JNDI和一些其他的底层应用基础架构。每个子规范都有自己的版本号(EJB 1.0、EJB 2.0、EJB 2.1)，这使得它们可以独立地从一个版本升级到另一个版本，每个版本都拥有自己的专家组。如果所有的子规范都进行了升级，它们就组成了一个新的J2EE版本(J2EE 1.2、1.3、1.4)。
J2EE是定义良好的规范而不是代码，意识到这一点很重要。在发布J2EE新版本时，JCP还会发布一个参考实现(Reference Implementation，RI)和认证测试套件(Certification Test Suite，CTS)，前者用于展示如何实现该规范，后者由数千个测试组成，确保供应商的实现服从该规范。这确保了应用程序可以从一种应用服务器产品移植到另一种应用服务器产品上。新规范发布之后，供应商就在他们的产品中实现新规范，并将其发布给客户。单击此处，查看所有服从J2EE的实现。
目前的J2EE版本是1.4，WebLogic Server 9.0中支持的就是该版本。
为了使J2EE这个标志更好看些，Sun宣布去掉其中的“2”，将其称作Java Enterprise Edition (Java EE)。使事情更加混乱的是，不像Solaris几年来一直以十进制小数表示，Java EE下一个版本将用整数表示，即，是Java EE 5而不是J2EE 1.5。
Enterprise Java Bean（EJB）
EJB是J2EE的核心和灵魂。早期的创建者们将它说得天花乱坠，说它是终极组件模型，不会再重复先前的组件模型CORBA所遇到的问题。您只需编写业务逻辑并将其放入一个应用服务器中，应用服务器就会为其提供安全性、管理、事务、高可用性和其他的基础架构服务。EJB将会是即插即用的，可以从为数众多的类别中选择一些并轻松地将其装配到新应用程序中。那时他们说，以后开发人员将分为三种类型：编写EJB的开发人员、将其装配到新应用程序中的开发人员以及创建用户界面的开发人员。
遗憾的是，事实并非如此。首先，学习过CORBA、EJB和其他的组件模型之后您就会明白，将它们混合搭配用于新应用程序的说法似乎不那么可行了。其次，从EJB获取数据到一个关系数据库中并返回（O/R映射）往往非常复杂。最后，相较于EJB的复杂，开发人员把Plain Old Java Object (POJO)视为一个简化模型。这些因素综合起来，导致Java开发人员社区大感失望，从而引发了许多对EJB的负面评价。
EJB开拓了一个成功但却有限的局面。许多情况下，开发人员或者避开它而使用JSP、Servlet和JDBC，或者转向专有的对象/关系(Object/Relation，O/R)映射工具和框架，比如TopLink或Hibernate。
最近几年，针对EJB的前景，在开发人员中间曾经发生过数不清的讨论。诸如Oracle的TopLink之类的产品虽然包含类似功能，但是因为它们是专有的，并且价格很高，所以并不是理想的产品。Hibernate之类的开源框架开始流行，但是它们不为大的供应商所支持，再说它们也不是正式的开放标准。
EJB 3.0
虽然进展很慢，但是JCP无疑正在致力于这一领域的两个新规范。其中一个称为Java数据对象(Java Data Objects，JDO)，另一个就是EJB 3.0。EJB 3.0规范的专家组由BEA、IBM、Oracle、Jboss、SolarMetric、Versant、Sybase以及其他公司组成，他们构建了一个极具行业意义的、易用的、更具伸缩性的解决方案。
EJB 3.0已经预定要进行大规模的更改，以便简化该模型的各个方面。这本质上就是使用实体Bean从头开始（数据持久性层执行O/R映射）。
近一年半以来，EJB 3.0的发展对于Java社区和客户来说可说是清晰可见的，它引起了极大的兴趣，并获得了许多反馈。最终的规范预计在2005年11月1日达到公开最终草案阶段。
对SolarMetric的收购
前几个月Jboss和Oracle已经配送了EJB 3预览版，试图要显示他们对新规范的“领导地位”。IBM在专家组中一向都非常“安静”，还不曾在这方面发表声明。
由于以下原因，SolarMetric对BEA极具吸引力：
- 它的领先的JDO实现（350个客户，对比Versant的150个客户）；
- TopLink和Hibernate团队称它是唯一值得考虑的竞争对手；
- 他们有一个强大、积极进取的工程团队；
- 他们的产品可以用于JDK 1.3，这样WebLogic Server 6.1及以后版本的客户就可以使用它；
- 他们的产品包含JDO和EJB 3.0，二者并不相互依赖，但是却使用相同的持久性引擎；
- 他们有分析工具；
- 他们有反向映射工具；
- 他们有一些处于alpha版本或正在进行的先进特性
- 他们产品的性能要比我们的竞争对手的好
- 它可以提供比Hibernate更高的迭代开发人员生产率，将系数从2提高到4；
- 它可以作为BEA的低端产品与WebLogic Express（WLX）、Tomcat或其他运行时一起使用
- 存在到WLS管理和分析/开发工具的集成
BEA做了一个构建/购买决策分析，得出的结论是，收购SolarMetric是最好的决策。
可在此处查看对此事件的反馈。
原文出处:http://dev2dev.bea.com/blog/estahl/archive/2005/11/background_on_t_1.html
