33558www.Sina.com/「J2EE”这个缩写第一次被介绍到世界上的时候，可能没有几个人能预料到未来发生了变化的历史。 那是1999年6月的JavaOne年会上，当时Sun公司Java企业开发部门负责人Mala Chandra兴奋地预告了Java世界的这个新成员。
不熟悉背景的听众们推测出了她演讲中出现的一系列新术语。 表情可能令人惊讶，也迷惑了：完整的“多层企业开发架构”，以“容器”和“组件”的形式提供服务，是一套“制造商中立的开放技术规范”，为开发者提供不同的平台
在当今的开发者看来，这些似乎已经成为了老生常谈，但当时幻灯片上闪烁的每一个口号都意味着观众以后都要经历一个艰难的学习过程。
幸运的是Chandra有很棒的口才； 在该系学习建筑学的印度裔高级负责人在谈到软件体系结构时也有特别强的空间想象力。 她清楚地说明了设计J2EE体系结构的两个最初目的。 首先，对制造商来说，J2EE意味着一套开放标准，通过加入这一标准，他们的产品可以在各种操作系统和操作环境中运行，成为成熟的企业计算系统中可更换的部件。
其次，对于开发人员来说，J2EE是现成的解决方案，该解决方案解决了企业APP应用程序开发中的许多技术难题，包括跨平台移植、事务处理、安全性等“信息就像一条川流不息的河流，经过各种平台和设备，从企业APP应用系统的边缘流向边缘”。
为了理解这句话当时的实际效果，我们还需要把时间指南回到1999年。 除了准备迎接千年虫之外，99年做了什么？ 为了回答这个尖锐的问题，我翻了六年前的工作记录，找到了自己当时参与的项目规格书。 它正好可以提供“Java企业开发”1999年的标准照片。
这是日本知名IT制造商的企业信息管理系统，是在NetScape 3.0 Gold浏览器上运行的Java小程序接口，通过专用的中间层系统连接到Oracle 8数据库。 该中间层已经相当现成完善，可以提供远程对象调用、事务处理等一系列基础服务； 我们剩下的任务只是完成服务端业务对象代码和相应的客户端交互开发。
除了applet客户端的特殊之处，上述系统与当今常见的J2EE体系结构相近，尤其是业务对象的编码也由home类、主键(PK )类、实体类等部分组成，多为但是，这些类不继承javax.ejb包的接口，而是使用专用的API。 与EJB的类似并不是偶然的。 设计师一定参考了Sun在1997年底发布的EJB 1.0技术规范。
换句话说，在J2EE诞生之初的语境下，市场上已经存在着各个层次的“准J2EE中间件”。 它们主要用于解决三个主要问题：事务处理、分布式对象管理和Web请求处理。 首先，事务管理器(Transaction Processing Monitor )是高端企业计算领域的热门产品，知名的APP应用服务器制造商BEA收购了事务软件Tuxedo，使其成为米另一方面，从90年代初开始，越来越多的人将“n层分布式对象体系结构”视为传统客户端/服务器体系结构的替代方案。
当时刚刚兴起的CORBA技术是推动这一趋势的重要力量(例如，上述日本制造商自行开发的专用中间层采用CORBA作为基础设施)。 最后，Java技术在网络领域的应用也是当时首个崭露头角的热点。
1997年6月，Sun在发布“Java Web Server”的同时首次发布了servlet API； 我不认为这种技术副产物与1998年问世的JSP一起完全符合制造商的战略需求。 对于上述n层体系结构来说，HTTP服务是非常理想的前端。 因此，基于Java的Web引擎此时也是企业级Java解决方案的不可缺少的一部分。
JVA、网络、事务处理、分布式对象，这些开发潮流汇聚在一起，形成了当时最受欢迎的产品“APP应用服务器”或“中间件”。
为了评论连体修饰语“最受欢迎”，我们来看看BEA公司1998年收购web APP应用服务器制造商Weblogic的交易价格。 1.92亿美元。 这不是孤立的收购，NetScape和Sun也以接近的价格购买了另外两家公司Kiva和NetDynamics。
这正是J2EE标准制定的背景。 几乎所有主要制造商都在推出或匆忙制造自己的APP应用服务器产品，但对于该“APP应用服务器”是什么，竞争对手各不相同。
至此，我们整理了J2EE技术规范的第一个版本于1999年12月问世的实际意义。 首先，它为Java企业开发提供了清晰的全景图，客观准确地定义了每个分支技术在这一领域的地位和作用。
至此，就Java企业解决方案的组成部分达成了基本共识。 然后，我们使用“容器”和“组件”等概念描绘了Java企业系统的典型体系结构，明确划分了中间件制造商和APP应用程序开发人员的角色。
最后(但绝不是最重要的)，J2EE通
过一套公开标准规定了应用服务器产品的具体行为，在执行此标准的厂商产品之间实现了一定程度的可替换性和互操作性。当时的媒体用“B2B开发的默认标准”之类的说法欢呼这项里程碑式的成就——那些撰稿人哪里知道，在J2EE与那个被称为“B2B” 的短命新贵之间，其实并不会有太多故事发生；同样，他们也不会想到，J2EE要想成为一种真正成熟的开发范式，前方还有一段远为艰辛的旅程。
社区的形成
记得Kruglinski在名著《Inside Visual C++》的某个版本中给出了一个Web浏览器的代码例子；在这一节的开头他说到：如果你几年前开发了一个Web浏览器，那肯定会给你带来上千万的收益；但 如果你现在才想到开发这个东西——那也就是个C++语言的练习罢了。
在今天的程序员眼中，应用服务器似乎也成了价格低廉（如果不是全然免费）的日用消费品。所以，想要理解它们在那几年的大行其道，就非得借助Kruglinski这样的智慧不可。
在1999年底，市面上可以找到30种以上自称“Java应用服务器”的产品，可见当时这类软件是网络风险投资的宠儿。但是此时出台的J2EE规范就像是 一阵席卷整个产业的劲风，在一夜之间，所有人都有了判断什么是一个“应用服务器”的权威途径。
为了获得一张J2EE竞技场的入场券，各家厂商面临两项考验：首先，要具有能够覆盖J2EE中所有主要技术的产品线。这在当时是一项非常苛刻的要求，在没 有开源产品可供参照的情况下，短时间内推出包括EJB容器、Web引擎和JMS中间件的整体解决方案，这决不是随便哪家创业公司都能办到的。
完成了若干次成功的并购之后，BEA在这一点上抢占了先机，完整的产品线使它成了人们心目中的首选J2EE平台提供商。其次，要让产品通过Sun的 J2EE兼容性测试。要做到这一点同样不易：就连IBM的WebSphere也一时还没达到百分之百的EJB支持。
到2000年底为止，共有15家厂商能够提供完整的J2EE解决方案，其中9家（包括Sun本身）实现了“J2EE兼容”，他们中间包括了日后这个领域的 主要竞争者。毫无疑问，这是一次非常残酷的行业洗牌，但留在场内的厂商也相应地形成了推动J2EE发展的主体力量。
上面说过，在它的孵化阶段，Sun的J2EE团队主管是女强人Mala Chandra，她本人虽不是工程师出身，但对技术有着很强的感知能力和想象力；J2EE一出台就能够为人们提供一幅完整、直观而不失深邃的图景，此中当 然有Chandra本人的大量贡献。
在她直接领导下工作的几位工程师，也都是Sun内部非常杰出的人才。无论是制定了JDBC、JMS等规范的Mark Hapner、JavaMail的设计者Bill Shannon，还是EJB的主要设计者Vlada Matena，后来都是业界一言九鼎的技术领袖。
这个班子的合作时间并不太长：2000年左右的那个时期正是IT界创业的黄金年月，Chandra很快就和Sun公司Java部门的总裁（也是创造 Java的功臣之一）Alan Baratz一起，到一家刚起步的Email中间件公司Zaplet淘金去了；捷克裔的开发天才Matena也离开Sun开办了自己的公司。留下的两个人 Hapner和Shannon先后担任了J2EE技术的首席设计师。
多年以后，Hapner回忆起J2EE初创的那个时期，深感如今Sun对Java的左右能力已经大不如前：“现在，Java事实上属于整个技术社区，它的 发展有赖全体参与者的推动。”的确，如今Sun已经不太可能重演当年的开拓性功绩，很难再为一个已经成形的领域重绘版图。
但正如上文所说，即使是在1999年，J2EE设计者们面对的也不是一张从未着墨的白纸。他们的设计始终要以各大厂商的现有产品为出发点，这也是天才的设 计师们做出的设计却远非完美的原因之一：与从头设计一门全新的编程语言不同，J2EE规范从一开始就是各方博弈和妥协的产物。
很容易注意到，J2EE与Java社区的决策机制JCP（Java Community Process）是几乎同步产生的。J2EE下属的各种技术规范，包括1.4版之后的J2EE本身，都作为待决规范议案（JSR，Java Specification Request）被纳入了JCP的议程。
这些议案的审议过程很少是一帆风顺的，几乎每一个都要经历18个月以上的拉锯战。在多项技术规范的审议过程中，我们都见到了这样的现象：最初列名审议委员会的某家主要厂商，没能等到该规范通过就已经被收购或倒闭了。
与微软在.NET平台上的乾刚独断相比，J2EE发展中的这个“牛步”特征虽说是审慎和民主的表现，但终归不符合软件演化应有的速度。
J2EE社区中的另一股重要力量，当然是种类极为丰富的开放源代码项目。2002年以来，在J2EE领域的各个层面上，几乎所有主流产品都有来自开源项目的替代方案，在其中很多位置上，开源产品反而是胜过商业产品的首选。
但请别误解，这里的“开源”并不意味着完全的自动自发，J2EE世界中的开源项目也与Linux或PHP世界颇为不同。在很多非常成功的J2EE开源项目 背后，我们都能发现商业机构的推动作用：Apache的Jakarta社区是IBM扶植的结果；实现了开源应用服务器JOnAS的ObjectWeb，则 是许多法国IT厂商（包括若干政府部门）合资支持的一个联盟组织……这些有商业背景的开源项目资金雄厚，人员齐整；更重要的是，从投资者到开发者，参与这 些项目的很多人都体现了软件工业中难得的非功利心态，因而最终推出的产品质量甚至高于同类型的商业软件。在主流厂商之外，它们是支撑J2EE大厦存在的一 组基石。
另一方面，不少开发者也间接地通过自己的开源产品获得了可观的盈利。这些人大多以免费的开源产品为依托，以收费方式提供附加的咨询、方案实施以及技术支持 服务。Marc Fleury，开源应用服务器的JBoss创始人，不无矛盾地把自己倡导的这种商业模式称为“职业开源开发”。
无论叫它什么，高端产品的开源化/免费化运动注定要在J2EE产业的发展过程中制造显著的后果。“JBoss的行径恶化了J2EE的商业环境，”这是 McNealy先生2002年的著名论断。他的推理过程如下：只有做好商业推广，J2EE产品才能最终击溃邪恶的.NET平台；但开源服务器会降低主流厂 商的销售利润；销售利润越低，用于商业推广的预算就越少；因此，整个J2EE阵营都将受损于JBoss。
但在狂热的开源运动fdhlg看来，以上论证的大前提就是可疑的。“难道只有会做广告的软件才是好软件？MySQL有过多少广告预算”争论的双方都认为对手误 解了软件商业模型的实质。究竟谁才掌握了这里的真理呢？也许只有根据J2EE的未来——也就是它的目标和终点（Telos）——才能做出最终的裁决。
技术的离心力
考 察事物的演化，通常有两种对立的方法。考古学家（Archaeologist）探究肇始和起源；目的论者（Teleologist）则揭示目的和终点。对 于前者，“开端（希腊语Arche）”从根本上决定了此后的发展，参天大树的繁茂都包含在种子最初的萌芽中；而对于后者，“目的（Telos）”才是事物 的根本和旨归：谁没见过样态完善的树，谁也就没法弄懂种子到底是怎么回事。
在J2EE五年之后，人们只能交替地用这两种目光审视它的演化历程。它的起源与它的目的、“它从何处来”与“它往何处去” 的问题紧密地交织在一起，谁拾起了其中的一个，谁也就要连同另一个一起回答。
今天的J2EE在多大程度上符合它的初衷？回答这个问题并不涉及对J2EE技术成败的评判，而只是要考察一下：它是否还运行在最初开辟的那个空间之中。在 事务处理、对象分布化和Web请求处理这三个方面中，也许J2EE对事务和Web保持了一贯的忠诚。
我们记得Fleury喜欢重复的一个信条:“He who owns the transactional Web owns the Web（谁掌握了带事务处理的Web，谁就掌握了Web）”Web接口是今天大部分J2EE应用暴露的唯一接口；而虽然事务处理的常用方法已经有了很大改 变（借助AOP机制，很多非EJB架构的系统也自如地实现了声明式的事务处理），但对事务的重视当然仍将是J2EE开发中的要素之一。
换言之，在5年的演化中，J2EE发生的最大变化可能就在于它放弃了对“分布式对象模型”的强调。EJB2.0引入的本地接口使得Web层与EJB层可以 运行在同一个Java虚拟机中，从而使Web容器与EJB容器的物理分离部署变成一种昂贵的冗余；J2EE 1.4以后版本支持的Web Services兼容性，使得客户端可以通过粗粒度的Web接口调用远程服务——这两次变化事实上都是在论证“分布式对象架构”的无用性。
人们发现，同一系统的各个分层最好采用细粒度接口调用，并且运行在同一个进程中；之所以划分不同的层次，与其说是为了实现物理上的可扩展性，不如说是设计美学上的考虑。
而对于异质系统之间的调用，则应该尽量选用异步的、粗粒度的服务接口（所以Web Services成为了非常理想的选择）。换句话说，传统上的“分布式对象架构”，现在看来似乎只适合于银行远程支付等要求极为苛刻的应用场景，而绝不是 所有J2EE应用都该考虑的标准方案。
前面描述的离心现象毕竟还遵循了J2EE发展的内在逻辑，说到底，EJB的革新和Web Services的引入更多地是主流厂商倡导的结果。但在近年来，还有一股更强劲的离心潮流在深刻地影响着J2EE的演进，它肇始于上文提到的开源软件运 动。
最初它只在Rickard Oberg的动态代理RMI设计与JBoss服务器的微内核架构中显露过邪恶的一角，但是两三年来，经过多个项目、各种技术杂志/论坛/Blog的折射和 放大，它已经形成了一个名为“轻量级容器架构”的完整解决方案，并暴露出完全取代传统EJB架构的终极野心。
按照这一运动yhm们的说法，J2EE的发展史上只出现过一个错误——不幸的是，这个错误名叫EJB。与EJB提供的重量级架构不同，借助AOP和IoC机 制，轻量级容器能够最大程度地降低代码对于专用接口的依赖性，以简短、轻便、专注、可移植的方式实现业务对象。
从“轻量级容器架构”这个词被发明出来的那一刻起，人们对J2EE远景的考虑就发生了根本性的分裂：Sun和大部分主流厂商更多地关注于“Web Services”和“快速开发工具”这些利润增长点，而一部分离经叛道的独立专家和开发者则认为，如果不把轻量级容器纳入规划，J2EE的发展蓝图就注 定无足称道。
其实，双方争执的关键是传统意义上的“应用服务器”的存亡——如果所有企业级服务都可以通过AOP机制提供给普通Java对象，如果管理业务对象生命周期的可以是一个最微不足道的“微内核”，那么深盔重铠的应用服务器还有什么存在理由？
而如果失去了应用服务器的这个产品类型，那些靠这项销售起家的厂商又将何以自处？正是在这里，两个阵营之间存在着最深刻的利益分歧；而这场争执的结局当然也将决定J2EE（乃至Java企业开发）的最终走向。
或许两年之后，我们将从纷争中胜利者一方的角度重述J2EE的整部历史——或许两年之后的J2EE本身也将随着纷争的解决而成为历史。但让我们换个乐观的 口吻：问世五年，J2EE的历史仍在持续的创生之中；此时善待这树种的人，也必在今后的树荫下获得它的祝福。